[mesa-users] Comparing OP_a09 vs. OP monochromatic track

[Aaron Dotter]

Hi Esan,

I have one suggestion: Run the mono version again but this time force Z to
be as defined in A09, instead of whatever it is exactly in your model.  By
"force Z" I mean rescale the abundance array input to the mono routines
such that H and He are unchanged but the other elements are rescaled by
(1-X_H-X_He)*AGSS09_element_zfracs.  I hope that makes sense.

This is essentially what the tabulated opacities do.

I have done this before but only with low-T opacities calculated on the
fly.  I can confirm that it resulted in a small shift in Teff similar to
what you've shown.

Aaron


On Saturday, August 1, 2015, Ehsan Moravveji <e.moravveji at gmail.com> wrote:

> Dear MESA users,
> I have computed two prototypical evolutionary tracks for a 7.5Msun star
> and Z=0.014 with Asplund et al. (2009) mixture, once setting
>
>     initial_zfracs = 6
>     kappa_file_prefix = ‘OP_a09'
>
> and another time turning on the monochromatic opacity (Mono) computations
> instead of using tables. Nothing else is changed.
> Mass loss and overshoot are also turned off, to make sure they do not
> intervene.
> I have attached my inlist and my modified net (that includes all 17 OP
> elements). I use version 7678 and MESASDK.
>
> I notice that there is a significant shift of the evolutionary track
> towards higher log_Teff when using the Mono opacities. The reason is that
> the OP Mono opacity profile in this model is systematically below what is
> retrieved from tables.
> This surprises me, because the default OP_A09 table should (almost) mimic
> OP_a09 (with a difference that we need an interpolation in the latter case).
>
> Has anyone seen this before?
> Is there a way to fix this difference? Am I making any mistake here in my
> inlists?
>
> Best regards
> Ehsan.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150801/ddf20ab5/attachment.html>