ivoa-std / ObsCoreExtensionForRadioData

ObsCore model extension for radio data
Creative Commons Attribution Share Alike 4.0 International
0 stars 6 forks source link

Specific comments on IVOA Obscore Extension for Radio data Version 1.0 (IVOA Note 2022-10-14) #23

Open Bonnarel opened 1 year ago

Bonnarel commented 1 year ago

Sent by Alessandra Zanichelli and Vincenzo Galuzzi (novembre 2022)

Introduction (page 3) and thereon: when referring to single dish data format we would avoid to be too specific in referring to the SDFITS format. SDFITS is a registered standard but is not the only possible data format. Other FITS flavours which follow the FITS prescriptions (without being registered standards) are delivered by the various telescopes.

it was given as an example, we may add others to be more realistic. FrancoisBonnarel - 2023-02-10"

Sect 2.1:

single dish may be equipped with multifeed receivers, we would avoid mentioning the acquisition of signal through a central beam only because this is a particular case of a more general scenario.

there seems to be a mix between the definitions of s_fov and primary beam. In ObsCore s_fov is defined as the “approximate size of the region covered by the data product”. This is not the primary beam size of the antenna, for instance a map observation has an s_fov described by the approximate size of the mapped region on the sky. See also note on Sect 4.1 below.

This part has to be rewriten FrancoisBonnarel - 2023-02-10

the typical case is not the one stated at the beginning of the section (spectrum), since the acquisition of emission for each spectral sample in the spectral band and polarization can be generally done in more complex modes (for instance, map). The following sentences well summarizes the variety of cases. We should rephrase the content, starting from the general statement and later describing specific cases.

OK FrancoisBonnarel - 2023-02-10"

single dish multifeed receivers typically allow to cover larger spatial regions, acquiring simultaneously spectra from different positions on the sky still sharing the same spectral setup.

OK FrancoisBonnarel - 2023-02-10"

Sect 3: a typo in the first sentence: for radio data (not only for visibilities)

OK FrancoisBonnarel - 2023-02-10"

Sect 3.2: a correspondent definition for single dish data should be given.

of course FrancoisBonnarel - 2023-02-10"

Also: with ultrawide band receivers (for instance: 20 GHz bandwidth at 7mm) it may happen that the number of spectral windows (each with its own setup) largely increases thus translating in a multiplication of entry lines in ObsCore for the same observation. How do we plan to deal with these cases? Are we happy to have a large number of records in such cases?

I think it's difficult to avoid. Or we have to group together several spectral windows and use the multi-interval support concept FrancoisBonnarel - 2023-02-10"

Something like a spectral-coverage MOC could be useful here, but that would be something for a future ObsCore update as it isn't really radio-specific. I think it makes sense to describe data with small "holes" in the spectral coverage using a single ObsCore entry, (i.e. 16 MHz "bands" separated by something like 1 MHz), but describe data with larger holes by multiple entries (i.e. 1GHz@4GHz + 1GHz@15GHz + 1GHz@22GHz). That would help discovery because people may discard individual entries with a small amount of bandwidth on grounds of not providing enough sensitivity. MarkKettenis -2023-03-01

Sect 3.3: the definition of D as the largest diameter of the array antennae or telescopes is not correct for any telescope type. In fact, there is no main mirror size in the case of dipole arrays or beamformed data. Instead, D should be defined as the measuring system aperture scale, as already written in Sect 2.

OK FrancoisBonnarel - 2023-02-10"

Sect 3.4: it should be clarified that s_resolution is the best (smallest) spatial resolution achieved during your observation. The minimum of the spectral range should be used instead. this holds true for any radio data. See also note on Sect 4.1 below.

i think it's the same discussion than for the s_fov family. What do we expect from such a value ? FrancoisBonnarel - 2023-02-10"

Sect 3.5: last sentence could be changed to mention MOCs: “the use of MOC for s_region is strongly encouraged to gather the more accurate description of the spatial coverage”

See my above comment : MOC is an xtype FrancoisBonnarel - 2023-02-10"

Sect 3.6: see note above on single dish values for o_ucd.

OK FrancoisBonnarel - 2023-02-10"

Sect 4.1: by ObsCore definition s_fov coincides with s_fov_max. We suggest to introduce s_fov_mid and s_fov_min. Similarly, s_resolution coincides with s_resolution_min and we suggest introducing s_resolution_min and s_resolution_max.

_ we agree that in the radio case we need three concepts for fov and resolution. Which we call s_resolution and s_fov has to be discussed according to what usage we want to make of it (discovery or description ) FrancoisBonnarel - 2023-02-10"