Massive HeWDs due to FGB core mass

[nrsegovia]

Describe the bug

When a star loses its envelope during the FGB phase it can evolve into a HeWD or HeMS, according to FGB::ResolveEnvelopeLoss. This depends on whether its mass is below/above the critical value for helium ignition, MHeF = 1.995 (in M_Sun, for solar metallicity), so it's possible to create a HeWD above 1.44 M_Sun. I would guess that this should be avoided by some constraints imposed on the core mass (most likely, on FGB::CalculateCoreMassOnPhase), as the HeWD is initialized with m_Mass = m_CoreMass. However, there are some cases where it is possible to create these massive WDs ( 1.44 < M_HeWD <= 1.995 M_Sun at initialization). I'm not sure if this is an issue related to the original Hurley et al. 2000 prescription (eq. 39) or a bug.

Note that this is unrelated to the problem where a HeWD can accrete indefinitely (but both can happen simultaneously, leading to WDs more massive than 2 M_Sun).

Label the issue

urgency_moderate

severity_moderate

To Reproduce

COMPAS --initial-mass-1 9.24718391097395 --initial-mass-2 1.10440774784006 --number-of-systems 1 --random-seed 2689 --semi-major-axis 3.55636304140966 --eccentricity 0.321951895544923 --detailed-output TRUE --timestep-multiplier 0.01 

Expected behavior

HeWDs should not be initialized with mass values above ~1.4 M_Sun.

Screenshots

From my plots, relevant panels are top (stage = 3 means that it happens during FGB) and bottom (the primary is initialized with M = 1.94196 M_Sun after it loses its envelope and becomes a HeWD):

Versioning:

• COMPAS v02.25.10 (also present in v 02.25.09)

[ilyamandel]

@solfreludio -- Oops! You are absolutely right. We currently check in FGB::ResolveEnvelopeLoss() whether the post-stripping core is more massive than M_HeF. We should be checking whether the initial mass exceeded M_HeF -- that's a threshold on the initial mass for He ignition. :)

[ilyamandel]

Ditto elsewhere, e.g., HG::ResolveEnvelopeLoss(). @avigna , @SimonStevenson -- do you agree with my reading of (admittedly, ambiguous) Hurley statement "We distinguish between three types of white dwarf, namely those composed of He (formed by complete envelope loss of a GB star with M < M_HeF expected only in binaries) ..." [see Hurley+ 2000, start of 6.2.1]?

[ilyamandel]

OK, Jarrod Hurley confirmed this check should be the initial mass for SSE -- but I think we need to think through what is most relevant for BSE, since an MS star could grow through MT leading to a larger core (maybe mass at TAMS?).

[ilyamandel]

@solfreludio -- this particular problem is solved in PR #719 . Closing.

[nrsegovia]

I think that a similar change ( #719 ) is required for FGB::CalculateCoreMassOnPhase. I have updated COMPAS to the latest version and I can see that the comparison within FGB::ResolveEnvelopeLoss is done against m_Mass0, but probably this is required when computing the core mass as well (check Hurley+ 2000. Eqs 39,45). For example:

COMPAS --initial-mass-1 5.46090081724472 --initial-mass-2 4.51607827199957 --number-of-systems 1 --random-seed 83231 --semi-major-axis 0.154971672759462 --eccentricity 0.352778215553779  --detailed-output TRUE

This system still gives a HeWD with a mass equal to ~1.8 M_Sun (no accretion, it happens when it is initialized). I have several other similar systems.

[ilyamandel]

@solfreludio — you are absolutely right that there is a bug, but it’s not quite what you think. I’ll describe the bug-hunting process in a bit of detail, just in case it’s useful for others.

FGB::CalculateCoreMassOnPhase() does not use either m_Mass or m_Mass0; it uses p_Mass, which is the variable being passed in as the argument, not the internal value. If you go to FGB.h, you will see that this function is called with m_Mass0 as the first argument. So, at first glance, this is not the issue.

Meanwhile, the object in your example (thank you for providing that — very helpful!) has never experienced an FGB phase at all — it transitions straight from HG to HeWD. It appears to do so after its envelope was stripped off by mass transfer. That suggests that we should be looking at what happens on envelope removal — i.e., HG::ResolveEnvelopeLoss() and/or HG::ResolveRemnantAfterEnvelopeLoss(). And, indeed, we see that there is a comparison to m_Mass there rather than m_Mass0 — which needs to be fixed. But I also see that there are some queries from @jeffriley in HG::ResolveRemnantAfterEnvelopeLoss() which I hadn’t looked at in the past, so I want to take an opportunity to look through these before making the obvious patch.

So this may have to wait until tomorrow. But I hope the comments are useful. :)

[ilyamandel]

Closing again -- see #721 . Hopefully, this time it will stay closed (but, of course, please do reopen if I messed up!).