Skip to content

Development Items Required for ASKAP Imaging #267

Description

@iancze

This issue is a first stab at identifying the MPoL features that would need to be developed in order to make a continuum RML image of a single ASKAP field.

ASKAP uses a phased array feed to achieve a wide field of view through the simultaneous formation of multiple beams. In typical operations, 36 beams tile a ~square field of view approximately 30 square degrees. To simplify development, one can consider the data products from a single beam to be analogous to those from a "traditional" interferometer like the VLA or ALMA. So, one can first focus on those features needed to successfully image a single beam, and then those needed to image an entire field of view.

Required to image a single beam

  • ASKAP produces polarized data products, and nearly all fields of view will contain polarized sources. Therefore, a base image cube capable of representing polarization is required. Following ALMA Polarization  #81 : Recommend 4-dimensional Stokes cube as base representation with Stokes I, Q, U, V. This could add an additional polarization axes to the image cube.
    • Should this polarization cube become the default internal product, or an additional product?
    • How do we need to modify all downstream methods now using an (npol, nchan, npix, npix) object, as opposed to an (nchan, npix, npix) object? Should unpolarized observations be treated as (1, nchan, npix, npix), or as (nchan, npix, npix)?
    • Should it be (nchan, npol, npix, npix) instead of (npol, nchan, npix, npix) ?
  • Implement multifrequency Taylor-term imaging for the wide frequency coverage of polarized sources
    • Do we need rotation-measure synthesis, too?
  • Efficiently parallelize the model execution across multiple channels
  • Self-calibration will be necessary to achieve sufficient dynamic range (Self calibration #24), since phase errors appear to be a dominant source of image systematics
  • How will we treat the w-term? In a CLEAN framework, this is usually addressed through w-projection, w-stacking, or w-snapshots/distortion. To figure out the best/fastest way to implement this in an RML framework would likely require significant R&D. w-projection would likely require some custom tampering with torchkbnufft kernels, while w-stacking is sort of a reverse WSClean.

Required to image an entire field

In standard ASKAP processing, each beam is imaged independently, and then the beams are stitched together in a linear mosaicking step. In our approach, instead, we would start with a large format image of the entire "mosaic," and via the forward model, chop this up to be fed to the visibilities corresponding to each beam.

  • primary beam models for each of the 36 beams (Primary beam correction #23)
  • large field image is "chopped up" and FFT and likelihood function is applied to individual Beam MS's
    • need image segmentation/primary beam tapering tools
    • need some sort of data parallel way to distribute likelihood calculations across a pool of GPUs
  • presumably joint/simultaneous imaging of the full FOV across all beams should allow us to model and correct for the subtlest calibration effects.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions