Create an analysis subpackage

[DanRyanIrish]

Describe the feature

This issue proposes a new analysis subpackage for functions that take NDCubeABC instances and perform some analysis task. The scope of this subpackage should be as follows:

• functions must only require the NDCube 2 API in order to carry out the entire task;
• functions do not have to be valid for all possible NDCube instances, but they must be general enough to be beyond the scope of an astronomy-sub-field-specific package. For example:
  • fitting a spectral line is beyond scope because it requires an understanding of a model and a fitter API which is not included in the NDCube 2 API;
  • Differentially rotating an image of the Sun is beyond scope because this is specific to the field of solar physics;
  • cropping just the celestial axes of a cube is within scope because, although it only applies to cubes with celestial axes, the task can be performed exclusively using the NDCube 2 API and is useful across multiple sub-fields of astronomy.

The subpackage should contain modules which encompass certain types of tasks. As a start, this issue proposes the following modules:

• ndcube.analysis.rebin
  • This can hold a rebin function equivalent to NDCube.rebin, but can also hold a function to irregularly rebin a cube, which, due to technical limitations at this time, can only be performed when all WCS axes are independent.
• ndcube.analysis.crop
  • This can hold a crop function equivalent to NDCube.crop, but can also contain functions to only crop the celestial axes, e.g. crop_celestial. The advantage of this is that more user-friendly APIs can be exposed to the user. The same could be done for crop_temporal, crop_spectral etc.

NDCube methods vs. analysis functions

Similar to numpy, NDCube can have methods that simply call an analysis function, e.g., rebin and crop. But when should NDCube have a method as well as an analysis function? The criterion for a method to exist should be that:

• Methods should apply to all possible NDCube instances, i.e. it should be completely agnostic to the number of dimensions and physical types associated with them. For example:
  • NDCube.crop should exist, even if ndcube.analysis.crop.crop() also exists. However, while ndcube.analysis.crop.crop_celestial is a valid anaylsis function, it should not be a method because it is only valid for cubes with celestial axes.

Proposed solution

No response

[DanRyanIrish]

ping @hayesla @Cadair