Create a solid properties module

[aprilnovak]

Rationale

MOOSE currently contains a fluid properties module that defines an interface for creating custom user objects or using existing equations of state to model wide classes of fluids. It would be convenient to have a similar solid properties module to provide the interface for consistent definition of solid material properties and permit sharing of widely-used properties to avoid re-implementation in multiple applications.

Description

Create a solid properties module that defines material classes for computing solid material properties and userobjects providing material properties for commonly-modeled solids. Different applications may require different types of properties; for example, the heat conduction module requires density, specific heat, and thermal conductivity, while the tensor mechanics module requires Young's modulus, etc. These different requirements can be provided through different base material classes that can be elaborated upon by applications.

For example, consider thermal properties (density, specific heat, and thermal conductivity) for stainless steel. An example inheritance for implementation of these properties could be: GeneralUserObject<--SolidProperties<--ThermalSolidProperties<--ThermalStainlessSteel316

An application requiring different types of properties for stainless steel, such as mechanical properties, could follow a different inheritance: GeneralUserObject<--SolidProperties<--MechanicalSolidProperties<--MechanicalStainlessSteel316

Or, application-specific requirements can create custom userobjects inheriting from SolidProperties, which through the use of actions would still share similar input file notation. And, again similar to the fluid properties module, material classes declare and compute the properties, such as: Material<--SolidPropertiesMaterial<--ThermalSolidPropertiesMaterial or Material<--SolidPropertiesMaterial<--MechanicalSolidPropertiesMaterial

Impact

This will improve the consistency of solid material properties used in multiphysics applications where coupled applications both require property data for the same material. A consistent module will permit more applications immediate access to a wide variety of solid properties without needing to implement from scratch. In addition, application-specific implementations of solid properties that become available in a module could be removed.

However, it may be difficult to adapt applications to use a new module rather than their specific solid properties implementations to take advantage of these benefits. The names of the material properties declared by the module material classes may not match, and all input files would need to be updated.

[YaqiWang]

I like this idea. When I did thermal radiation transport in Rattlesnake, I need to couple with thermal conduction equations and implemented my own heat conduction stuff with a general user object ThermalConductionEoS, which should be ThermalSolidProperties. I think we can set this module up first. I believe people will realize how easy this can be used and switch their code over eventually. BTW, we do not have to separate thermal and mechanical out in the user object. We can leave error messages in the virtual functions of the base class saying the function is not implemented. If a derived class implements the thermal functions, the class can be used for thermal conduction without hitting error. But if somebody tries to use it in solid mechanics, he will get an error to remind him to add missing implementations.

[aprilnovak]

we do not have to separate thermal and mechanical out in the user object.

I suppose it's just a matter of style - would we rather have lots of pure virtual methods in a single base class, or multiple base classes with less pure virtual methods in each? Either option is fine with me.

[aprilnovak]

By the way, I'm hoping to have a PR within the next couple of days (just working on documentation) - I'm not sure how to assign this issue to myself, I think I'm missing some type of permission setting/not seeing it..

[tophmatthews]

This may be a good opportunity to utilize derivative parsed materials to be able to pass derivative terms to kernels. It'd be nice to have a consistent method to calculate and utilize derivative terms.

[aprilnovak]

This may be a good opportunity to utilize derivative parsed materials to be able to pass derivative terms to kernels.

I'm implementing calls like k_from_T(Real T, Real & k, Real & dk_dT), very similar to the fluid_properties module, to let applications compute derivatives if needed. If you had something else in mind let me know!

[lindsayad]

@dschwen I'm going to continue the discussion from https://github.com/idaholab/moose/pull/23208#issuecomment-1399315630 where you make some great points. The UO setup of the solid properties module is indeed ideal for the functor system. The functor system is in turn critical for the MOOSE finite volume implementation because FV residuals can be a function of an element stencil up to 3 element neighbor layers wide. Attempting to compute, store, and keep track of property information for that kind of residual is not tenable, hence the on-the-fly functor evaluation system. Functors can be used in finite element calculations but I frankly don't see them as very useful there. The price of the extreme flexibility of the functor system is that it is a bit slow IMO.

Anyway, I think the UO "root" design is the best for the possible diverse set of consumers, e.g. finite element Materials, finite volume functor material properties, etc. You mentioned using the UOs in BISON materials as much as possible and that sounds like a great suggestion. I also wonder whether with the increased emphasis on open source whether we might start pushing Material classes from BISON into the solid properties module. I don't see any reason why there can't be both UOs and Materials in the module, where ideally the Materials are leveraging the UOs wherever it makes sense.