[mesa-users] Slow evolution in 1.5 Msun model
moravveji at iasbs.ac.ir
Thu Oct 18 06:22:09 EDT 2012
Thanks Aaron for your prompt reaction.
Certainly, my MESA tracks extend to Teff < 3000 K after core He depletion
(using v. 4226 and earlier.). I have attached a sample HRD. This is also
consistent with the location of mid to late M-type stars (M5 in my case).
This is achieved without any witchcraft. My inlist has the Reimers mass
loss, the 'mesa' EOS, and the 'a09' kappa.
The only point that I am crying out for is the time cost of the run on a
12 node cluster.
With the same machine, say a 15 Msun star, reaches the RGB phase in two
hours. So, I am expecting nearly the same on the AGB phase. If each track
would take half or full day, then running a grid with say 60 tracks (my
case) needs over a month for one test :-0
Another point that confuses me is the large number of mesh points
(~24,000) by setting mesh_delta_coeff = 0.80, and keeping the rest as
> Hi Ehsan,
> You've certainly gone past central He depletion as your terminal output
> shows. You may never achieve Teff < 3000 K for these stars unless you are
> using fancy mass loss and opacities. If you just want central He
> depletion, use that alone to stop the calculation. There is also
> something along the lines of "stop at 1st thermal pulse" that would take
> you a bit further. How long it will take depends on your hardware, but it
> should not be more than ~5000 time steps.
> On Oct 18, 2012, at 7:23 PM, "Ehsan Moravveji" <moravveji at iasbs.ac.ir>
>> Dear all,
>> I am running a grid of models of 1.5 to 2.5 Msun stars with v. 4589. The
>> star is supposed to start from the pre-MS phase, and stop after the core
>> He depletion once Teff < 3000.
>> This is supposed to be a trivial evolution as my experience with massive
>> tracks tell, in a sense that each model must finish in an hour or two.
>> However, it is over 12 hours that even the first model has not finished.
>> Here is the terminal output:
>> step lg_Tcntr Teff lg_LH lg_Lnuc Mass
>> H_rich H_cntr N_cntr Y_surf X_avg eta_cntr
>> pts retry
>> lg_dt_yr lg_Dcntr lg_R lg_L3a lg_Lneu lg_Mdot
>> H_poor He_cntr O_cntr Z_surf Y_avg gam_cntr iters
>> age lg_Pcntr lg_L lg_LZ lg_Psurf lg_Dsurf
>> He_poor C_cntr Ne_cntr Z_cntr Z_avg v_div_cs
>> 17250 8.032290 3384.687 3.079061 3.210327 1.347981
>> 0.819935 0.000000 0.000000 0.282155 0.427826 17.730055
>> 24225 81
>> 3.351565 6.104060 2.073604 2.480932 1.982266 -8.135194
>> 0.528046 0.000000 0.661732 0.014063 0.196686 4.907572 4
>> 2.9688E+09 22.584314 3.218765 2.081776 3.222172 -8.111061
>> 0.449231 0.322686 0.001312 1.000E+00 3.755E-01 0.420E-06
>> I noticed that the number of mesh points in the model is exceedingly
>> That might be a reason for this slow evolution. True?
>> I am sure that I never wanted such a fine mesh spacing as in from my
>> mesh_delta_coeff = 0.8
>> varcontrol_target = 1d-4 ! to adjust the time steps
>> Is this typical of low-mass stars with mesa to take too long time to
>> Are there switches (except varcontrol_target) to speed up the evolution?
>> I believe there must be a way to reduce the time cost when running a
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 177859 bytes
Desc: not available
More information about the Mesa-users