[Mesa-users] Models failing to reach core collapse

Mon Jan 28 08:36:35 EST 2019

Hi Dan and Tylor,

We have also been working on a similar model involving inlists form Farmer
et al. referred here. We have been able to successfully run a 15Msun model
through CC with r10398. I have attached here relevant inlists and a
Kippenhahn plot at the end of the run. We have modified the original
inlists to meet some of our requirements though, important ones being -
turning off thermohaline mixing, changing overshoot parameters,
alpha_semiconvection, etc. (one may run vimdiff on my inlist_control
attached here and the original "complete" one from dropbox to see the
differences.)

We had encountered a similar problem of models cruising for several
thousand steps during late burning stages. One change in the original
inlist_control that helped us get the models to reach CC was to change the
lg_X_cntr_limit for Ne, O and Si from 0.01 to 0.02 (and corresponding
hardlimit to 0.03 from 0.02). Si burning still occupies a significant
portion of the run (ref. KH plot attached here.) I haven't tried running an
unchanged version of the Farmer et al. inlists with r10398, but perhaps
this change will help get your models to CC, or so I hope.

regards,
Guru
--
Gururaj  Wagle, Ph.D.
Research Associate - Astrophysics,
HBCSE-TIFR, Mumbai

On Mon, Jan 28, 2019 at 4:12 PM Rob Farmer <r.j.farmer at uva.nl> wrote:

> Hi Dan,
>
> Thanks for finding the issue with the inlist i (incorrectly) assumed you
> had made a decision to remove the mixing rather than the file having be
> truncated, sorry. Indeed the dropbox version was correct and the mesastar
> version should be updated shortly.
>
> On your point 2, i'm happy to help , if you could send a kippenhan plot
> (or just send the last Grid1 plot you have from the inlist_pgstar in the
> dropbox folder) and also the terminal output so we can see where things
> have stalled and what is controlling the timestep at this point.
>
> Thanks,
> Rob
>
>
> On Mon, 28 Jan 2019 at 00:59, Dan Patnaude via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
>> Hi Rob-
>>
>> Thanks for pointing this out. There are two things to point out here, one
>> related to the mesa marketplace, and another related to the inlists.
>>
>> 1: On the mesa marketplace (
>> http://cococubed.asu.edu/mesa_market/inlists.html), the inlists from
>> your paper linked here (
>> http://cococubed.asu.edu/mesa_market/ewExternalFiles/Variations_rf.zip ,
>> under the "Get" URL) vs those linked through the
>> dropbox
>> https://www.dropbox.com/sh/yclyf0fv7az8eya/AAAUeaqJYLeBYb0-CXeZ82Kza?dl=0 are
>> not the same. The dropbox files are consistent with what are in your paper
>> and what  you suggest. The "marketplace" inlists don't mention overshoot
>> and don't set the Ledoux criteria to true. This probably needs to be fixed
>> by the MESA folks.
>>
>> 2: Even with using the appropriate inlists, Taylor and I are still unable
>> to get the 15M core to collapse. I don't think this is related to "islands
>> of explodability," as these are the exact same inlists I used in my 2017
>> paper, version 7624, where I was able to get a core to collapse just fine.
>>
>> So I guess the 1st question is, have you been able to reproduce some of
>> your results using the latest stable release of MESA? Perhaps if you have
>> the time, you can work with us to iron out the issues.
>>
>> Thanks,
>> Dan
>>
>>
>> On Thu, Jan 17, 2019 at 4:44 AM Rob Farmer <r.j.farmer at uva.nl> wrote:
>>
>>> Hi,
>>>
>>> I see you've removed overshoot from your models. I find that having even
>>> a little bit of overshoot usually helps mesa evolve a model more
>>> efficiently, as it smooths the composition boundaries. Also you've removed
>>> the use_Ledoux_criterion=.true. so your using the default
>>> use_Ledoux_criterion=.false. which means schwarzschild convection
>>> boundaries. Again i've found ledoux to make the evolution easier (but this
>>> depends on what physics you want to test, if you want to change it)
>>>
>>> The other thing to do is work out what is happening inside the star that
>>> is causing problems. Kippenhan/abundance profile/mixing profile plots can
>>> help here to see how the burning/mixing is behaving and if it seems to get
>>> stuck somewhere particular (core burning? shell burning? which fuel?) which
>>> can help refine what you need to change to get the model working.
>>>
>>> I'd also look at what is limiting the timetsep. This is given by the
>>> string in the last entry of the terminal output for a step (called
>>> dt_limit). That limit can then be compared to the names here
>>> http://mesa.sourceforge.net/controls_defaults.html#timestep_controls
>>> and that will give you the timestep control that is currently limiting your
>>> evolution.
>>>
>>> Rob
>>>
>>>
>>> On Thu, 17 Jan 2019 at 05:42, Jamie Tayar <jtayar at hawaii.edu> wrote:
>>>
>>>> Hi Taylor,
>>>> This isn't really my area of expertise, so I'll let someone else
>>>> comment on the details of your models, but 15 solar masses is right around
>>>> where the 'islands of explodability' start to show up (e.g. Figure 5 of
>>>> https://arxiv.org/abs/1602.05956 or Figure 8 of
>>>> https://arxiv.org/pdf/1710.03243.pdf), and some fraction of models
>>>> never reach the sort of compactness that indicates a successful collapse,
>>>> so there's a possibility that what you're seeing is physics and not
>>>> numerics.
>>>> Apologies if you've already thought of that,
>>>> Jamie
>>>>
>>>> On Wed, Jan 16, 2019 at 6:25 PM Taylor Jacovich via Mesa-users <
>>>> mesa-users at lists.mesastar.org> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> Have run into an issue with the current version of MESA where stars
>>>>> with a specific mass will never reach core-collapse (fe_core_infall >
>>>>> 10**3km/s stopping condition).  A full description of the issue and all the
>>>>> model data can be found here:
>>>>> https://gitlab.com/wind-loss-testing/readme .
>>>>>
>>>>> The reader’s digest version is that stars with a certain mass (eg.
>>>>> 15.0Msun) will get stuck at a sub-Chandrasekhar mass iron core and happily
>>>>> coast for weeks at a time.  Meanwhile masses directly around the ones that
>>>>> fail to collapse (eg. 14.9Msun and 15.1Msun) will collapse without fail.
>>>>> We are using Farmer’s inlists that were designed to help with
>>>>> explodability, and the only parameter we change between runs is the mass.
>>>>> Any suggestions on new parameters to try or other options that may
>>>>> relieve the issue are much appreciated. Inlists are attached below, or you
>>>>> can clone from this directory
>>>>> https://gitlab.com/wind-loss-testing/windloss-template to have an
>>>>> identical experience.
>>>>>
>>>>> Thank you,
>>>>>
>>>>>
>>>>> Taylor Jacovich
>>>>>
>>>>>
>>>>> _______________________________________________
>>>> mesa-users at lists.mesastar.org
>>>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>>
>>>> _______________________________________________
>>> mesa-users at lists.mesastar.org
>>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>
>>> _______________________________________________
>> mesa-users at lists.mesastar.org
>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>
>> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190128/6d9384a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_cluster
Type: application/octet-stream
Size: 426 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190128/6d9384a6/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_star
Type: application/octet-stream
Size: 1364 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190128/6d9384a6/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_control
Type: application/octet-stream
Size: 5717 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190128/6d9384a6/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kipp_056800.png
Type: image/png
Size: 20528 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190128/6d9384a6/attachment.png>