Integration of cube fitting

[drvdputt]

My work to make PAHFIT run on spectral cubes is in a separate repo: https://github.com/drvdputt/PAHFIT-cube.

The readme is quite outdated though. I initially tried some things based on a set of Spitzer cubes (LL1, LL2, SL1, and SL2). By now, it also works for MIRI cubes. (With work I mean the mechanics are there. The science packs are a whole other issue of course.)

Brief summary of the contents:

Main script run_pahfit_cube.py

• Reads in cube data. Either a fits file that is supported by spectutils.Spectrum1D.read(), or a pickle that was produced by one of the merging/reprojection scripts (see below).
• Sets up PAHFIT model for each spaxel, runs the fits.
• The fits happen in parallel
• Gathers the results and makes feature maps (a multi-extension fits cube with the same spatial WCS as the given spectral cube).

Merging/reprojection scripts

• IFU cubes will have different fields of view. Regardless of whether we want to merge them across all wavelengths or not, we still need everything on the same spatial grid.
• Scripts like merge_miri_cubes.py and merge_spitzer_cubes.py will reproject all slices onto the same grid, and then write out the results as a pickle that can be read by the run script.
• If you only want to fit a single MIRI cube, the merge step can be skipped, and the fits from the MIRI pipeline can be given directly to the run script directly.

Use of model trimming tool

• To make sure we need only one science pack, regardless of the wavelength coverage of the cube given, the cube fitting script makes use of the feature introduced in #165.

Integration into PAHFIT

Now the question is: do we want to put all of this in the main PAHFIT repo, or in a separate package under the same organization? Considering both the run script and the instrument-specific reprojection tools mentioned above.

This could also be relevant for #34. The parallel fitting of the cube spectra could be generalized for use with many individual spectra (not necessarily from a cube).

[jdtsmith]

Hi @drvdputt, this looks very interesting. In principle I'm signed up to do some of this type of thing for various Cycle 1 proposals, and have some ideas about making the parallel/joint fits more performant/robust (i.e. not fully separate). I think it should definitely live in a separate repo, as a "driver" to the PAHFIT model (in all its glorious flexibility). cubePAHFIT?