Quality-of-Life improvements and bugfixes for LiDO

[samuelpmishLLNL]

Kenny has been wrapping the solid mechanics module in LiDO and mentioned that he ran into a few issues, I'm summarizing a few of them here so I don't forget before the weekend:

1. Some missing implementation for 0th-order (constant) L2 spaces. Some of our polynomial bases routines start at order 1 instead of zero, we just need to add a few lines of code to support this.
2. Be more explicit about not supporting L2 spaces on boundary integrals. Right now, the failure mode is a long compiler error message, but this should be easy to address with a static_assert in addBoundaryIntegral(). There's some relevant discussions about why mfem doesn't want to support boundary elements for L2 here:

• https://github.com/mfem/mfem/issues/2320
• https://mfem.slack.com/archives/C0258BVPQP3/p1629304286057700

It may still be possible to implement a workaround to enable boundary integrals that involve L2 spaces, but unfortunately it would require a considerable amount of work to do, since it's not supported in mfem.

3. LiDO is using quite a few parameters, and it's tedious to make every material and traction take them as arguments. This would be addressed by some of the ideas described in the content/discussion of this PR

4. Confusion about these types for specifying loads and tractions, e.g.

template <int dim>
struct PressureFunction {
  std::function<double(const tensor<double, dim>&, const double)> pressure_func_;

  SERAC_HOST_DEVICE double operator()(const tensor<double, dim>& x, const double t) const
  {
    return pressure_func_(x, t);
  }
};

It is not a requirement to use functors like this as arguments to SolidMechanics::addPiolaTraction().

And to clarify: lambdas or std::functions for materials, tractions, loads, etc can be passed in directly, but will not work on a GPU, since std::function can only represent CPU-specific functions and "extended" lambdas can't be generic. For defining materials and loads that work on a GPU, you can put the implementation inside a functor object and mark its operator() with SERAC_HOST_DEVICE. However, PressureFunction, TractionFunction and so on, will not work on a GPU, because they are implemented in terms of the CPU-specific std::function.

5. Member functions that require explicit template parameters (e.g. solid_mechanics.compute_sensitivity<index>()) end up needing to be invoked with solid_mechanics.template compute_sensitivity<index>() in a dependent context, see near the bottom of: https://en.cppreference.com/w/cpp/language/dependent_name

It doesn't prevent the functions from working, but the syntax is counterintuitive, and it just looks really ugly. I believe there are other ways to pass the same compile-time information to a function without ever requiring that unsightly template keyword (e.g. using tag-types as regular arguments).

If there's any other ones I missed from that meeting, please add them to this issue as well.

[kswartz92]

There was also a bug somewhere in functional where the trial and test space ordering was backwards causing an out of bounds error when computeSensitivity<> was called with different dimension trail/test spaces. @samuelpmishLLNL I'm not sure if this bug was addressed in a different issue/PR, just wanted to remind you.

[kswartz92]

Also, there is an issue with functional's AddVolumeIntegral when using the default argument for Qdata

[kswartz92]

Need to add K_elem[0][j][0]to domain integral kernal, this caused problems when adding a domain integral with a vector-valued parameter

[samuelpmishLLNL]

I believe these have all been addressed (except 5, which we will defer for now since it's an aesthetic choice).