Output of internal (material) variables

[ischeider]

Coming from the solid mechanics side, I can print out stresses and strains with the STRESS_STRAIN parameter in the respective RUNTIME VTK OUTPUT section. However, there are often internal variables (like plastic or viscous strains), which I would like to see as well.

Currently, they are stored in the vtu files when I add the parameter GAUSS_POINT_DATA_OUTPUT_TYPE and set it to something except none. This is weird in my opinion; I would expect that this parameter controls the output position (node, GP, center) of all gauss point variables (including stress and strain).

I would rather expect an additional boolean parameter INTERNAL_VARIABLES (or material_variables), which switches all internal variables on and off. Alternatively, one could also have a bunch of additional boolean parameters PLASTIC_STRAIN, VISCOUS_STRAIN, BACK_STRESS; the list might then become pretty long. On the other hand, a more granular output option may reduce file sizes significantly.

There is an additional parameter OPTIONAL_OUTPUT. This expects an enum (currently just two options: [no, membranethickness]). Actually I find the name of this parameter strange as well, but I could live with that. But then the expected value must be changed to an array of enums where I can put any variables in it (plastic_strain, viscous_strain, etc.).

In short: I am disappointed of the current option to print material variables, and I really beg for a change. I would like to have your opinion, what we should do:

1. Have one additional bool parameter for all internal variables
2. Have additional parameters for each internal variable
3. Have an array of enums in one parameter (might be OPTIONAL_QUANTITY or another one)
4. Any other option which I cannot think of yet.

@4C-multiphysics/developers : Please, comment whatever you prefer.

[amgebauer]

Thanks for opening this discussion. I also think that we can remove the special stress/strain case and use the (more powerful) gauss-point-data output for that.

I would suggest to define a parameter taking a list of quantities to write and/or not-to-write so that we don't have to introduce an extra option for every possible output quantity.

[c-p-schmidt]

Sounds good to me. So the default would be to not write all of these quantities if they are not listed there, right? This way, we would also avoid unnecessary output data if the user does not explicitly request it.

[tuchpaul]

I support option 3 as well. Maybe we could use e.g.
OUTPUT_QUANTITIES = [all_internal_variables]
as the default case to print all available internal material variables.
If a user only wants specific quantities, they could instead set, e.g.,
OUTPUT_QUANTITIES = [stress, strain]

[rjoussen]

I think using the names of internal material variables in a global context is problematic because their name are unknown. For example, plastic strain might be called plastic_strain, accumulated_plastic_strain, or anything else, depending on what the material registers in register_output_data_names.

I think if we want finer control than just all_internal_variables, there could be maybe a list of material IDs that should write all of their internal variables (if they have any).

If turning on/off specific internal variables for certain materials is desired, I think it would be more intuitive to do that in the material definition. The material definition section could also inform about which internal variables it has and can write.

[amgebauer]

Then one could define two material ids, which differ only in the output.

I think that does not really help. We cannot write output only for a partial discretization, so we need to fill the data with dummy data (and in that case, we could directly write the true data of that material)

[ischeider]

Ah, I see. This is because vtk always uses the complete array of all elements. But this is a quite severe drawback. If one has a two materials in a structure, the variables, let say plastic_strain, is written for the whole structure, even if 90% of the structure has an elastic material model.

[dragos-ana]

Based on this discussion, it makes sense, for me, to set one single list of internal variable enums to be written as output within the input file, instead of material-specific ones (although it would have been nice if this was feasible). Then, we could have one global list of valid internal variable enums in the code that can be output, and we could modify the gauss point output methods to manage enums instead of strings as internal variable identifiers. If the enum plastic_strain is to be written, the material can provide the plastic strain if it is an internal variable of the material (otherwise dummy value). Additionally, depending on whether this is manageable, we could detect all internal variables that can be written for each specific material and add them to the documentation. Also, we could provide an additional parameter in the material definition, e.g. VERIFY_INTERNAL_VARIABLE_OUTPUT, which can display a warning, or output an error, if none of the internal variable enums set in the input file can be written as output.

[rjoussen]

Sounds good to me. It's definitely much better than how it is at the moment. We should still think about how to document duplicate internal variables. And I think the documentation should also state, for each internal variable, by which material(s) it is provided.

[amgebauer]

Managing one global list in an enum is difficult. The mixture material for example adds the constituent id to the name since there might be multiple constituents that are writing the same output. Also, we would then again need some kind of global module that contains all possible output data names, which contradicts modularization.

[mayrmt]

I cannot contribute to the detailed discussion about material output options. A general remark though: let's be cautious with outputting too much by default. I'd rather have no output by default (for eyery user) and let expert users activate just those fields that they are interested in.