Make a new instrument object for the NIRC2 post electronics upgrade?

[abhimat]

I'm currently updating the pipeline to handle the changes to the output data since the new electronics upgrades on NIRC2. I'm not sure if it's best to leave NIRC2 as one Instrument object, or to have separate NIRC2 Instrument objects for NIRC2 pre-upgrade and post-upgrade.

Namely, several of the FITS header keywords have changed, so it would be easiest to start a new Instrument object with new hdr_keys. But I'm not sure if that's the cleanest way to approach this, or how I should name the new and old Instrument objects for least confusion for other users!

@jluastro : do you have any thoughts on how to best approach implementing the necessary changes for the NIRC2 electronics upgrade?

[jluastro]

This depends on how extensive the changes are. If it is minimal, then I’d suggest we keep the same instrument and just put in date checks for changed header keywords, etc.

Do you have a list of how many header keywords are changed?

The other issue is if we are going to have to change any thresholds for cosmic rays, etc. This might require adding some new functionality into the instrument object to serve up such instrument-dependent quantities. We already have these in place for something like distortion maps (which are date dependent). We handled OSIRIS imager upgrades this way, so same should apply for NIRC2 electronics upgrade.

Jessica

On May 16, 2024, at 5:28 PM, Abhimat Gautam @.***> wrote:

I'm currently updating the pipeline to handle the changes to the output data since the new electronics upgrades on NIRC2. I'm not sure if it's best to leave NIRC2 as one Instrument object, or to have separate NIRC2 Instrument objects for NIRC2 pre-upgrade and post-upgrade.

Namely, several of the FITS header keywords have changed, so it would be easiest to start a new Instrument object with new hdr_keys. But I'm not sure if that's the cleanest way to approach this, or how I should name the new and old Instrument objects for least confusion for other users!

@jluastro https://github.com/jluastro : do you have any thoughts on how to best approach implementing the necessary changes for the NIRC2 electronics upgrade?

— Reply to this email directly, view it on GitHub https://github.com/Keck-DataReductionPipelines/KAI/issues/32, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALEJQFHZFQUSQKPQDEGDQ3ZCVFJLAVCNFSM6AAAAABH3FSPYWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYDCNJYHE4TOMY. You are receiving this because you were mentioned.

[abhimat]

Thanks! The main challenge I'm having with using the existing NIRC2 object is that the hdr_keys dictionary is set up during object instantiation (when the object doesn't yet know what's in the file headers). There aren't many header changes that affect KAI, but I would want to specify some of the new header name changes there.

As it is, we don't pass in the FITS header as a keyword during instrument object instantiation in __init__() (lines 66--92 here), so I couldn't figure out a good way to determine if we're working with the old or new NIRC2 electronics during this stage of the instrument call. Perhaps having an optional keyword in the __init__() function of the NIRC2 instrument object would allow determining if we're working with pre-upgrade or post-upgrade files?

In the other functions, we pass in the FITS header to the function. So determining the date from the header to determine pre- or post-upgrade is pretty straightforward in the existing NIRC2 object!