Cleanup element map and decrease size of ChildSize/MortarSize enums

[nilsdeppe]

Proposed changes

• goal is to further reduce memory overhead
• removes what I can from ElementMap without breaking anything
• Reduces the size of ChildSize/MortarSize but does not attempt to optimize any use cases specifically.
• The big thing that would help a lot is removing the block maps from the element map and instead just grabbing the block map from the global cache. I think the elliptic solver uses the block map in a non-trivial way, right @nilsvu ? It might make more sense to just get rid of ElementMap all together in the evolution code and just have the compute tags handle the calls direction.

Upgrade instructions

Code review checklist

• The code is documented and the documentation renders correctly. Run
  make doc to generate the documentation locally into BUILD_DIR/docs/html.
  Then open index.html.
• The code follows the stylistic and code quality guidelines listed in the
  code review guide.
• The PR lists upgrade instructions and is labeled bugfix or
  new feature if appropriate.

Further comments

[nilsvu]

Yes I think we can get rid of ElementMap, see the notes I wrote in this file: https://github.com/sxs-collaboration/spectre/blob/develop/src/Domain/Python/ElementMap.cpp. I think we can just construct a Composition coordinate map instead of the ElementMap where it's needed. The function to create a Composition element map is already implemented in the file I linked. We could factor that out to a free function.

[nilsdeppe]

Right, though if I'm reading the comment right that's saying replace ElementMap by a composition? The goal is to not store the block maps in the element databoxes, which means doing a composition is an issue

[nilsvu]

No need to store the (composition) element map in the element databoxes either in most cases. It can always be constructed on the fly just from the ElementID and the domain/block.

Note: I remember vaguely that some coordinate maps have caches (ylm interpolation info or something like that), so removing them from the element databox may have an effect. Can't find the code right now though, so maybe this was just an idea. I only find src/Domain/CoordinateMaps/TimeDependent/Shape.cpp where the interpolation info doesn't seem to be cached.

[nilsdeppe]

Oh, I see. Sure! What Larry and I had discussed was possibly having the coordinates/Jacobians compute tags handle the compositions in some manner as needed. But I have no idea what all this looks like exactly in the elliptic code. I think in the evolution code we could just store a pointer in ElementMap that points to the global cache, or just have the compute items.

Hmm, I don't remember us caching anything. SpEC does that a lot, but I thoguht we intentionally avoided it because of memory overhead. But there's too much code now, so I don't honestly remember :)

[knelli2]

Just an FYI, I'm planning a lot of interpolation framework changes around using compute tags to have coordinates/tensors in different frames