Tue, 01/24/2012 - 03:40
Hello,
I use SALOME GEOM module (stand-alone version) to design a paramateric geometry modeler for electromagnetic devices (microwave waveguide components).
Consider that some complex structure is built employing GEOM's ops (e.g. booleans, fillets, etc). Is there any possibility to attach a "hook" to a given face of the aforementioned structure? I tried to store the face as the corresponding sub-shape index provided by GEOM's sub-shape ops. The problem shows when the topology of the shape changes as a consequence of altering the value of some parameter used along the shape construction. Then the stored sub-shape index may point to a completely different sub-shape, therefore the "hook" is lost. I tried the TNaming_* package without success.
Thanks in advance,
Vali
Tue, 01/24/2012 - 12:12
Hello Vali,
This is a known problem (to me at least) of GEOM module (and probably of the underlying occ engine). I had several failures of the parametricity in our program, because of the situation you describe. The failure, in general, does not show up when using booleans, fillets, chamfers etc. , but shows up when using more advanced features (topologically at least) like thicksolids or offsets. I think the original design intend for occ was to provide persistency of the generated topology indexes (since this is the case with most operations) except the mentioned cases and others. Is it a bug or a feature ? not really sure ... Like you did, I thought of using the naming features of occ in order to solve this case, but time and schedules did not permit it so far (this would lead to a big refactoring in GEOM code).As I see it at the moment, the solution lies within TNaming, so i suggest to try again this direction for a solution.For sure, occ support would be a help for your case, since they can provide assistance with TNaming, in case you need help with it.
Fotis
Tue, 01/24/2012 - 12:13
btw, can you pinpoint the exact operation where the indexes are lost ?
Fotis
Tue, 01/24/2012 - 15:57
Hi Fotis,
thanks for your replies.
I'm not sure where the indexes are lost. I've just observed this behaviour for some structures (more or less complex) when I modified some variable. It seems to be more robust if one uses the indexing given by TopExp::MapShapes(shape, shapeType, subShapeMap) instead of TopExp::MapShapes(shape, subShapeMap).
I'll let you know if I find any robust solution although the TNaming documentation of OCC is very brief.
Cheers,
Vali
Tue, 01/24/2012 - 19:06
Hi Fotis,
just to be more explicit: I select some face of a parametrized structure. This face is then used to define a (waveguide) port. I store the face as its subshape index (using GEOM's sub-shape index extraction ops). Now, I change some parameter and recompute the whole document. The problem is that the stored face index may not point to the same face. Moreover, sometimes it points to a subshpae of different topological type (e.g. edge). Of course, my port is then lost.
Therefore I do not necessary need to follow the evolution of some subshape but rather to set a "hook" in a subshape (face) of some constructed structure. This "hook" should be invariant to
structure recomputation due to parameter change.
I tried TNaming*, thus far without success.
I hope this sheds a little more light.
Cheers,
Vali
Wed, 01/25/2012 - 14:15
Dear Valeriu,
If you are going to use a parametric approach it is necessary to use a)history of algorithm (accessible via API: Modified(), Generated(), Deleted()), b)TNaming_Selector (to keep Naming data structure) and c)solver to regenerated the specified entity. Some elements you can find in DNaming package (see DNaming_ModelingCommands).
Also Advanced OCAFSample (distributed for a fee at the moment) may be useful in your case if you want to have fully consistent example. You may contact us (in case of need) via the Contact Form http://www.opencascade.org/about/contacts/.
Regards