[Mesa-users] hot accretion and spiky luminosity

Thu May 28 11:17:28 EDT 2020

Hi Thomas,

I can certainly believe that what you are trying to do something reasonable that is causing problems for mesa.  But I can’t understand yet is why this is so much different than the cases that do work in mesa that involve accretion leading to temperature increases and even ignition of nuclear flashes such as in the case of nova bursts.   How is it that nova bursts work, but your accretion doesn’t?  Also note that for the other accretion cases illustrated in the star/test_suite, there are no extra heat sources - instead we use the treatment described in detail in section 3.3 of MESA5.   And these cases of course generate local temperature maxima and those in turn drive a negative luminosity - none of which breaks the code.  

It may be that what you are trying to do is somehow very different physically from anything we’ve ever done in mesa (although the accretion rates you mention aren’t extreme).   And mesa certainly can’t do all possible interesting experiments!    But it would help to get a clear understanding of why this is different including why you need a special extra heat source.

-B

> On May 28, 2020, at 12:28 AM, Steindl, Thomas <Thomas.Steindl at uibk.ac.at> wrote:
> 
> Hi Bill!
> 
> I ran some tests, using different accretion rates at a constant level. I find that the accretion rate, and therefore the amount of extra heat, is not necessarily the breaking point. If we set the accretion rate to 1d-7 M_sun/yr the evolution run very well until 0.043 M_sun at which point the extra_L is about 1.36d-2 L_sun. What is as far as I can guess more important, is that at this moment the extra heat is enough to to suppress the luminosity that arises intrinsically. Meaning the luminosity drops from a high level at the surface to 0 somewehere below the injection area (before that it attained a non-zero level). Then tiny convective zones start to appear, from sizes of 1 to 10ish zones (see pgstar screenshot I attached). But the position and size of this tiny convective zones change very rapidly with iterations which I think leads to the convergence issues.
> There are some controls to deal with tiny convective zones and some are already activated (min_convective_gap = 1.0, or remove_mixing_glitches = .true., as is the default option), but I don't find an option that helps remove this issues.
> 
> For completeness, running with for example an accretion rate of 2d-7, this happens at extra_L = 1.56d-2 L_sun at 0.032 M_sun (this is actually the evolution where the screenshot is from). We also see that the amount of extra_heat put into the outer zones is rising rapidly at this point, but this is due to the fact that the injection area is dependent on the time step. Removing this dependency, I find basically the same results!
> 
> I hope this helps pinpoint the issue. Again, thank you for your help, I really appreciate it!
> 
> Thomas
> 
> 
> From: Mesa-users [mesa-users-bounces at lists.mesastar.org <mailto:mesa-users-bounces at lists.mesastar.org>] on behalf of Thomas Steindl [thomas.steindl at uibk.ac.at <mailto:thomas.steindl at uibk.ac.at>]
> Sent: Wednesday, May 27, 2020 6:11 PM
> To: Bill Paxton
> Cc: mesa-users at lists.mesastar.org <mailto:mesa-users at lists.mesastar.org>
> Subject: Re: [Mesa-users] hot accretion and spiky luminosity
> 
> Hi Bill,
> 
> Thank you for the quick response!
> Sure,  I will run some tests and see at which point the trouble starts. I will come back to you as soon as I have some results!
> 
> Thomas
> 
>> Am 27.05.2020 um 17:56 schrieb Bill Paxton <paxton at kitp.ucsb.edu <mailto:paxton at kitp.ucsb.edu>>:
>> 
>> you can help me on this by finding the smallest extra heat that works well.  then we can increment from there to see what breaks.  that approach to debugging works better for me than starting from something badly broken and trying to make sense of the rubble.
>> 
>> b
>> 
>> 
>>> On May 27, 2020, at 8:27 AM, Bill Paxton <paxton at kitp.ucsb.edu <mailto:paxton at kitp.ucsb.edu>> wrote:
>>> 
>>> retract that — i looked more closely at your run_star_extras routine.  since the extra_heat you are adding doesn’t depend on the cell variables such as T or rho, you don’t need to use the implicit form.
>>> 
>>> this one will take some time.  i’ll put it on my to-do list, but perhaps someone else will be able to help sooner.
>>> 
>>> good luck,
>>> b
>>> 
>>>> On May 27, 2020, at 7:52 AM, Bill Paxton <paxton at kitp.ucsb.edu <mailto:paxton at kitp.ucsb.edu>> wrote:
>>>> 
>>>> Hi Thomas,
>>>> 
>>>> 1st thing to try is to replace your use of other_energy by other_energy_implicit.  That allows the extra heat to be calculated on each newton iteration and provides the necessary partials of the heat to guide the solver.
>>>> 
>>>> -B
>>>> 
>>>> 
>>>>> On May 27, 2020, at 4:36 AM, Steindl, Thomas <Thomas.Steindl at uibk.ac.at <mailto:Thomas.Steindl at uibk.ac.at>> wrote:
>>>>> 
>>>>> Hello all,
>>>>> 
>>>>> I am trying to calculate models of accreting protostars with accretion rates up to 1d-4 M_sun/yr and hot accretion, where the energy is put into the outer layers of star only (typically outer 10% of the radius).  I have tested different methods to put in the extra heat but I decided to use the method which is available on the marketplace (http://cococubed.asu.edu/mesa_market/inlists.html <http://cococubed.asu.edu/mesa_market/inlists.html>, Michael Kuffmeier) for this thread. In essence, a lot of material is accreted onto the star which leads to extra heat in the surface area.
>>>>> However, I am having the problem that in the zones below the injection of the extra heat, the luminosity becomes very spiky and the solver is having trouble with convergence. This spikes appear rather random to me and change size and form with almost every timestep. I attach a work directory (latest MESA version) to this mail in order for you to reproduce the problem. This includes pgstar inlist that will show the luminosity profile. The calculations are rather lengthy, therefore i include a model after 400 steps, for you to see the problem immediately if you want. I do not include the star executable as this has ~50mb.
>>>>> In this case, the extra_heat is put in at a constant level, leading to a jump in extra heat. I have experimented with multiple other ways to put in the extra heat (e.g. in a tanh shape to not have any jumps) but the problem persists.
>>>>> 
>>>>> Do any of you have any idea concerning what causes this spikes and how I can help MESA with the convergence?
>>>>> As always, I am happy for any input. Thank you very much in advance!
>>>>> 
>>>>> Thomas
>>>>> 
>>>>> __________________________________________________________________
>>>>> Thomas Steindl, MSc
>>>>> University of Innsbruck | Institute for Astro- and Particle Physics
>>>>> Tel: +43 512507 52031
>>>>> Mail: thomas.steindl at uibk.ac.at <mailto:thomas.steindl at uibk.ac.at>
>>>>> <work_mailing.zip>_______________________________________________
>>>>> mesa-users at lists.mesastar.org <mailto:mesa-users at lists.mesastar.org>
>>>>> https://lists.mesastar.org/mailman/listinfo/mesa-users <https://lists.mesastar.org/mailman/listinfo/mesa-users>
>>> 
>> 
> 
> <Screenshot from 2020-05-28 08-54-20.png><Screenshot from 2020-05-28 08-54-20.png>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200528/b8c7ec90/attachment.htm>