Forward model luminosities

[jsinkbaek]

Hello!

I am normally working with JKTEBOP, where I normalize my light curve using polynomial curve fitting around the eclipses ahead of analysis. I wish to ascertain what effect this has on the stellar radii and other parameters, so I decided to produce a forward model using PHOEBE and my found JKTEBOP parameters, and normalize it in the same way before using it as a synthetic light curve in JKTEBOP. However, I want to be absolutely sure that I'm handling it right, since I'm getting some wild results.

In order to get the right luminosity ratio in the forward model without accurate temperatures, I am currently using the decoupled setting in pblum_mode, and then manually scaling the secondary component pblum using my previously found luminosity ratio. Is that reasonable?

What about third light? If I manually input something like
b['l3_frac@lc_kepler@dataset'] = 0.0029667000
will that still be included in the forward model?

I suspect that I might be doing something wrong somewhere. It is possible that everything is as it's supposed to be. I'm just a little bit skeptical since I'm seeing a 60%-90% increase in radius for both my components by doing this, which I suspect might be a bit extreme. Is it possible that the eclipse depths are simply too deep in the forward model due to some setting I'm using?

The change in eclipse depths for the forward model is also visible in an over-plot:

I have also attached a pdf version of my notebook, if that is helpful.
forward.pdf

[kecnry]

The third light should definitely be in the forward model, so I don't think that should be a problem, unless its defined at a different reference time/flux which is possible.

I would caution against using decoupled luminosities unless absolutely necessary (as luminosities will no longer be coupled with radii and temperatures). Instead it might be worth trying to back out the temperatures that give you the luminosity ratio (probably surface brightness ratio) from jktebop, and see if that agrees better. You can find the way that we estimate surface brightness ratio from phoebe parameters when calling jktebop in the jktebop wrapper.

My last suggestion would be to just run the forward model with PHOEBE's jktebop wrapper and compare those to see how well the code's compare in this area of parameter space (keeping in mind some discrepancies could also be caused by approximations in the wrapper itself... including this ugly surface brightness approximation).

[jsinkbaek]

What do you mean by the third light being defined at a different reference time/flux?

It sounds like the easiest solution, if I don't want to try to work out some kind of custom constraints, is to do some form of minimization of the calculated surface brightness ratio in relation to the JKTEBOP ones. I'll try to do that, and report back.

[jsinkbaek]

It seemed like the surface brightness trick did not produce better results, so I've stuck to the decoupled pblums. To give some idea of why I think that's still reasonable: The stellar light ratio fitted to my original light curve is much better determined than the radii and temperatures, given that I have a total eclipse present. Therefore I'm more comfortable with using that to produce a forward model than the two other parameters.

The following two changes seem to have fixed the issue, since I'm getting much more reasonable results now:

• I changed the limb darkening in PHOEBE to be a manual quadratic law using the same coefficients as in JKTEBOP (maybe it makes more sense to keep the interpolated values, but since that's not what I'm trying to quantify I wanted as little difference as possible between the models as possible, except for deformation and irradiation).
• I got JKTEBOP to iteratively calculate errors for my data points. It seems that the program does not handle light curves without errors in any reasonable fashion. I find it odd that it's even an option then.

Thank you very much for taking the time to assist me!

[kecnry]

Glad to hear you got reasonable results, thanks for the updates!

What do you mean by the third light being defined at a different reference time/flux?

Since you're providing third light in fractional units, those need to be converted to a constant third light flux based on the total system flux, which is of course time-dependent in a binary system. Each code that supports fractional third light likely has different assumptions on how to make this conversion.

[jsinkbaek]

Hello @kecnry

This is an old thread, but I have a follow-up question.
Is it possible to change the phase that pblums are defined at?

I wish to adjust so that it is defined at some-place close to eclipses, instead of at maximum light or periastron (which is current?)

Example plot where luminosity~1 at maximum light:

[jsinkbaek]

So please correct me if I am wrong, but so far my understanding is:

• pblums are normally ~unchanged and all (most?) of deformation and reflection is incorporated only in the pbflux along with other geometric effects (eclipses).

• Providing fractional third light gives a static flux addition relative to pbflux at t0. Meaning it depends on which phase it is provided in. If I define t0@system = t0_supconj (within primary eclipse), would this mean that flux amount of third light is significantly lower for the whole model, compared with providing it at f.ex. maximum flux or some other t0?

• If I, with t0 = t0_supconj and no third light, give pblums for both components such that total flux is 1 if no eclipse was present and stars were spherical, e.g. pblum_A = 4pi/(1+L_B/L_A) and pblum_B = 4pi * (1 - 1/(1+L_B/L_A)), then the model should have flux ~1 at around primary eclipse (if the eclipse is ignored).

The last effect is the one I am most puzzled by, because that is what I tried to do for the plot above where it seems that flux (sorry for the confusion with luminosity before I see it now) is ~1 at maximum flux, not near eclipse. I have managed to rescale it fine outside of PHOEBE. But I was just confused since it did not behave like I expected when I changed t0@system.

[jsinkbaek]

Reading back, I realise now that at what t0@system I define pblums should probably not have an effect on what pbflux is calculated in my case. I assume this means pblum provided this way always relates to the maximum flux?

Is there a way that I can work backwards? E.g. calculate pblums given that I know what the flux of both components should be at a specific phase?

[aprsa]

In essence, pblum is the value assigned to the integrated model atmosphere-dependent emergent passband intensity from the entire star at time t0. If the star was spherical and unobscured, you would then get flux from that star that is close to but not exactly pblum/4pi, and that is because of the model atmospheres -- specific passband intensity variations compared to blackbody make this relationship not exact. Thus, there is no ready way to request pbflux@t0=value as we'd need to iterate on pblum to get there. Under the hood we calculate absolute pblum from model atmospheres (that is internal to phoebe and unexposed unless you change pblum_mode) and calculate a scaling factor that turns it into the parameterized pblum (i.e., assigned by you). This sets the "units" for the entire radiative description in phoebe.

[kecnry]

Just wanted to add a clarification about third light.

If I define t0@system = t0_supconj (within primary eclipse), would this mean that flux amount of third light is significantly lower for the whole model, compared with providing it at f.ex. maximum flux or some other t0?

My explanation overly simplified this, so sorry for the confusion. Under-the-hood third light is always added as a constant flux at all phases. If you provide third light in fractional units (l3_mode='fraction'), then this constant flux is estimated ignoring distortion and eclipses (by using the expected pblum/4pi). You can always see how that mapping will re-act by calling b.compute_l3s manually. Unless you're forced to work in fractional third light, its probably best to just work with flux units.

[jsinkbaek]

Ok thank you both. I think that gives me an overall idea about it.

@kecnry that makes sense! I was also a bit confused why it would be a good idea to have it distortion and eclipse dependent.
I have not been able to properly resolve the differences between l3_frac and JKTEBOP third light, so I have decided to simply use a light curve that has previously been corrected for third light.