[Mesa-users] hot accretion and spiky luminosity

Thomas Steindl thomas.steindl at uibk.ac.at
Thu May 28 14:40:41 EDT 2020



> ok.  understood.  that case is beyond the scope of the method of 3.3 in MESA5 at least as far as I understand it - remember i’m a computer scientist, not an astrophysicist.  ;-)


First, I am sure you are underestimating yourself and second, I am sure I am not the first one to point that out! 
Given the fact, that the method of 3.3 corrects for energy, do you think it would be beneficial (or possible) to implement the extra heat already in this methodology?

> ouch!   yes, you are right to check with mesa-users for help with that sort of issue. 
> 
> As a compromise between what you want and what mesa can do, you might explore spreading the extra heat over larger portions of the envelope until you find something that runs ok.    concentrating the extra in a thin outer layer might lead to nasty problems such as lots of retries and backups and very lengthy runs!

Yes, that might be an option. Unfortunately, I am a concerned with loosing the physical properties that we obtain from concentrating it in a thin layer. But as the simulations run (even if only very slowly), we should be able to compare the models and asses the influence. 

> if you are interested, after i restore make_gradr_sticky_in_newton_iters i can point you to a private version of mesa before the next public release.  


I would love that. I found that this helps just a little bit with convergence issues. I also tested the calculations by looking for single zones with different mlt_mixing_types than its direct neighbours in the use_other_gradr_factor routine and found that such zones indeed change with every newton iteration. So I am interested to see if there is still a small improvement. I have to state that I started this project with mesa r-11701 and the problems persisted since then (yes it took me quite a while until I realised I had to ask for help :) ). Therefore, the make_gradr_sticky_in_newton_iters will definitely not magically solve the issues :(

Thomas


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


More information about the Mesa-users mailing list