Re: mesa-users] Massive stars not reaching TPAGB

[Bill P. <pa...@ki...>]

Hi Eric,

Thanks for the update.

It appears that now instead of a problem in the code, you may be hitting a problem with the star.
This is speculation, so please feel free to show that it is wrong.  But here's my current understanding.
(Keep in mind that I'm a computer scientist with a smattering of astrophysics, so don't believe any
of this without checking for yourself!)

If you make a profile plot of pgas_div_ptotal, I expect you will find it drops to a low value just below
the bottom of the outer convection zone.  And that drop occurs where there is a spike in opacity.
The temperature is around logT = 5.2 or so at that location (at least in the cases I've seen).
And the opacity spike is from the "iron bump" that shows up around there.  The high luminosity and
the spike in opacity probably combine to give the small value for pgas_div_ptotal.
And when prad >> pgas, things get unstable.  If the timesteps are too large, the code starts getting
bad things like negative cell volumes, so it responds by making the timesteps very small.
By doing that it can deal with the instability, but as you note, it will never get through the AGB.
All of this might be a reflection of problems with the 1D approximation in this situation;
perhaps the instability turns into convection in 3D.

So now forget everything I just said, and figure it out for yourself -- then tell me what's going on!

BTW: just to check, you might try running your 7 Msun at very low Z to reduce the opacity.  Then what happens?


--Bill




On Jul 19, 2010, at 1:06 PM, Eric Blais wrote:

> Hi,
> 
> I wanted to get back to you for a while but the run just kept on going!  I decided to test version 2514 with a 7 solar masses star with mostly standard controls.  It ran for 120 hours.  It only stopped because that's the maximum amount of time allowed for a job on the cluster I'm using, so If I wanted to, I could set it to run for another 120 hours.
> 
> After a few hours, the luminosity and temperature change very slowly, so I doubt it could eventually get to the WD stage.  Towards the end, the time step was about 1.22E-6, so I guess this explains the extremely slow progress.  In fact, only the first 1% of the log has a time step above 1.  Were it not for this extremely slow TPAGB phase, the whole run could probably be completed on the cluster I'm using in under 5 hours.
> 
> I thought you mind find that interesting.
> 
> Eric Blais
> 
> 
> 
> On Mon, Jul 12, 2010 at 3:53 PM, Bill Paxton <pa...@ki...> wrote:
> Hi Eric,
> 
> Please update to the current version.
> The bug you are getting has been fixed.
> Let me know how it goes!
> 
> Thanks,
> Bill
> 
> 
> <HR_7Msun_test.JPG>