[Bug]: HSTRamp parameters can not be of "fixed" type when using mult_white.

[astroRez]

FAQ check

• [X] Yes, I checked the FAQ and my question has not been addressed.

Instrument

Other (any stage)

What happened?

When performing a joint fit of multiple white curves, if an HSTRampModel coefficient (e.g. h5 or h6) is set to "fixed", only the first transit is fitted.

Unfortunaly, the kernel crashes without providing an error.

Examples of the program fitting the first transit, but failing to fit the remaining transits are attached.

Error traceback output

No response

What operating system are you using?

No response

What version of Python are you running?

No response

What Python packages do you have installed?

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[taylorbell57]

@kevin218 and I discussed this issue in a previous Eureka! team meeting, and my best guess at the time was that there was some issue where the orbital phase of HST was being shared between multiple observations assuming a stable, non-precessing orbit. HST's orbit varies quite a bit from one observation to the next, so fixing both h5 (HST's orbital period) and h6 (something like the zero-phase time for HST) across multiple visits seems like a bad idea to me; I'm quite new to working with HST data though, so I could be wrong.

Additionally, it's possible that there is some bug in the code that computes something like time_batch or time_local, which is only buggy for mult_white fits.

Beyond that, it's hard for me to troubleshoot without an error message or putting a bunch of print statements throughout to see what unexpected things are happening. I might be able to find time to investigate this, but probably not for a while (>2 weeks) since I'm pretty over-commited right now. If you or anyone else figures out a solution to this, please feel free to submit a PR or describe what your solution was and I can help you implement the patch.

[taylorbell57]

@kevin218, is this known bug something we'd like to resolve for v1.0?

[kevin218]

@taylorbell57 I don't think this is something that needs to be done for v1.0, maybe v1.1.