instrumentation details

[Bonnarel]

Discussion started after 2023-11-98 release

[Bonnarel]

Another somewhat questionable example is use case 1.10. The minimum number of antennas for a "good" observation really is instrument-specific and the maximum distance between antennas really is just a very poor way of expressing a resolution or uv-coverage constraint for which we already have columns. So unless someone can come up with a scientific use case for these parameters, I think they should be dropped from the extension.

-- MarkKettenis 2023-11-10

[Bonnarel]

Apologies that I have not been following this in detail but whilst I agree with Mark that 1.10 is not a realistic use case, selection by uv coverage is, but just the number of antennas and extrema of baseline lengths is not enough. On the other hand, often all archives provide is baseline length (or even just antenna positions), frequency, pointing direction and observation duration. Metrics related to uv coverage density can then easily be calculated (as in the L5 and L80 etc. metrics in the ALMA archive) but I don't know if this is commonly seachable directly for any archive. So it is not just a matter of what is commonly searched for, but also what archives provide and how much there can be an interface to convert the latter to the former. -- AnitaRichards 2023-11-10

[Bonnarel]

The columns the DaCHS extension now offers are f_resolution, instrument_ant_diameter, instrument_ant_max_dist, instrument_ant_min_dist, instrument_ant_number, instrument_feed, obs_publisher_did, s_fov_max, s_fov_min, s_maximum_angular_scale, s_resolution_max, s_resolution_min, scan_mode, t_exp_max, t_exp_mean, t_exp_min, tracking_mode, uv_distance_max, uv_distance_min, uv_distribution_ecc, uv_distribution_fill

(select column_name from tap_schema.columns where table_name='ivoa.obs_radio' order by column_name)

This doesn't mean I'm convinced all of them should be in. But it does mean that I'm pretty sure all others should go from table 1; in particular, the "via DataLink" things I think are just confusing in there.

-- MarkusDemleitner 2023-12-11

[Bonnarel]

I raised my concerns about the instrument_* columns during the InterOp. Those really are instrument specific and therefore not very useful in generic queries one would issue to multiple TAP services. It may make more sense to provide this information in an observatory specific table (see for example the presentation by Greg Sleap on how the MWA presents information like this).

-- MarkKettenis 2023-12-13

[Bonnarel]

• Given that ObsCore is meant for data discovery, any instrument specific details should be removed as much as possible, to make sure that a cross-ObsTAP-service-query will Just Work ™. That there may be a (defined) mechanism to get to instrument specifics would be important to have - e.g. for visibility data te u,v-plane characterisation. These could be standard extensions of ObsCore but could live outside the ObsCore standard itself if you catch my drift.

• Very much related to that, columns like instrument_and_diameter, instrument_ant_number, or almost all instrumentant* for that matter, are, for any array of radio receivers unhelpful. I have argued before. In my opinion they'd fall under an instrument characterisation. I'm also thinking of dipole or large-N-small-D arrays here, in the event they'd want to publish some visibility data.

Possibily a proper instrument characterisation mechanism can be thought of, but in the end, only two things are important for interoperability I think: what was the instrument signature at the time of observation and has it been removed from the published data.

My .02 arbitrary currency units, obviously.

MarjoleinVerkouter 2023-12-18

[Bonnarel]

Humm, before ruling out all this, I just want to explain where it came from. This was not a fantasy of the editor or first authors.

To help a user to discover quality data we have to give a way to estimate this quality, by trying to characterize the original raw data.

Of the course the uv plane characterization is the best we can do, but if we cannot provide them whta can be done ? nothing ?

Our background was this rather old but very comprehensive note by Anita Richards

https://wiki.ivoa.net/internal/IVOA/SiaInterface/Anita-InterferometryVO.pdf

The whole section 1.1 is to be read again.

But I would like to mention here these excerpts :

Component telescope properties, such as location and diameter, can be used to deduce other prop- erties if these are not provided explicitly. Should these be included in this model or in Prove- nance/Observation (and/or a link to the array web page in the absence of the latter models)

and

Diagnostics of the uv plane coverage. – Most conventional radio archives provide links to plots (such as Fig. 1) of visibility am- plitude as a function of uv distance This is in dimensionless units of (projected baseline length)/(observing wavelength), or SI multiples, written as e.g. Mλ (mega-lambda). – Table 1.1 provides a machine-readable quantification of Fig. 1. – The range of the maximum and minimum uv distances present in a data set is the simplest fairly accurate quantifier. The example shown in Table 1.1 gives 114.93–3553.52 kλ.

– The range of intermediate spacings available as well as the limits of uv coverage affect the data quality. There is no commonly-used universal quantifier for this although the coverage could be described in more detail using the finer levels of Characterization. Astronomers usually inspect plots such as Fig. 1 or the dirty beam (see Section 1.2 and Fig. 2). The time axis also provides some information, see below. – A crude estimate of coverage can be obtained from the number of participating telescopes, the maximum and minimum baselines on the ground in m or km and the duration of the observation (last item bolded by me)

So if the data provider is not able to quantifify the uv plane quality some of these instrumental details seem to be useful

In addition, immediatly before we started the radio interest group in the VO there was an Asterics project / ESCAPE project initial work on that

which happened to be a first contribution.

A dedicated meeting on "radio astronomy data in the VO" was held in Strasbourg in february 2019.

Several radio astronomers gave talks about their needs and requirements for data discovery.

Loook at Katarina Lutz presentation here :

https://www.asterics2020.eu/dokuwiki/lib/exe/fetch.php?media=open:wp4:wp4techforum5:talk_klutz.pdf

or Yelena Stein's one

https://www.asterics2020.eu/dokuwiki/lib/exe/fetch.php?media=open:wp4:voradio_stein_.pdf

I copy paste you two interesting slides (one from each of these two talks) below

So my conclusion : I understand we still have to discuss the details and science cases. But do not exclude instrumental and configuration details

to early.

-- IVOA.FrancoisBonnarel 2024-03-08