[mesa-users] Getting uniform coverage of the upper main-sequence / post main-sequence

[Richard Townsend]

These controls indeed work well (I think I was the one who originally pushed Bill to put them in!). But I was hoping MESA would find more-fundamental reasons to avoid galloping off into the post-MS unknown!

Inspired by Bill’s comment a few minutes ago, I looked at the screen output for the M=4.76 track, and found the ‘dt_limit’ string was ‘max decrease’, for the last few steps. This means that MESA was trying hard to shorten the timestep, but was prevented by the default min_timestep_factor setting of 0.8.

I’ve just completed a run where I set min_timestep_factor to zero (removing this limit); here’s the result:



Much improved — although I should probably tighten up max_timestep_factor a bit also, to stop the gallop during the Henyey hook.

It’s particularly noteworthy in comparing the two M=4.76 calculations, that they differ quite noticeably in the post-MS region. So, MESA users, take care in choosing your timestep controls!

Best wishes,

Rich

> On Feb 3, 2015, at 5:10 PM, Aaron Dotter <aaron.dotter at gmail.com> wrote:
> 
> Hi Rich,
> 
> Your question is a really interesting one and I want to know the answer, too.
> 
> This is not an answer but just a suggestion regarding control of the timesteps.  I like to use these:
> 
>       ! limits based on changes at photosphere
> 
>          !### delta_lgTeff_limit
>          !### delta_lgTeff_hard_limit
> 
>          ! Limit for magnitude of max change in log10 temperature at photosphere.
> 
>       delta_lgTeff_limit = 0.01
>       delta_lgTeff_hard_limit = -1
> 
> 
>          !### delta_lgL_limit_L_min
>          !### delta_lgL_limit
>          !### delta_lgL_hard_limit
> 
>          ! Limit for magnitude of change in log10(L/Lsun).
>          ! Only apply this limit when L >= `delta_lgL_limit_L_min` (in Lsun units).
>       delta_lgL_limit_L_min = -100
>       delta_lgL_limit = 0.1
>       delta_lgL_hard_limit = -1
> 
> I'd suggest reducing delta_lgL_limit considerably and maybe setting the hard limits for both as well.
> 
> Cheers,
> Aaron
> 
> 
> 
> On Wed, Feb 4, 2015 at 11:56 AM, Richard Townsend <townsend at astro.wisc.edu <mailto:townsend at astro.wisc.edu>> wrote:
> Further to my mail below, here are tracks for two neighboring masses.
> 
> 
> 
> 
> Clearly, the end of the MS, and the post-MS evolution, is being handled using much larger timesteps in the M=4.76 model than the M=4.66 model. Can anyone suggest why this might be? The inlist files are, apart from the initial mass, identical (I attach the file for M=4.66).
> 
> cheers,
> 
> Rich
> 
> 
> 
> 
> > On Feb 3, 2015, at 4:20 PM, Richard Townsend <townsend at astro.wisc.edu <mailto:townsend at astro.wisc.edu>> wrote:
> >
> > Hi folks —
> >
> > I’m running a grid of 101 massive-star evolutionary tracks (over the mass range 2.5 < M < 25, logarithmically spaced in M) with an eye to mapping out instability strips. For each M, I use MESA to evolve from the ZAMS through to the point where Teff < 6,600K.
> >
> > Perhaps naively, I was expecting the tracks to each contain a similar number of steps — and that the (log Teff, log L) values from all steps of all tracks would, in some sense, cover the HR diagram reasonably smoothly.
> >
> > However, I’m finding this not to be the case — tracks with neighboring masses often contain very different numbers of steps. To illustrate this, I attach here a plot of #stesp vs. mass.
> >
> > <steps-from-zams.png>
> >
> > Can anyone enlighten me as to why the number of steps jumps around so much — and what I might do to obtain more predictable behavior? I’m digging through the log files right now, but I thought I should check whether there is a known solution out there.
> >
> > cheers,
> >
> > Rich
> >
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________ <http://goparallel.sourceforge.net/_______________________________________________>
> > mesa-users mailing list
> > mesa-users at lists.sourceforge.net <mailto:mesa-users at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/mesa-users <https://lists.sourceforge.net/lists/listinfo/mesa-users>
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/ <http://goparallel.sourceforge.net/>
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net <mailto:mesa-users at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/mesa-users <https://lists.sourceforge.net/lists/listinfo/mesa-users>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150203/1a4727f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hrd-4.66-4.76-nolim.png
Type: image/png
Size: 41410 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150203/1a4727f6/attachment.png>