Keywords: class-average

Next: Conclusion Up: IRAM Memo 2009-4 Averaging Previous: Concatenation Contents

# 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 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.

Next: Conclusion Up: IRAM Memo 2009-4 Averaging Previous: Concatenation Contents