Refactor evolution systems into pointwise functions

[nilsdeppe]

As part of a resulting discussion from #3448 @nilsleiffischer @yoonso0-0 @kidder @wthrowe and I came up with the following idea on how to refactor a lot of what is currently in Evolution/Systems into PointwiseFunctions. This will allow us to eliminate a large number of cyclic dependencies, and will also mean more python bindings can (relatively) easily by added. We are soliciting feedback on the suggested refactor. Probably the earliest any such refactoring would actually happen is early Oct. 2021.

3448 will only add the PointwiseFunctions/InitialDataUtilities directory and library. The larger refactors will be done at a later time.

• PointwiseFunctions depends on:
  • DataStructures (avoid DataBox if possible)
  • Options (because of tags)
  • Utilities
  • Numerical algorithms (root finding, derivatives?)
• PointwiseFunctions doesn't depend on:
  • Time (we will use a double but not slab-type info)
  • Domain (we only care about grid-point-wise values)
  • Parallel
• These dependencies allow easy python bindings
• Tags should go into PointwiseFunctions
  • E.g. PointwiseFunctions/Burgers/Tags.hpp (only holds simple tags)
  • Only include "DataStructures/DataBox/Tags.hpp" (only base classes) and "Tensor/TypeAliases.hpp"
  • Compute tags should have their own file (eg Burgers/ComputeTags/Blah.hpp) or in the free function's file. Consistent within a library.
• Have one library eg "PointwiseFunctions/Burgers" with subdirs "AnalyticData" and "AnalyticSolutions" but that are all part of the "Burgers" library. This means most things from the Evolution(Elliptic)/Systems/ThisSystem ends up in "PointwiseFunctions/ThisSystem"
  • The PointwiseFunctions libraries will be called, e.g. Burgers while libraries like Evolution/Systems/Burgers will be called BurgersSystem
• Have "PointwiseFunctions/InitialDataUtilities" library for the "MarkAs"/protocol-type classes. This also includes an "InitialData" base class that the AnalyticData/Solutions inherit from.
• Keep numerical initial data separate for now, but explore how to build that into a unified infrastructure.
• Boundary conditions and initial data should be completely separate. That is, the analytic data/solution BCs shouldn't get a tag out of the DataBox but internally store the analytic data/solution. This allows us to ultimately have numerical initian data and still apply Minkowski or KS boundary conditions.

[nilsvu]

This may be obvious, but I would like to emphasize that, in the example above, the BurgersSystem library depends on Burgers, but not the other way 'round. Therefore:

• Simple tags that identify physical quantities are defined in PointwiseFunctions/Burgers.
• Code that is specific to where an executable stores things in the DataBox remain in Evolution(Elliptic)/Systems/, e.g. executable-specific simple tags and compute tags.