Meshing strategies

[lurpi]

I am modifying the excavation benchmark, generating a mesh with GMSH like the one depicted here:

, producing a mesh with GMSH and converting it to OGS with the tool GMSH2OGS.

I am wondering what is the best strategy to define the internal holes boundary condition.
I am using the utility ExtractBoundary and then, manually, I filter out in Paraview each one of the circle … however it is quite time consuming.
Is there a way to define the different boundaries Id in GMSH, so then the routine ExtractBoundary provides each boundary separated? any ideas?

[dmitri.naumov]

To my knowledge, there is no OGS tool currently, which could extract boundaries automatically.

I could imagine, that gmsh to vtk converter could be extended to generate the boundary meshes as there is some information from gmsh on physical entities/material ids.

I’d use paraview for that simple mesh.

[lurpi]

Thanks for your answer, defining the future polylines in GMSH as Physical Curves makes easier to prepare the geometry .gml file.

I prepared a Python script to prepare the gml file from GMSH mesh, I will share it here in the next days.
I know that extracting nodes/polylines/surfaces directly from Paraview is more robust, but sometimes it is easier to have a fixed geometry .gml and changing the mesh (for example for mesh convergence tests), trusting the node search capabilities of OGS.

[dmitri.naumov]

A script with such functionality would be cool. I can think of few people who might use it.

Be careful with node searching. I recommend to use the constructMeshesFromGeometry tool to visually verify the results.

[lurpi]

Here attached the python script and an application example (both poorly written, quick&dirty, .gmsh-gml_ogs6.zip.zip the python script comes with no guarantee whatsoever)
The file gmsh_coarse.geo provides the input for GMSH, to build a rectangle with two holes, with the following physical groups defined:

• 3 physical surfaces: the rectangle minus the 2 holes, the hole on the left and the hoel on the right
• 5 physical curves: the 4 borders of the rectangle plus 2 curves defining the circle boundary of each holes.

The mesh generated with GMSH must be saved as GMSH v.2, as always (for example as gmsh.msh, like here )

The script msh2gml.py will then prepare the geometry mesh.gml starting from the gmsh.msh file (Have a look at the Note at the bottom of this message).

Then the mesh is prepared with various iterations of manual editing of the gmsh.msh to remove the holes material, NodeReordering , Paraview to add PointData and CellData, etcetc…

Note: the gml file generated this way almost always produces a segmentation fault error in OGS6 (serial, Singularity container).
For some reasons I don’t understand, manually adding a point (for example, a point id=“236” x=…) before the first point id output by the script makes OGS6 happy.
An example of this behavior can be seen in the simle example attached ( seg_fault.zip (25.7 KB) ) simply by using either geometry_1.gml (ogs6 crashing) or geometry_2.gml (random point added, not used in any polylines, but ogs6 is happy).

[thomas.fischer]

I think OGS6 expects that the point IDs in the gml file are zero-based numbered. In the file geometry_1.gml I decreased the point ids and changed also the IDs referencing the points in the polyline. Then the file is loaded without an error message.

[lurpi]

Thanks!

Related question (I cannot test it, I have no access to my machine now): do the point IDs need to be in order?
From what I understand, even if I had my points ID defined, then in the polylines it is not the IDs that are read, but only the position of the nodes. In my example the SegFault was coming only because the polyline was asking for the node 114, which was missing in the nodes list because I had only 113 nodes, numbered 1-114 … since no polylines was calling the node 0, I was then ok with having an arbitrary node at the beginning.

Anyhow, It would be good to have the .gml specifications written here (indexing, ID must be number/string and when it is used etcetc):
https://www.opengeosys.org/docs/tools/getting-started/first_steps/

[joergbuchwald]

Yes, it is a good idea to put it there.
Especially because our GML file format has nothing to do with the Geography Markup Language, which might be also confusing for some people and there is no external software that is able to write GML files. The specifications of the GML file are somehow given in doxygen.
E.g, https://doxygen.opengeosys.org/d3/d7f/ogs_file_attr__gml__points__point__id.html
There, it is written that the ID is of type size std::size_t. However, I think, we cannot expect from every user to know what it means.