[BUG]: Another Binary Step Exceeded Allotted Time: 120

[maxbriel]

Describe the bug
A binary reaching:
RuntimeError: Binary Step Exceeded Allotted Time: 120

To Reproduce

from posydon.binary_evol.binarystar import BinaryStar, SingleStar
from posydon.binary_evol.simulationproperties import SimulationProperties
from posydon.popsyn.io import simprop_kwargs_from_ini


sim_kwargs = simprop_kwargs_from_ini('run_0.ini', verbose=True)
metallicity = {'metallicity':0.1, 'verbose':True}

sim_kwargs['step_HMS_HMS'][1].update(metallicity)
sim_kwargs['step_CO_HeMS'][1].update(metallicity)
sim_kwargs['step_CO_HMS_RLO'][1].update(metallicity)
sim_kwargs['step_CO_HeMS_RLO'][1].update(metallicity)
sim_kwargs['step_detached'][1].update(metallicity)
sim_kwargs['step_disrupted'][1].update(metallicity)
sim_kwargs['step_merged'][1].update(metallicity)
sim_kwargs['step_initially_single'][1].update(metallicity)

sim_pop = SimulationProperties(**sim_kwargs)

sim_pop.load_steps(verbose=True)

star_1 = SingleStar(**{'mass':  7.082482087008959 , 'state': 'H-rich_Core_H_burning','metallicity':0.1,
                'natal_kick_array': [38.32237608078092, 6.0368730380460205, 1.848568130755055,6.2160086037434565]})
star_2 = SingleStar(**{'mass': 2.6379543729221413 , 'state': 'H-rich_Core_H_burning','metallicity':0.1,
                'natal_kick_array': [None, None, None, None]})
binary = BinaryStar(star_1, star_2, **{'time': 0.0,  'state': 'detached',  'event': 'ZAMS', 
                        'orbital_period': 115.08514438464961 ,'eccentricity': 0.0}, properties = sim_pop)

binary.evolve()

You might have to rerun the binary, based on the secondary kick.

Expected behavior
Should probably reach max_time, since the secondary is very 2.7 Msun at after the first star becoming a NS.

POSYDON Version:
V2.2 PR

[sgossage]

Running this locally, I see e.g., this successful evolution (for comparison):

and this failed evolution, which is the one in question I think:

I noticed that at least in this case, the failed evolution above seems to slow down perhaps because the change in separation is very small. Each time step, it is often the order of 1e-5 or smaller near the end of the evolution. Setting the change in separation to zero in this case (if da < 1e-4 for example) appears to solve the issue, although I still plan to test this a bit more.

[astroJeff]

It looks like this is an issue with solve_ivp producing very small time steps. Setting atol and rtol doesn't seem to fix it, but more testing and investigation is required