You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have several similar (but slightly different) scenario's:
a recipe accepting data for any of the detectors, GEO, 2RG, or IFU, and that should output a data product of the same detector,
a recipe accepting data for any of the 'bands', N, LM, or IFU, and that should output a data product of the same detector
the flat recipe accepting either LAMP or TWILIGHT flats that should output a master product of the same kind
the recipes that accept either STD or SCI and should output something of the same class
It would be good if all these recipes share the same structure to accomplish the task of creating output products that match the input products. That is, we should not invent the wheel 4 times.
Maybe we can also apply this to other places e.g. IFU_TELLURIC is currently only a single data product, but it can be derived in three different ways. Maybe there should be three different data products, like IFU_SCI_TELLURIC, IFU_STD_TELLURIC and IFU_CLASSIC_TELLURIC or something like that.
Also, we can deviate from the DRLD if we want to. I like to stress that deviating from the DRLD should be a conscious collaborative action (that is, not accidental by an individual), and that we should then also update the DRLD. Or at least, there should be a machine readable version of our data model, so it can be used by the archive etc; using the DRLD for that shared source of truth is just convenience.
There are product name hard coded in the metis_lm_img_basic_reduce.py. We should revised this part
The text was updated successfully, but these errors were encountered: