[mesa-users] Problems with Rochelobe overflow

Tue Jun 14 04:19:36 EDT 2016

My apologies for not sending a message to all. I just clicked on reply and
didn't pay attention to the recipients.
So, if I understand correctly, I just have to experiment a bit with the
amount of Newton-iterations I allow the solver to take until I reach a
point that the evolution continues properly?
With kind regards,
Hannah

2016-06-13 18:23 GMT+02:00 Pablo Marchant <pamarca at gmail.com>:

> Hannah, please keep mesa-users in the loop.
>
> That's what's controlling your timestep. If you check carefully, as long
> as the reason for the timestep limit is max_increase, timesteps will be
> increasing, until once you get newton_iters, it will decrease. This option
> is to reduce the timestep when the newton solver has do to many steps to
> get a solution. You can relax this by increasing the
> newton_iterations_limit option. Beware though, you likely have many
> iterations because the solver is having trouble finding a solution, likely
> increasing the timestep too much will result in convergence issues. But you
> can experiment with that and see how it works.
>
> On Mon, Jun 13, 2016 at 5:04 PM, Hannah Brinkman <brinkmanhe at gmail.com>
> wrote:
>
>> Dear Pablo,
>> the terminal output is already set to every step. It just says max
>> increase all the time at the end of the simulation, sometimes interupted by
>> newton_iter, but mostly max increase.
>> For the binary system I do not get neon-ignition, just shell-burning. And
>> as soon as I see neon-ignition in the Kippenhahn-diagram, the star is no
>> longer relevant for me since these stars won't evolve into electroncapture
>> supernovae. The problem is that from about model 7000, nothing seems to
>> happen anymore to the system and I need to know if there is a next phase of
>> Rochelobe overflow to do a proper prediction whether the star will become
>> an ECSN. This depends highly on the final mass of the core of the star, and
>> if I have rochelobe overflow in the final stages of the evolution, the
>> core  might not be able to become heavy enough to go supernova.
>> The helium-coremass at this point is for the 8.5Msun primary is 1.33Msun
>> which is also the total mass of this star. This rules out this star to
>> become an ECSN, unless it accretes mass from its companion at a later
>> stage. There is shell-burning, but no energy generation in the center of
>> the star.
>> Is there a way to get through this post-carbon burning phase in a
>> smoother way? Because I don't think simply running the code longer will
>> solve this problem.
>> With kind regards,
>> Hannah
>>
>> 2016-06-13 12:59 GMT+02:00 Pablo Marchant <pamarca at gmail.com>:
>>
>>> Hannah, you are likely miswing terminal output for every step. Set the
>>> control terminal_cnt to 1 and you will get the reason for the timestep
>>> control at every step.
>>>
>>> Max_increase means the timestep should be steadily increasing, so it
>>> cant be thr single thing controlling your timesteps.
>>>
>>> What is the size of your helium core when you run into issues? If the
>>> mass is not high enough you can get off-center neon ignition, which is
>>> simply computationally expensive to model. If this is what is happrning,
>>> further evolution should proceed rapidly and you might be able to simply
>>> ignore it. Do some Kippenhahn diagrams to see what the core is doing at
>>> those late phases.
>>> Am 13.06.2016 12:10 nachm. schrieb "Hannah Brinkman" <
>>> brinkmanhe at gmail.com>:
>>>
>>>> I checked the limitation on the timestep for the binary system, but it
>>>> gives me simply max increase, which has no counterpart in the control
>>>> files. This leaves me clueless on what to increase to get a bigger timestep
>>>> in the final phases of the evolution. Any ideas how to proceed?
>>>> The timesteps for the single star go down slowly from about a year to
>>>> 10^-5 years at the very end of the evolution. This seems indeed to be the
>>>> post-carbon burning state. It reaches this point in only 2000 timesteps and
>>>> uses the other 8000 to get barely any further in the evolution. The
>>>> limiting factor for the single star is dX_nuc_drop. But since these stars
>>>> don't have Roche-lobe overflow that changes the mass drastically, I think I
>>>> will be able to predict the final state of the star based on the core just
>>>> after carbon-burning.
>>>> With kind regards,
>>>> Hannah
>>>>
>>>> 2016-06-10 17:22 GMT+02:00 Hannah Brinkman <brinkmanhe at gmail.com>:
>>>>
>>>>> Thanks for giving me some advice! At the moment I have no acces to my
>>>>> data, so I will look at these suggestions on Monday.
>>>>> With kind regards,
>>>>> Hannah
>>>>>
>>>>> 2016-06-10 16:33 GMT+02:00 Robert Farmer <rjfarmer at asu.edu>:
>>>>>
>>>>>> What happens to the timestep if you run your primary star inlist as a
>>>>>> single star? Post carbon burning can be difficult without the added
>>>>>> complications of mass transfer.
>>>>>>
>>>>>> Also in your terminal output what's limiting the timestep? This will
>>>>>> give you a clue as to what to change to get bigger timestep. Your looking
>>>>>> for dt_limit in the output. Then search the binary and single star
>>>>>> control.defaults file to match that limit to a inlist parameter.
>>>>>>
>>>>>> Rob
>>>>>> Dear all,
>>>>>> for my masterthesis I am using MESA to evolve binary systems in
>>>>>> search for electron capture supernovae in binary systems. However, I am
>>>>>> experiencing some troubles with the Rochelobe overflow, especially later in
>>>>>> the evolution. This limits my ability to predict if a star will become a
>>>>>> supernova or not since this depends a lot on the final mass of the star. If
>>>>>> there is a phase of Rochelobe overflow at the end of the run and this
>>>>>> removes enough mass, the supernova can be prohibited.
>>>>>> The problem is that at the end of the simulation run, after
>>>>>> carbon-burning, the timesteps become very small, as in seconds, and it
>>>>>> seems that the code is a bit stuck. When checking the radius and radius of
>>>>>> the Rochelobe, this seems to be the same moment as a second phase of
>>>>>> Rochelobe overflow begins.
>>>>>> Is there a way to get the binary system through this second Rochelobe
>>>>>> overflow more smoothly?
>>>>>> I have attached the inlist-files I am using. I use MESA-version 8118.
>>>>>> With kind regards,
>>>>>> Hannah Brinkman
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>>>>> traffic
>>>>>> patterns at an interface-level. Reveals which users, apps, and
>>>>>> protocols are
>>>>>> consuming the most bandwidth. Provides multi-vendor support for
>>>>>> NetFlow,
>>>>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>>>>> planning reports.
>>>>>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>>>>>> _______________________________________________
>>>>>> mesa-users mailing list
>>>>>> mesa-users at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>>> traffic
>>>> patterns at an interface-level. Reveals which users, apps, and
>>>> protocols are
>>>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>>> planning reports.
>>>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>>>> _______________________________________________
>>>> mesa-users mailing list
>>>> mesa-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>
>>>>
>>
>
>
> --
> Pablo Marchant Campos
> M.Sc on Astrophysics, Universidad Católica de Chile
> PhD student, Argelander-Institut für Astronomie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20160614/d3036742/attachment.html>