[mesa-users] Post-processing of mixing regions
Bill Paxton
paxton at kitp.ucsb.edu
Tue Apr 22 18:56:29 EDT 2014
On Apr 22, 2014, at 3:13 PM, Radek Smolec wrote:
> 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?
that's a strange one -- and I'm not able to reproduce it in my current version (I get good agreement with actual_gradT and gradT).
if you'd like to take 6380 for a test drive, it has the changes we've been discussing.
-B
> 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/20140422/2e10c364/attachment.html>
More information about the Mesa-users
mailing list