Scale flash reference file to observation date in CALACS flash correction

[jryon]

In the event of HST budget cuts, we may end up with very little support for ACS/WFC observations in FY26. In that case, we will not take data for post-flash reference files. The flash rate in those files has been decreasing linearly over time, so we'd like to add in a linear scaling factor to the flash correction step in CALACS to appropriately scale the last available post-flash reference file's flash rate to the observation date.

We will update this issue when we have more details on the linear scaling factor and observation date after which to apply this change.

Note that if ACS/WFC support continues into FY26, we would not implement this change to flash correction. So, development of these changes can proceed, but until we know more about the fate of ACS, we should wait to merge it into CALACS.

[jryon]

@mdlpstsci @pllim Here's the scaling factor by which to multiply the SCI and ERR arrays of the last available post-flash reference file prior to flash correction in CALACS:

s = [m * (t_obs - t_0)]/F + 1

where m is the slope of the linear decrease, t_obs is the observation MJD of the input image, t_0 is the USEAFTER MJD of the last available post-flash reference file, and F is the average of the SCI arrays of the last available post-flash reference file.

I will be able to provide m shortly. If you need (or prefer) the values of t_0 and F to be provided by me rather than taken from the post-flash file's header or calculated from its SCI arrays, let me know. Hopefully this is enough to start development of this update.

[pllim]

F is the average of the SCI arrays of the last available post-flash reference file

Is GOODMEAN still a thing? Will this F value be populated in that keyword or you rather we calculate it on-the-fly? I don't see this value ever changing for a given reference file?

I think it is reasonable to grab values from ref file header, if they can be trusted. I vaguely remember USEAFTER date format used to be funky but that was years ago. As long as that format is stable now, should be okay.

Will "m" also be a reference file keyword? If not, is it safe to be hardcoded straight into the pipeline?

Thanks!

[jryon]

Correct, the average of the SCI arrays shouldn't change for a given reference file, so we can consider putting the average in the header. GOODMEAN is not currently populated with useful values for this in recent flash reference files, but I can check if that keyword is one we are allowed to change, or if other options exist.

Apologies, looks like it should be the MJD of the DATE-OBS keyword, not USEAFTER. I imagine that is in a more reasonable format for you.

"m" will not be a reference file keyword. I believe it would be safe to hardcode.

Thanks!

[pllim]

Any update on value of "m"? Thanks!

[mdlpstsci]

@jryon @pllim
Just my two cents. It is preferred to put "m" in the calibration reference file header where any other relevant information for this issue is stored. At the least each value should have a thorough description of its meaning. I know "m" is the usual variable name for the slope from algebra (blast from the past: y=mx +b), but it would be better to use more descriptive variable names (i.e., use "slope" instead of "m") in general. The "t_0" should also be in the header of the calibration reference file in units of MJD.

The reason for putting the values in the calibration reference file header is that the file is easily updated with a new delivery of the reference file by INS -- no code has to change (in an ideal situation). This is an empowering situation for INS.

[jryon]

@mdlpstsci That makes sense, thanks! I will check that CRDS/ReDCaT is ok with adding new header keywords to the postflash reference file. And yes, we will include lots of description.

@pllim Will check on the status of the best slope value and get back to you soon

[pllim]

If you decide to put the "m" in reference file instead, me knowing the value won't do much good. I would need to know the new keyword to look for and a copy of the new file prototype for testing. Thanks, all! :)

[jryon]

@pllim Yep, mostly meant I'm checking on the status of the analysis.