Adding field to output total strain

[ryar9534]

This PR adds registers total strain as a field within solid mechanics solvers so that it can be output to vtk. An incremental strain is updated when strain increments are computed within the quadrature point kernel, and these are added to the total stran at the end of the time step. We may want to rethink this once the new packing/data interface is in place.

I believe rebaselining will be needed as there is new output, but none of the results should change.

I also propose we have the TotalEnergies folks propose which constitutive laws they use most frequently and from which they would like elastic/plastic strain output as well, and that can be incrementally added.

An example output from my staircase runs which shows x displacement and the corresponding XX strain:

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 0% with 41 lines in your changes missing coverage. Please review.

Project coverage is 55.68%. Comparing base (3bf12d2) to head (b3e928f).

Files	Patch %	Lines
...icsSolvers/solidMechanics/kernels/StrainHelper.hpp	0.00%	28 Missing :warning:
...ers/solidMechanics/SolidMechanicsLagrangianFEM.cpp	0.00%	12 Missing :warning:
...icsSolvers/solidMechanics/SolidMechanicsFields.hpp	0.00%	1 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## develop #3142 +/- ## =========================================== - Coverage 55.71% 55.68% -0.03% =========================================== Files 1031 1032 +1 Lines 87698 87739 +41 =========================================== - Hits 48863 48861 -2 - Misses 38835 38878 +43 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ryar9534]

Thanks for the review @CusiniM . You picked up on the things I was hoping to ask about. In particular, the need for both incremental strain and total strain, and the zeroing I have to do - It seemed to me that the strainInc used in the quadraturePointKernel is an increment from the previous converged time step to the current state, so I don't think you can just sum all of the increments across newton iterations, if that makes sense. I think if you dont do the zeroing in the quadrature point kernel then the results directly depend on the number of newton iterations, or at least thats what I saw during testing. I think a separate variable for the increment is needed for a similar reason, but perhaps we can think of something more clever.

[CusiniM]

Thanks for the review @CusiniM . You picked up on the things I was hoping to ask about. In particular, the need for both incremental strain and total strain, and the zeroing I have to do - It seemed to me that the strainInc used in the quadraturePointKernel is an increment from the previous converged time step to the current state, so I don't think you can just sum all of the increments across newton iterations, if that makes sense. I think if you dont do the zeroing in the quadrature point kernel then the results directly depend on the number of newton iterations, or at least thats what I saw during testing. I think a separate variable for the increment is needed for a similar reason, but perhaps we can think of something more clever.

Hmm, if instead of using u_hat, we use u don't we get directly the total strain? At that point there is no need to store the incremental one.

[CusiniM]

Thanks for the review @CusiniM . You picked up on the things I was hoping to ask about. In particular, the need for both incremental strain and total strain, and the zeroing I have to do - It seemed to me that the strainInc used in the quadraturePointKernel is an increment from the previous converged time step to the current state, so I don't think you can just sum all of the increments across newton iterations, if that makes sense. I think if you dont do the zeroing in the quadrature point kernel then the results directly depend on the number of newton iterations, or at least thats what I saw during testing. I think a separate variable for the increment is needed for a similar reason, but perhaps we can think of something more clever.

Hmm, if instead of using u_hat, we use u don't we get directly the total strain? At that point there is no need to store the incremental one.

I am also still not entirely convinced that it's not worth it to launch a simpler kernel just for this computation at the end of the timestep instead of trying to combine it with the assembly. I think we would only need to dispatch on the elem type since all we need is to know how to perform the interpolation and the integration and we don't care about the constitutive type (I think).

[ryar9534]

@CusiniM Should be good to go now if youd like to take a look.