Radio interest group session at the May 2023 Interop

Speakers: 
    Pety 
    Schussler
    Cecconi
    Bonnarel
    
    
    J. Pety: The IRAM information flow
    40TB/yr NOEMA, 28TB/yr Pico
    CDS advising on the VO port (thorugh ESCAPE)
    Working on importing user data products, workflow defined.
    PI can link publication DOIs
    Interactive visualization with YAFITS
    
    FB: do you have plans for a VO service?
    JP plan to have a TAP service
    
    F. Schussler:
        Astro-COLBRI multi-messenger 
        Events -> Brokers -> Follow-up observing
        Large variety of brokers, not all use VOEvent
        Many telescopes have automated follow-up 
        Radio events still usually distributed by astronomer's telegram. Maybe read them automatically?
        UTMOST was sending VOEvents (but shutting down) CHIME is sending VOEvents (but not public).
        Most radio observatories are a patchwork of other methods.
        Default platform is now GCN, originally GRBs but now expanding more, include VOEvent distributions now but plan to move away to their own format (Kafka)
       Seems to be a fracturing of alert formats and transport protocols.
        
Qs (nearly inaudible) about format vs content of the alerts and how different formats can be accommodated
Large observatories can probably adapt to changes in format, smaller organizations will have a harder time to adapt

B. Cecconi:
    MASER service (low frequency radio toolbox)
    a lot of dynamic spectra (including polarization), waveform data, event data and catalogs (not images)
    TF-cat - geometry with coordinates in time and frequency (or other variables) as points or polygons
    
B Cecconi: data sharing prototype for pulsar data 
folded light curves, a lot of metadata
Most exchange of pulsar data is done wirh PSRCHIVE format, not PSRFITS
Multibeam data: one row per beam
suggest defining a new dataproduct-type "hyper-dynamic-spectrum"
instrument_name -> backend name
pol_states need to include more allowed values e.g. ReXY, ImXY
Need a pulsar name resolution service

FB - pol states in ObsCore were coming from the FITS convention. Baptiste will check

FB - will organize a running meeting in the coming months for further discussions

Francois: ObsCore extension

FB will send the document coordinator at the end of the week to move the IVOA radio extension doc to a working draft (discussions can continue).

Hot topics:
    scan modes for single dish
    more breakdown of instruments (backend, correlator etc)
    tracking mode
    data product types
    MOC needs expansion into frequency (and time)
    
    f_min/f_max Add columns versus functions? Functions could work for obsTAP, but not for other protocols
    s_fov - min/max or mid-value? Similarly for s_resolution. Depends on the data provider.
    
    o_ucd - raw ADU, voltages etc not represented.
    
    How to delare extension in registry? MODEL element in the capability, table utype, how to deal with any inconsistencies between extension and main ObsCore table.
    
Q. obsecore extension, would it be another table? Yes, would probably be another table, or extension that could include more columns in the Obscore table. 

May have a discussion on Friday.