RadioAstronomy in the VO

14/11/2019 telecon

At the call: Mark Lacy [ML], Alessandra Zanichelli [AZ], Marco Molinaro [MM], Mark Allen [MA], François Bonarel [FB], Janet Evans [JE], Bruno Merín [BM]

Inputs from VLA (Mark Lacy)

1) As an astronomer who is interested in searching for extended CO emission at high redshifts, I wish to find all the VLA data between 30 and 50 GHz including in the results only observations having sensitivities on scales of 20” and larger, with frequency (velocity) resolution better than 50km/s, and with a total bandwidth >2GHz.

2) As an astronomer who is interested in the repeatability of polarization calibration, I wish to find all the VLA and ALMA data with calibrated Stokes IQU polarization in the range 30-100GHz for the source 3C 286 (including both observations where it was used as a calibrator and those when it was the main target).

3) As an astronomer who is interested in the magnetoionic environment around the galactic center, I want to find all the archived Faraday rotation measure cubes and 1D spectra within 2 degrees of the galactic center that are sensitive to rotation measures >100 rad/m^2, irrespective of telescope. (more advanced use-case)

Inputs from CDS (François Bonarel)

+ CDS provides radio cubes in the Vizier associated data service.

selection by wavelength range doesn't allow to distinguish "radio line" cubes (such as 21 cm) and continuum ones.

a solution could be to use the o_ucd column in obscore. The main ucd states for the measured quantity. The complementary part of the ucd can allow to distinguish the two different data "types"

eg : phot.flux;em.line ----> radio line

phot.flus;em.line.HI ---> 21Cm line

phot.flux;spect.continuum --> radio continuum (and look at em-min, em_max ) to know where

The issue is that neither VizieR, nor ATCA provide the correct values in o_ucd (this is basically not used)

---> A good idea could be to encourage data providers to use this column for this kind of usage and clientapplication developpers to read it and use it.


+ Some observations gather several very different things . Most interferometers are able to observe with multiple detector setups simultaneously. For example observations made by some CDS astronomers would always produce two sets of continuum measurements and two sets of HI measurements.

It would be very nice to see these things appear as several distinct rows in Obscore. (could also imagine that they share the same obsid in order to find back they belonged to the same "observation")


+ cubes FOV are very useful. Retrieving them in MOC would be valuable for further catalog or dataset queries inside the FOV

ML does not see the need to differentiate between line and continuum if you can select by frequency.

FB: from discussions at CDS, it was clear that in case of unkonwn radial velocity/redshift, you might need some higher level description of what is a line and what is continuum..

AZ: for us, this line/continuum distinction would be useful since there are now many observations trying to produce line cubes.

Inputs from INAF (Alessandra)

INAF radio telescopes observe in interferometric and single dish mode. In both cases, the radio archive stores raw data. It is planned that at some point we will be able to store also data reduction products, but this is not going to happen in the (very) near future.

I have as a first step mostly focused on use cases for single dish data. Interferometric ones are mostly common to other such instruments, for instance the use case 1) described by Marc Lacy.
Also, I consider the retreival of raw data for further processing by the archive user.


--> Data product type: it seems that the best value to describe our data could be 'visibility'. However, there is a large variety of data types coming from our telescopes: visibility files for interferometry, single dish maps/cross scans/pointed, dynamical spectra, pulsar data in folding or search mode. We have to understand how to represent this variety. Other attributes can be used? Define a vocabulary for data product subtype?


--> Single dish data: the geometry of the observation (examples of scan types: CROSS SCAN, MAP, ON-OFF) is strictly related to the scientific content of the data. Thus, the science one wants to do (or can do) depends on the availability/discoverability of a specific dataset type.
Some possible (very simple) use cases of this kind:

1) retrieve the observations of the Sun done in MAP mode at 22 GHz. (Scientific application: space weather and solar physics studies.)

2) retrieve the observations of the calibrator 3C48 done in CROSS SCAN mode at 5 GHz from Oct 1st 2018 to Oct 1st 2019.
(Scientific application: monitor the variability of a calibrator source.)


--> Single dish with multi-beam receivers: describe the footprint of the dataset. How many beams? Which geometry they have on the sky?
When retrieving a raw data set, this information is crucial for the archive user in order to estimate if the efficiency of the observation (n. of beams coupled with exposure time and scanning parameters) can match the desired science goal. This should be evaluated before data retrieval.
As an example, mapping of a Supernova Remnant: for the same exposure+scanning parameters, the number of available beams affect the final sensitivity on the map. Depending on the frequency, it affects also the accuracy in the removal of the sky signature.
(Coverage class s_region could be useful?).

AZ: regarding VLBI data, there are several targets inside every single observational set and also in the near future there will be simultaneous frequency receivers so we will have different types of data products that should be taken into account.

FB: data product type is handled in ObsCore by DM WG in collaboration with the DAL (Data Access Layer) group, where data vocabularies are discussed. Ada Nebot proposed to complete the "data product type" by a more accurate normative "subtype" and this is being discussed at the moment. Participation from Alessandra to characterize the radioastronomy data types would help enormously getting radioastronomy data discoverable in the VO.

FB: re. the second question (the source vs the observations), the proposal might be to do a binary response from the s_region (target in the observation or target not in the observation). If you would need sensitivity in the target position, then further investigation might be needed.

ML: re. the multi-band dataset, we do have them at the VLA, not simultaneous but in the same visibility files. The products are typically separated (S and C-band) are separated.

Inputs from ASTRON (Yan Grange)

The plan of Jive is to implement the VO to their archival data. This
requires making visibility data available to the VO.
For ASTRON, the short-term (funded) work is mostly bringing existing
surveys into the VO first. We are however happy to participate in the
discussion with respect to the visibilities even though implementation
is currently not part of the plan.

We flagged the following list of user types, ordered on the relevance
for the VO (i.e. from typical VO users to more probable to use other
ways of data access):
1. general astronomer
2. radio astronomer
3. expert user
4. PI


Parameters we should be able to search on (question is: what needs to be in obscore and what should be an application filter):
- Position on the sky
- fractional bandwidth
- exposure time
- polarisation type
- min. max resolution (this also translates to shortest/longest baseline)
- time resolution
- spectral resolutions

From a scientific perspective the following use cases could be used
1. Transient analysis. If a transient went off, a user should be able to
query historical observations of the position on the sky.
2. Wide-field search. The quality of off-centre sources strongly depends
on the beam shape and sensitivity.
3. Solar physics/space weather. There are images/data cubes, beamformed data and visibilities
that can be searched for.


Points that require further discussion:
1. provenance.
1a. How do we handle multi-beam data? (is this a problem at all if we
consider each beam as a separate observation pointing)?
1b. Coupling of calibrator and target. A specific calibrator has been
observed for the calibration of a specific target so those should be
somehow linked.
1c. Coupling of derived data (e.g. images pulse profiles) to raw data
sets (e.g. beamformed data, visibilities)
2. Filtering the results for instrument-specifics. This may be mostly
applicable to user groups 3 and 4, and therefore not necessarily a
problem of the VO. 
3. How to characterize UV-coverage and therefore sensitivity to certain
type of sources.

FB:  For 3, wide-field search is related to the discussion above regarding the s_region 
and the on/off response from the services. This has been discussed with Marco
Iacobelli. 
-- IVOA.FrancoisBonnarel - 2019-12-16 added :
We could consider a coarse grain search first to find out a list of candidates
and then proceed to fine-tuned sensitivity estimation.  

FB: regarding the provenance, I need to read this in details and see what
can be proposed for this usecase.
-- IVOA.FrancoisBonnarel - 2019-12-16 added : 
1b and 1c can definitely enter into IVOA provenance metadata frame: derived data are entities related to visibility entities (or whatever)
 by a (sequence of) activities. 1a can be easily managed at the Obscore level. Each "beam" has a row in ObsCore table but several rows 
may share the same "obsid" value. Further details on the observation could be given by some "provenance metdata" but Provenance DM 
has to be extended for entities and activities with observation or device types. 

Inputs on ESCAPE (Mark Allen)

Attachment.

ML: regarding ALMA, they are developing VO interfaces in all region data
centres, including a TAP interface to their observation table.
FB: Felix Stoehr gave me the access to the ALMA ObsTAP server, when you click
on the data URL you go to the native website with that website. This is
a minimal way for integrating the data into the VO world. It seems to be
on-development.

Common low-hanging fruit use-cases

BM: most use-cases have in common the need to search for data in a given position in the sky (target/coordinates) so implementing the
 content of footprints for all the RadioAstronomy observatories above would achieve a lot of functionality.
FB: using DataLink we could add further info like sensitivity, or any other more advanced filtering could be made possible. Maybe users can make
 first a first selection based on position. This was discussed with -- IVOA.MarcoIacobelli, -- IVOA.MireilleLouys and -- IVOA.MarkusDemleitner
 already in the context of ASTERICS.
ML: In the VLA and ALMA, the content of the footprints, even for the mosaic observations are defined.
BM: for ALMA we have been able to query and retrieve the footprints. ML: for the VLA, all the metadata required to create the footprints is available but
 we would need to construct that new field.
AI_ML: talk to the project scientists and try to produce prototype footprints such that the observations can be found in VO interfaces.
MA: for CDS, the coverage has been computed in the form of MOCs (Multi-Object Coverage maps). How does this relate do the s_region metadata?
FB: this was already discussed at Groningen and in the context of the DALI specification upgrade. Many people want to have MOCs as region description for their datasets. 
That is being discussed. DALI might get the MOC s-type in the next version. For ADQL that might take more time. For the s_region description in the MOC that might require
 an update of the ObsCore standard.
MM: The s_region in the MOC is under definition and the current thinking is to add a double entry. We should be careful to have a standard that does not allow ambiguities.
AZ: at the moment we are working on the data descriptions, probably the s_region or the MOC, as described. Mostly for the description of the raw data. This will be done in 
a way that is VO compliant from the beginning.
AZ: regarding the multi-beam receiver, there might be some confusion between e.g. LOFAR or single dish. INAF uses these type of receivers to increase the sensitivity on a 
single sky position, instead of to get a wider coverage.
AI_AZ: investigate VO footprint definition for INAF radiotelescopes and report back.
YG: the regional coverage is something different in ASTRON and JIDE given the differences in the observatories.
AI_YG: investigate the possible mapping of coverage information in ASTRON and JIDE onto VO footprint definition and report back.
AI_MA: make the ESCAPE SKA contact aware of this work and invite them to join the work.
FG: ASKAP are involved in the first version of the protocols in last year's efforts on cubes and their services are working already with MOCs for full collections that allow
 quite advanced data searches already. James Dempsey provided examples at Groningen.
FG: together with Yan, we confirmed that LOFAR VO services work fine with Aladin and datasets and cubes can be found.
AI_all: circulate URLs of the different TAP services, interfaces, and examples of working systems in the different radioastronomy observatories.

<!--

 

 

• • Set ALLOWTOPICRENAME = TWikiAdminGroup
    -->