Discussion

As raised in section , the CLASS data format does not provide a weight array, even if one is available in the Fortran type observation which is used to load in memory the observations read from file. The observation type is used only when processing the data e.g. in the current context of AVERAGE and ACCUMULATE.

For consistency reasons over all the commands in CLASS which can make use of the weight array, its content is assumed to be inexistant or unset when entering the command: the weight array is recomputed each time it is needed. This implies a unique value for all the channels, e.g. the $\sigma$ value computed by BASE.

The discussions in this document raise the idea to save the weight array in the CLASS data format. Indeed, we have seen that the single value which is recomputed from scratch can not reflect the real weight of each channel, e.g. when the spectrum is the AVERAGE of several others in COMPOSITE mode. But this has two major caveats:

• if it is introduced in the CLASS data format, the weight should properly be taken into account everywhere in CLASS, in each command which makes use of it, including AVERAGE, ACCUMULATE, and BASE.
• this implies an increased weight on disk for each spectrum: the amount of data written (data array + weight array) will typically double. This point has not been quantified in particular their relative weight compared to the observation header.

  For small amount of data (e.g. with long integration times, line surveys,...), this would not be a problem. But when dealing with large quantity of data e.g. multibeam OTF observations, the increase would become dramatic. We may need in this case to have the choice to save or not the weight arrays.

For the time being, saving (always or not) the weight array in the CLASS data format remains an open question.