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.

[maxfirmbach]

What is still missing here? I think @sebproell and @maxiludwig did a great job in implementing a .json based material distribution input, to prescribe different material parameters per element. The only thing is that one has to implement it in 4C for the respective material of interest.

[gilrrei]

It might be interesting to roll this out on a larger scale to the different materials. I think there are more improvements possible, such as providing an analytical function or node-based values, but I think that it is amazing already!

Btw, if you need a converter script between input files for the changes, the update mechanism has been ready for a while for such cases 👌

[maxfirmbach]

I think the relevant people involved in this discussion are already aware of the analytical function feature (which is currently missing). I'm not so sure about the node-based input as the material is usually defined on the element (but of course I don't know the application scenario, so there might be cases were it makes sense).

The large roll out of this feature to different (or even all) materials might be more difficult than one thinks in the beginning. We have so many materials and respective parameters, how do we decide for which ones this feature actually makes sense and for which ones it doesn't? To me this doesn't seem trivial.

[sbrandstaeter]

Thanks for the update — great to hear that an implementation has already been merged! Huge thanks to everyone who contributed.

For those (like me) who have missed the PRs, see, for example, here: #890

As mentioned earlier, this is really important for me and many of my collaborators. Not least because this is a fantastic and crucial step toward improving how we handle random fields in QUEENS (thanks to @gilrrei for highlighting that!).

One question that comes to my mind: do you think it would be possible to extend this to support nodal or Gauss point levels as well? In some cases, approximating the parameter field at that level could be necessary.
Seems like I was too slow and the question was already posed.

Just to bring others into the loop:
@mairehenke – could we incorporate this into our stomach model?
@BishrMaradni – let’s plan to switch over and prepare the materials we are using with this new feature.

[gilrrei]

Something I forgot to mention, one use case is materials, but I think this functionality (reading spatially and timedependent parameters, no matter if elementwise, nodal, Gauss points, from an analytical function) could be useful in other parts of 4C such as boundary, initial, or interface conditions, as well as for source terms. Basically, every time something could change in time or space. (Not saying this has the highest priority, only pointing out it requires a similar infrastrucuture)

[gilrrei]

There has been a lot of improvements regarding this feature/issue:

• From a JSON file: Input field InputSpec to read local parameters #890 (and related PRs) thanks to @maxiludwig, @lauraengelhardt, and @sebproell (hopefully I didn't forget anybody)
• Directly from VTU meshes: Allow reading input fields directly from the (VTU-)mesh #1321 thanks to @amgebauer

Although it's not enabled automatically for all materials/parameters, it is a great improvement already