NS/WD NaN mass, SN_type & CO_type not consistent

[maxbriel]

For systems with state=NS and SN_Type=WD, no mass is present in the MODELxx. Is this expected behaviour for the models, when the state and SN type do not match?

Should we recalculate the mass with the state/SN_type based on the preSN model parameters?

STAR1 = SingleStar(**{'mass': 7.592921,
                      'state': 'H-rich_Core_H_burning'})
STAR2 = SingleStar(**{'mass':5.038679 ,
                      'state': 'H-rich_Core_H_burning'})

BINARY = BinaryStar(STAR1, STAR2,
                    **{'time': 0.0, 'state': 'detached', 'event': 'ZAMS', 'orbital_period':5.537807, 'eccentricity': 0.0},
                    properties = sim_pop)

S1_mass	S2_mass	S1_he_core_mass	S1_co_core_mass	S1_state	S2_state	time	state	event	orbital_period	eccentricity
7.592921	5.038679	NaN	NaN	H-rich_Core_H_burning	H-rich_Core_H_burning	0.000000e+00	detached	ZAMS	5.537807	0.0
1.229538	5.234164	1.229538	1.120187	stripped_He_Central_He_depleted	H-rich_Core_H_burning	5.204840e+07	detached	CC1	11.434389	0.0
NaN	5.234164	NaN	NaN	WD	H-rich_Core_H_burning	5.204840e+07	detached		NaN	0.0
NaN	5.234164	NaN	NaN	WD	H-rich_Core_H_burning	5.204840e+07	detached		NaN	0.0

[maxbriel]

Small update: This also occurs for some BHs.

[celiotine]

Adding an update: I have also noticed this behavior is happening for ECSN when use_interp_values = True. This is causing problems later in the evolution, because the resulting NS masses are NaN, which is crashing the evolution in the detached step.

[maxbriel]

@philipp-rajah Here's a full example. I've send you the population.ini

import numpy as np
import os
from posydon.config import PATH_TO_POSYDON, PATH_TO_POSYDON_DATA
import pandas as pd

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('population.ini', verbose=True)
metallicity = {'metallicity':1}

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=False)

STAR1 = SingleStar(**{'mass': 7.592921,
                      'state': 'H-rich_Core_H_burning'})
STAR2 = SingleStar(**{'mass':5.038679 ,
                      'state': 'H-rich_Core_H_burning'})

BINARY = BinaryStar(STAR1, STAR2,
                    **{'time': 0.0, 'state': 'detached', 'event': 'ZAMS', 'orbital_period':5.537807, 'eccentricity': 0.0},
                    properties = sim_pop)

BINARY.evolve()

[mkruckow]

As we discussed, we could think of combining the classifiers for SN_type and CO_type into one, which avoids undefined combinations. A deeper thought brought me to the point, that this won't necessarily help us to infer the interpolation class better:

• @philipp-rajah : we would change two independent classifiers with 4-5 values to one with 6-8 values. What does behave better in having less misclassifications?
• @maxbriel : can you check whether you get a out or hull warning for those binaries? If this is the case, we are probably between the hulls of two interpolation classes, hence outside the validity area of the interpolators. There the only help would be to have a higher resolution at the boundary in the grid used for training. Alternatively, we could think about allowing the interpolator to extrapolate a bit, e.g. by setting a larger hull on training (@philipp-rajah any thoughts on this?).

[maxbriel]

We decided to implement a 'quick fix' for the issue to push the system into the manual remnant mass calculation, if SN_type and CO_type do not match.

However, this is not the preferred solution. It's preferred to solve the issue at the interpolator.

@mkruckow I do not get any out of hull warnings for the example binary above.