Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adopting mask_phases from lc_geometry results in confusing/ambiguous behavior #756

Open
kecnry opened this issue Jun 22, 2023 · 1 comment

Comments

@kecnry
Copy link
Member

kecnry commented Jun 22, 2023

to avoid confusion when adopting the proposed t0 and mask_phases which can then result in a confusing phase-shift.

@kmhambleton

@kecnry
Copy link
Member Author

kecnry commented Jun 14, 2024

the mask_phases are currently automatically shifted if adopting mask_phases and t0_supconj at the same time (by passing adopt_parameters=['*'], for example. This should be more clearly documented in the tutorials.

However, if adopting t0_supconj first, and then adopting both mask_phases and t0_supconj, the shift will be based on the current face-value of t0_supconj. This could be "fixed" by storing the original value when running the estimator in the solution so that the shift could be correctly applied at any point later.

Also might be useful to have a function in phoebe.helpers to arbitrarily shift the proposed mask phases (or eclipse edges) by a change in t0 from the t0 used to estimate those mask_phases, etc.

@kecnry kecnry changed the title mask_phases to be split out of lc_geometry into its own estimator adopting mask_phases from lc_geometry results in confusing/ambiguous behavior Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant