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

Product name should not hard coded #71

Open
chyan26 opened this issue Dec 9, 2024 · 1 comment
Open

Product name should not hard coded #71

chyan26 opened this issue Dec 9, 2024 · 1 comment
Assignees

Comments

@chyan26
Copy link
Collaborator

chyan26 commented Dec 9, 2024

There are product name hard coded in the metis_lm_img_basic_reduce.py. We should revised this part

@chyan26 chyan26 self-assigned this Dec 9, 2024
@hugobuddel
Copy link
Contributor

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.

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

2 participants