[mesa-users] Getting uniform coverage of the upper main-sequence / post main-sequence
Aaron Dotter
aaron.dotter at gmail.com
Tue Feb 3 20:10:04 EST 2015
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150204/70d9f318/attachment.html>
More information about the Mesa-users
mailing list