Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RIDs by DDo about Additional QC parameters #267

Open
hugobuddel opened this issue Oct 24, 2023 · 3 comments
Open

RIDs by DDo about Additional QC parameters #267

hugobuddel opened this issue Oct 24, 2023 · 3 comments

Comments

@hugobuddel
Copy link
Contributor

Danuta Dobrzycka has added a whole bunch of RIDs about adding QC parameters

Seems fine to add those. The QC parameters are a bit of a mess anyway.

@hugobuddel
Copy link
Contributor Author

I've answered them all with something like

Thank you for the suggested QC parameters. We will add those and see which other parameters we can add to metis_det_lingain and the other recipes.

(Which I think is broken English, but well.)

@hugobuddel
Copy link
Contributor Author

All suggested QC parameters are sensible BTW.

We should also add QC parameters for instrument monitoring, see #270

@hugobuddel
Copy link
Contributor Author

Woah @JenniferKarr you did soo much work, thanks!

Some notes:

  • It is my understanding that the individual parts of the names may only be 8 characters. That is, the NPIXTHRESH in QC IFU TELLURIC NPIXTHRESH would be too long. No one from ESO complained about such names in the past, so it should be fine, but perhaps good to take into account. It could be that this 8-character limit is enforced technically, then we do need to make them shorter when implementing them, not sure though.
  • There is some kinda standardized way to represent statistics of other values, such as minimum and maximum values, see the "DICD"
    ESO-044156_7_DataInterfaceControlDocument.pdf . I don't think this is very strict, but we could take it into account whenever reasonable.

From the DICD:

In some cases, it is important to provide, in addition to the parameter value being reported,
also an error, range or some other statistical property. The convention for such cases is to
provide auxiliary parameters whose names share the first 5 characters with their root
parameter name and end with one of the strings given below:
• ERR error bars (e.g. FWHMERR), i.e. the uncertainty of the root parameter value in
both directions ( + and –);
• MIN/MAX minimum and maximum values (e.g. RHUMMIN, TEMPMAX) during a given
period of time (e.g. during the exposure);
• RMS root mean square of the parameter values during a given period of time;
• AVG average of the parameter values during a given period of time;
• SD standard deviation of the parameter values during a given period of time;
• PTV peak-to-valley variation of the root parameter values during a given period of
time.
The units of the ERR, MIN, MAX, AVG, SD and PTV parameters are always the same as their
root parameters.
In case of enumerated parameters, (e.g. TEMP1) the index suffix shall be added at the end
of the keyword (TEMPMAX1 in this example).

Lastly, I've token the liberty to fix some broken links. The \QC{} macros etc automatically create hyperrefs, and some didn't resolve. I fixed those where the intent was obvious. I'm happy with fixing those BTW, as it is a small contribution to your momentous work. There are four that I could not find, so I'm assuming you just didn't get to adding those yet; I'm merely listing them here for completeness/reference:

  • QC LIN MIN FLUX
  • QC LIN MAX FLUX
  • QC GAIN LINEARITY
  • QC GAIN COEFF

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant