[Radioig] Comments on ObsCore extension and Pulsar/FRB draft documents {External}

[John Tobin]

Hi All,

This is my first correspondence since being added to the group. I had a 
few comments that I noted in the PDF, but wanted to highlight a few of 
them in my message.


1. spelling of names/definintions/utypes - antennae -> antennas, 
excentricity -> eccentricity or ellipticity hence uv_distribution_exc 
might not be appropriately named.

2. uv_distribution_fill - this definition seemed quite confusing to me 
as written it seems like you would always get an answer of 1/N_samples, 
I think it needs to be summation over i,j for n_cells with n_points 
 >=1/n_cells. Maybe I am reading the definition incorrectly. The other 
issue with this definition is that it does not account for the fact that 
a dataset can have a large number of channels, where each is actually is 
own uv point. Each entry in a VO Table will be split into some number of 
channels, so this might need to be addressed and perhaps requires its 
own field. Finally, the uv filling factor will also be different 
depending on whether a user has continuum or spectral line observations 
in mind, continuum will have multi-frequency synthesis which implicitly 
increases its uv-coverage, while a spectral line applications will have 
worse uv-coverage implicitly.

3. uv_distance_max, uv_distance_min; This might not quite be 
fine-grained enough because you might have one really long baseline and 
one very short baseline, but an array is actually configured somewhere 
in between. Perhaps also adding a 75th percentile baseline and 50th 
percentile baseline distance would be useful to add to this since those 
values would provide more information about where most of the 
uv-coverage is concentrated.


4. sky_scan_mode - this has applications beyond just single-dish as 
listed because interferometry data also have single-pointing, mosaic, 
and on the fly mosaics. Also, for single-dish there may be other modes 
that are not covered like drift-scan.

5. s_resolution_beam_dirty - it is unclear what is intended here, 
whether it's to be a map of the dirty beam or the resolution of the 
dirty beam. If it's the resolution, this is somewhat redundant because 
the resolution of a cleaned map is derived from a Gaussian fit to the 
central core of the dirty beam, and there would be a degeneracy with 
what is provided by s_resolution. The dirty beam image, or psf image as 
CASA refers to it, is not always archived. ALMA and the NRAO do not 
include it in their standard image products for instance, so it is 
unclear how readily available this information would be for most archives.

Best,
John Tobin

On 1/3/23 14:47, BONNAREL FRANCOIS wrote:
> Dear Alessandra,Vincenzo and Marco,
> Dear members of the Radio IG;
>
> First of all I would like to wish you all in the group an happy new 
> year , the best things we can imagine for our personal and 
> professional lives  and great successes and achievements  for our group;
>
>
> Le 17/11/2022 à 18:57, Alessandra Zanichelli a écrit :
>>
>> Dear all,
>> we would like to share with the Radio Interest Group some 
>> considerations triggered by our work on single dish/pulsar data and 
>> related to the two draft documents: IVOA Obscore Extension for Radio 
>> data Version 1.0 (IVOA Note 2022-10-14) 
>
> i realize that this version although announced at this date and 
> briefly presented during the interop can be hardly found on github 
> because it's related to a Radio branch which has not been merged with 
> the main branch yet.
>
> Actually this was an attempt to extend the previous 
> ObsCoreExtensionForvisibilityData 
> (https://github.com/ivoa/ObsCoreExtensionForVisibilityData) into a 
> more general ObsCoreExtensionForRadioData)
>
> We needed some more feedback to merge in the main branch. You can find 
> the extended version attached with this email. This is the version 
> which Alessandra, Vincenzo and Marco are commenting.
>
>> and Pulsar and FRB Radio Data Discovery and Access Version 1.0 (IVOA 
>> Note 2022-09-22).
>> We hope these considerations may be useful to trigger some discussion 
>> before moving them to issues on the github version of the documents.
>
> Thanks for that. I answered and commented all the points you addressed 
> in the google document only today !!!
>
> To list the points which are discussed;
>
> - Need for new dataproduct_types for single dish data or need for new 
> parameters to describe single dish observations
>
> - Need for a spectral "support" for very wide band radio data as a 
> testbed case for emoc.
>
> - definitions of s_fov and s_resolution in the wide spectral band 
> radio case ; min, max, and mid values.
>
>>
>> We thought that - at this preliminary stage - a Google document may 
>> be more efficient to share ideas and comments in a collaborative 
>> manner, this is the link:
>> https://docs.google.com/document/d/1CQZytl5B2n5vojn7bcVakLSzAig_ymGgIdwy74ssFXo/edit?usp=sharing 
>>
>>
>> Please feel free to suggest and comment as you like.
>
> i think most of these things can also be transformed in github issues; 
> i think I can transfer that tomorrow; but if people prefer google docs 
> please go on there.
>
> Cheers
>
> François
>
>>
>> Cheers,
>> Alessandra, Vincenzo and Marco
>>
>>
>> ------------------------------------------
>> Alessandra Zanichelli
>> Istituto di Radioastronomia - INAF
>> Via Gobetti, 101
>> I-40129 Bologna - Italy
>>
>> Email: a.zanichelli at ira.inaf.it
>> Phone: +39-051-6399366
>> Fax:   +39-051-6399431
>> ------------------------------------------
>

-- 
John Tobin
Scientist
Science Ready Data Products (SRDP) Project Scientist
National Radio Astronomy Observatory
jtobin at nrao.edu
+1-434-244-6815
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObsCoreExtensionForRadioData_jt.pdf
Type: application/pdf
Size: 569392 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/radioig/attachments/20230104/92b5eaf8/attachment-0001.pdf>