3D/cube dataset modelling

[HRSAstro]

Problem

I would like to request a new feature to model data cubes. The use cases are for source spectral line kinematics and joint constraints from 3D lens modelling. At present, it is only possible to model single-channel (continuum) data sets.

Proposed Solution

The proposed solution is similar to the extant multi-band modelling feature (see examples in autolens_workspace/scripts/multi), but simpler: instead of modelling several datasets, the input dataset has an extra (spectral) dimension. The source gridding and lens model are identical for each channel, including centroids. The source regularisation can be optionally per channel (because the signal-to-noise in each channel will be different) or global. Therefore, it could be possible to optimise both the global non-linear lens parameters and the per-channel linear solution. The solution should allow either optical/image data or interferometer input data.

Alternatives Considered

In principle, multi-band modelling is possible if one splits the cube into independent data sets, but this is over-complicated and time-consuming.

[Jammy2211]

Do you have an example of a data cube being load and modeled (or manipulated) with the existing multi API you could copy and paste here?

[Jammy2211]

Is there any reason you can't use the existing multi API (e.g. lists of datasets)? Is there a specific reason in terms of functionality or just that it doesn't create an intuitive interface?

[HRSAstro]

it's not a separate dataset, it's a multidimensional dataset, so one would have to split out each channel separately (which could be 50 channels). Unless there is something I'm misunderstanding about that. For optical data, the PSF is the same (I think, unless there are some cases where it isn't) and for interferometric, that's per channel

[Jammy2211]

In multi, you can create a list of Imaging datasets where each has its own unique data, noise_map and psf.

The question for Claude is going to be do we:

1. Reuse existing Imaging / Interferometer objects and just create lists of them to model data cubes or;
2. Create a DataCube object which has its own interface and ultimately needs its own AnalysisDataCube, FitDataCube, etc.

The latter creates a lot more source code so should be avoided unless there is genuinely something about data cubes that requires its own objects and section in the source code. I suspect he final solution will be we create a layer which maps data cubes into lists of existing objects and uses all the exiting functionality.

[HRSAstro]

I think it's more about simplifying the input, but I don't know whether that requires a new object or just a new parameter of existing objects. I guess there would not be an advantage to creating a new task over the existing multi-band framework

[Jammy2211]

Hi Hannah — the datacube modeling work from this thread is now merged. Implementation moved to the autolens_workspace issue, where I've left try-it-out instructions, links to all the new scripts, and a request for the three numbers (real_space_mask shape/pixel_scales, visibilities per channel, number of channels) I need to tune the JAX profiling script for your real use case:

PyAutoLabs/autolens_workspace#120 (comment)