Undefined binaries in flow: ('stripped_He_Central_He_depleted', 'H-rich_Core_H_burning', 'RLO1', 'oRLO1')

[celiotine]

Binaries with the parameters ('stripped_He_Central_He_depleted', 'H-rich_Core_H_burning', 'RLO1', 'oRLO1') are failing because they are not handled in the flow. An example of one such binary:

ini_filepath_IF = "/projects/b1119/cliotine/pulsar_dev/pulsar_pops/runs/oct_2024/Sukhbold+16/grid_reruns_final/params.ini"
sim_kwargs_IF = simprop_kwargs_from_ini(ini_filepath_IF)
sim_prop_IF = SimulationProperties(**sim_kwargs_IF)
sim_prop_IF.load_steps(verbose=True)

star_1 = SingleStar(**{'mass':  6.30415516982906, 'state': 'H-rich_Core_H_burning',
                'natal_kick_array': [None, None, None, None]})
star_2 = SingleStar(**{'mass': 3.19348803304828, 'state': 'H-rich_Core_H_burning',
                'natal_kick_array': [None, None, None, None]})
binary_IF = BinaryStar(star_1, star_2, **{'time': 0.0,  'state': 'detached',  'event': 'ZAMS', 
                        'orbital_period': 585.7165771197014,'eccentricity': 0.0}, properties = sim_prop_IF)
binary_IF.evolve()

This is happening when running with IF but not NN.

[celiotine]

Possibly related systems, though they are much rarer (these binaries also leave step_CE in RLO after step_HMS_HMS with an undefined state):

('H-rich_Core_He_burning', 'H-rich_Shell_H_burning', 'RLO2', 'oRLO2')

star_1 = SingleStar(**{'mass':  6.629154054663811, 'state': 'H-rich_Core_H_burning',
                'natal_kick_array': [None, None, None, None]})
star_2 = SingleStar(**{'mass': 5.643884766762587, 'state': 'H-rich_Core_H_burning',
                'natal_kick_array': [None, None, None, None]})
binary_IF = BinaryStar(star_1, star_2, **{'time': 0.0,  'state': 'detached',  'event': 'ZAMS', 
                        'orbital_period': 3.5751166715461835,'eccentricity': 0.0}, properties = sim_prop_IF)

('H-rich_Central_He_depleted', 'H-rich_Core_H_burning', 'RLO1', 'oRLO1')

star_1 = SingleStar(**{'mass':  6.231467289002243, 'state': 'H-rich_Core_H_burning',
                'natal_kick_array': [None, None, None, None]})
star_2 = SingleStar(**{'mass': 4.131398947001683, 'state': 'H-rich_Core_H_burning',
                'natal_kick_array': [None, None, None, None]})
binary_IF = BinaryStar(star_1, star_2, **{'time': 0.0,  'state': 'detached',  'event': 'ZAMS', 
                        'orbital_period': 1091.020469084488, 'eccentricity': 0.0}, properties = sim_prop_IF)

[celiotine]

Per discussion 10/24:
It will be helpful to make a corner plot of the component masses and orbital periods for the He-rich stars RLOing onto H-rich stars. We should also get a more accurate estimate of their overall population frequency. We will most likely need a new grid to handle these systems. For now, these binaries can fail with a POSYDON error, but this is not the ideal long-term resolution.

For the other two binaries posted, there is a matching issue, because their primary stars leave CE as stripped_He stars but are matched to H-rich stars in the detached step. This should not happen.

[celiotine]

I've confirmed that, for the two systems I added in the above comment that enter RLO after HMS-HMS with an H-rich primary star, that the primary stellar state is a result of the matching (a stripped_He star is being matched to an H-rich star via the third alternative matching option). @mkruckow is this a case that would be handled by the HMS-HMS-RLO step? I'm currently not sure how to handle these systems.

[mkruckow]

The steps should only look at the last status, thus any star coming from detached with both H-rich should be handled by the HMS-HMS_RLO, the RLO step shouldn't know about the fact, that the H-rich star was a stripped_He at some point in the past.
But it could be the case, that those stars come from tracks in H-rich detached which are intrinsically hard to match on the HMS-HMS_RLO grid.
Long story short: technically it should work, while the physical results might be questionable.

Edit: sorry, I forgot, that @astroJeff decided to not have the HMS-HMS_RLO grid to be part of the v2 dataset.

[celiotine]

Ok sounds good. Do you think we need a way to "handle" these systems (like a POSYDON error) without the HMS-HMS-RLO step, or should we just let them fail for now if the step is not included? I forgot what the status of that is.

[celiotine]

These binaries should be handled by PR #430.