[mesa-users] Order of relax_initial_Y and relax_initial_Z

[Bill Paxton]

Hi,

On Oct 30, 2013, at 6:43 AM, Warrick Ball wrote:

> Hi,
> 
> I'm trying to create a grid of MESA models for some grid-modelling.  I fought with the create_pre_main_sequence_model for a while but, given that it's a bit fickle, I thought a better bet would be to get one pre-MS model that does converge and adjust it through the relax_* options in &star_job. That is, my (attached) inlist contains (among other things)
> 
>      relax_mass_scale = .true.
>      new_mass = 0.80 ! in Msun units
> 
>      relax_Y = .true.
>      new_Y = .315
> 
>      relax_Z = .true.
>      new_Z = 0.005
> 
> What I've noticed is that after relaxing the pre-MS model, the composition doesn't match my input.  I regard each time MESA doesn't do what I'm expecting as an opportunity to open the hood and see what's going on, so I followed a whole lot of function calls down the rabbit hole.  

As Alice said, down the rabbit hole things get curiouser and curiouser!  Glad to have you looking at this -- I hope more users take the trip to wonderland!

> First, I established that Y is relaxed before Z in mesa/star/job/run_star_support.f (line 1048).  I then kept following the calls until I got to the functions set_y and set_z in mesa/star/private/adjust_xyz.f.
> 
> set_y functions pretty much as I'd expect: it basically converts H1 into He4 or vice versa.  In set_z, the work is done in the local subroutine "convert", from which it appears that first the metallicity is decreased by rescaling each abundance that isn't H1, He3 or He4, and then the others are rescaled to make the abundances all add up to one.
> 
> Now, this is perfectly acceptable behaviour.  But!  It means that I have to set up my input files by inverting the calculation in set_z so that the numbers come out the way I want them.  (Okay, actually, all I have to do is swap relax_Y and relax_Z in run_star_support.f and recompile, but tinkering with the source is cheating!)  I'm not sure of how things pan out in other use cases, but I think it's reasonable to expect that if one sets new values for Y and Z in the inlist, the evolution should start from a model with that Y and Z.

Sounds to me like you have made a good argument for changing the order in run_star_support.  I'll do it!  ;D   in next release, relax Z will be done before relax Y.  

> 
> To close, I have one related question.  There are also controls called relax_initial_Y and Z.  From looking at the source, these seem to do exactly the same thing as relax_Y and Z.  Are these legacy controls?  It's no issue but I just want to make sure that they aren't actually subtly different controls that I should be using.

The controls with "initial" in their name only happen for ./rn, not for ./re -- the ones without "initial" happen at both ./rn and ./re
I typically use the "initial" ones to avoid unintentional redoing of things like relax_Y when I do a restart.

Cheers,
Bill









> 
> Cheers,
> Warrick
> 
> --
> MESA 5527, MESA SDK (April 2013), Scientific Linux 6.4 (Carbon)
> 
> 
> ------------
> Warrick Ball
> Postdoc, Institut für Astrophysik Göttingen
> wball at astro.physik.uni-goettingen.de
> +49 (0) 551 39 5069<inlist.txt><pms.mod>------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users