[Mesa-users] Updating the binary history file

[Pablo Marchant]

Hi Dean,

this is long overdue, but I just submitted a change that fixes this issue.
Now the iteration loop works such that once the implicit scheme says the
next iteration should have a mass transfer rate larger than the maximum,
the following iteration is done using the maximum. After the iteration
using the maximum value, the resulting model is only accepted if the
implicit scheme determines the next iteration would have a mass transfer
rate larger than the maximum.

Version number is 10353 in case you want to check.

Cheers

On Mon, Nov 27, 2017 at 6:38 PM, Pablo Marchant <pamarca at gmail.com> wrote:

> Aaaaaah, think I'm getting it now. After having one iteration where
> max_implicit_abs_mdot is used, we should check if the solver returns a
> next_mdot that is below max_implicit_abs_mdot. In that case there exists a
> solution that is below the maximum, and we should use that. That's
> something that would be straightforward to implement, will do in the
> following days.
>
> Cheers
>
> On Mon, Nov 27, 2017 at 4:46 PM, Dean Townsley <Dean.M.Townsley at ua.edu>
> wrote:
>
>> Hi Pablo,
>>
>> Thanks for the explanation.
>>
>> I figured I would mention what I tried in case it is useful...
>>
>> I tried just continuing the step loop by changing the check to be like
>> this:
>>
>>          if (-new_mdot > b% max_implicit_abs_mdot*Msun/secyer) then
>>             new_mdot = - b% max_implicit_abs_mdot*Msun/secyer
>>             ! check_implicit_rlo = keep_going
>>             if (b% report_rlo_solver_progress) then
>>                rlo_result = 'OK (max mdot)'
>>                call report_rlo_iter
>>             end if
>>             ! return
>>          end if
>>
>> i.e. just let it fall through so that further down check_implicit_rlo is
>> set to "redo" if the "new_mdot" is sufficiently different from the "old"
>> (the previous guess).  This behaves similar to your "one more step loop
>> iteration" suggestion.  Assuming that when the star is evolved at the mdot
>> limit it still implies an mdot over the limit, the next iterations' mdot
>> (the next guess) will also be the limit and the step loop will exit, having
>> evolved the star at the limiting mdot value.  That's what it seemed to do
>> for me, though there may be some edge cases in some of the other if
>> statements that I didn't check through.  (also I didn't try it in the
>> current version of mesa)
>>
>> I see now that this is not technically "converged", as I used that term,
>> since one has only confirmed that with the stellar properties obtained with
>> mdot at the limit the predicted mdot is over the limit.  However, unlike
>> just making a single extra iteration in the step loop, as you seem to
>> suggest, I think the above method will converge to the correct mdot in the
>> case where the guess was just over the limit but the correct mdot is still
>> below the limit.
>>
>>
>> Anyway, thanks again for the help!
>>
>> Dean
>>
>>
>>
>> On 11/27/2017 12:47 PM, Pablo Marchant wrote:
>>
>> Hi Dean,
>>
>> I realize there are a few inconsistencies in here, will try to get to
>> them asap (falling behind on other threads here in mesa-users as well).
>> Guess the issue with max_implicit_abs_mdot can be sorted out by having one
>> iteration in the solver actually done with that maximum value. This is
>> actually the behavior I intended, though my implementation cut things short
>> one iteration earlier than I wanted.
>>
>> What I meant with using this as a stopping condition in my older post,
>> was that when mass transfer becomes unstable the solver will generally
>> become incapable of finding a solution at all; each iteration will keep
>> increasing the mass transfer rate, find that it's even further away from a
>> solution, and eventually fail because the stellar model can't converge with
>> a very large mdot. Generally, if left to itself, this will cause a
>> simulation to hit a wall, constantly reducing the timestep until reaching
>> the min_timestep_limit condition. This results in a very large amount of
>> wasted computation, and so far this is the only "solution" I've devised.
>>
>> I just quickly modified binary_mdot to actually perform the extra
>> iteration with the maximum value of max_implicit_abs_mdot. Have not tested
>> it yet, just verified it compiles! but in the meantime, you can check it
>> and tell me if it works, I'll get to it anyhow in a couple of days.
>>
>> Regarding extras_binary_check_model being called after each iteration, I
>> think I will switch that such that it is called only after the final
>> iteration of the implicit mdot calculations. The idea of binary is to
>> behave consistently with star. I think its still useful to have a hook that
>> is called after every iteration of the solver, so will implement that as
>> well.
>>
>> Cheers, and thanks for your feedback!
>>
>> On Mon, Nov 27, 2017 at 11:42 AM, Josiah Schwab via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>>
>>> Hi Dean & Odette,
>>>
>>> > Pablo actually alludes to this issue in his message (linked above), as
>>> > a feature. But I would think that the issue he mentions (not being
>>> > able to converge the step) should be addressed with
>>> > max_tries_to_achieve, not by making max_implicit_abs_mdot immediately
>>> > truncate the step-loop with an unconverged mdot. The latter can lead
>>> > to situations where the converged mdot is not actually above the
>>> > limit, but a somewhat high guess truncates the search for the correct
>>> > value. (Odette has seen this behavior.)
>>>
>>> Your analysis makes sense to me, but I'll let Pablo be the one to decide
>>> how to best address this.
>>>
>>> > I would also note that I believe a similar issue is created if one
>>> > tries to use extras_binary_check_model to terminate the simulation
>>> > instead of extras_binary_finish_step, per the standard example
>>> > (http://mesa.sourceforge.net/run_star_extras.html#adding-a-c
>>> ustom-stopping-condition). check_model
>>> > is called for each step-loop during the implicit search for the
>>> > end-of-step mdot. So if one sets terminate in
>>> > extras_binary_check_model, the step-loop is truncated and things are
>>> > left in a somewhat unexpected state, just like above. In contrast, if
>>> > mdot is checked in extras_binary_finish_step, only converged values of
>>> > mdot are seen, and things behave more as I would have expected.
>>>
>>> Yeah, this is a case where binary requires more care than star.
>>>
>>> For star, there's little practical difference between extras_check_model
>>> and extras_finish_step because almost nothing happens in between.
>>>
>>> But for binary there's more going on, so as you say, the correct place
>>> to do the check is in extras_binary_finish_step.
>>>
>>> I definitely see how the existing documentation can lead one down a bad
>>> path when using binary.  I'll take a whack at improving this soon.
>>>
>>> Thanks,
>>> Josiah
>>>
>>
>>
>>
>> --
>> Pablo Marchant Campos
>> M.Sc on Astrophysics, Universidad Católica de Chile
>> PhD on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn
>>
>>
>>
>
>
> --
> Pablo Marchant Campos
> M.Sc on Astrophysics, Universidad Católica de Chile
> PhD on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn
>



-- 
Pablo Marchant Campos
M.Sc on Astrophysics, Universidad Católica de Chile
PhD on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180305/880fa110/attachment.html>