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

[Richard Townsend]

Further to my mail below, here are tracks for two neighboring masses.

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


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_project
Type: application/octet-stream
Size: 1148 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150203/1bdbd537/attachment.obj>
-------------- next part --------------


> 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