Meshing (or other features) - tool agnostic

[joergfunger]

In the current plate with hole implementation, meshing is done with the same mesher (gmsh) for all tools, resulting in indentical meshes to be compared. This has the advantage that we compare the tools directly and are able to compare even not fully converged meshes. On the other hand, it might be tricky for some tools to use interoperable meshes (e.g. importing a gmsh mesh) - even though I personally think that most tools actually provide an interface. Another case is that certain features are not supported (e.g. triangular elements vs. quad elements). IMO deviations should then not be "hidden" somewhere, but have to be documented. There are two options. Option 1 would be we that we try to add parameter configurations e.g. in the parameter_1.json add a variable element_type = triangular or element_type=quad (or in the parameters of the KG, that is then used to write these parameter files). Then we actually have both cases directly documented, all tools implement either triangles, or quads, or both and the user in the jupyter notebook in the analysis phase can decide if they want triangles, quads, or even want to compare both, but this is then transparent. There might be cases, where this is not possible, and someone has on purpose to deviate from some specifications in the benchmark definition, but still wants to add their results (e.g. someone is using XFEM to describe the mesh rather than meshing the void directly, or using IGA, ...). In those cases, I think we have to make sure that there is some standardized deviation file that explains that and a flag added to the result that this files is not empty. In this case we could have queries that only allow non-deviation ROCrates (standard), or the user can decide which other ROCrates they want to allow (they would read the deviations file and then decide themselves if this is included in the comparison or not). At the end, we do not want to provide a final pass or fail metric, but just show the user how they can visualize the different results, and which results the users are actually interested in is up to them. What do you think @berndflemisch, @Sarbani-Roy, @div-tyg , @srosenbu and @jpthiele.

[srosenbu]

Sure, we can just add "element-type" to the .json. I don't see any disadvantage. Apart from the fact that we should probably start to document what kind of values are allowed in the parameter file, but I assume that this will become part of the benchmark description. Or the parameter files get a json schema that defines what is allowed.

{
    "element-type": "triangle",
    "element-size": {
        "value": 0.00625,
        "unit": "m"
    },
    "element-order": 1,
    "element-degree": 1,
    "quadrature-rule": "gauss",
    "quadrature-degree": 1,
}

I also noticed that Kratos does not even use the parameter "quadrature-rule" and also it can only use isoparametric meshes (element-order=element-degree). So even in our current setup, we could get cases where the tool cannot fulfill the whole parameter file. So I like the Idea of the deviation file. But that would also mean that for each tool, we would need to implement a set of rules about how we want to deviate from the parameter file. For example if we have the following in the parameter file:

{
    "element-order": 2,
    "element-degree": 1,
}

and our tool can only do isoparametric meshes, we would need to decide if we want to make an error in the geometry (reduce element order) or if we improve the degree of the shape functions, or if this is such a weird case that it does not make sense to deviate from the setup because the meaning behind the specific parameters would be lost.

Although for this case the deviation file could simply be a json with the parameters that deviate from the original parameter file.

For more complex cases such as XFEM, what kind of flag would you suggest to put into the deviation file? And how should a user query the results? Are these flags are only for exclusion from the standard case or do we want to be able to querey results that have the same kind of deviation?

[doigl]

Just for clarification as we are actually in the process to model the configuration of a benchmark: In the semantic representation of the benchmark itself, there should be a parameter (in this case "element-type") that have two (or more?) different valid values (in this case "triangle" and "quad"). And in the actual implementation of a benchmark by a tool, the parameter has to be set with the chosen value. The parameter should also be documented, when running the implementation. Right? Or should the parameter only be set in the implementation? Or only in the run?

[joergfunger]

You are right, we need to define for each parameter that we define what the possible values are (e.g. element order = pos. integer) or element_type with quadrilateral or triangle. However, we might have to rethink about the latter one, because it is actually not the element type, but rather the element geometric shape (Viereck oder Dreieck). And we have to think what is happening, when the parameters are not being valid inputs to a tool e.g. a tool does not allow to specify the quadrature rule, but chooses something internally, or the element type is not existing. There are actually two options, one is that only valid parameter sets are computed, and we then assume the prescribed configurations are the one that are actually computed. In this case, no documentation while running is required On the other hand, we could think about documenting all parameters again, i.e. enforcing the user to actually document and (review) the parameters that they have actually used - either in the parameter file, but maybe also in a textual representation when something completely different is done.

[joergfunger]

Regarding @srosenbu’s question: I believe we need a flag that we can query to explicitly indicate whether a configuration is computed as defined in the benchmark definition (or not). This would allow us to exclude all non‑standard setups during verification runs. Alternatively, we could just document all parameters again and in the query check if they are identical with the ones that are in the benchmark definition (in this case we could compute this flag ourselves).
For example, in the case you mention where Kratos only supports isoparametric elements, any configuration where the element order differs from the geometric interpolation (i.e., where the element degree/order of the displacement interpolation is inconsistent) would simply not be computed by Kratos.
Alternatively, Kratos could return a structured response indicating which parts of the parameter configuration are unsupported and what has been used instead. This would allow us to later check why a particular tool did not compute certain parameter combinations. However, we have to make sure that there is the option of an additional text string if the deviations are really outside of what we initially thought (e.g. XFEM)

[srosenbu]

In dolfinx they use triangle and quadrilateral as names for the geometry definition of the mesh https://docs.fenicsproject.org/dolfinx/v0.10.0/python/generated/dolfinx.mesh.html#dolfinx.mesh.CellType

For the geometry definition they refer to the entities as cells and the combination of a cell with shape functions is an element. I would be fine with using cell-type as a parameter name.

[joergfunger]

I agree, maybe cell-topology is even more exact, and with the order of the geometry interpolation we get the cell-type. An alternative might be element shape, but I think that is not accurate.

[jpthiele]

We might also have to think about parameter sections, e.g. material parameters, geometry parameters (if any, some benchmark geometries are fixed after all), and then sections for specific discretization methods.
Currently, every tool is FEM, but thinking about CFD benchmarks, finite difference or finite volume methods don't have an 'element degree'.

[jpthiele]

In dolfinx they use triangle and quadrilateral as names for the geometry definition of the mesh https://docs.fenicsproject.org/dolfinx/v0.10.0/python/generated/dolfinx.mesh.html#dolfinx.mesh.CellType

For the geometry definition they refer to the entities as cells and the combination of a cell with shape functions is an element. I would be fine with using cell-type as a parameter name.

Which matches with the definition of a Ciarlet-Triple (cf. Brenner & Scott) which is a geometric cell, a space of polynomials and a set of degrees of freedom.

[joergfunger]

We might also have to think about parameter sections, e.g. material parameters, geometry parameters (if any, some benchmark geometries are fixed after all), and then sections for specific discretization methods. Currently, every tool is FEM, but thinking about CFD benchmarks, finite difference or finite volume methods don't have an 'element degree'.

I think this is benchmark specific, so not every benchmark should have an element degree. Maybe this is a good thing to be mentioned in particular for @doigl , these parameters are specific to a benchmark problem and might be completely different for a different benchmark. But IMO we have to add some form of general description of the mathematical problem that really specifies in a semantic way what is computed, not only in the textual representation or in the parameters of the benchmark problem (because the parameter with the configurations is actually the ones we want to be able to change and have templates of the tools to allows these automatic changes).