[mesa-users] Post-processing of mixing regions
Radek Smolec
smolec at camk.edu.pl
Tue Apr 22 18:13:22 EDT 2014
Hi Bill,
Thank you very much for the explanations. The changes sound good to me.
More 'documentation' e.g. in star/defaults/profile_columns.list would be
great (just short comments like 'at the start/end of time step'). I am not
quite sure whether I get the gradients right. Considering my figure
gradsM14.eps: the shading in the bottom panel (stability_type equiv.
mlt_mixing_type) and the gradients corresponds to situation at the end of
the time step. gradT should closely match actual_gradT, but it doesn't
because we are not getting exact solutions. In this case however the
difference is confusing: actual_gradT (cyan, nabla) follows gradr in the
convective zone which nicely matches the mixing_type in the top panel (from
the start of the time step), since in SC region gradt=gradr. Is it by
chance only?
Radek
2014-04-22 18:47 GMT+02:00 Bill Paxton <paxton at kitp.ucsb.edu>:
> Hi Radek,
>
> Thanks for sending the inlist --- that makes all the difference!
>
> Turns out to be a subtle effect of the time of evolution represented in
> the different plots.
>
> As you might recall, MLT provides 2 things for the evolution: gradTs and
> diffusion coefficients for mixing.
>
> We call MLT at the start of the timestep to get the diffusion
> coefficients. Then we "edit" those and add overshooting if requested.
> The results of this are saved in these variables in star_info:
>
> ! adjusted (non-local) mixing info
> real(dp), pointer :: D_mix(:) ! diffusion coeff. (cm^2/sec)
> real(dp), pointer :: conv_vel(:) ! convection velocity
> integer, pointer :: mixing_type(:) ! mixing types are defined in
> mesa/mlt
>
> and -- importantly -- we do not modify those values during the rest of the
> timestep. those values are what we use during the evolution for the step.
>
> However, gradT is different. It is the target temperature gradient for
> the model, and we get a new value for it every iteration. So at the end of
> the step the value of gradT matches the new model. To get the updated
> values for gradT, we call MLT at each iteration. And for each call on MLT,
> these values are stored:
>
> ! results from mlt
> real(dp), pointer :: mlt_mixing_length(:)
> ! mixing_length_alpha * scale_height as computed by mlt
> integer, pointer :: mlt_mixing_type(:) ! as defined in mesa/const
> ! this is the value from mlt, before overshooting has been added.
> real(dp), pointer :: mlt_D(:)
> ! local mlt estimate for diffusion coeff. (cm^2/sec)
> real(dp), pointer :: mlt_vc(:)
> ! local mlt estimate for convection velocity
> real(dp), pointer :: mlt_Gamma(:)
> ! local mlt convection efficiency.
> real(dp), pointer :: gradT_sub_grada(:) ! difference at cell boundary
> real(dp), pointer :: grada_at_face(:) ! grada evaluated at cell
> boundary
>
> So at the end of the step, mlt_mixing_type and friends hold information
> about the new model (end of timestep), while mixing_type (etc) have info
> about the old model (start of timestep).
>
> You can check this --- look at the plot of mixing_type for model n and
> compare to mlt_mixing_type for model n-1. Here's an example. Look
> closely and you'll see that the location of the bottom of the convective
> zone is the same for mlt_mixing_type in model 2212 and mixing_type in 2213.
>
>
> but since the convective zone is moving inward, you'll find that the
> location of mlt_mixing_type in 2213 is at a smaller mass coord than the
> location shown for mixing_type in 2213 --- not because we have magically
> turned convection into semiconvection, but because we're looking at
> different times.
>
> Concerning "actual_gradT" --- you can now answer this for yourself. Find
> where it is set (grep in star/private) and see when it is set and how.
>
> The "gradT" value comes from MLT and is the target for the structure
> evolution to match. "actual_gradT" is the actual temperature gradient in
> the model. they should be very close, but not exactly the same because
> we're not getting exact solutions, just approximate ones.
>
> If you'd like to check mixing_type vs the corresponding values for grada
> and gradr, you'll need to use the values from the starting model. They are
> available along with some other things (see star_data.inc) -- remember to
> compare gradr_start (a cell face value) to grada_at_face_start (a cell face
> value), not grada_start (a cell center value) when checking gradT (a cell
> face value).
>
> real(dp), pointer :: lnd_start(:) ! (nz)
> real(dp), pointer :: lnP_start(:) ! (nz)
> real(dp), pointer :: lnPgas_start(:) ! (nz)
> real(dp), pointer :: lnT_start(:) ! (nz)
> real(dp), pointer :: lnR_start(:) ! (nz)
> real(dp), pointer :: L_start(:) ! (nz)
> real(dp), pointer :: omega_start(:) ! (nz)
> real(dp), pointer :: Z_start(:) ! (nz)
> real(dp), pointer :: ye_start(:) ! (nz)
> real(dp), pointer :: i_rot_start(:) ! (nz)
> real(dp), pointer :: P_div_rho_start(:)
> real(dp), pointer :: mass_correction_start(:)
> real(dp), pointer :: dxdt_nuc_start(:,:)
> real(dp), pointer :: luminosity_by_category_start(:,:) !
> (num_catgories,nz)
> real(dp), pointer :: grada_start(:) ! (nz)
> real(dp), pointer :: gradr_start(:) ! (nz)
> real(dp), pointer :: grada_at_face_start(:) ! (nz)
> real(dp), pointer :: chiT_start(:) ! (nz)
> real(dp), pointer :: chiRho_start(:) ! (nz)
> real(dp), pointer :: cp_start(:) ! (nz)
> real(dp), pointer :: cv_start(:) ! (nz)
> real(dp), pointer :: gam_start(:) ! (nz)
> real(dp), pointer :: eta_start(:) ! (nz)
> real(dp), pointer :: T_start(:) ! (nz)
> real(dp), pointer :: mu_start(:) ! (nz)
> real(dp), pointer :: abar_start(:) ! (nz)
> real(dp), pointer :: zbar_start(:) ! (nz)
> real(dp), pointer :: eps_nuc_start(:) ! (nz)
> real(dp), pointer :: non_nuc_neu_start(:) ! (nz)
> real(dp), pointer :: csound_start(:) ! (nz)
>
>
>
>
> What do you think about this idea for a change: I can modify the call on
> MLT so that when it is called to get gradT during the iterations it doesn't
> update the mixing information such as mlt_mixing_type. Then at the end of
> the step, mlt_mixing_type would still reflect the start of the step and
> could be compared to mixing_type without the confusion we have now. Would
> that be an improvement? We'd still have the confusion of users
> incorrectly comparing mixing_type from start of step to grada and gradr
> from end of step instead of the corresponding values from the start of the
> step. Some of this stuff is just complicated!
>
>
> -B
>
>
>
>
>
>
>
> On Apr 22, 2014, at 7:40 AM, Radek Smolec wrote:
>
> 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
>>
>
> <inlist_project_sc><gradsM14.eps>
> ------------------------------------------------------------------------------
> 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/20140423/ed51d57d/attachment.html>
More information about the Mesa-users
mailing list