[mesa-users] Problem with evolving pure helium stars

[Philip D. Hall]

Hi,

It seems the wind mass-loss is partly responsible for the decrease in
timestep at the onset of core He burning. Running MESA r7624 with Ylva's
inlist minus mass-loss gives a sequence which gets through He burning with
fewer timesteps.

The desired fewer timesteps can be achieved when mass-loss is switched on
by running Ylva's inlist with the boundaries of the const_q and const_mass
parts of the mesh fixed in q. For example:

    max_logT_for_k_below_const_q = 1d99
    max_q_for_k_below_const_q = 1
    min_q_for_k_below_const_q = 0.999

    max_logT_for_k_const_mass = 1d99
    max_q_for_k_const_mass = 1
    min_q_for_k_const_mass = 0.995

This could suggest that the small timesteps with the default boundary
choices are related to the treatment of eps_grav and the different mesh
regions during mass-loss. Could the fact that the boundaries for the form
of eps_grav and the mesh aren't tied together during mass-loss as they are
for mass-gain cause var_control to increase?

The timestep in the pre-MS phase is limited by "delta_HR_limit". Relaxing
this limit could speed things up in that phase.

Philip

On 9 September 2015 at 16:18, Bill Paxton <paxton at kitp.ucsb.edu> wrote:

> Hi,
>
> Note that there is a Z=0.02, Y=0.98 helium main sequence included in the
> mesa release
>         mesa/data/star_data/zams_models/zams_z2m2_y98.data
>
> To load starting models using that file, set this &controls parameter
>         zams_filename = 'zams_z2m2_y98.data'
>
> The data file covers the mass range 3.25 to 18.25 Msun, and the load zams
> routine will interpolate for any intermediate mass values.
>
> Cheers,
> Bill
>
>
>
> On Sep 9, 2015, at 2:17 AM, Ylva Götberg wrote:
>
> > Hi Aaron and Philip,
> >
> > So, I wanted to compare the evolution of pure helium stars with helium
> stars created from envelope stripping in binaries. Also, I’d like to check
> how well I could estimate the helium zero-age main sequence with homology
> relations.
> >
> > The star is taking extreme amount of models though to get to this tiny
> burning so I don’t know if it would get much better if I just continued
> longer (see attached Kippenhahn diagram).
> >
> > I have attached the enlist_project for the 0.5 MSun, happy to hear that
> you succeeded Philip!
> >
> > Ylva
> >
> <inlist_project_M0.5he><A6B1D357-7F2B-4A33-9CDE-412079D6911F.png>------------------------------------------------------------------------------
> > Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> > Get real-time metrics from all of your servers, apps and tools
> > in one place.
> > SourceForge users - Click here to start your Free Trial of Datadog now!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140_______________________________________________
> > mesa-users mailing list
> > mesa-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> 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/20150909/b4238c90/attachment.html>