Failing to blend EOS around Z=0.04

[noahjdowning]

When diffusion is turned on and Z drops below 0.04, the EOS changes. This leads to discontinuities in the star's evolution.

This was found while running a ~0.65 Msun model at Z a little larger than 0.04 with do_element_diffusion = .true.

Setting OPAL_SCVH = .false. removes this discontinuity.

Below is surf_cell_z vs. logTeff for model grid of a ~0.65 Msun star on the main sequence. Note that when surf_cell_z crosses 0.04, there is a sharp change in logTeff.

Version

• MESA version [r24.08.1]
• MESA SDK VERSION [aarch64-macos-25.8.1.pkg)]
• OS: [MacOS 15.6.1]

[Debraheem]

I think i know what's happening. Mesa's Z blend from scvh to Helm/ideal is failing.

At a representative OPAL/SCVH interior point (logT ~= 3.513, logRho ~= -2.044), the intended Z ramp changes, but the actual derived alfa does not:

Z	zfactor from 0.035 to 0.040	OPAL/SCVH frac	HELM frac	ideal frac	derived alfa
0.0340	0.000	1.000	0.000	0.000	0.000
0.0360	0.200	1.000	0.000	0.000	0.000
0.0380	0.600	1.000	0.000	0.000	0.000
0.0395	0.900	1.000	0.000	0.000	0.000
0.0400	1.000	0.000	0.000	1.000	1.000
0.0420	1.000	0.000	0.000	1.000	1.000

So the Z blend factor is ramping between Z_all_OPAL = 0.035 and Z_all_HELM = 0.040, but alfa stays at 0 in the OPAL/SCVH interior and then jumps to 1 at Z = 0.040.

I think the issue is in :

behavior	main line	blamed commit
Z >= Z_all_HELM forces iregion = use_none	eos/private/eosdt_eval.f90:L1221	13fe30d52
use_none sets alfa = 1	eos/private/eosdt_eval.f90:L1405	13fe30d52
use_all sets alfa = 0	eos/private/eosdt_eval.f90:L1408	13fe30d52
Z ramp multiplies the already-zero alfa	eos/private/eosdt_eval.f90:L1453	13fe30d52

This behavior predates the GitHub migration: git blame traces it back to the initial import of MESA r15140, not to a recent GitHub commit.

I show the relevant blend routines below, where alfa was set to 0 so the z blend wasn't doing anything. I also show the diff for my fix, which i can add into #997