What about a pixel dimension?

All the MRTCAL internal data structures and engines have been written in the order (i.e. from contiguous to less contiguous):

1. channels,
2. chunks,
3. pixel(s),
4. time dumps

with the assumption this is the natural and desired ordering of the data coming from the backend, which for example writes as

  type imbfits_data_t
    integer(kind=4) :: ntime = 0  ! Number of 'time' rows read
    integer(kind=4) :: npix  = 0  !
    integer(kind=4) :: nchan = 0  ! Number of channels
    real(kind=4), pointer :: val(:,:,:) => null()  ! [nchan,npix,ntimes] The DATA block
    real(kind=4), pointer :: wei(:)     => null()  ! [nchan] The WEIGHT array (same for all channels and pixels)
  end type imbfits_data_t

in the internal data structure mapping (a piece of) the DATA column. For a given time dump and a given pixel, the dimension channels $\times$ chunks is contiguous and treated as a spectrum to be split and reordered when relevant (this is why the chunk dimension does not appear in the data structure).

However, HERA IMBFITS data does not follow this ordering. It is actually ordered as

1. channels,
2. pixel(s),
3. chunks,
4. time dumps.

Because of this, the pixel dimension could not be used. For the time being, it is kept degenerate (npix=1), and the pixel dimension is melted in the channels $\times$ chunks dimension.

For future multibeam receivers, we will work with the IMBFITS developers to evaluate (in particular in terms of efficiency) and if possible ensure that the data is ordered as we expect. Note that this order could for example allow for parallelized processing of the pixels.