I’m having some issues running a project file. I’m essentially running the simple square benchmark file, ‘Mechanics/Linear/square_1e0.prj’, except I’m using a geometry and mesh I’ve made from GMSH.
When I run the file I get teh following error: det J = -15013 is negative for element 0.
error: Please check the node numbering of the element. at NaturalCoordinatesMapping.cpp, line 115.
I suspect that there is an issue with my GMSH set up.
Thanks,
Eric
Hi,
did you check the mesh quality with GMSH or Paraview?
However, I had a similar problem with a curved mesh created with GMSH.
Both, GMSH and Paraview tell me that the mesh quality is fine and the jacobian is always greater than zero. But OGS tells me, that it’s negative:
error: det J = -5.82955e-15 is negative for element 0.
error: Please check the node numbering of the element. at NaturalCoordinatesMapping.cpp, line 115
There the problem was that there were additional boundary elements in the vtu file.
Volume meshes should only contain volume elements, whereas boundary meshes should only contain boundary elements (dim=d-1). The unnecessary elements can be removed using the removeMeshElements tool. (The related types to specify are given in ogs/MeshLib/MeshEnums.cpp at master · ufz/ogs · GitHub). A negative Jabobian that high sounds more like a wrong order. You may also try the NodeReordering tool.
my typical set looks somehow like this
NodeReordering.exe -m 1 V1_SubsurfaceMesh.vtu V2_SubsurfaceMesh.vtu
identifySubdomains.exe -m V2_SubsurfaceMesh.vtu -s 1 -o BC_ -- RiverLineNetworkMapped.vtu
Finding the correct number for -s is sometimes tricky as well.
Isn’t -s the search length? So it should be really small, like \approx 1.0e-10 or even lower depending on your spatial scales and element sizes, no?
Occasionally I have the same problem in HM with some meshes from GMSH. A solution I found for me is to look at which Plane Surface the Element belongs to. Then I have to reverse the order of the Curve Loop of this Plane Surface: Curve Loop(1) = {1, 2, 3, 4}; → Curve Loop(1) = {4, 3, 2, 1};
If OGS then complains about another element with negative det J, just repeat the procedure.
This solves the problem for me at least.
Yes it is the search length.
In my example (from a regional model) the mesh is large and element edge lengths range from 200m - 2000m . The method identifysubdomain didn’t work with s smaller than 1. It seems that s must fit somehow to your model.