[Mesa-users] Updating the binary history file
Dean Townsley
Dean.M.Townsley at ua.edu
Mon Mar 5 17:51:17 EST 2018
Hi Pablo,
Thanks for keeping in line and getting it in. Unfortunately I won't be
able to check it right away, but I appreciate knowing its there :)
Dean
On 03/05/2018 12:01 PM, Pablo Marchant wrote:
> 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
> <mailto: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 <mailto: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
>> <mailto: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-custom-stopping-condition
>> <http://mesa.sourceforge.net/run_star_extras.html#adding-a-custom-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/ecaf6f7d/attachment.html>
More information about the Mesa-users
mailing list