I am trying to do a simulation of a pile that is embedded in a soil with multiple layers and I created my mesh in gmsh and I am using 6-noded-triangle elements. I am converting the .msh file into .vtu using the mshtovtu tool. However, when I try to run the model, I get an error saying that the det J is negative.
I have already read all the posts here regarding this issue and I have tried also using the tools ./checkMesh and ./NodeReordering, but even when I reorder the mesh, the error keeps appearing. Is there anything else I am missing? Do I have to change also the vtu files with the boundaries after reordering the mesh?
I also check if there were other elements and used ./checkMesh again after reordering and it seems to be okay (attached picture).
I think the numbering of the higher order nodes at the edge center is wrong. Node no. 3 should be between 0 and 1 etc., see the sketch in MeshLib/Elements/TriRule6.h in the OGS source code (GitLab is irresponsive ATM so I cannot add a link, here).
And if you do node reordering you have to recreate boundary meshes, too, because the mapping to bulk mesh nodes (via bulk_node_ids) might become invalid by node reordering.
Btw.: the wrong triangle from the error message is part of a mesh produced by the NodeReordering tool?
Then there might be a bug in that tool. Could you open a bug report in gitlab and add your input/output meshes?
You are using msh2vtu from OGSTools. Which OGSTools version do you have? Maybe an update to the latest version changes something. There could have been some changes in msh2vtu, but I’m not entirely sure.
In the meantime a workaround could be the following (if you have linear geometries, i.e., no curved surfaces that you want to resolve as precisely as possible):
generate a mesh with 1st order elements with gmsh
convert that to vtu (msh2vtu)
do NodeReordering on all meshes from step 2
convert the meshes from step 3 to 2nd order: createQuadraticMesh
“connect” boundary meshes and the bulk mesh via identifySubdomains for each boundary mesh.
Thank you for your quick response. I am doing the reordering with the NodeReordering tool, but I also have some physical groups generated with the msh2vtu that I am not changing again after the reordering. Do I have to recreate them again? and if so, how can I do that?
Because I saw the ./ExtractBoundary tool, but I don’t know how to have the boundary separated in a way I can apply my boundary conditions (I want to have the top, bottom, left and right boundary as in the picture) and also I have .vtu for the different materials, which I am not changing after the reordering. Is this my problem?
For very simple use cases you can extract the full boundary with ExtractBoundary and then clip it with removeMeshElements. See Mesh Tutorial.
But that’s the opposite of convenient.
msh2vtu outputs boundary meshes, e.g., pile_THM_physical_group_Soil3.vtu. You don’t have to recreate them after mesh reordering.
But you have to update the bulk_node_ids if the bulk mesh is reordered.
That can be done with the identifySubdomains tool, see Identify subdomains in bulk mesh..
E.g., in your case (not tested, but should work): identifySubdomains -m pile_THM_domain.vtu -s 1e-6 -o new_ -- pile_THM_physical_group_Soil3.vtu
That should output a file new_pile_THM_physical_group_Soil3.vtu that you then have to use in the OGS prj file.
But the problematic triangle is in the bulk mesh in your axial symmetric case. So, identifySubdomains is important, but your first problem is in the bulk mesh.
Hi @maripicod,
Has the suggestion from @chleh solved your problem? I am facing a similar one.
Could you let us know what version of Gmsh you are using?
Thank you and best,
Feliks
I realized my problem was that I was not doing the NodeReordering for all the meshes, only for the bulk mesh. I followed your steps and now the simulation runs.
