[mesa-users] Problems with Rochelobe overflow

Mon Jun 13 12:23:31 EDT 2016

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/20160613/41bb4724/attachment.html>