Enabling dimension to be deduced for parameterized solid materials

[kswartz92]

While helping Irvin get his code to compile I realized the parameterized materials require a template dim parameter in the struct type. I moved this template argument to the operator overload so that the compiler can deduce it from the displacement gradient. This is how the non-parameterized material are set up

[kswartz92]

It's worth noting that is an interface-breaking change, although I don't expect many people are using this material model. I hope at least serac's test suite uses it somewhere, so that will also need to be updated.

After skimming through serac's materials, it seems we have no consistent convention for how dimensionality is handled:

• some material models are hard-coded to be only 3-dimensional
• some material models are structs with dim as a template parameter
• some material models are neither, with an operator() that supports arbitrary dimensions (as in this PR)

I was hoping this PR would at least reduce the convention list to two, meaning materials were either hard-coded 3D or have operator() that supports arbitrary dimensions. Did I miss any material models that still require dim as a template parameter?

[samuelpmishLLNL]

The traction and body force structs (which aren't really materials, but are in solid_material.hpp) take it as a template parameter, as does the LinearConductor thermal material. But I'm happy to just have this PR go in as-is.

[kswartz92]

The traction and body force structs (which aren't really materials, but are in solid_material.hpp) take it as a template parameter, as does the LinearConductor thermal material. But I'm happy to just have this PR go in as-is.

I found it more convenient to have dim deduced from the operator() call. Do others agree (@btalamini @tupek2)? Am I missing anything performance related? If there are no objections I'd be happy to include other situations where we could remove dim from the struct type

[samuelpmishLLNL]

Am I missing anything performance related?

It's not a performance thing, but note that more interesting materials would need the template parameter on the struct itself, rather than the operator() (e.g. an anisotropic conductor would need either a 2x2 or 3x3 conductivity tensor, depending on dimension).

[tupek2]

I have no strong view. I agree with Sam that a templated 3D material might occur in the future. Though, the template may never be needed, we could just pass an int to the constructor for this anisotropic example. I like the change suggested here though.