PopSynth: Binary stuck between steps `detached` and `CO_HMS`

[maxbriel]

Problem A binary with a massive BH outside the CO_HMS grid mass will get redirect to the detached step. However, if the binary then experiences RLOF, it will be moved to the CO_HMS grid at RLOF, where it falls outside the grid and gets redirected back to detached. Since this binary is undergoing RLOF, it gets put back to CO_HMS. This causes a cyclical process. This process repeats itself several times with a different number of repetitions for different binaries.

Interestingly, the period reduces slightly every time it goes from step_CO_HMS_RLO -> step_detached. Tides?

Solution Temporary: Stop the systems from being send to the CO_HMS grid if they already came from there? Actual solution: extend the secondary grid to include such massive BHs.

Example ZAMS binary at $Z=0.00142$. S1_mass	S2_mass	Period	eccentricity
170.638207	37.917852	113.352736	0

Evolution: step_names	state	event	S1_mass	S2_mass	S1_state	S2_state	orbital_period	eccentricity
initial_cond	detached	ZAMS	170.638207	37.917852	H-rich_Core_H_burning	H-rich_Core_H_burning	113.352736	0.000000
step_HMS_HMS	detached	CC1	150.423664	35.663753	H-rich_Central_He_depleted	H-rich_Core_H_burning	131.463720	0.000000
step_SN	detached	NaN	148.677267	35.663753	BH	H-rich_Core_H_burning	132.374753	0.018719
step_detached	RLO2	oRLO2	148.677267	34.844310	BH	H-rich_Core_He_burning	128.487365	0.000000
step_CO_HMS_RLO	detached	redirect	148.677267	34.844310	BH	H-rich_Core_He_burning	128.487365	0.000000
step_detached	RLO2	oRLO2	148.677267	34.893625	BH	H-rich_Core_He_burning	128.456467	0.000000

etc etc

[tassos25]

Can you also please add the ID of the system and where the relevant population datafile can be found?

[maxbriel]

The this binary can be found in the population datafile at 230914/POSYDON_data/tutorials/population-synthesis/example/1.00e-01_Zsun_population.h5. It is the binary with binary_index 63

[astroJeff]

I just checked, and it looks like currently the CO_RLO_HMS grid has a maximum compact object mass of 52 Msun, expanding to cover at least this BH mass would require us to go from 22 grid slices on M_CO to 28 grid slices, or a ~25% increase in overall size. This seems worth it to me...

On a separate note, I did not realize that we can form 150 Msun BHs at 0.1 Sun. This seems high to me. Is there something else going on here that we should be considering (i.e., what's going on with the winds)?

[maxbriel]

To help with the last point, here's the total mass evolution of the closest model for the primary at different metallicities. (ZAMS mass = 172.00314763 $M_\odot$)

[maxbriel]

The total number of systems undergoing this error per metallicity

Metallicity [$Z_\odot$]	Total binaries	Err. #	Err. %
10$^{-4}$	1000000	651	0.0651
10$^{-3}$	1000000	740	0.074
10$^{-2}$	985294	1036	0.105
10$^{-1}$	1000000	746	0.0746
2 x 10$^{-1}$	1000000	490	0.049
4.5 x 10$^{-1}$	1000000	76	0.0076
1	1000000	510	0.051
2	1000000	716	0.0716

[maxbriel]

In the example population, theses are the maximum BH masses formed. These are filtered to not be merged or disrupted systems. metallicity	Maximum BH mass at step SN
2 $Z_\odot$	20.14001937440778
1 $Z_\odot$	29.727357640553727
0.2 $Z_\odot$	43.88486714438659
4.5 $Z_\odot$	44.121391054958146
0.1 $Z_\odot$	214.90970040335225
0.01 $Z_\odot$	289.15697913890654
0.001 $Z_\odot$	295.68184016494564
0.0001 $Z_\odot$	303.89610508155533

[mkruckow]

Done in PR #222 .

Please add this change for the other CO gird, too.

[mkruckow]

@maxbriel could you please check, whether this issue can be closed after PR #239 got merged.

[maxbriel]

This issue is solved with the temporary solution in PR #239. $Z = 0.1 Z_\odot$

STAR1 = SingleStar(**{'mass': 170.638207,
                      'state': 'H-rich_Core_H_burning', 
                      'natal_kick_array':[5.252975716982831, 2.9130465526555263, 1.8590029365249685, 6.154738614785131]})
STAR2 = SingleStar(**{'mass'37.917852,
                      'state': 'H-rich_Core_H_burning'})

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

The above binary would loop. Now it fails with ValueError: CO_HMS_RLO binary outside grid and coming from detached.