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

BONNAREL FRANCOIS francois.bonnarel at astro.unistra.fr
Wed Jan 11 18:39:19 CET 2023


Hi John, all
Thank you John for your feedback.
Le 04/01/2023 à 20:32, John Tobin a écrit :
> 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.
OK thanks.
>
> 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.
I see your point, and would like to have comments coming from our Astron 
and JIVE colleagues who originally proposed to characterize the uv 
coverage this way.
>
> 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.
>
Good point, we were already wondering how to estimate "effective 
numbers" for these two quantities in order to avoid "outliers". Your 
percentile is an interesting proposal to investigate. Or can we find 
another significant minimum and maximum estimation ?
>
> 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.
OK. thanks for that. In that case we have to restructure the text.
>
> 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.
>
Obviously the idea was to add a FIELD containing a link to the dirty 
beam map. The idea was to display it to help the user to figure out the 
level of quality of data. And this not a queryable column of course.

Cheers

François

> 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
>>> ------------------------------------------
>>
>



More information about the Radioig mailing list