-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
Currently, we store example visibility sets in a .npy
or .asdf
format uploaded to Zenodo. There is some variation, but generally these are:
- data (complex visibility), often with shape (nchan, nvis)
- spatial frequencies
$u$ and$v$ in kilo$\lambda$ , with shape (nchan, nvis) - flag (Boolean), with shape (nchan, nvis)
- weight, with shape (nchan, nvis)
But it's more efficient to save these as CASA does,
-
$u$ ,$v$ in meters, shape (nvis) - channel frequencies, shape (nchan)
- data (nchan, nvis) (assuming we average over the npol dimension)
- flag (nchan, nvis) (assuming we average over the npol dimension)
- weight (nvis) (assuming we average over the npol dimension, and the weights are not channelized)
I think there are a few benefits to this.
- The file size is much smaller, so this should speed up downloads for builds
- Tutorials can show the user how to convert from the format their data is likely to be in into the format used by MPoL (
$u$ and$v$ in$\lambda$ , following MPoL #223)
@jeffjennings we might want to discuss this as part of a larger redesign for MPoL #223 and tutorials (#63).
Metadata
Metadata
Assignees
Labels
No labels