Read spatial varying material parameters

[gilrrei]

The new updates in input introduce loads of flexibility. However, one key aspect that is missing is reading spatially varying parameters. Some examples:

• Spatially varying Youngs modulus
• Spatially varying thermal coefficients
• Spatially varying source terms

Edit: an example from a QUEENS presentation last year:

For our research, they are super important. The current workflow that QUEENS follows is to create a new material for each element with varying parameters. This is tedious, and to me, feels like QUEENS is creating an interface that is missing in 4C. Also, a downside of this approach is the increased file sizes due to the redundant information. The problem gets amplified with nested materials. If I understood correctly, in the past @lauraengelhardt ran into memory problems with such an approach and therefore reading in material parameters from csv was introduced. However, I didn't fully understand how this works. Could somebody provide an example :)

Since we are now able to read in binary meshes (@sebproell 🚀) I was wondering if we could introduce the spatial variable parameters directly into the mesh.

The QUEENS community is particularly interested in this, even though this is not only related to probabilistic analyses. We would appreciate some cross-project communication here, since this affects how we improve/develop our QUEENS-4C interface, see the issue here

[amgebauer]

Could somebody provide an example :)

The material needs to be prepared for this, so it is not generally available for all materials and paramters. You might have a look at tests/input_files/mat_muscle_combo_hex_act_map_interpolation.dat, specifically at the MAPFILE

Since we are now able to read in binary meshes (@sebproell 🚀) I was wondering if we could introduce the spatial variable parameters directly into the mesh.

We need this functionality to read in fiber orientations from the mesh directly 👍

[gilrrei]

Thanks for the input 😉

If I understood correctly, in order to make this usable, I need to first modify 4C for each material I want to change, right?
Afterwards, how do I know how to create the pattern file? Do we use a syntax standard, or is it home-made?

The input-elephant in the room: Will/can this be generalized and rolled out to all materials? I guess there must be a reason if this isn't done yet.

[amgebauer]

I think it is our invention, but @lauraengelhardt is the expert.

I think the way to go is to read spatially inhomogeneous parameters from the mesh file directly as you suggested. I think there are some problems to solve before this can be made generally available.

[lauraengelhardt]

I need to first modify 4C for each material I want to change, right?

Correct. You need to tell your material which parameter should be retrieved from which pattern file (it’s not a csv file strictly speaking as we rely on our custom pattern syntax) and how the content should be parsed.
You need to implement this yourself for each material. There is no such “automatic” mechanism that takes either a path or a constant value for a parameter.

As an example, if you were to create a St. Venant Kirchhoff material with a spatially varying Young’s modulus: You would need to create a material that takes the path to the pattern file that supplies the element-wise defined Young’s moduli as an input parameter. Or, wrap the parameter YOUNG in a one_of such that you can either pass the global parameter value directly or the path to the pattern file. The example @amgebauer provided does exactly this, just that it doesn’t retrieve the Young’s moduls but the mixture mass fractions from a pattern file.

Do we use a syntax standard, or is it home-made?

These pattern files rely on the StringConverter class.
Simply speaking, the StringConverter can convert a string matching a predefined pattern into an object of a defined data type. The syntax for the string pattern is build based on map-like {':', '=', '@', '#'} and list-like separators {',', ';', '|', '%'}. With thouse you can build nested data structures (you can check the tests in src/core/io/tests/4C_io_string_converter_test.cpp). The docu should be rather good (4C_io_string_converter.hpp) and contains some examples as well.

Let’s say you want to parse the content of your pattern file into an std:map<int, double>, where the key is the element id and the value is the young’s modulus. You would create a pattern file where each line looks like this:
<element_id>: <youngs_modulus>. Your material then needs to select the Young's modulus for the given element id. If you wrapped the Young's modulus in a one_of, you would also handle both cases.

Will/can this be generalized and rolled out to all materials?

I'm not sure if you mean it this way, but just generally making every parameter of every material a spatially inhomogeneous parameter doesn't make much sense imo. This would mean that also parameters that act like switches between different models or stuff like NUMMAT possibly retrievable from a pattern file. Selectively enabling this for certain parameters should be easily doable with a one_of - I can help if needed.

I would also like to mention that while this is a working solution, it is not optimal, e.g., searching for the element id would ideally not be necessary. But this is related to the way materials and material parameters are handled in 4C. I agree with @amgebauer here:

I think the way to go is to read spatially inhomogeneous parameters from the mesh file directly as you suggested. I think there are some problems to solve before this can be made generally available.

But as of now, it is still more convenient than creating single materials (which I also did before ;)).

[gilrrei]

@lauraengelhardt, thanks for the insightful answer! I'll have a look

[sbrandstaeter]

Heterogeneous material parameter fields, which may vary even in space and time, are not only extremely important for QUEENS but also for many applications in biomechanics.

Just off the top of my head, it is important for the research of @mairehenke, @shervas, and @BishrMaradni

[maxfirmbach]

I would also be interested in an "easy" solution for this.

[sebproell]

@maxiludwig @bgoderbauer and I will look into this and try to make the existing approach, which @lauraengelhardt describes as "pattern file", more conventionally accessible through our improved input mechanism. In the first iteration, this should make it easy to read in an elementwise field as json/yaml and access this via an element ID. Depending on what we learn from this feature, we can think about a more general (interpolated) field depending on a physical position.