[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