[Mesa-users] lowT opacities---preprocessor step blends Freedman tables and Ferguson tables

Wed May 27 14:54:43 UTC 2026

Cheers, thanks, Ebraheem! That makes sense, I should have checked the 
Freedman+2014 paper for the upper T limit. I will keep the 
get_lowT_blend but fix the other logic issue you identified.

Regarding the choice of hard-coded Ferguson table--having thought about 
it more this afternoon, perhaps a more consistent choice would be to 
pick the X and Z combination that yields an X/Y ratio closest to the 
protosolar X/Y ratio presented in Lodders 2003, upon which the 
Freedman+2008,2014 tables are based? Lodders measures protosolar X/Y = 
2.594, and the combination of available Ferguson X, Z that matches this 
most closely is X = 0.7, Z = 0.03 -> X/Y = 2.593.

On 2026-05-27 14:20, Farag, Ebraheem wrote:
> Hi Emily,
> 
>  The relevant MESA input data are the 2011 tables privately
> communicated by R. S. Freedman. These appear to correspond to the
> expanded opacity tables later described by Freedman et al. 2014 [1],
> while Freedman et al. 2008 [2] is the earlier paper currently linked
> in the MESA kap documentation. I think the docs should say this more
> explicitly, so the PR updates that wording. Some of the original MESA
> documentation predates the 2014 paper, which may be part of the
> confusion here.
> 
>  The raw Freedman opacity tables used here do not actually extend to
> `logT = 4.5`. They stop near `T = 4000 K`, i.e. `logT ~= 3.60`. The
> preprocessed MESA `lowT_Freedman11` tables extend to `logT = 4.5` so
> they can sit on the same output grid and overlap region as the other
> opacity tables, but values above the top of the raw Freedman grid need
> to be filled or blended somehow.
> 
>  I would not replace the blend with `eval_freedman` all the way to
> `logT = 4.5`. In the preprocessor, `eval_freedman` clips the requested
> temperature to the raw Freedman table limits, so above ~4000 K that
> would not be evaluating actual Freedman opacities at those
> temperatures.
> 
>  You are right that there was a separate composition bookkeeping issue
> for these tables, and that was the issue addressed in the PR that came
> out of your earlier thread: the Freedman `[M/H]` labels were being
> treated as metal mass fractions `Z`. That was fixed in GitHub issue
> 993/current main by changing the `lowT_Freedman11` `Z` grid to the
> corresponding metal mass fractions and regenerating the tables.
> 
>  The hard coded Ferguson table used in the high temperature blend
> seems like a separate thing we should either fix or document. The main
> point is that the blend is there because the Freedman data end near
> 4000 K, not because the raw Freedman tables are valid to `logT = 4.5`.
> 
> 
>  While looking closer, I did notice something weird though: in the
> current preprocessor source, the intended Ferguson blend appears to be
> unreachable for normal table points. In `get_lowT_blend`, the branch
> is:
> 
>  ```
>  if (logT <= logT_low1 .or. R > 0) then ! all Freedman
>     call eval_freedman(T, Rho, logK, dbg)
>     return
>  end if
>  ```
> 
>  and `R` is defined as `Rho/(T6*T6*T6)`. Since both `Rho` and `T6` are
> positive for physical opacity table points, `R > 0` is always true.
> Because that condition is an `.or.`, the code takes the Freedman
> branch regardless of `logT`, so the later Ferguson only and blended
> branches are not reached in practice. I suspect that condition was
> intended to be something else, but as written it makes the "all
> Freedman" path unconditional for physical table points.
> 
>  As a result, for requested points above the top of the raw Freedman
> temperature grid, e.g. `logT = 3.7` or `3.8`, the preprocessor is not
> using Ferguson there. It calls `eval_freedman`, which clips the
> temperature to the raw upper limit, approximately `log10(4000) =
> 3.60206`, while still using the density implied by the requested
> output point. So the generated entries are basically
> 
>  ```
>  kappa(logT_requested, logR) = kappa_Freedman(logT = log10(4000),
> logRho = logR + 3*logT_requested - 18)
>  ```
> 
>  This means the values above 4000 K are not real higher temperature
> Freedman data, and they are also not the Ferguson part of the intended
> blend. They are top edge Freedman values evaluated at the densities
> corresponding to the higher requested `logT` values.
> 
>  I'm not sure if this was done intentionally or not, but we can think
> about changing/fixing this blend behavior in the current github pull
> request that addresses your previous issue:
> https://github.com/MESAHub/mesa/pull/994 [3].
> 
>  -EbF
> 
> -------------------------
> 
> From: Mesa-users <mesa-users-bounces at lists.mesastar.org> on behalf of
> Emily Sandford via Mesa-users <mesa-users at lists.mesastar.org>
> Sent: Wednesday, May 27, 2026 6:26 AM
> To: mesa-users at lists.mesastar.org <mesa-users at lists.mesastar.org>
> Subject: [Mesa-users] lowT opacities---preprocessor step blends
> Freedman tables and Ferguson tables
> 
> Hello all,
> 
> Back with more questions about the lowT opacity tables! Based on the
> kap
> module documentation, I had assumed that the Freedman tables and the
> Ferguson tables were two separate options, but investigating further,
> it
> appears that the Ferguson tables can be used on their own, but that
> the
> Freedman tables are always blended with the Ferguson tables in the
> kap/preprocessor step.
> 
> Specifically, in kap/preprocessor/src/kap_support.f:
>     -if lowT_flag is .true. and Freedman_flag is .false., then the
> funciton eval_ferg from kap/preprocessor/src/ferguson.f is called,
> returning an opacity from the Ferguson tables, as I would have
> expected.
>     -however, if lowT_flag is .true. and Freedman_flag is .true., then
> 
> the function get_lowT_blend is called, which returns an opacity from
> the
> Freedman tables for logT <= 3.58, but an opacity from the *Ferguson*
> tables for logT >= 3.6. For 3.58 < logT < 3.6, it returns a linear
> blend
> between the Freedman and Ferguson opacities.
> 
> The Freedman tables do cover temperatures up to logT = 4.5, so I'm not
> 
> sure why this blend is enforced. Additionally, I don't think the blend
> 
> is calculated at the right metal mass fraction, because if
> Freedman_flag
> is .true., then ferguson.f reads in the Ferguson table corresponding
> to
> X = 0.7, Z = 0.1 regardless of the user-supplied composition (see the
> get_ferg_filename routine in ferguson.f).
> 
> I want to use the Freedman tables only, so my plan is to change the
> get_lowT_blend call to an eval_freedman call and rerun all the table
> preprocessing. I'm happy to pull request my changes if this is another
> 
> legitimate problem in the preprocessor scripts, but curious if anyone
> can shed some light on the situation.
> 
> Thanks,
> Emily
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=05%7C02%7CEbraheem.Farag%40yale.edu%7C5363a771270a4aabf3d108debbda8dcf%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C639154744555169321%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V3V150EetH141mvVt5S7l%2BLYaj0Wor91wm1dsO0Gym8%3D&reserved=0
> [4]
> 
> 
> 
> Links:
> ------
> [1] https://ui.adsabs.harvard.edu/abs/2014ApJS..214...25F/abstract
> [2] https://ui.adsabs.harvard.edu/abs/2008ApJS..174..504F/abstract
> [3] https://github.com/MESAHub/mesa/pull/994
> [4] https://lists.mesastar.org/mailman/listinfo/mesa-users