Lo pointing set and map background rates update

[ahotasu]

Worked with Nathan to implement addition of background to intensities per the latest update to the mapping document.

Change Summary

Overview

Added scalar logarithmic stability factor and code to use that factor for adding the background intensities to the ENA intensities for all energies. This, combined with Greg and Tim's work on (BUG - Lo L1c backgrounds not being selected #2651) was used to generate new L1c Pset and L2 CG Corrected Flux products that Nathan validated late last night.

New Dependencies

None

Updated Files

• lo_l2.py
  • added background factor, summation, and uncertainties/systematic errors to the start of the flux calculation function, which operates on the intensities after the bootstrap and sputtering corrections, but before the logarithmic calculations in the PowerLawFluxCorrector

Testing

Not versed enough yet on pytest to run. :-(

[subagonsouth]

This is really confusing to me. I thought that a critical idea in the Lo algorithm is that the backgrounds do not get subtracted. So coming into this function, ena_intensity = signal_intensity + bg_intensity. Then this factor of the background is added in on top which means ena_intensity = signal_intensity + bg_intensity + stability_factor * bg_intensity. That doesn't make sense to me. I know that this is what Nathan wants but I am really struggling to understand why. To me this seems like it is purely an problem with the crappy intput data being used for validation and this fix actually degrades the output product.

[greglucas]

I completely agree with this comment, and that is why I'm hesitant to throw this in there at the last second.

I think this is actually really bad because it adds in 4% uncertainty, but then doesn't remove that later on, so could be very misleading in terms of what is going on, and this is only before flux corrections, but if someone is looking at a sputtering/bootstrap map, then those wouldn't be corrected. It seems like this is a recipe for confusion.

[greglucas]

There is no systematic error here it looks like:
https://github.com/IMAP-Science-Operations-Center/imap_processing/actions/runs/21547460903/job/62093470806?pr=2653#step:7:3631

https://github.com/IMAP-Science-Operations-Center/imap_processing/actions/runs/21547460903/job/62093470806?pr=2653#step:7:3375

[greglucas]

I think we should take some time and think about this more (not just us, but the instrument team as well). Are there other ways to approach this, like for instance setting the flux values to the min(flux, bg) so that flux is never lower than bg. Or to set bg to the flux value if you are measuring less than background. i.e. I am wondering if we can somehow make the algorithm more robust rather than changing the data itself that goes into the algorithm.