Generating PPV cubes

[robjmcgibbon]

Several COLIBRE-project use cases need PPV (position-position-velocity) cubes of simulated galaxies. I've written code for this, and Joop seems keen that it gets added to swiftsimio. I think it might be better as a separate package, so would like to hear what others think. Some further info:

• The implementation is numba-based, similar to the existing project/visualisation backend. I'm testing it by masking particles by velocity, building a 2D map per velocity channel, stacking them into a cube, and comparing with the numba backend.
• The main use case would be for emission, which means the user needs to use the particle properties to index the CHIMES table. I don't think that step belongs in swiftsimio.
• The output has units of length on the x/y axes but velocity on the z axis. I'm not sure how to represent that cleanly with cosmo_array as it currently stands.
• Smoothing the particles in velocity space:
  • Default would be no smoothing, particles deposited into a single cell.
  • Support for smoothing by particles velocity dispersion, assuming a Gaussian. COLIBRE snapshots carry velocity dispersion directly, but we could add a helper function to compute it if it's missing.
  • Support for thermal broadening, would species-dependent.
• If we do this as a small separate package then we could return an object, with useful methods
  • Converting units (including to RA/DEC)
  • Adding noise
  • Computing moment maps (integrated intensity, velocity field, dispersion)
  • Writing to FITS

[kyleaoman]

Hmm, interesting. I'm in the midst of rewriting the backend to martini so would be curious to compare notes. I have considered giving up on my old approach and basically implementing it the way you describe but finally figured out some KDTree, vectorizarion & numba trickery to stay closer to the "classic" martini algorithm. Diego also has something he's been using along these lines and has mused about packaging or partially contributing to swiftsimio, but his method is more like partridge in the sense that it first builds a grid in 3 spatial dimensions. On to some of your specific questions:

• Your cosmo array doesn't have two spatial and one velocity axis, it's just a cube with units of flux or similar. Should probably be returned with arrays giving the spatial and velocity coordinates.
• Agree the CHIMES (or similar) part should be left separate. Overall I'd say keep it minimalist/simple. There are other bespoke packages for cubes with all of the bells and whistles.
• I'd be a bit wary of adding noise (presumably also PSF convolution?), ra/dec, moments, etc. There is a lot to unpack there, and a lot of it is wavelength dependent. To do it all properly sounds like many months of concerted effort, at least. Again would argue to keep it simple, at least initially.

Also a couple of questions:

• Many (most?) lines are not optically thin, but it sounds like the plan is to do this in the optically thin limit, is that right?
• Is this basically intended for optical nebular lines? Or also sub-mm (CO?) and radio (HI)? Xray? Just gas or also stellar absorption lines?

[robjmcgibbon]

Thanks Kyle, that's helpful. Yes I see what you mean about the units.

• Yep this would just be assuming it was optically thin
• I'm not sure what lines Joop was thinking of, I'll need to ask him when he's back. I think it's more than just optical lines though