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

Wed Feb 4 01:02:28 EST 2015

Hi again folks —

Further digging into the ‘galloping’ around the Henyey hook reveals that the correct fix is to restrict the max change in the central hydrogen abundance. This is handled well by the default setting of delta_lg_XH_cntr_limit=0.05; however, this limit is only applied for log10(X) between delta_lg_XH_cntr_min and delta_lg_XH_cntr_max. With the default delta_lg_XH_cntr_min=-3, the limiting gets switched on too late in the Henyey hook. As a fix, I changed delta_lg_XH_cntr_min to -1. Voila; problem fixed.

So, here’s what things looked like before the fix (and also without the min_timestep_factor=0 fix):

…and here’s what things look like after the fix (see the plot title for the precise details of the fix):

Thanks to everyone who made helpful suggestions; my education in MESA continues apace!

cheers,

Rich

> On Feb 3, 2015, at 5:26 PM, Richard Townsend <townsend at astro.wisc.edu> wrote:
> 
> 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:
> 
> <hrd-4.66-4.76-nolim.png>
> 
> 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 <mailto: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>
>> 
>> 
> 
> ------------------------------------------------------------------------------
> 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/_______________________________________________
> 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/20150203/aa180f6c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hrd-original.png
Type: image/png
Size: 43626 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150203/aa180f6c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hrd-fixed.png
Type: image/png
Size: 53918 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150203/aa180f6c/attachment-0001.png>