A more flexible polarization option for UVH5

[david-macmahon]

UVH5 requires that all cross-polarizations for each pair of antennas are grouped together in the visdata dataset. In fact, Npols is a dimension of visdata. This is fine for radio telescope arrays where both polarizations of all antennas are connected to the correlator in an orderly manner, but it's a bit inflexible when it comes to less orthodox antenna-polarization to correlator input mappings. One such alternate mapping is the swapping of inputs that is often done for diagnostic purposes. Another alternate mapping is when the array has more antennas than correlator inputs, but some antennas have a faulty polarization (e.g. a broken LNA). In this case, some cross-polarizations are not present at all and some of the Npols visibilities for a given pair of "dual pol" (but not really) inputs might actually not be two different polarizations from each of two antennas, but arbitrary polarizations from each of two to four antennas! Clearly the Npols sized polarization_array dataset will not capture this information.

I think the current approach works great for "well behaved" arrays/correlators and is too entrenched (and intertwined with UVData) to change now, so I propose that an optional, more flexible approach to dual polarization data be developed. One idea would be to eliminate the Npols dimension of visdata (et al.) and effectively include that factor in Nblts instead. This would basically quadruple the size of Header datasets dimensioned by Nblts, but it would not significantly increase the size of the overall file since it is so largely dominated by visdata whose size would remain the same (or even shrink slightly since the redundant cross-pol autocorrelation products could be omitted). In this mode, the polarization_array would have length Nblts, one entry for each cross-product. To indicate that the dataset was written using this optional mode, Npols could be set to some "special" value (e.g. 0, which is not a specified cross-polarization value in AIPS memo 117). This is just an idea at this point, but I do think it would be good to specify such an optional approach so as to discourage the proliferation of incompatible methods for dealing with data from such "avant-guade" instruments.