metallicity dependence of stellar winds

[mathren]

Hi all! I was looking at the wind mass-loss implementation in MESA, and I think there is a long-standing issue at this line: https://github.com/MESAHub/mesa/blob/db6331e58f493bd910a032815bc554d12a8d1220/star/private/winds.f90#L341 This explicitly allows the surface metallicity to change as the star evolves (and possibly interacts with companions!). This is fine everywhere in the code because physically the surface metallicity can evolve in time, of course.

However, I think it is an issue in the wind mass loss routine (at least for line-driven winds of hot massive stars). For line-driven winds, the bulk of the opacity below the sonic point is provided by iron group elements, and the other metals may contribute to the radiative acceleration post-sonic-point (thus only influencing the wind v_infinity but not Mdot). Most stellar wind recipes are designed using Z as a proxy for surface iron abundance. See for instance the discussion in sec. 3 here https://arxiv.org/abs/2205.09125 (for O and WNh stars) or here: https://ui.adsabs.harvard.edu/abs/2016ApJ...833..133T/abstract (for WR of various sub-classes).

Except for pollution from a nearby SN explosion, which is usually a small effect, the iron-group element abundances are not modified throughout the star's lifetime. So even if H and He drop (maybe because of mass loss), and N increases (say because of rotational mixing or accretion), affecting Z, the driving of the wind should not change. Presently MESA is likely doing something incorrect. This is likely not a major problem (most winds scale with Z^x with x~0.5-0.8 and are uncertain between 0.1-1dex anyways), but it is a theoretical inconsistency that can be easily fixed, e.g., by changing the line above to use Z=Z_base in the wind routines. Z_base is a constant throughout the evolution (like the surface Fe-group abundances), related to opacity (i.e. what matters for the wind driving). Even if this means that X+Y+Z_base is not one in the wind routines, that should not be a problem. Using Z_base instead of Z would be a simple fix that makes things nuclear-reaction-network independent.

What do the developers think about this? Would such a "fix" be welcome?

[rjfarmer]

Yes, a fix would be helpful.

Though we need a fallback for when zbase isn't set (when not using type2 opacties). Initial_z would work but that then needs a fallback if that's not set (when loading a model you don't need to set initial_z). Maybe that then just falls back to the surface Z.

[mathren]

Is there any variable that stores (or could be misused to store) the initial surface Z? I think since initial_z is set to 0.02 in the defaults, wouldn't that be the "incorrect" value that MESA picks up if you load a model?

[rjfarmer]

Yes that's what I meant with initial_z not being set, that you'd get the default 0.02

[evbauer]

Thanks for the clear diagnosis and explanation Mathieu! Should we document this change in the changelog? And perhaps also add a brief note about this behavior in the documentation of winds routines in controls.defaults as well?

[mathren]

Thanks Evan!

I think it is worth mentioning it, yes. I did leave a small comment in winds.f90, but maybe it would be good to have a note also in controls.default and possibly in kap.defaults where Z_base is defined (saying that if it is not -1 it will be used to scale the wind mass loss rate too), to prevent any users from being surprised.

[evbauer]

Ok, I added a bit more documentation in 68ebc1ab780e5d2f2595d1395a338bfe0dbc735e. Can you take a look at the changes there and make sure they're accurate?

[evbauer]

The suggestion has been implemented and documented, so I think we can close this issue now.