max_requiv problem

[MohammadReza0GH]

hi im trying to fit a data (semidetached) , bot i got this problem:

secondary is overflowing at periastron (requiv=1.0, requiv_max=0.0835699129883548). Use contact model if overflowing is desired. (3 affected parameters, affecting system,run_compute) when requiv of primary =0.0835699129883548=requiv_max, why they are always same?? i changed parameters but this happened again. i did : b.add_constraint('semidetached','primary')

this is my code:
import numpy as np
import phoebe

b = phoebe.default_binary()
logger = phoebe.logger(clevel = 'WARNING')
lc = np.loadtxt('D:\J2215.txt')

fluxes = np.empty(81)
for i in range(81):
fluxes[i] = 1373*10**((-26-lc[i,1])/2.5)

b.add_constraint('semidetached','primary')
b.set_value('requiv', component='secondary', value=0.00014)
b.set_value('eclipse_method', value ='only_horizon')
b.set_value('sma', component = 'binary', value= 0.22)
b.set_value_all('atm', value='blackbody')
b.set_value_all('ld_mode_bol', value='manual')
b.set_value('distance@system', value = 150, unit = 'pc')
times = b.to_time(lc[:,0])
b.add_dataset('lc', times = times, fluxes = fluxes, passband = 'Johnson:V',ld_mode='manual',pblum_mode='absolute', dataset= 'lc01')
b.set_value_all('ld_mode', value='manual')

b.run_compute()
b.add_solver('estimator.lc_periodogram', solver='lcperiod', algorithm = 'ls')
b.run_solver('lcperiod', solution='lcperiod_sol')
b.adopt_solution('lcperiod_sol')

b.add_solver('estimator.ebai', solver = 'ebai_1')
b.run_solver('ebai_1', solution='ebai1_sol')
#b.add_constraint('requivsumfrac')
#b.add_constraint('requivratio')
#b.flip_constraint('requivratio', solve_for='sma@binary')
b.flip_constraint('requivsumfrac', solve_for='requiv@secondary')
#b.add_constraint('teffratio')
b.flip_constraint('teffratio', solve_for='teff@secondary')
b.flip_constraint('ecosw', solve_for='per0')
b.flip_constraint('esinw', solve_for='ecc')
b.adopt_solution('ebai1_sol')

b.add_solver('estimator.lc_geometry', solver = 'lcgeo',eclipse_method ='only_horizon', overwrite=True)
b.run_solver('lcgeo', solution = 'lcgeo_sol',overwrite=True)
for param,value,unit in zip(b.get_value('fitted_twigs', solution='lcgeo_sol'),b.get_value('fitted_values', solution = 'lcgeo_sol'), b.get_value('fitted_units', solution = 'lcgeo_sol')):
print((param,value,unit))

b.flip_constraint('per0', solve_for='ecosw')
b.flip_constraint('ecc', solve_for='esinw')
b.adopt_solution('lcgeo_sol')

b.run_compute(model = 'ebai_model')
b.run_compute(model = 'lcgeom_model')
b.plot(x='phases', legend = True, show=True)

[MohammadReza0GH]

J2215.txt

this is the observation data that Im using.

[kecnry]

b.add_constraint('semidetached','primary') tells the primary to always have requiv == requiv_max, by definition (see this tutorial on the semi-detached constraint). Alternatively, you can omit the constraint and set the radius to at or near the critical value manually, the constraint just enforces the radius to update as you update other parameters that affect the critical value.

The error message, however, is telling you that the other star is overflowing its critical radius. If this is just showing as a warning (through the logger), then it might just be intermediate and you fix the problem later in the script. If it is being raised as an error when you call run_compute, then that means that your system is not physical and the parameters need to be adjusted before the model can be calculated - in which case you'll need to decrease the radius of the secondary star (and/or increase the semi-major axis, and/or decrease eccentricity, etc.)

[kecnry]

oh ok, so then I think everything is okay. The requiv_max are the same for the primary and secondary because the mass ratio q is one. You can see what goes in to computing requiv_max in the constraint definitions:

requiv_max@primary@constraint: requiv_L1({q@binary@component}, {syncpar@primary@component}, {ecc@binary@component}, {sma@binary@component}, {incl@primary@component}, {long_an@primary@component}, {incl@binary@component}, {long_an@binary@component}, 1)

[MohammadReza0GH]

thanks.

[MohammadReza0GH]

i tried to fit with only EBAI but i got this:

[kecnry]

EBAI, along with the other estimators, acts on phased data and proposes some values as an estimate (but should not be expected to reproduce the light curve immediately or even work well on all cases). Unless the orbital period of this system is actually ~1, you'll need to unphase the input data first before computing a physical model. And either way, make sure that when plotted in phase space (x=phases) that the phased light curve looks correct to pass off to the estimator.

There are a number of examples and tutorials on the website (including some recordings from past workshops) that you might also find helpful:

• section 8 of the tutorials is dedicated to the inverse problem (fitting)
• inverse problem examples

[MohammadReza0GH]

ok tnx