Too large triangles due to optimization

Hello

I faced an issue the netgen creates triangles of size 3 times larger than maxh. This is due to optimization, as with optimization switched off triangles size is OK. In the image bellow a triangle with red edge has max edge length 8.89 while maxh is 3. I found that this issue appeared with commit https://github.com/NGSolve/netgen/commit/17dfd4560 which greatly refactors improve2.cpp I attach the problematic geometry in BREP format.Geometry.zip Used netgen parameters are as in the next image.

Your help is much appreciated.

Thanks in advance

Hi, thanks for reporting. I think this is fixed in the current master now. Can you confirm? Best

Hi, thanks for your answer. I tried the master. Result is that map::at throws at libsrc/occ/occgenmesh.cpp: line 500 I call netgen from SALOME. Probably some porting is required as occ package significantly changes as I see.

Hi, yes. We are currenly actively working on opencascade bindings for our python interface which lead to some changes and improvements in the binding code. The map where you get the issue is built in the BuildFMap function. Is this function called before you call the OCCSetMeshsize routine? It is for example called in the OCCGeometry constructor with a TopoDS_Shape in occgeom.cpp:153. I cannot find the source code for Salome any more. Did it change hosting platform?

Thank you for your clarification. I'll try to take it into account. SALOME sources are still at https://git.salome-platform.org/gitweb/

In SALOME we can't call BuildFMap() because some sub-shapes may be pre-meshed by other mesher and hence those sub-shapes must not be added to emap and fmap. So we fill those maps "manually".

Hm. Then you would now also need to create the OCCEdge, OCCFace,... objects and fill the edge_map,... done at the end of the BuildFMap function in occgeom.cpp:1110 downwards. These objects are now mainly needed for anisotropic and periodic meshes (I think you have separate functionality for things like this), so it might also work already again if you comment out lines 498-515 in occgenmesh.cpp. If this works then we can do these lines just when the lists are filled.

These lines just prevent restricting the mesh size on segments that are marked as "close" -> Will be meshed with anisotropic prism mesh. There might be other places where this edge map is used, but I don't think for meshing relevant stuff, so it should work with just removing these parts.

I already tried to comment out those lines. The exception disappeared but the mesh remained empty. Here I stopped trying.

I've cross-updated netgen and SALOME to work together again. I have it all working, master with master, but have been thinking hard about how to break up and present the patches.

Summary: OCC refactoring in commit 16b88e8e67a0e52d4de3e17b43343d0a09a3c790 has made it much harder for SALOME to work properly with netgen geometries moving forward, as there's now a fundamental representational mismatch between the two.

Netgen determines high-level shape uniqueness according to the equivalent of TopoDS_Shape::IsPartner().
Salome determines high-level shape uniqueness according to the equivalent of TopoDS_Shape::IsSame().

So, where Salome (and other packages) routinely have TopDS_Shapes that reuse TopoDS_TShapes, but placing them at different locations, that's no longer possible in Netgen. And because Salome et. al. track both Shape and TShape uniqueness, doing a deep-copy of 'duplicate' shapes is not an option either; that breaks the other side.

Previously, the fmap/emap were effectively authoritative shape lists for OCCGeometry faces and edges. You could (and still can) store unique TopoDS_Shape()s with shared TShapes. However the new changes mean that if you do, you'll crash netgen. And even if you fix the crash, it still won't work. All the 'duplicate' faces will simply be missing.

It seems to me the functionality regression is on the netgen side, so I've gone about changing the new OCC code since Novemeber to use TopoDS_Shape::HashCode() rather than hashing against TShapes, and this works as hoped.

(One other noticeable change with the new code: Each edge now gets one set of mesh segments, as opposed to a set for each face sharing the edge. Default SALOME behavior thinks segments/mesh nodes are missing. Setting the IsAlwaysComputed flag on all the edges will avoid the misplaced error check).

It seems to me the functionality regression is on the netgen side, so I've gone about changing the new OCC code since Novemeber to use TopoDS_Shape::HashCode() rather than hashing against TShapes, and this works as hoped.

We were discussing that recently, I think our way is the wrong one.

Would you be interested in discussing this in a call? You can write me at [email protected] and we can schedule some time.

Sure, writing now.

I've now had time to change everything from using TShape to HashCode. This should be resolved now, if there is something still not working please open another issue.

Oops, replied in a new message before seeing this. Letting you know in case a spam filter eats it by accident.

Monty

On Mon, Apr 4, 2022 at 2:05 AM Christopher Lackner @.***> wrote:

It seems to me the functionality regression is on the netgen side, so I've gone about changing the new OCC code since Novemeber to use TopoDS_Shape::HashCode() rather than hashing against TShapes, and this works as hoped.

We were discussing that recently, I think our way is the wrong one.

Would you be interested in discussing this in a call? You can write me at @.*** and we can schedule some time.

— Reply to this email directly, view it on GitHub https://github.com/NGSolve/netgen/issues/111#issuecomment-1087149885, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWMHEAAVF27XCRQRN2ZP2LVDKBAVANCNFSM5OXWQK4Q . You are receiving this because you commented.Message ID: @.***>