netgen
netgen copied to clipboard
salome patch
this patch allows to generate meshes from faces with internal edges and may have included some other fixes.
example which previously wasn't working:
This happens in Netgen GUI (BRep file provided below):
Here is the OCCT brep:
DBRep_DrawableShape
CASCADE Topology V1, (c) Matra-Datavision
Locations 0
Curve2ds 5
1 -5 0 0 1
1 0 -5 1 0
1 5 0 0 1
1 0 5 1 0
1 -10 0 1 0
Curves 5
1 -5 0 0 -0 1 0
1 0 -5 0 1 0 -0
1 5 0 0 -0 1 0
1 0 5 0 1 0 -0
1 -10 0 0 1 0 0
Polygon3D 0
PolygonOnTriangulations 6
2 1 2
p 0.0400000008 1 -5 0
2 1 3
p 0.0400000008 1 -5 5
2 2 4
p 0.0400000008 1 0 5
2 3 5
p 0.0400000008 1 -5 5
2 4 5
p 0.0400000008 1 -5 5
2 2 6
p 0.0400000008 1 5 10
Surfaces 1
1 0 0 0 0 0 1 1 0 -0 -0 1 0
Triangulations 1
6 5 1 0
-5 -5 0 -5 0 0 5 -5 0 -5 5 0 5 5 0 0 0 0 -5 -5 -5 0 5 -5 -5 5 5 5 0 0 6 2 1 6 1 3 6 4 2 5 6 3 5 4 6
TShapes 16
Ve
1e-07
-5 -5 0
0 0
0101101
*
Ve
1e-07
-5 0 0
0 0
0101101
*
Ed
1e-07 1 1 0
1 1 0 -5 0
2 1 1 0 -5 0
6 1 1 0
0
0101000
+16 0 -15 0 *
Ve
1e-07
5 -5 0
0 0
0101101
*
Ed
1e-07 1 1 0
1 2 0 -5 5
2 2 1 0 -5 5
6 2 1 0
0
0101000
+16 0 -13 0 *
Ve
1e-07
-5 5 0
0 0
0101101
*
Ed
1e-07 1 1 0
1 1 0 0 5
2 1 1 0 0 5
6 3 1 0
0
0101000
+15 0 -11 0 *
Ve
1e-07
5 5 0
0 0
0101101
*
Ed
1e-07 1 1 0
1 3 0 -5 5
2 3 1 0 -5 5
6 4 1 0
0
0101000
+13 0 -9 0 *
Ed
1e-07 1 1 0
1 4 0 -5 5
2 4 1 0 -5 5
6 5 1 0
0
0101000
+11 0 -9 0 *
Wi
0101100
-14 0 +12 0 -10 0 +8 0 -7 0 *
Ve
1e-07
0 0 0
0 0
0101101
*
Ed
1e-07 1 1 0
1 5 0 5 10
2 5 1 0 5 10
6 6 1 0
0
0101000
+15 0 -5 0 *
Wi
0101000
i4 0 *
Fa
0 1e-07 1 0
2 1
0101000
+6 0 +3 0 *
Co
1100000
+2 0 *
+1 0
Netgen needs a closed boundary. If there is an edge added to the geometry that goes outwards again I believe Netgen is able to mesh the internal edge. But tbh I have not much clue about how the "standard" for internal edges in brep format is... Do we really need to support this?
@trelau what do you think?
if i understand correctly, not supporting the meshing of internal edges on faces would be a pretty major regression, imo. this would prevent me from using newer netgen versions. i use netgen mostly for quad-dominated surface meshing, and i frequently encounter the case as shown in the example.
here is a sample aircraft from a project:
if you zoom in to the circled region:
you can see where the adjacent structure trims each other, generating an internal edge on the face that will need to be enforced in the resulting mesh and also share the same nodes between the two faces.
Internal edges work, but the boundary around each face has to be closed. So if the edge is added in both directions to the boundary of the surface then meshing should work fine. In the example you have given in the start, the edge is only added in one direction, so the boundary around the face is not closed. From what I have seen in step geometries, typically the edge around each face is closed and so netgen manages to build a mesh. But if you say it is typical that boundaries are not closed when internal edges are given, then we will consider adding this.
If the conflicting files can be addressed, will this be considered for a timely merge? It's causing issues in downstream projects. There was a patch applied for 6.2.1804 in netgen-feedstock but i guess that was removed starting in 1808 and now this issue is showing up again.
In general, are PR's on github the best way to contribute to the project?
The best way is to provide easy to reproduce test cases and minimal examples for bugs and misbehaviours. The problem (with complex pull request) is that the dev team is quite small and we want to keep it that way so that maintain a good overview and can be flexible in new development (specially for ngsolve). If you can provide us with a test suite for smesh we can add it to our internal test runners and we can provide you with patches if api changes happen. Code parts that we do not know where they come from are problematic as well, as currently we hold the IP to Netgen within a small group of individuals/organizations. One advantage of using the newest version of netgen is that we parallelized some of the meshing (optimization) parts of netgen - you should be able to leverage that as well using the netgen TaskManager. See for example here https://ngsolve.org/news/new-features/52-netgen-parallelization
I guess setting up a test suite that can grow over time may be worth it.
thanks for info @ChrLackner. those parallel optimizations look great.
i would be happy to contribute to a basic test suite . i started a small one here in smesh (only 2 so far for netgen). there is one for a simple box with a global edge length (which works), and then the one for enforcing a local edge length here. This one fails in versions beyond 1804, but i looks like it's because the salome patch was removed in the netgen-feedstock for conda-forge.
I see two basic tests that would be great to capture (for smesh purposes):
- Meshing of internal edges as shown in this issue above. Perhaps this can be added to your test suite just importing the .brep and meshing it?
- Mesh of a simple shape (e.g., a box), but with one of the edges having a different edge length or an enforced set of nodes/edges. This might be an enhancement on the smesh side of things, so I'm not sure that is something netgen supports natively. if not, then at least getting a test in place with the desired behavior can help check any enhancements along the way.
let me know how i can help. if nothing else, i'll try and resolve the conflicts for this PR for reference.
Different mesh size on one edge should be no problem, using the RestrictH function for points on the edge. I started rewriting some of the base geometry code in netgen to use with external geo kernels. Goal is to slowly move the occ kernel to a cleaner interface and allow stuff like that. A lot of the stuff in the smesh interface could be done easier then. But I do not know how much time I'll have for this, so it might take a while. Test cases for internal edges and predefined surface meshes,... would be nice for that then we can apply changes easier.
Using predefined edge meshes should work now with the latest netgen master as well. I tested your example and it works.
I think the internal edges should work as well as long as the edge is defined twice (the face needs a closed boundary). I saw something in the smesh code to gurantee that...
Large parts of this merge request are obsolete, e.g. the Handle
changes for current OCCT.
Salome/SMESH has finally updated their netgen version to 6.2.x (from 5.3), and they provide a newer patch for the remaining required features: https://git.salome-platform.org/gitweb/?p=plugins/netgenplugin.git;a=blob;f=src/NETGEN/netgen62ForSalome.patch;h=20c187b9755e250cfdfbbe7fc623895830ca74f4;hb=HEAD
Unfortunately, the patch still lacks any description what it does ...
@trelau Did you manage to mesh this with netgen+patch or salome smesh, and did you use any specific parameters? I've applied the patch to netgen 6.2.1804 but haven't had any luck meshing your test case.
I just used a test script based on nglib as:
mp.uselocalh = 1;
mp.elementsperedge = 2.0;
mp.elementspercurve = 21.0;
mp.maxh = 0.2;
mp.grading = 0.2;
mp.closeedgeenable = 0;
mp.closeedgefact = 1.0;
mp.optsurfmeshenable = 1;
Ng_OCC_SetLocalMeshSize(occ_geom, occ_mesh, &mp);
ng_res = Ng_OCC_GenerateEdgeMesh(occ_geom, occ_mesh, &mp);
ng_res = Ng_OCC_GenerateSurfaceMesh(occ_geom, occ_mesh, &mp);
ng_res = Ng_GenerateVolumeMesh(occ_mesh, &mp);
but got UVbounds exceeded, and never ending loop on the surface.
UV bounds exceeded
retry Surface 1
load internal triangle rules
Face 1 / 1 (plane space projection)
faces = 294 trials = 1000 elements = 1433 els/sec = 22891.4
faces = 355 trials = 2000 elements = 2250 els/sec = 17985.6
faces = 413 trials = 3000 elements = 2786 els/sec = 13708.9
faces = 435 trials = 4000 elements = 3441 ...
This happens in Netgen GUI (BRep file provided below):
Here is the OCCT brep: