taylorbell57
commented
5 months ago @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.
kevin218
astroRez
FAQ check
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