Undefined binaries in flow: ('H-rich_Core_H_burning', 'H-rich_Core_H_burning', 'RLO2', 'oRLO2')

[celiotine]

Binaries with the parameters ('H-rich_Core_H_burning', 'H-rich_Core_H_burning', 'RLO2', 'oRLO2') 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.263565862272097, 'state': 'H-rich_Core_H_burning',
                'natal_kick_array': [None, None, None, None]})
star_2 = SingleStar(**{'mass': 4.042250364920023, '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':  2.3130949924692237, 'eccentricity': 0.0}, properties = sim_prop_IF)
binary_IF.evolve()

[celiotine]

Per discussion 10/24: this is most likely a bug with labeling the star type, should go to CC1 and form WD?

[celiotine]

These binaries should be handled by PR #430.

[celiotine]

In addition, I am wondering if something wonky is happening with the interpolation for these binaries? It is still unclear to me why they are entering RLO after HMS-HMS to begin with. This is the interpolation information for the binary above:

So not sure if these systems should be entering CE?

[maxbriel]

@celiotine Yep. That looks like another classifier inconsistency to me. I've seen similar things in this issue #402

[celiotine]

From discussion on 11/21: We think this is an interpolator issue, as the binary interpolation class and MT history do not match (former is unstable, latter is stable). @philipp-rajah and @mkruckow plan to discuss possible solutions in more detail.

For now, we agreed we can create a separate POSYDON error to handle these binaries, but keep the issue open until the underlying issue is resolved.

[celiotine]

PR #430 was merged, which includes a ClassificationError catch for these binaries in the detached step.
I am leaving the issue open since the underlying problem still exists.

[astroJeff]

@celiotine just to check, is this a still-open issue because the ClassificationError check doesn't check all cases of inconsistencies?