layout shape migration

Hi Stu

 You are probably running out of memory by trying to process 52000 shapes in a single list. Process them one lpp at a time and let the garbage collection take care of freeing memory:

lpps = cvId~>lpps
foreach( lpp lpps
  cond(
    ( lpp~>layerName == "OD" && lpp~>purpose == "drawing"
        newLayer = "NWELL"
        newPurpose = "drawing"
    )
    .... Put your layer/purpose mapping here
  )

  foreach( shape lpps~>shapes
    shape~>layerName = newLayer
    shape~>purpose = newPurpose
  )

)

Ted (Signature not part of the code)

Stu,

Not sure - 52000 should be simple to handle. I can't really see why you're doing all those nth() calls - surely it would be easier to do:

cond(
  (shape_item~>layerName=="VTLN" && shape_item~>purpose=="drawing"
    shape_item~>layerName="OD" ...

That would cut down the garbage created. But I doubt that's the problem.

It would also be more efficient to do:

shapeTable=makeTable('shapeTable nil)
foreach(lpp cv~>lpps
  shapeTable[list(lpp~>layerName lpp~>purpose)]=lpp~>shapes
)
foreach(lpp shapeTable
  cond(
    (car(lpp)=="VTLN" && cadr(lpp)=="drawing"
      shapeTable[lpp]~>layerName="OD"
    )
    (car(lpp)=="OD" && cadr(lpp)=="drawing"
      shapeTable[lpp]~>layerName="NWELL"
    )
 )
)
shapeTable=nil

The reason for storing it all in a table first is because if you update the lpps as you go along, you'll be modifying lpps that you've not got to yet - so if I store the list of the original shapes for each layer purpose pair, they won't clobber each other. Also directly updating the layerName or purpose of a list of shapes in one go should be more efficient.

Regards,

Andrew.

 I forgot, this processing will move shapes to the new lpps and then if you process the new lpps you will move ALL of those shapes to the even newer lpps. The best way to do this is to make sure you are processing the lpps in an order where the shapes are always moved to an open layer. That requires sorting the lpp list and you may have to move the first lpp shapes to a temporary layer then move them again to the final layer after everything is moved.

BE SURE YOU MAKE A BACKUP BEFORE RUNNING THE CODE!!!! 

I'm surprised you are running out of memory, since 52,000 doesn't seem that huge, but I do have several suggestions for performance improvement and simplicity of code.

If your conditional is quite large (I'm assuming it is filled with many layer mappings), then you are making too many accesses to shape_item~>lpp. For example, if there are 20 checks in your conditional, they you are accessing this attribute 40 times if only the last item in the conditional matches. Generally speaking, try using car instead of nth(0 and cadr instead of nth(1. However, in this case I wouldn't do either. First of all, if you are not changing the purpose, then just check the layer name and save some trouble.

(shape_item~>layerName == "VTLN" 
  shape_item~>layerName = "OD"
)

Again, you don't want to access that attribute more time than necessary, so try a case statement:

case(shape_item~>layerName
  ("VTLN" 
    shape_item~>layerName = "OD")
  ("OD"
    shape_item~>layerName = "NWELL")
)

You could also loop through the cellview lpps attribute and then process the shapes one lpp at a time. Looks like Ted posted before me, so check out his solution.

Derek

 Using tables is pretty effecient, Andrew.

Ted, our posts crossed - that's why I'm doing the table approach - to avoid them clobbering each other as you go along.

Looks as if you, Derek and I have all come up with the same answer - so there would seem a strong likelihood that it's the right way to solve it!

Andrew.

Hi guys, thanks for the advice so far. I agree my skill code is inefficent & i'll tidy it up. I have heard from one guy who says he has known a list of 8 million elements.

I tried an experiment putting a dbSave in my foreach so in effect it would save EVERY time it went round the loop, very inefficient i know. However, it did run (for at least 8 hours!!!) BUT it did not crash. Something interesting happened with the MPP's (multi-part path) , the base layer got changed but the subparts (e.g contacts) did not. I guess this ties in with when you "q" the properties of an MPP, you as the shapes other than the base layer are sub-parts that cannot be directly modified. 

So thinking out loud the options could be:

1) subpart shapes are editable in a mpp, i just need to allow this somehow

2) shapes (subparts) are not directly editable in  a mpp, therefore i could select all MPP's, get their required data ( co-ords, layers ..etc) then delete the mpp, do my layer translation, then re-draw the new mpp ( i have the skill for the new mpp's). I see some similar SR's which i need to look into.

3) flatten the mpp's, highly undesirable 

I'm guessing that in my test run that the routine is attempting to edit shapes which are not editable and thats an issue.

Thanks

Stu 

Hi Stu,

since an MPP is a rod object, you can obtain the rod object id and then the subaprts are all visible from there - you should be able to alter them through SKILL in a similar fashion to editing them using the Edit Path Properties form -> "Subparts" form.  There are bound to be some solutions that discuss modifying an MPP's subparts.

Hope this helps,

Lawrence.

Stu,

You can't directly edit the shapes in the subparts (you'd have to flatten it, or reconstruct it), but you can (in IC615) use rodGetSubPart(), rodDeleteSubPart() and rodAddSubPart().

Andrew.