feat: support non-scalar valued field specifications

[kdrienCG]

This PR generalizes field specifications to support non-scalar values, notably scales (and so function names).

The following interface is proposed:

<FieldSpecification
   name="perm_wall"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="{ 2.0e-22, 2.0e-22, 2.0e-22 }"
/>

Instead of:

<FieldSpecification
   name="permx_wall"
   component="0"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="2.0e-22"
/>

<FieldSpecification
   name="permy_wall"
   component="1"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="2.0e-22"
/>

<FieldSpecification
   name="permz_wall"
   component="2"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="2.0e-22"
/>

This PR also add a regionNames array to make it easier to specify multiple regions.

Considerations

Implementations considerations:

Design choice

I added a separate scales attribute (on top of the already existing scale) and a functionNames attribute (on top of the already existing functionName) to keep backward compatibility with every input files.

The user must choose one way to describe its field specification,
either the scalar way:

<FieldSpecification
   ...
   functionName="func"
   scale="11"
   ...
/>

or the non-scalar way:

<FieldSpecification
   ...
   functionNames="{ func1, func2, func3 }"
   scales="{ 11, 12, 13 }"
   ...
/>

and will not be able to use both at the same time.

Other possible implementations

There are different ways this PR could have been implemented, like:

• completly removing the scalar scale attribute in favor of a non-scalar scales
  • _{It would requires a massive refactor and break every input files (if no solution is found to treat scale="42" and scale="{ 42 }" as the same type)}
• use the blueprint/factory design (from feat: add PermeabilitySpecification as an high-level FieldSpecification #4019) to describe a new non-scalar component that creates multiple FieldSpecification
  • _{It would produce a lot of code duplication to have the same capabilities between all the new components (condensing multiple FieldSpecification in one, having a user-friendly way to specify a region, have similar validations etc.). Where those "high-level"/specialized components could be thin wrappers over this PR for custom validation, documentation, etc.}
• others.

[herve-gross]

@rrsettgast does this work for you?

[rrsettgast]

Really only two potential issues I have:

1. It seems like the tensorial specifications are a completely separate thing from the scalar specifications. They should be able to be made into the same thing.
2. The introduction of regionNames seems like it is duplicating the objectPath capability but just cutting out the ElementRegions/regionName*? Can you comment on how the usage is improved?

[rrsettgast]

you can just leave this as scale?

[rrsettgast]

What is the driver to make a new m_scales instead of generalizing m_scale?

[rrsettgast]

similar to the m_scales comment below. Can we generalize m_bcApplicaitonFunctionName to serve the role you have here for m_functionNames?

[rrsettgast]

Is this to avoid ElementRegions/regionName type specifications in objectPath?