[mesa-users] Post-processing of mixing regions

[Radek Smolec]

Hi,

I try to understand a similar problem: in my case convective region turns
to be semi-convective and I was not able to trace in mix_info how (and why)
this actually happens. In the attached figure you may see the plot of
relevant gradients close to the border of the envelope convection zone.
This is a 1.02 solar mass model at the onset of RGB and hence the envelope
convection penetrates deep into the star. In the bottom panel the color
stipes correspond to stability_type (equivalent to mlt_mixing_type), in the
top panel they correspond to the mixing_type. The white stripe in-between
convective (pink) and semi-convective (green) regions is just in-between
two mesh points for which stability/mixing types are different (1/3) and
does not mean there is a radiative zone in-between (I should make a better
plot). In the bottom panel you can also see a (two mesh points) difference
between gradT (blue line, nabla_T, returned by mlt module?) and
actual_gradT (nabla, after mix_info?)  the former consistent with the plot
in the bottom and the latter consistent with the plot in the top.

Why the sc-zone expanded? I find the differences between mixing_type and
mlt_mixing_type (stability type) and gradT and actual_gradT a little bit
confusing. Before finding this problem I was using gradT as an actual
temperature gradient.

The inlist is attached. Starting model (ms.mod) can be downloaded here (
https://www.dropbox.com/s/b9wvpry3zjloqq9/ms.mod). The plotted model is
2300. Mesa version 6208.

Radek



2014-04-22 0:28 GMT+02:00 Kevin Moore <klmoore at soe.ucsc.edu>:

> Hi all,
>
> I’m trying to understand the post-processing that’s done by MESA to tidy
> up different mixing regions (eg. gap removal) that happens after the MLT
> module is called. This code (I think) is all in star/private/mix_info.f.
>
> I’m working with models where the only non-default mixing is
> semiconvection and I see examples of both semiconvective regions turning
> radiative (eg. MLT_mixing_type = 3 and mixing_type = 0) as well as
> radiative regions turning semiconvective (eg. MLT_mixing_type = 0 and
> mixing_type = 3). As I understand it, MLT_mixing_type is the mixing type of
> the cell that the MLT module returns, while mixing_type is the actual
> mixing type after some post-processsing.
>
> It appears that by default, the only mixing ‘glitches’ that MESA deals
> with are remove_small_D_limit, which is checked when the MLT module is
> called, so shouldn’t cause differences between MLT_mixing_type and
> mixing_type, and remove_mixing_singletons(), which can turn isolated
> radiative zones into mixing zones and vice-versa. There’s also a check to
> remove entire convective regions that are smaller than 10% of the mixing
> length (along with any mixing in cells that border that region), called
> from locate_convection_boundaries().
>
> I can’t, however, find anywhere in the code where an isolated radiative
> zone (surrounded by convective zones) can be converted into a
> semiconvective zone. I also observe isolated radiative zones that persist
> from MLT_mixing_type into mixing_type without being absorbed into their
> surrounding convective zones. Are there additional places in the code
> (other than star/private/mix_info.f) where mixing types can be changed?
>
> -Kevin
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140422/aec2bce9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_project_sc
Type: application/octet-stream
Size: 5213 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140422/aec2bce9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gradsM14.eps
Type: application/postscript
Size: 37580 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140422/aec2bce9/attachment.eps>