em_xel and spectral MOCs (From Alessandra, Vincenzo and Marco)

[Bonnarel]

From Alessandra Zanichelli, Vincenzo Galluzi and Marco Molinaro

em_xel and spectral MOCs Single dish radio data may contain a multifrequency setup, that is many spectral windows disjointed on the spectral axis and with different resolutions (i.e. different numbers of spectral channels). In such a case em_xel can be computed but could lead to an incorrect interpretation of the actual spectral sampling of the dataset. In this respect, current efforts towards the creation of energy/frequency MOCs by the IVOA Applications Working Group could represent a solution. We note that frequency MOCs would also offer a comprehensive representation of the em_min, em_max and overall spectral coverage/properties of the dataset. A further extension of the work on energy/frequency MOCs could be developed to include also the polarimetric information. In fact, two polarisation states in the same dataset could in principle have different frequency setups.

Therefore, ObsCore mapping on radio data in general represents a proof of concept for current developments on the MOC standard.

An example of multifrequency setup is shown in the following figure: a spectroscopic observation in the so-called “zoom mode” with the Xarcos spectrograph, delivering the two circular polarisations for each spectral window.

[Bonnarel]

From Alessandra Zanichelli, Vincenzo Galluzi and Marco Molinaro

em_xel and spectral MOCs Single dish radio data may contain a multifrequency setup, that is many spectral windows disjointed on the spectral axis and with different resolutions (i.e. different numbers of spectral channels). In such a case em_xel can be computed but could lead to an incorrect interpretation of the actual spectral sampling of the dataset. In this respect, current efforts towards the creation of energy/frequency MOCs by the IVOA Applications Working Group could represent a solution. We note that frequency MOCs would also offer a comprehensive representation of the em_min, em_max and overall spectral coverage/properties of the dataset. A further extension of the work on energy/frequency MOCs could be developed to include also the polarimetric information. In fact, two polarisation states in the same dataset could in principle have different frequency setups.

From François Bonnarel : From the ObsCore/Characterisation point of view what you describe is the "support" concept which is more accurate than "bounds" (= min/max). A support is either a spatial detailed field of view or a set of intervals. MOC can be used to render those things. It would not be a new extension concept but a coding format for it. In VOTable would be rendered by the xtype attribute (xtype="moc" or "stmoc" or "emoc")

[Bonnarel]

From Alessandra Zanichelli, Vincenzo Galluzi and Marco Molinaro em_xel and spectral MOCs Single dish radio data may contain a multifrequency setup, that is many spectral windows disjointed on the spectral axis and with different resolutions (i.e. different numbers of spectral channels). In such a case em_xel can be computed but could lead to an incorrect interpretation of the actual spectral sampling of the dataset. In this respect, current efforts towards the creation of energy/frequency MOCs by the IVOA Applications Working Group could represent a solution. We note that frequency MOCs would also offer a comprehensive representation of the em_min, em_max and overall spectral coverage/properties of the dataset. A further extension of the work on energy/frequency MOCs could be developed to include also the polarimetric information. In fact, two polarisation states in the same dataset could in principle have different frequency setups.

From François Bonnarel : From the ObsCore/Characterisation point of view what you describe is the "support" concept which is more accurate than "bounds" (= min/max). A support is either a spatial detailed field of view or a set of intervals. MOC can be used to render those things. It would not be a new extension concept but a coding format for it. In VOTable would be rendered by the xtype attribute (xtype="moc" or "stmoc" or "emoc")

From Baptiste Cecconi :

May be a solution would be to have a generic "multi_dim_coverage" column (or just "coverage"); which there would be a MOC (with spatial, temporal and/or spectral domains, defined by an xtype in the column header). This may cover the other comment later in the text about the variation of the field of view across the spectral window. This should be further discussed, of course, but it might be useful here.

[kettenis]

I agree that having a more detailed description of the spectral "support" would be desirable. Question is whether we expect the work on energy/frequency MOCs to be mature enough to include it in the first version of the proposed radio obscore extension?

Is there a pointer the energy/frequency MOCs somewhere?

[Bonnarel]

Le 28/08/2023 à 15:02, kettenis a écrit :

I agree that having a more detailed description of the spectral "support" would be desirable. Question is whether we expect the work on energy/frequency MOCs to be mature enough to include it in the first version of the proposed radio obscore extension?

Is there a pointer the energy/frequency MOCs somewhere?

Not yet something official .  I will send you something informal.

— Reply to this email directly, view it on GitHub https://github.com/ivoa-std/ObsCoreExtensionForRadioData/issues/9#issuecomment-1695661484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMP5LTBIA5ZWWWZFARGRLJ3XXSJFNANCNFSM6AAAAAAUWWBLKI. You are receiving this because you authored the thread.Message ID: @.***>

[Bonnarel]

Le 28/08/2023 à 15:02, kettenis a écrit :

I agree that having a more detailed description of the spectral "support" would be desirable. Question is whether we expect the work on energy/frequency MOCs to be mature enough to include it in the first version of the proposed radio obscore extension?

Is there a pointer the energy/frequency MOCs somewhere?

— Reply to this email directly, view it on GitHub https://github.com/ivoa-std/ObsCoreExtensionForRadioData/issues/9#issuecomment-1695661484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMP5LTBIA5ZWWWZFARGRLJ3XXSJFNANCNFSM6AAAAAAUWWBLKI. You are receiving this because you authored the thread.Message ID: @.***>

Informal discussion between Pierre Fernique and other CDS people :

The principle of F-MOC coding as "frequency expressed on a long in EXPOSANT|MANTISSE coding" has been implemented both in the Mocpy library and in Mocjava to see what it would look like in practice.

And it does the job well at first glance. With François Xavier (Pineau), we manage to generate, trade and manipulate our first F-MOCs. And even FS-MOC and FT-MOC (only in java for the moment) But before we go any further, one of the key questions that some of you had raised was about the precision available depending on the plan concerned. I concocted this table just to put things concretely. I took about ten bands described by their UCD, and coded in F-MOC the central frequency.

Then I calculated with the help of FX the associated precision available at max orders (59), 39 and 19. In short, it gives us roughly 15 significant digits whatever the frequency band, and we divide the precision by 2

each time we reduce the order by one notch. Maybe it's clearer by looking at the table Regime Avg.freq                     Res59 Res39                     Res19

---

em.radio.100-200MHz             150MHz/1.995m 29.802nHz/4.1E-13m         31.25mHz/4.2E-07m 32.768kHz/4.4E-01m em.radio.6-12GHz                10GHz/29.93mm 1.907µHz/6.5E-15m              2Hz/6.0E-09m 2.097MHz/6.3E-03m em.mm.20-100GHz                 60GHz/4.988mm 7.629µHz/8.1E-16m              8Hz/6.7E-10m 8.389MHz/7.0E-04m em.mm.750-1500GHz          1.125THz/266.042µm 244.141µHz/5.0E-17m            256Hz/6.1E-11m 268.435MHz/6.3E-05m em.IR.30-60um                 7.5THz/39.906µm 976.562µHz/6.3E-18m         1.024kHz/5.4E-12m 1.074GHz/5.7E-06m em.IR.3-4um                   87.5THz/3.421µm 15.625mHz/7.9E-19m        16.384kHz/6.4E-13m 17.18GHz/6.7E-07m em.opt.R                     450THz/665.105nm 62.5mHz/9.9E-20m        65.536kHz/9.7E-14m 68.719GHz/1.0E-07m em.opt.B                     675THz/443.404nm 125mHz/4.9E-20m       131.072kHz/8.6E-14m 137.439GHz/9.0E-08m em.UV.100-200nm             2.25PHz/133.021nm 250mHz/2.5E-20m       262.144kHz/1.5E-14m 274.878GHz/1.6E-08m em.UV.10-50nm                  18PHz/16.628nm 2Hz/3.1E-21m         2.097MHz/1.9E-15m         2.199THz/2.0E-09m em.X-ray.soft                  265PHz/1.129nm 32Hz/1.9E-22m        33.554MHz/1.4E-16m 35.184THz/1.5E-10m em.X-ray.hard                16.5EHz/18.139pm 2.048kHz/3.0E-24m         2.147GHz/2.4E-18m 2.252PHz/2.5E-12m em.gamma.soft                615EHz/486.663fm 131.072kHz/1.9E-25m       137.439GHz/1.1E-19m 144.115PHz/1.1E-13m em.gamma.hard              2,000EHz/149.649fm 262.144kHz/2.4E-26m       274.878GHz/2.1E-20m 288.23PHz/2.2E-14m Are the resolutions at the maximum order (3rd column) compatible with the precision of the spectrometers that you know? For example for a UV spectro, I found that it went for example from 128 to 130nm (HST-STIS). The FMOC gives me a center resolution of 2.5E-20m.

It would allow us to roughly encode 1E+11 different values. Seems wide to me for a spectrum. Or ? I did the same with IR. The JWST/MIRI instrument produces spectra from 5 to 28µm. And here we have a central precision of 1E-19, and so this time we would have roughly 1E14 different possible values ​​for the spectra of this instrument.

[Bonnarel]

This issue cannot be solved for a single extension. It is relevant for an ObsCore upgrade discussion