t_exp_min, t_exp_max and t_exp mean

[alle-ira]

Sect 4.4 -
t_exp_min, t_exp_max and t_exp mean are parameters pertaining time domain and in fact are proposed in the IVOA Note "Pulsar and FRB Radio Data Discovery and Access". They are not useful for non-time domain data (both SD and interferometric) and should not be listed here. Also, we note that names used in the IVOA Note "Pulsar and FRB Radio Data Discovery and Access" (t_res_min, t_res_max and t_res) are different from those used here.

[kettenis]

Interferometric visibility data does have an inherent time-domain aspect, so I disagree with the statement that parameters pertaining the time domain aren't useful. As long as the instantaneous UV-coverage is sufficient, the visibility data can be used to construct a light curve at a time resolution comparable with the integration time. And the data product used for (VLBI) FRB localization is the same as for normal continuum observations; just with much higher time resolution.

That said, I'm not sure the proposed parameters make sense. For one thing the description in section 4.4 clearly suggests these are referring to time resolution aspects rather than time exposure. Also, visibility data within a data set usually has the same integration time. There may be shorter integrations at the start and end of a "scan" and in VLBI when sub-second integrations are used there may be small differences between the actual integration times to make sure they add up to an integral second. But these are details that should be largely irrelevant. So generally speaking t_resolution as defined in ObsCore will be good enough. And I don't see how a proposed t_exp_mean/t_res(_mean) would be different from ObsCore's t_resolution. One use case for t_res_min/t_res_max would be baseline-dependent averaging. This is an idea to reduce the amount of data by using larger integration times for short baselines and shorter integrations for longer baselines as the time-smearing effects that reduce the FoV hit the long baselines first. This is an idea that keeps being discussed in the community but I'm not aware of any instrument that actually implements this "in production".

Some coordination between the Pulsar/FRB proposal and this proposal may be desirable here. But the Pulsar/FRB proposal is only a note at this stage...

[alle-ira]

We agree that ObsCore time_resolution would be good enough for our purposes.

[Bonnarel]

To clarify where it comes from : t_exp_min and t_exp_max are about sampling , not about resolution strictly speaking

It has been introduced in epntap this way

time_sampling_step (min/max)

These parameters provide the sampling step in seconds for measurements of dynamical phenomena, and for computations. This is the time between 2 successive measurements or data, which is mostly relevant when the measurements are regularly spaced. This may also reflect an input parameter, e.g., for simulations or ephemeris computations. This parameter is intended to allow the user to search for time-resolved observations of dynamic phenomena, but can also accommodate the "repetition time" for several types of instruments.

time_exp (min/max)

These parameters correspond to the integration time (or exposure time) of measurements in seconds. They provide an estimate of the time resolution for dynamical phenomena, as well as an indication of relative S/N ratio inside a given dataset. This time is usually shorter than the time_sampling_step if both are present. It provides the overall integration time, i.e. individual exposure time x number of summed frames when relevant.

So in terms of the initial characterization data model which distinguishes resolution and sampling, this t_exp_mean is the sampling extent (duration of ilndividual samples). While the time_sampling_step is the characterization period (called cadence on the time axis if I'm not mistaking). The time_resolution is the minimal time shift which can be distinguished.

In the spatial domain sampling period (shift between two pixel centers) and sampling extent (size of the pixel) are often very close. But they are different from the spatial resolution (if well sampled the resolution should be worse, ie larger). For time I don't know. The epntap statement reads thatn the sampling extent is an indication of the resolution. But I don't know if this is valid in all cases.

In any case I agree that t_exp_min and t_exp_max are confusing terms. t_sampexp_min and t_sampexpl_max at least. or t_resolution if the naswer to the question above is yes in all cases.

[BaptisteCecconi]

In any case I agree that t_exp_min and t_exp_max are confusing terms. t_sampexp_min and t_sampexp_max at least. or t_resolution if the answer to the question above is yes in all cases.

There seems to be some confusion here. The proposal of t_exp_min and t_exp_max was to allow for providing the interval of values for individual exposure times in a time-resolved dataset (like in interferometry). This is different from the Obscore t_exptime, which is explicitly defined as the total exposure time.

The Obscore t_resolution term refers to the minimal interval between two samples of a time-resolved dataset. So t_resolution terms are about the temporal sampling intervals and t_exp terms are about temporal exposure durations.

So: I really disagree with this change. Another argument for the t_exp_min and t_exp_max terms: there are in the time-domain extension proposal for ObsCore. Do we really want to add even more confusion and have different terms for the same concept in different extensions? May be we should just rely on the time-domain Obscore extension here.

[BaptisteCecconi]

NB: in EPNcore we decided to move from "t_resolution" to "time_sampling_step" so that we are fully explicit with what we mean. But this a different discussion.

In EPNcore anyhow, we took the early design decision to have min/max ranges for any numerical value metadata. This adds a number of columns in the tables, indeed, and it implies to write queries a bit differently. Frankly, we don't regret this decision, since it regularly saves us time. Specifically when data providers don't have to take arbitrary decisions when there is only a single "typical value" term to fill and they want to give an interval. In any case, setting the min and max terms to the same value is equivalent to having a single term is a typical value.

[BaptisteCecconi]

The bottomline for me is to be able to advertise individual exposure to a time-resolved dataset. This may be suitable for the time-domain obscore extension, indeed.

[kettenis]

In any case I agree that t_exp_min and t_exp_max are confusing terms. t_sampexp_min and t_sampexp_max at least. or t_resolution if the answer to the question above is yes in all cases.

There seems to be some confusion here. The proposal of t_exp_min and t_exp_max was to allow for providing the interval of values for individual exposure times in a time-resolved dataset (like in interferometry). This is different from the Obscore t_exptime, which is explicitly defined as the total exposure time.

No kidding, but I still think part of the confusion stems from the choice of using 'exp' in these names.

The Obscore t_resolution term refers to the minimal interval between two samples of a time-resolved dataset. So t_resolution terms are about the temporal sampling intervals and t_exp terms are about temporal exposure durations.

Still not clear to me what the t_exp terms are supposed to represent. The exposure duration of a single sample? For the sampler setups we use in radio interferometry that will be the same as the interval between two samples. Or are you talking about the duration of a series of continuous samples here? Something that in VLBI we would call a scan?

I think we need an example here. And a scientific use case...

So: I really disagree with this change. Another argument for the t_exp_min and t_exp_max terms: there are in the time-domain extension proposal for ObsCore. Do we really want to add even more confusion and have different terms for the same concept in different extensions? May be we should just rely on the time-domain Obscore extension here.

[kettenis]

The bottomline for me is to be able to advertise individual exposure to a time-resolved dataset. This may be suitable for the time-domain obscore extension, indeed.

If these parameters are indeed only really useful in a "time-domain astronomy" context, that might indeed a better approach. But that does mean the "obscore + radio + time-domain" discovery discussed in issue #49 becomes important