Minor repairs, change of default value for --scale-mass-loss-with-surface-helium-abundance

[brcekadam]

Corrects the luminosity evolution of CH stars, and fixes a bug that caused MS stars to stop ageing after mass transfer when stellar winds are disabled.

I also changed the default value for --scale-mass-loss-with-surface-helium-abundance back to FALSE, since it produces stellar winds that are too strong when --main-sequence-core-prescription BRCEK is used. In the case of CH stars, the luminosity in no longer fixed and is enhanced in comparison to standard MS stars, which should naturally enhance their mass loss rates. Let me know if anyone objects to this change :)

Closes #1443, closes #1444

[jeffriley]

Will get to this over the next few days.

[ilyamandel]

Thanks, @brcekadam , and sorry for the delay!

Looks good. But note that before my change (which you've partly undone), we did enhance the mass loss rate of CHE stars as a default, and now we don't. I would suggest using enhanced mass loss rates for CHE stars anyway, regardless of the option value of scaling mass loss with surface He abundance.

[brcekadam]

@ilyamandel
As discussed, I've reverted some changes you introduced in PR #1437. We're back to having only the option --scale-CHE-mass-loss-with-surface-helium-abundance, which applies only to CHE stars and is enabled by default.

Since I restored the previous code, CH::CalculateMassLossRateMerritt2025() is again using the HeMS clone. Just flagging this for now... let me know if this should be updated :)

[ilyamandel]

Thank you, @brcekadam -- looks great!

[jeffriley]

@brcekadam @ilyamandel

I know this is closed, and I didn't review it in time, but if we're changing functionality, especially changing default functionality of an option or options, we should announce the change in "What's New" - we shouldn't just change default functionality silently, and by announcing it in "What's New" we at least give users a chance of noticing that default functionality has changed. Some users are just users (and not developers) and won't/don't look at the code changelog.

Also, if we change functionality with code changes that are not fixing defects, we should change the minor number in the version number - that should signal to users that a change to functionality has taken place (simply changing the fix number doesn't necessarily convey that). If the PR contains a defect repair, and unrelated code changes (as in this case), the minor number should be incremented in favour of the fix (patch) number.

[ilyamandel]

Hi @jeffriley ,
My fault on both counts, sorry! Let's remember to update whatsnew in the next PR.

[brcekadam]

I'll keep that in mind next time, @jeffriley! Also, despite the name of this PR, no default values ended up being changed. I just restored the option --scale-CHE-mass-loss-with-surface-helium-abundance (essentially undoing part of what was done in PR #1437). But the default was set to TRUE and that still holds after this PR.

Looking at the “What’s new” section: the second point in the Oct 27 entry is no longer accurate, since that’s exactly what I reverted. That will need to be updated, sorry for missing that!