Be safer and more correct when using strain rate

[gassmoeller]

This PR contains three changes that make using the strain rate in material models safer. All of these changes were necessary for #5211.

1. The Stokes assembly currently only provides the strain rate to the material model if the viscosity is requested. However, with complex material models we dont know what other material properties the strain rate may be needed for. For example the visco_plastic and viscoelastic material models also need the viscosity to compute the elastic force terms.
2. The visco-plastic rheology sometimes has to use a reference strain rate, but the condition for when to use the reference strain rate seems wrong. It needs to use the reference strain rate during the initialization (when timestep_number is undefined), during the first timestep (but only the first nonlinear iteration when we dont have the Stokes solution yet), and if the strain rate is very small (because we need to be able to divide through it).
3. The visco-plastic material model only computes the viscosity when it is requested, but it also uses the viscosity for the additional outputs (the elastic force terms). Make sure it computes the viscosity if the additional_outputs are requested.

[bobmyhill]

Looks sensible. One grammatical suggestion.

[bobmyhill]

Suggested change

	// Compute the effective viscosity if requested and retrieve whether the material is plastically yielding
	// Compute the effective viscosity if requested and retrieve whether the material is plastically yielding.

[gassmoeller]

I think this broke some tests, but I am unsure if the new version is better or worse. @naliboff and @MFraters I think this affects your models most. Could you take a look at this PR and tell me what you think about the changed test results?

[bangerth]

Specifically, the single failing test is:

	823 - solubility (Failed)

Isn't that test new? Did that test succeed on your branch before the commits?

[bangerth]

This seems right, but points out the fact that we should add an else to this if that poisons the output fields then not computed with signaling_nans.

[naliboff]

@bangerth - are the material model outputs by default not already set to signaling nans?

[bangerth]

Perhaps -- we weren't sure whether it's possible that the same object was reused from a state where information was requested to where it is no longer requested (but at that point no longer contains the signaling nans).

[bangerth]

Doesn't this negate the point of the flag? Do you even still need need_viscosity in this case?

[gassmoeller]

We still need the flag, because need_viscosity is used in the next line to tell the material model which outputs to compute. The wrong assumption here was that if we do not explicitly request the viscosity we also never need the strain rate input. This is not true anymore for complex material model (strain rate may be used for other properties than just viscosity).

[bangerth]

Ah, that's a bummer. I recall that computing the strain rate was expensive, and it's a shame that we now compute it unconditionally because the material model does not have a way to indicate whether or not it actually wants it...

[bangerth]

Since you observe that this patch changes output, the conclusion is that apparently we forgot to compute something previously and used invalid values (perhaps zeros, perhaps computed previously on the same object). This suggests what I mention in a comment above: We should have poisoned these values in an else branch. It would be interesting to write such an else branch for a separate PR and see what fails.

[bangerth]

See #5247 for an attempt.

[naliboff]

@gassmoeller - Aside from addressing comments from @bangerth, this looks good to go. Thanks for adding this.

One general comment - at some point it may be worth adding the checks for using the reference strain rate to the material model utilities, as other material models have to do the same checks.