Squashed main melt implementation

[jdannberg]

This is the core of the melt implementation (ripped out of the melt branch).
To make the pull request small enough for reviewing, we here include only the general implementation. All additional features such as melt material models, heating models and benchmarks will follow separately. The code also still contains a few todos that we plan to work on soon, but we would already be glad about feedback regarding the structure and possible improvements.
Overall, it would be great if we could merge the melt implementation before the hackathon, so that we can avoid getting additional conflicts.

[gassmoeller]

Maybe break this paragraph into more lines. That also makes it easier to comment lines. In the second to last sentence: maybe change "... and so this is implemented" into " ... and so they are implemented in the individual material models"

[bangerth]

might almost be easier to read if you just put the first line into the second

[bangerth]

I know that you worked hard to minimize the impact of this on the rest of the code base, but there are still a significant number of if-statements in the core files that test for melt. This worries me because it significantly increases the complexity of the code base -- which leads to a number of problems: (i) Have we tested all combinations of parameters, and what happens if someone chooses a combination that doesn't work? (ii) What does it mean for reviewing future patches as the new complexity reduces the number of people who still really understand what is going on? (iii) How are we going to treat proposed contributions that further add similar functionality by modifying the formulation in other directions, e.g., by making both strain and velocity first-class variables to support viscoelasticity? Having opened to the door to one different formulation means that we at least have to significantly think about other people wanting to add other things. (iv) What about solutions that extend, not just augment stuff, for example by adding a Newton scheme? Would they have to support the full set of melt-enabled equation, or just the original part? If the latter, this opens more doors for unsupported combinations of parameters. (v) What about variations of formulations? We talked about adding assemblers for the BA, for example; will we also have to add BA assemblers for melt variations? If not, how do we deal with the resulting unsupported combinations of parameters?

I don't suggest that we don't merge this patch. In fact, I think it looks good enough that I would suggest it be merged once you address my comments made yesterday and today. I also recognize the incredible amount of work that has gone into it, as well as the effort to fit it in and provide testcases. But I will have to admit that I have concerns given the impact it will have on the long term maintainability of ASPECT.

[tjhei]

I know that you worked hard to minimize the impact of this on the rest of the code base, but there are still a significant number of if-statements in the core files that test for melt.

I agree. I think some things can be improved down the line when we modularize parts of ASPECT better. I have some ideas on how to deal with linear/nonlinear solvers for example. That is a bigger revamp, but should take care of quite a few places.

At first I was hoping we could use signals to hook the melt stuff into the main code without touching anything, but this has two problems:

1. The macros to register are currently broken if they are used in the main executable (order of construction of static members is not defined). This can probably be fixed somehow, but I gave up after playing with workarounds for a while.
2. Using signals would interfere with plugins that also want to change things by hooking into the same signals. What order should we subscribe, etc. The logic is much simpler as a plugin writer, if you only have to think about a single entity modifying the code.

We talked about adding assemblers for the BA, for example; will we also have to add BA assemblers for melt variations?

I don't see a way around this. My suggestion here would be to modularize the assemblers further so parts can be reused. Juliane and I have been working on BA and other formulations already, PR incoming soon.

If not, how do we deal with the resulting unsupported combinations of parameters?

I think the only viable option is to assert when we encounter unsupported combinations.

Having opened to the door to one different formulation means that we at least have to significantly think about other people wanting to add other things.

Yes, that is an important question. While I think we shouldn't include everything in the universe, I would rather allow things that are less than ideal to be merged than turning away people. Otherwise we risk forks, fewer contributions, and a splintered community.

[bangerth]

Yes, I agree that we want to include, not turn away. I'm ok with merging as-is. I just wanted to bring up the issues I see.

There are currently regression tester failures. Please make sure everything is ok and merge yourself.