03.22.00: fixes to nuclear timescale mass transfer, new 2-stage CE options, etc.

[ilyamandel]

• Changed default values of --enhance-CHE-lifetimes-luminosities and --scale-CHE-mass-loss-with-surface-helium-abundance to true
• Added options to set beta and gamma prescription for second stage of 2-stage CE (--common-envelope-second-stage-beta, --common-envelope-second-stage-gamma-prescription)
• Fixed a bug in CalculateZetaEquilibrium(), which impacted when mass transfer is declared nuclear (and how conservative it is)
• Now calculate mass accretion rate for nuclear timescale mass transfer on the fly to match with donor mass loss rate set by donor mass loss (required to fit into Roche lobe) divided by time step
• Fixed random draws of SN kicks to avoid artificial pile-up at boundaries of distribution
• Split --muller-mandel-sigma-kick into --muller-mandel-sigma-kick-NS and --muller-mandel-sigma-kick-BH

[ilyamandel]

This one has a bit for everybody:

• It addresses an issue that @veome22 initially identified with timestep non-convergence (this occurred because nuclear timescale mass transfer didn't do what it was supposed to);
• It introduces new functionality for varying beta and gamma for the second stage of the 2-stage CE, as @ryosuke-hirai suggested
• It may be of interest to folks who are particularly interested in nuclear timescale MT, including @SimonStevenson and @yuzhesong (@SimonStevenson, maybe you could check how things work now?)

[ilyamandel]

Warning: one of the fixes is a very stupid but fairly serious bug. I initially forgot the virtual keyword when declaring
virtual double CalculateZetaEquilibrium() { return 0.0; }
As a result, zeta equilibrium was always zero, and far more MT events were considered nuclear timescale than should have been the case.
In addition to fixing this, I also improved the treatment of nuclear timescale mass transfer to now simultaneously (and thus, hopefully, self-consistently) model how conservative it is and how much mass needs to be stripped from the donor to allow it to just fill the RL, since these two are connected. (Previously, we used thermal timescale MT to determine how conservative MT should be for the purposes of determining how far the donor should be stripped, and then separately computed how conservative the MT actually was based on the amount of mass transferred, which was inconsistent.)

[jeffriley]

Changes look good to me. I'll approve, but not merge yet so other reviewers can comment

[SimonStevenson]

Similar to #1327 I ran this test:

./COMPAS -n 1 --mode BSE --detailed-output TRUE --initial-mass-1 9.0 --initial-mass-2 1.0 --orbital-period 750.0 --common-envelope-alpha s[1.4,1.5,2.0,3.0,4.0,5.0,7.0,10.0,15.0,20.0] --kick-magnitude-1 0.0 --remnant-mass-prescription FRYER2012 --random-seed 0

Here is the resulting plot

This seems to have reverted to the previous behaviour and no longer reproduces the Tauris & Savonije relation. For comparison, here is the plot from running the same test with current dev:

[ilyamandel]

Hi @SimonStevenson ,
Thank you very much for the check! I am sorry it took so long to respond to it -- Aspen has kept me busy. The problem was very simple: I somehow forgot the inheritance hierarchy and instructed CalculateZetaEquilibrium() to return 0 in GiantBranch.h only to overwrite it immediately in HG.h. Now moved correctly, and problem fixed. I ran the test from #1327, namely,

./COMPAS -n 1 --mode BSE --detailed-output TRUE --initial-mass-1 9.0 --initial-mass-2 1.0 --orbital-period 750.0 --common-envelope-alpha 2.0 --kick-magnitude-1 0.0 --remnant-mass-prescription FRYER2012 --random-seed 0

I can confirm that we now do have nuclear timescale MT fitting within the RL with significant NS mass growth (see attached plots).

The results aren't exactly identical to the previous version, but that's expected because I am now calculating the mass accretion rate for nuclear timescale mass transfer self-consistently to match with donor mass loss rate set by donor mass loss (required to fit into Roche lobe) divided by time step.

Given the many changes now rolled into this PR, I'll pull it in now -- but please let me know if you or anyone else spots any other issues.