[Mesa-users] hot accretion and spiky luminosity

Thu May 28 12:20:25 EDT 2020

Hi Bill,

I will try to shed some light on way we want to use the extra heat source. The methodolgy described in 3.3 of MESA5 assumes that mass is added with the same specific energy as the material at the surface of the model. However, during strong mass accretion episodes, which i.e. Fu Orionis stars undergo, a fair amount of the accretion energy may be deposited in the stellar interior instead of being radiated away (see i.e. https://ui.adsabs.harvard.edu/abs/2019MNRAS.484..146E/abstract <https://ui.adsabs.harvard.edu/abs/2019MNRAS.484..146E/abstract> and references therein for a discussion. See also equation 1 of https://ui.adsabs.harvard.edu/abs/2012ApJ...756..118B/abstract <https://ui.adsabs.harvard.edu/abs/2012ApJ...756..118B/abstract> ). This energy is given by

L_add = \alpha \epsilon  G M Mdot  / R

Where \alpha controls the 'hotness' of accretion that is how much of the accretion energy is actually put into star, \epsilon is dependent on the geometrical properties of the accretion and is expect to be ~1/2 for disc accretion, G is the gravitational constant, M the mass of the star, Mdot the accretion rate and R the radius of the star. 
This usually is modelled with an extra heat term and has been done with MESA before:
-kuffmeier 2018 & Jensen 2018https://ui.adsabs.harvard.edu/abs/2018MNRAS.475.2642K/abstract <https://ui.adsabs.harvard.edu/abs/2018MNRAS.475.2642K/abstract>  or https://ui.adsabs.harvard.edu/abs/2018MNRAS.474.1176J/abstract <https://ui.adsabs.harvard.edu/abs/2018MNRAS.474.1176J/abstract> using MESA version 8845 which is actually the source of inlist/run_star_extras I mentioned from the marketplace.
-konitomo  2017:  https://ui.adsabs.harvard.edu/abs/2017A%26A...599A..49K/abstract <https://ui.adsabs.harvard.edu/abs/2017A&A...599A..49K/abstract>  I have been in contact with Masanobu and he has been very helpful. My initial models are created in a very similar fashion than what he did. 

The main difference is that the extra heat is put into the very outer edge of the star, while in Konitomo 2017 the extra heat is mostly distributed in the entire star. What we are trying to do is very similar to what has been done before. Now, it does work with MESA, but the we need a lot of retries and backups which make the evolution very lengthy. I have run full evolutions but they take somewhere between 2 weeks and a month on my machine which is undesirable. I have long tried to figure out a way to help MESA with convergence, and then gave up and decided to ask for help :)

I hope this helps a bit why we are using the extra heat source.  As always, I cannot thank you enough for taking the time!

Thomas

PS: what happened to make_gradr_sticky_in_newton_iters. I used it to reproduce the results in konitomo 2017 but it has disappeared in the newest release and I didn’t find anything in the release notes.

> Am 28.05.2020 um 17:17 schrieb Bill Paxton <paxton at kitp.ucsb.edu>:
> 
> 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 <mailto: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/f88c936d/attachment.htm>