Possible issue with LBV winds

[ilyamandel]

There may be an issue with LBV implementation: there does no appear to be a flattening of the remnant masses due to LBV winds at high ZAMS masses that is described, e.g., in the appendix to Neijssel+, 2019.

Running single stellar evolution, COMPAS v02.09.08

Relevant settings: metallicity = 0.0142 mass_loss_prescription = 'VINK' luminous_blue_variable_multiplier = 1.5 wolf_rayet_multiplier = 1.0

Plot attached.

[SimonStevenson]

Indeed I see Type 4 (CHeB) stars not losing any mass at all. (example attached generated with same default input as Ilya above) SSE_Parameters_90.txt

[SimonStevenson]

[SimonStevenson]

The orange dashed is the CHeB, so it seems mass loss completely switches off towards the end of the HG

[SimonStevenson]

This seems to be because m_LBVfactor = 0 despite the fact that in the pythonSubmit luminous_blue_variable_multiplier = 1.5

possibly because this seems to be set in ./BaseBinaryStar.cpp: m_LBVfactor = OPTIONS->LuminousBlueVariableFactor(); rather than in BaseStar

The same also seems to be true for the WR factor.

So I think that we need to pull them out and make them be part of BaseStar rather than BaseBinaryStar . As far as I can tell, this means this issue will only affect single stars, and binaries should be doing the correct thing.

[SimonStevenson]

Or at least make sure the pythonSubmit values of luminous_blue_variable_multiplier and wolf_rayet_multiplier get passed to the Star constructor when using single stars

[jeffriley]

I believe the LBV factor and WR factor are passed as parameters to the BasStar() constructor...

[jeffriley]

At least they are for BSE... It seems they are not passed for SSE so both default to 0.0. So yes, probably need to pick up the option values in main() and pass them there

[SimonStevenson]

Yeah sorry, that's what I meant :)

[ilyamandel]

@jeffriley -- I am confused. :)

Main.cpp creates a new single Star with new Star(randomSeed, gV.mass, gV.metallicity);
[line 374]

and a new BinaryStar with binary = new BinaryStar(ais, gV.mass1, gV.mass2, gV.metallicity1, gV.metallicity2, gV.separation, gV.eccentricity, gV.star1KickParameters, gV.star2KickParameters, index); [line 1068]

Neither seems to be getting the WR and LBV parameters passed in, right? In fact, the constructor for Star at least has them as optional inputs, though they are set to zero by default in Star.h, but the constructor for BinaryStar does not...

[jeffriley]

Look for this in BaseBinaryStar.cpp:

    // binary star contains two instances of star to hold masses, radii and luminosities.
    // star 1 initially more massive
    m_Star1 = new BinaryConstituentStar(m_RandomSeed, mass1, metallicity1, {}, m_LBVfactor, m_WolfRayetFactor);
    m_Star2 = new BinaryConstituentStar(m_RandomSeed, mass2, metallicity2, {}, m_LBVfactor, m_WolfRayetFactor);

[ilyamandel]

That was nicely hidden. :-) OK, we should make an exact parallel for single stars.

[jeffriley]

Yeah, I think we should clean it up and make it consistent.

[ilyamandel]

Testing Jeff's branch, winds appear fixed, continuing to test.

[ilyamandel]

Spot checking against wide binaries evolved with our BSE implementation indicates good agreement, so we Jeff's fix works:

[ilyamandel]

Fixed in PR 235, closing.