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

Pablo Marchant pamarca at gmail.com
Wed Feb 4 06:25:44 EST 2015 

I had this problem a while ago, and I also sorted it out with the XH_cntr
limit, but also with the delta_HR_limit. With these options I don't need to
set min_timestep_factor to zero, and I get things pretty well resolved at
the end of the main sequence, and all the way to the giant branch. I
normally use this in the 10-20 solar mass range, but I guess it will still
work for lower masses.

     ! these are to properly resolve core hydrogen depletion
     delta_lg_XH_cntr_limit = 0.02d0
     delta_lg_XH_cntr_max = 0.0d0
     delta_lg_XH_cntr_min = -6.0d0
     delta_lg_XH_cntr_hard_limit = 0.03d0
     ! this is mainly to resolve properly when the star goes off the main
sequence
     delta_HR_limit = 0.005d0

On Wed, Feb 4, 2015 at 7:02 AM, Richard Townsend <townsend at astro.wisc.edu>
wrote:

> 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> 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
> > 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>
>> 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/_______________________________________________
>> > mesa-users mailing list
>> > mesa-users at lists.sourceforge.net
>> > 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 
Pablo Marchant Campos
M.Sc on Astrophysics, Universidad Católica de Chile
PhD student, Argelander-Institut für Astronomie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150204/2f46810a/attachment.html>
-------------- 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/20150204/2f46810a/attachment.png>
-------------- 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/20150204/2f46810a/attachment-0001.png>

More information about the Mesa-users mailing list