Add surface strainrate postprocessor

[anne-glerum]

This PR adds a postprocessor that outputs the strain rate tensor on the surface of the mesh.

For all pull requests:

• [x] I have followed the instructions for indenting my code.

For new features/models or changes of existing features:

• [x] I have tested my new feature locally to ensure it is correct.
• [x] I have created a testcase for the new feature/benchmark in the tests/ directory.
• [ ] I have added a changelog entry in the doc/modules/changes directory that will inform other users of my change.

[anne-glerum]

I added a test in 3D, and there I noticed some differences between the surface solution and the full mesh solution. However, similar differences occur for the existing surface stress postprocessor. I've opened an issue for it (#4056).

[gassmoeller]

I will reply separately to your issue, but about the postprocessor: I have not looked at the code yet, but it is probably fine, because it likely is just a copy from the strain rate postprocessor? However, this is also what concerns me. With our current way of deriving surface postprocessors from a different base class we will eventually end up duplicating a lot of our postprocessors. Maybe we instead should have introduced a new function into the visualization postprocessor interface named bool restrict_output_to_surfaces() or similar, default it to false, and let some postprocessors set it to true based on an input parameter? Then we would not need to duplicate a lot of code. The only downside would be that we could not out surface and volume stress at the same time and the name of the output would likely be the same ("stress" no matter if it is just surface or everywhere). I think @bangerth implemented the interface, do you remember if there was a reason we need a different base class? At the moment we only have two surface postprocessors so maybe it is not too late to change the interface? @anne-glerum What do you think about it? If it is important to you to get this in first we could also do that and fix the interface later (it will just slightly increase the effort to do so).

[anne-glerum]

I agree the code duplication is not ideal. On the other hand, in our use-case, we will need both the volume and surface strain rate for example, so it wouldn't do to restrict output to one or the other.

I don't mind taking the time to change the interface. We're using the plugin as is for now, and updating the interface won't change the workflow.

[gassmoeller]

How many other postprocessors do you think we need to duplicate? I saw the base variables one in #4061. I think originally we had expected to only need very few postprocessors on the surface, but it seems we may have been wrong?

[anne-glerum]

For our current purposes, the base variables + strain rate + stress are enough. I don't know about other people's plans though.

[anne-glerum]

@bangerth , as discussed in #2982, this pull request is now updated and ready for another look. I'll squash the commits when you and the testers are happy.

I've checked whether the volume and surface mesh output agree, and they do for those components that are of significant magnitude, see the figures below.

[anne-glerum]

@bangerth Updated and squashed :)