UVH5 not ideally suited for arrays with relocatable antennas

[david-macmahon]

As described in the current UVH5 memo, the UVH5 format seems to assume/require that antennas have only one position for all the visibilities in the file. Normally data are not taken while the antennas are "on the move" (unless there's a space based VLBI component!), but it may be desirable to support consolidating visibilities from multiple array configurations into one UVH5 file. This is not possible given constraints in the current UVH5 memo (e.g. antenna_positions is limited to Nants_telescope entries).

UVH5 can be used to store visibilities for each array configuration in separate files, each with their own antenna_positions dataset, but the current spec does not allow combining these into one file. Not sure the best way to deal with this, or if it's even worth supporting this.

I guess so long as uvw_array has the correct (u,v,w) coordinates for each baseline-time sample, maybe it doesn't really matter what the antenna positions are?

[plaplant]

It is true that the UVH5 format as currently specified does not support antennas having different positions for different times in the file (though note that by extension, UVData does not support this for the in-memory object either). Although we don't currently have plans to extend support for moving antennas within a single file, we thought of a few potential workarounds if this behavior is desired. As you said, if it is not important that the antenna positions for different times are recorded, one could just ensure that the (u,v,w) coordinates are self-consistent with the data. If they are important, one could assign a different set of unique antenna positions/names/numbers for each time sample, and build a dataset in which different sets of antennas have data for different times inside the file (because not all antennas need have data associated with them for all times). We could certainly explore more robust solutions in the future if users consistently request this feature.

[david-macmahon]

I think this is a low priority in terms of features, but I think a brief discussion in the memo would be nice for completeness (maybe in a short appendix?).