Fitting for syncpar

[dmrowan]

Hello,

I'm modeling a light curve of a system with a spot on the primary star. The binary is not tidally synchronized, so P_rot != P_orb. I see that I can set the syncpar (or period@primary) to change the rotation period of the primary to be different to the orbital period.

I'm interested in including syncpar as a free parameter for an MCMC fit. However, I get the error
ValueError: cannot interpolate in phase for time-dependent systems
when including syncpar as a fit parameter (or flipping constraints and fitting for period@primary).

Is this functionality not available in PHOEBE, or have I misunderstood how to setup the parameterization? Do you have any suggestions on how I can use PHOEBE to solve for asynchronous binaries?

Cheers,
Dom

[kecnry]

This is likely happening because you've provided either compute or solver times, and the light curve is no longer just phase-dependent (meaning you'll need to compute the forward model spanning your entire timespan of observations). I would expect this to raise a warning, but not an error. Can you provide more of the traceback, the options you have for compute_times, solver_times, and dataset times? I'm hoping it is an easy bugfix or can at least be avoided by setting these to cover the full span. The "easiest" (but probably not cheap) way to get around the issue would be to force the forward model to compute at all of your observation times, but it really should still be possible to do some time-interpolation if necessary.

[dmrowan]

Hi Kyle,

Thanks for the quick response. I had solver_times set to auto. Changing it to times got rid of the error, but this does make the runtime exceptionally long.

I did not realize that the default to solver_times is based on the length of the dataset. Is there a part of the documentation that talks more about how the default compute_times are created? I'm wondering if they are evenly spaced in time/phase or if it is something more complicated.

Cheers,
Dom

[kecnry]

Hi Dom - there is just this one tutorial on solver times, although it seems that both the logic and that tutorial could use more thought about how to be more efficient in the time-dependent case. If you have any suggestions for either, we'd love to hear them!

My suggestion with the current implementation would be to use compute_times (note: not compute_phases) and make sure that it encompasses the full range of times and samples finely enough that linear interpolation won't cause any problems but coarse enough to save some computation time compared to having to evaluate at each time point (you can make the arrays such that eclipses have more coverage than out-of-eclipse phases, for example).