Open mkruckow opened 7 months ago
With https://github.com/POSYDON-code/POSYDON/pull/281 all the limits and thresholds are collected in https://github.com/POSYDON-code/POSYDON/blob/development/posydon/utils/limits_thresholds.py, but still need to be aligned with the values in MESA.
There are several parts of the code which use the limits to connect them:
https://github.com/POSYDON-code/POSYDON/blob/development/posydon/grids/termination_flags.py in get_mass_transfer_flag
(getting termination flag 2 from MESA)
https://github.com/POSYDON-code/POSYDON/blob/development/posydon/utils/common_functions.py in infer_mass_transfer_case
(inferring the mass transfer case)
https://github.com/POSYDON-code/POSYDON/blob/development/posydon/grids/scrubbing.py in keep_after_RLO
(cut off stuff before RLO)
The MESA code is in function extras_binary_check_model
in run_binary_extras.f
:
if (b% point_mass_i/=0 .and. ((b% rl_relative_gap(1) .ge. 0.d0) &
.or. (abs(b% mtransfer_rate/(Msun/secyer)) .ge. 1.0d-10))) then
The preferred values from POSYDON have been (b% rl_relative_gap(1) .ge. -5d2)
and (abs(b% mtransfer_rate/(Msun/secyer)) .ge. 1.0d-12)
I'd suggest to make this as least restrictive as possible. So maybe we should allow things like (b% rl_relative_gap(1) .ge. -1d1)
and (abs(b% mtransfer_rate/(Msun/secyer)) .ge. 1.0d-15)
to leave space for potential adjustments on POSYDON.
Still one needs to have the drawback in mind, that the more relaxed the criterion is, the more does the orbit evolve between ZAMS and onset of RLO. This might cause less nice samples parameter space at onset of RLO. But I think this could be compensated by using the dynamical grids in the future.
When going towards version 3, we should revisit, which condition we'd like to use to detect the onset of RLO. We need to keep this always aligned between the MESA setup and the POSYDON post-processing, see https://github.com/POSYDON-code/POSYDON/pull/249.