Verification tests

[dmay23]

Casper, Please find attached the toml, lua and mesh files (.msh, .geo) I used for the tests I did. For testing i used the static executable.

./app/static cosine.toml --output testA

Verifying the result can be done by opening the generated vtu file and plotting the values for mu.

I note that you have defined the region index as a float. Hence in the Lua files I use floor() to map the floats to the current region (integer) index. This is not ideal. It would be better to just have an integer coming into the Lua callback.

Archive_2.zip

I found a mistake in the mesh definition I used with the previous zip file. Please use the -diri.{geo, msh} files.

[dmay23]

@cpranger It is great to parse all the physical tags. Nice one!

However, I would strongly caution against parsing and exposing the the elementary tag from GMSH (etag).

The reason for this is that the elementary tags are not unique. These numbers are autogenerated by GMSH are essentially a function of the order you create objects in the input file. For instance, if you edit the .geo file these numbers can and often do change when you re-load the .geo file. There the elementary tag generation may not even be consistent across GMSH versions, e.g. the same .geo file run through different GMSH versions can result in different values for the elementary tags. Hence, defining the behavior of a physical model in tandem (e,g. boundary condition specification, material properties) using elementary tags is super fragile, error prone and not very portable (or reproducible).

Given this issue, I would suggest not to expose the elementary tags to the end user.

[cpranger]

@dmay23 -- Thanks for having a look Dave!

My understanding was that the physical tags correspond to physical objects declared in the GMSH .geo file, whereas elementary tags correspond to the geometrical primitives that constitute the physical objects. So e.g. in the example .geo file excerpt

Curve Loop(1) = {1, 2, 3, 4};
Plane Surface(2) = {1};
Physical Surface(3) = {2};

2 would be the elementary tag and 3 would be the physical tag of the elements in the mesh. This seems to be the case when looking at some generated .msh files by eye, and is also the explanation given in the GMSH documentation (https://gmsh.info/doc/texinfo/gmsh.html, search for 'elementary'). That being said, it is nowhere affirmed that this principle is guaranteed, and you might be right.

My idea was to reserve the physical tags for distinguishing sets of equations to be solved, as in the case of boundary conditions, and use the remaining elementary tags to define groups with different material properties, be that on the boundary or in the domain. Because the elementary tags would be incredibly useful given that on the boundaries the physical tags are already reserved, it would be a shame to toss this functionality. Are you 100% sure that the elementary tags are unreliable?

[dmay23]

@dmay23 -- Thanks for having a look Dave!

My understanding was that the physical tags correspond to physical objects declared in the GMSH .geo file, whereas elementary tags correspond to the geometrical primitives that constitute the physical objects. So e.g. in the example .geo file excerpt

Curve Loop(1) = {1, 2, 3, 4};
Plane Surface(2) = {1};
Physical Surface(3) = {2};

Yes and no. The elementary tags are identifiers for any geometric primitive, but the tag value does not impart any info about the type of the geometric primitive. The elementary tags indicate a unique identifier for given class / type of geometric primitive. For example, you can have an elementary tag for a point with the label 0, and an elementary tag for a line with a label 0. But you cannot have two points assigned the same elementary tag of 0.

2 would be the elementary tag and 3 would be the physical tag of the elements in the mesh. This seems to be the case when looking at some generated .msh files by eye, and is also the explanation given in the GMSH documentation (https://gmsh.info/doc/texinfo/gmsh.html, search for 'elementary'). That being said, it is nowhere affirmed that this principle is guaranteed, and you might be right.

When building simple geometries, elementary tags are assigned by the user. However in more complicated (and relevant to building models with faults) the elementary tags are not explicitly assigned by the user. For instance, suppose you build two surfaces which intersect. To build a mesh which conforms to these two interfaces, you would call BooleanFragments(). This method takes your two surfaces, and determines the intersection between them and returns an array of objects defining new surfaces, new lines and new points associated with the intersection. These returned objects are not assigned elementary tags by the user, they are assigned by GMSH. In fact, the user doesn't usually even care what such tags are - rather for a tandem/seissol model you would simply collect all the returned surfaces and assign them an appropriate physical tag to identify them as a fault.

Whenever you use methods such as BooleanFragments() (or even Box() for that matter), geometric primitives are created and GMSH assigns unique elementary tags. To figure out what these elementary tags are, you have to inspect the geometry in the GMSH GUI and then configure the GUI to display the elementary tags. So is not only tedious, but worse over, the e-tags auto generated are dependent on the order your geometry is defined.

My idea was to reserve the physical tags for distinguishing sets of equations to be solved, as in the case of boundary conditions, and use the remaining elementary tags to define groups with different material properties, be that on the boundary or in the domain. Because the elementary tags would be incredibly useful given that on the boundaries the physical tags are already reserved, it would be a shame to toss this functionality. Are you 100% sure that the elementary tags are unreliable?

Yes.

I can agree that exposing the elementary tags could be quite convenient for an advanced user (or when ones needs to do some hack test or build some very special/unique model), but I don't believe it is good that the Lua files depend on them by default.

If you expose both elementary tags and physical tags in the Lua file you seemingly would also need a way to indicate whether the specification of model boundary conditions (for example) is to made using e-tags or physical tags.

It's probably easier to work through specific use cases to see what works best. As an example, take a case of one fault where you want to use R&S but you want some over stressed patch in some region and possibly different R&S parameters in different sections. Lets assume R&S requires at each point a value for "a", "b", and normal stress \sigma_n Assume the 1D profile along the fault looks like this

 |----- segment 1 ----------| ------ segment 2 ------------ | ------ segment 3 -------- |

In segment 1 we want

• a = a_A
• b = b_A
• \sigma_n = f_A(x,y)

In segment 2 we want

• a = a_A # same as segment 1
• b = b_A # same as segment 1
• \sigma_n = f_A(x,y) + 100

In segment 3 we want

• a = a_A # same as segment 1
• b = b_B
• \sigma_n = f_B(x,y)

The above could readily be defined with three unique physical tags, and a mechanism to define parameters (or methods dependent on space) region-wise for each segment 1, 2, 3 based on the specific physical tag the user selected when defining the .geo file.

Even more generally, it would be fantastic to be able to associated a specific friction law to a given physical tag (however the this is something we should address at a latter point in time).

[AliceGabriel]

Hi @cpranger did you have comments reviewing this PR? Is it still open for a reason? Thanks!