[WIP] Add multigrid

[landinjm]

Summary

Discussion

I need to profile and optimize the access of variable container. Due to frequent look-ups, it's essential to measure the performance difference between std::map, std::unordered_map, and std::vector.

Todo

• Neumann boundary conditions
• Grains
• Nucleation
• Warning that all fields should be marked as periodic if one is since we modified the triangulation
• Patterns::Selection
• Limit on user inputs
• Log file into something machine readable? JSON?
• Scaling of multiple independent Cahn-Hilliard equations
• Implicit solves
• Storage of old solutions. For old solutions we must have sequential storage (i.e., if we want 4 timesteps back we must store the 3rd, 2nd, and 1st as well.
• Optimizations with shared DoFHandlers between fields?
• Element volume calculation
• Overloads in equations.cc and variableContainer to prevent the calculated of quad point location. This could be a compile time flag or something. This is worth looking into because there is a decent amount of time spent calculating the quadrature point locations (~5%).
• Initial condition read-in
• Restarts
• 1D output should also provide the x-coordinate to make graphing in Visit easier
• Break up type_enums
• Various assertions on dependencies.
• Integral output for post-processed fields

[landinjm]

There's a few internal benchmarks that would be good to test the performance of our software.

1. How does the the wall-time scale with independent copies of the same equation? For example, we could solve 1 Cahn-Hilliard CH) and 10 CH to see how our internals scale. This can also be used to see if we can exploit shared DoFHandlers as in Check to see if each field really needs its own DoFHandler #65 . This should be done with the Allen-Cahn and Cahn-Hilliard equations.
2. How often should outputs & restarts be made. The answer to this depends on how fast your solution is changing and how much time each step takes, but it would be a good idea to quantify this to show new users. It becomes particularly important for higher order time schemes since the old solutions must be saved in the restart as well.
3. We can also doing something similar with remeshing and the application of time-dependent boundary conditions.

@fractalsbyx @david-montiel-t @zachcroft @wband Any other thoughts here?

[wband]

For 3), I expect that most problems that have time-dependent boundary conditions would benefit from them being updated/enforced at every step. For fracture it's the main factor driving evolution.