The H4RG quantum efficiency response curve needs an update

[carmeloarci]

The file
MICADO/MICADO_H4RG.yaml
is currently pointing to a quantum efficiency vs wavelength profile of the old H2RG detector that is not correct (MICADO/QE_detector_H2RG.dat).

MICADO will use H4RG-15 instead.
Unfortunately, the H2RG curve currently used is badly cutting the response in the I-band.
Something like the following (better) matches the expectation:

or look here
https://onlinelibrary.wiley.com/doi/full/10.1002/asna.20230058

[carmeloarci]

In the meantime, I'm using this file by extracting the data point from an FDR MICADO document
QE_detector_H4RG.zip
ELT-TRE-MCD-56309-0004
issue : 2.0
date : 12.04.2021
page : 19 of 54

[carmeloarci]

Just in case, I updated the file for QEff of the H4RG. See here:
MICADO_detector_H4RG.zip

[hugobuddel]

Thanks for doing all this work @carmeloarci !

Side note: the idea behind the IRDB is that the consortia can themselves update the information, so feel free to create branch with this new data and make a pull request. Preparing a pull request (PR) is certainly the fastest way to get things into the IRDB, because if all the tests pass, then we will probably just merge it.

It is also fine to have us create the pull request though. The idea is to empower you to update the information independently of our schedule and planning. The previous week I was preoccupied by some other projects; I can probably look at your new numbers next week.

In this particular case, we do have some tests to check the optical performance of the MICADO simulations. It seems that we do not yet have (adequate) tests for the quantum efficiency, so maybe we should add those.

[carmeloarci]

Ok. I try to create a new branch and make the pull request

[carmeloarci]

I seems that I cannot:

• open a new branch
• upload a file

[hugobuddel]

The usual procedure on github is to create your own fork, create a branch there, and then push changes to that branch, and then make a pull request to the original repository. A fork is essentially a copy of the repository in your own github account.

This process is fairly automatic if you press the 'edit' button (a pencil) on a specific file. In this case, the specific file you probably want to edit is https://github.com/AstarVienna/irdb/blob/dev_master/MICADO/QE_detector_H2RG.dat

Github should guide you through the process if you go to that page and press the pencil in the top right corner. It will first suggest to make a fork, then you can edit that fork, and when you commit your changes, github should suggest to make a pull request to this repository.

You can also clone your fork on your own machine (with git clone), and then commit the changes on your machine (git commit), push them to github (with git push), and then create the pull request. Git should print the instructions on how to make a pull request when you push your branch.

By the way, most files contain some meta data at the top, for example, where the information in the file came from, and who edited the file and why. It would be great if you could keep that information up-to-date if you edit a file.

[carmeloarci]

Ok. I tried to make the pull request. Hopefully, it is all ok.
#153

[hugobuddel]

Thank you @carmeloarci . I tried to make it worth your time by giving some elaborate feedback in #153. My conclusion is that we should do it, see detailed discussion in #153. I'd like to get confirmation from @astronomyk or JUP though if possible.

One note about git branches: it is more convenient (for you) to create a 'feature branch', with a unique name. It is common to use your initials, e.g. ca/h4rgqecurve could be a nice name.

The problem with using dev_master, even in your own fork, is that the 'upstream' (this repository) version of dev_master might get commits before yours is merged, and this will lead to the branches getting out of sync, complicating merges. But FWIW, 'never commit to the default branch' is something we have all learned (and relearn) the hard way.

[astronomyk]

@carmeloarci thanks for creating this pull request!
Just to add my two cents - I see no reason to not update the QE curve to the latest version. The H2RG is still a legacy of SimCADO and so is most definitely in need of a refresh.
It seems the file format in #153 is fine, so I'd say we can go ahead an merge it.
I'll run the MICADO tests once I fix the dev_master version of scopesim, and if everything still works we can push an update to the instrument package server. This might take a week or two, depending on my work load.