RadioAstronomy in the VO

14/11/2019 telecon

At the call: Mark Lacy, Alessandra Zanichelli, Marco Molinaro, Mark Allen, François Bonarel, Janet Evans, Bruno Merín

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 by the DAL (Data Access Layer) group, where data vocabularies are discussed. Ada Nebot proposed to separate the data product type and 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 respone form the s_region (target in the observation or target not in the observation). If you would need sensitivity in the target position, then more implementation 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)


Inputs on ESCAPE (Mark Allen)


Common low-hanging fruit use-cases

 =BM: most use-cases have in common the need to search for data in a given= 

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2019-11-14 - BrunoMerin
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback