Skip to content

Future Steps for Karabo

Jump to bottom
Andreas Wassmer edited this page Sep 13, 2024 · 4 revisions

Remark

Author of this document is Luis Fernando Machado Poletti Valle. It was provided to me (Andreas Wassmer) via this link. Because it is not clear what will happen to this Google account now that Luis left I am providing the document here.

Future Steps for Karabo / Line Emission

Links for references

(BEWARE! RASCIL also has older documentation and gitlab repos that are still found via a Google search. Use the following links to make sure you’re reading the latest docs.):

Non-coding Tasks

Continue writing Karabo paper (Ask Simon Felix for access if cannot open link): https://www.overleaf.com/project/65ce1b3ab582a25fea50cf70

Debugging / Robustness Checks

Investigate differences between backends within LineEmission ipynb notebook. Tips: differences may be due to different defaults for handling some of the following: (if these terms are not clear, ask for help on their definitions and where in the code they can be found):

  • Weighting schemes
  • Taper
  • w-term approximations
  • Baseline cuts (see below for “rmax” parameter within RASCIL)

Investigate "WARNING: Skipped xxxxx visibility points." from OSKAR line emission pipeline

Add support for RASCIL Telescope instances to store and use the “rmax” parameter, which controls baseline cuts. The OSKAR equivalent is stored in the InterferometerSimulation, not in the Telescope class. Therefore, we need to think carefully about how to design this so we offer a uniform API to the end user.

(Quite important!) Run simulations using more physically-motivated parameter settings:

  • Field of View (FOV) and Beam Width (FWHM) should follow this rule: FOV ~ Beam FWHM ~ 1.2 lambda / D, where D = diameter of dish or station
  • Cellsize (i.e. angular resolution, i.e. radians/pixel) should follow this rule: cellsize ~ 1.2 lambda / B_max, where B_max = maximum baseline of the array
  • SkyModel source catalog should cover footprint on the sky at least as large as the FOV area (in order to prevent issues with missing data from e.g. sidelobes of the beam)
  • Image size (side of image in degrees) should be smaller than FOV

New Features: Computing

Use RASCIL Main GPU functions in Karabo. There have been issues with their GPU-enabled APIs, see the following links for more details:

Enable Dask into RASCIL functionality (SkyModel, InterferometerSimulation, maybe Imager?)

New Features: Short Term

  • Add support for RASCIL to produce visibilities via the image route, instead of via the SkyComponents + DFT route. This may be useful when handling e.g. extended emission / diffuse emission fields.

  • Include functionality into Visibility class for plotting visibilities with OSKAR and RASCIL. Note that the visibility data has different column orders and meanings from OSKAR vs. RASCIL.

  • Include functionality into Telescope class for plotting antenna/dish configurations using OSKAR and RASCIL

New Features: Long Term

  • Support full stokes throughout Karabo code (there are a few #TODO comments indicating places where this support will need to be added, but note these are not exhaustive).
  • Add functionality for RASCIL to write visibilities as Measurement Sets. Use the following API: https://developer.skao.int/projects/ska-sdp-datamodels/en/latest/api/ska_sdp_datamodels.visibility.export_visibility_to_ms.html#ska_sdp_datamodels.visibility.export_visibility_to_ms
  • Include effects of ionosphere into simulations. These effects on image quality may be small according to Devin Crichton (ETHZ). Nevertheless, they can have some influence if the sun is very active. An ionosphere model can demand a lot of computing resources and slow down the simulation to a high degree. It is thus important to think about this feature carefully. One could think of providing 2 pre-calculated files. One for a quite sun and one for an active sun.
Clone this wiki locally