fix low density/Pressure SCVH EOS tables

[Debraheem]

This pr is an attempt to address #995, which spawned from a mailing-list thread initially raised by Natasha Ivanova:

I believe the main concern was the mean molecular weight being that of an ionized mixture in the regions highighted in the plots below, when adopting both Free_EOS and OPAL/SCVH.

https://lists.mesastar.org/pipermail/mesa-users/2026-May/015873.html:

Particularly in the low T-rho regime, as I'm not sure there is a better fallback than HELM in the high pressure regime (that would require an actual eos for that region).

For the SCVH tables, below logP_min = -0.6 the SCVH coverage is now supplied analytically in
eos/eosDT_builder/src/scvh_core.f90. For each fixed logT row and each species, the tail uses the edge state and extrapolates to the ideal gas limit.

logP0 = -0.6
logrho0 = logrho(logP0, logT)
logu0 = logu(logP0, logT)
logs0 = logs(logP0, logT)
R = 10**(logP0 - logrho0 - logT)

and the ideal low-pressure limit

logrho_ideal(logP) = logrho0 + logP - logP0
logu_ideal(logP) = logu0
S_ideal(logP) = S0 + R*ln(10)*(logP0 - logP)
logs_ideal(logP) = log10(S_ideal)
comp_ideal(logP) = comp0

The implementation uses this ideal value below the first lower-pressure grid
step and applies a local cubic correction between logP0 and that point so the
tail is value-continuous and has the same d/dlogP as the restored processed
SCVH table at the edge. That keeps the generated eosDT interpolation support
smooth without editing the raw SCVH data files.

In this pr, I also noticed when regenerating the eos tables that there was a HELM fallback in
the high pressure region, and it produced noisy mu features
near the OPAL/SCVH support boundary in regenerated tables. I think this fallback didn't exist,
when the tables where generated the first time, so i turned it off for the table generation. see check_results :

was
gamma1_opalscvh <= 1d0 .or. gamma1_opalscvh >= 2d0 .or. grad_ad_opalscvh >= 50d0) then
now
gamma1_opalscvh <= 0d0) then

This might not be correct, but it was the only way for me to make the new eos smooth like the old eos tables, but maybe this expression should be adjusted.

See the plots below

After adding the smooth extrapolation to SCVH, i also noticed there was a bad row of partials on the
FreeEOS SCVH boundary at logT = 3 - 3.1. It turns out the fallback here were rows generated from the
MESA EOS with lnPgas, lnE, and lnS in natural log form, but the FreeEOS data files
store those columns as base-10 logarithms. so i these just need to be converted in eos/eosFreeEOS_builder/src/free_eos_table.f90. (See the original issue below).

I had to regenerate the eos for this pr.

• eos/eosFreeEOS_data.tar.xz
• eos/eosDT_data.tar.xz

I bumped the the FreeEOS table version and the eosDT table version to 52.

A few plots from the new eos looks like this:

(a bit low res for the eos plotter)

The eosDT region definitions shifted very slightly in eos/eosDT_builder/src/eos_regions_defs.dek and
eos/eosDT_builder/src/eos_regions_code.dek keep the generated OPAL/SCVH support
out of the warm, very-low-density FreeEOS side. This prevents the SCVH
low-pressure floor from interacting with the FreeEOS boundary at
logrho ~ -15.

This PR probably needs some further attention validation and testing, maybe clean up.

[evbauer]

Wow. Did you actually rerun the full FreeEOS preprocessor to regenerate all of the FreeEOS tables after the fix for the MESA fallback points? What version of FreeEOS did you use? Last time I tried this, I was having trouble getting an external FreeEOS installation to compile, run, and be compatible with the MESA preprocessor. But that was a while ago.

[evbauer]

Rather than extrapolating "OPAL/SCVH" over to low density, why not just blend over to neutral ideal gas there? It seems like making a table that extrapolates toward ideal gas is maybe just a less-optimal version, since we can do it analytically with auto-diff now?

[evbauer]

Great catch! I think you're right about this. Do you know if it has an impact on anything?

In practice, I think we cut out most of the region where FreeEOS was failing and falling back to MESA with the "logQ_cut"-related boundary controls. Anyway, I've always been a bit uncomfortable with the idea that our "FreeEOS" tables that were meant to replace the older EOS might end up falling back to the older EOS without being very clear about that. So I like the fix, but I don't really like the existence of the thing that we're fixing here...

[evbauer]

Why did the write format change?