Mochi integration

[kyleaoman]

To do

• Unify inbound particle checking
• Switch off pruning in velocity for mochi.
• spherical coordinates MOCHI
• Make tests for MOCHI (Mathieu handles internal, Kyle handles integration)
• Support non-cubic meshes (cells remain cubic)
• Merge MFM & SPH loops?
• Check with pyopensci if MOCHI-MARTINI integration allows publication
• Check MARTINI-MOCHI resolution break point, when do MARTINI and MOCHI make the same spectra?
• Implement memory limiting similar to martini (how to predict for adaptive grid?).
• ipynb notebooks
• Documentation
• Narrative documentation
• Update MARTINI repository author list

Just opening a draft PR as a place to discuss and perhaps collaboratively develop.

I've had an initial quick hack starting to integrate the mochi approach into the overall martini framework. Some initial notes:

• My first goal was to have a Mochi class analogous to the main Martini class that could implement a similar API and take advantage of a lot of existing functionality. This is done (at least as a rough draft), you can create a Mochi, call Mochi.insert_source_in_cube() and end up with a DataCube object populated with emission. The convolution, write to fits/hdf5, etc. features from Martini then work automatically.
• Next was to homogenize the style a bit. This is still very much a rough and negotiable proposal. For example, I think that it makes sense to have an AdaptiveCellGrid class so that some of the information (e.g. cell coordinates) can be held centrally instead of passed around many functions. The current implementation is still rough but splits up the process into functions corresponding to the relevant steps (initial grid, refined, interpolated, regular grid, radiative transfer). Many options still need to be exposed to the outside world, and I think that there's still some unnecessary passing of arguments etc., but what's there gives an idea of a suggested framework.
• Currently the "radiative transfer" and "interpolant" tools have basically been copied as-is (though I have been tinkering with naming and arguments here and there). I would probably suggest moving both of these to a class framework similar to the SPH kernel classes just to keep consistency in style and make housekeeping easier. I don't see any incompatibility between this and the nice function composition approach, both are probably simultaneously possible.
• Most of the rest of the code becomes obsolete under this proposal (everything under post-processing, I think). I haven't ported over the non-adaptive grid feature yet, would make sense to do that, but there are many re-implementations of martini features that can be dropped.
• I started renaming lots of things from camelCase to snake_case, just a consistency choice. Also started on many of the docstrings, just filling stuff in as I was trying to figure out what types various things were supposed to have.
• The cartesian grid -> spherical grid change that is the main technical hurdle is partially implemented with some comments highlighting some (probably missed a few) things that still need looking at. Roughly: I have an initial stab at the particle coordinates implemented, but the cell volumes for example are all still calculated as if they were cubic.

As evidence that "it works!" here are two tiny mom0 maps from the same particles. They're not identical because mochi has a limited depth along the LoS and I haven't made sure to cover all particles that can be included by martini (plus the expected scanline vs non-scanline differences), but at least the general data-wrangling is operational.

martini:

mochi:

This is about a day's effort so if you prefer to go down a different path then no harm done. If this approach seems promising then I'm happy to collaborate on a full implementation, perhaps aiming for a release in time for PHISCC. I think that there's probably a reasonable way to divide up the work. Note that everything is self-contained in the new mochi subdirectory in this branch. That could stay there, move around within the martini namespace, or be split off as a separate package or sub-package. There are various pros/cons. For example under this repo you benefit from having the docs, CI and deployment pipelines already set up. However perhaps you prefer more ownership and autonomy. We can discuss further if wanted.