[mesa-users] hydro_failed_to_converge
Pablo Marchant
pamarca at gmail.com
Fri Oct 18 09:40:37 EDT 2013
Jaime, could you provide me with the inlists for this? Regarding the plots,
I can't really vouch for 10^-6 being too high or low. These binaries with
smaller masses and magnetic braking are not quite what I'm used to, so I
need to check some things.
Cheers!
On Fri, Oct 18, 2013 at 1:10 AM, Jaime Villaseñor <
jaime.villasenor at postgrado.uv.cl> wrote:
> Pablo, when running the test ('binary_donor_only_implicit_mdot') with
> everything as default, and plotting orbital period vs mass transfer rate, I
> get the exact same result as in Fig. 7 of rlo_implicit documentation
> (attached file PvsMLR1), so it seems like problem solved. But when I do it
> with different masses and period (as in the inlist I sent you before), I
> get a peak in the mass transfer rate around 10^-6 (PvsMLR2), which is much
> higher than the characteristic rates due to magnetic braking.
>
> Do you think this is normal? Or definitely something is not working as it
> should? I hope you can give me some thought about it.
>
> Best, Jaime
>
>
> 2013/10/13 Jaime Villaseñor <jaime.villasenor at postgrado.uv.cl>
>
>> Bill, ok I took note ;)
>>
>> Pablo, thanks a lot for all your useful comments. I used the roche_lobe
>> scheme in the implicit_mdot test and everything seems to be working fine,
>> no error message and the plot looks nice. I'll do some other plots to check
>> if everything is alright.
>>
>> Thank you one more time!
>> Best, Jaime
>>
>>
>>
>> 2013/10/13 Pablo Marchant <pamarca at gmail.com>
>>
>>> Going to your plots.
>>>
>>> The case with the explicit scheme is due to using to large timesteps (as
>>> defined by varcontrol_target). The scheme is very sensitive to changes in
>>> radius (exponential dependence on (r-rl)/H_P), so things will go bad if you
>>> use too large timesteps, mdot will experience huge increases causing that
>>> sawtooth behaviour. Try out with the attached inlists and it will work much
>>> better, I only chose a smaller varcontrol_target (and I think it would be
>>> wise to change it also in the test_suite examples).
>>>
>>> For the case of the implicit scheme, as I said before, there's a bug.
>>> Don't assume that things not working = you're doing something wrong,
>>> there's always a good chance that you catched a bug (as in this case).
>>>
>>> Cheers!
>>>
>>>
>>> On Sun, Oct 13, 2013 at 10:00 PM, Pablo Marchant <pamarca at gmail.com>wrote:
>>>
>>>> Jaime, there's effectively a problem here. The mass transfer rate gets
>>>> stuck in a value when magnetic braking stops working, instead of properly
>>>> detaching. In order to "fix" it, you can switch to the roche_lobe scheme
>>>> for mass transfer instead of the default ritter one. Another option would
>>>> be to just try and see if the explicit scheme works for you. The implicit
>>>> scheme adds overhead and in plenty of cases doesn't make much of a
>>>> difference.
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Sun, Oct 13, 2013 at 9:55 PM, Jaime Villaseñor <
>>>> jaime.villasenor at postgrado.uv.cl> wrote:
>>>>
>>>>> Hi Bill, thanks for your comments.
>>>>> I think that is the thing, and is what Pablo was just saying too, the
>>>>> test went too far in the evolution. I haven't tried removing the
>>>>> max_number_backups line yet, because what worries me most is how the data
>>>>> is looking. I'm sharing with you a plot of the donor mass vs orbital period
>>>>> that I made with the old rlo test (from version 4909) and what I'm getting
>>>>> with the binary_donor_only_implicit_mdot and the binary_donor_only
>>>>> tests.
>>>>> What do you think is happening? Should I adjust something related to
>>>>> the angular momentum loss? The third graphic is a completely impossible
>>>>> scenario, so clearly I'm doing something wrong here.
>>>>>
>>>>> Best, Jaime
>>>>>
>>>>>
>>>>> 2013/10/13 Bill Paxton <paxton at kitp.ucsb.edu>
>>>>>
>>>>>> Hi Jamie,
>>>>>>
>>>>>> On Oct 13, 2013, at 8:40 AM, Jaime Villaseñor wrote:
>>>>>>
>>>>>> * num_backups 11
>>>>>> max_number_backups 10
>>>>>>
>>>>>> stopping because of convergence problems num_backups >
>>>>>> max_number_backups
>>>>>> *
>>>>>>
>>>>>>
>>>>>> Starting from a test case inlist is a good idea.
>>>>>> But the tests include checks for number or retries and number of
>>>>>> backups that you may not want.
>>>>>>
>>>>>> Here are the lines from the inlist
>>>>>>
>>>>>> ! check for retries and backups as part of test_suite
>>>>>> ! you can/should delete this for use outside of test_suite
>>>>>> max_number_backups = 10
>>>>>> max_number_retries = 80
>>>>>>
>>>>>>
>>>>>> When the test case is running properly, it reaches the desired
>>>>>> stopping point without many backups, so something has gone very bad in the
>>>>>> test if it reaches 10 backups. Rather than let it keeping, we make the
>>>>>> test terminate at that point.
>>>>>>
>>>>>> But if you are going to do a longer run, it isn't unreasonable that
>>>>>> it could require more backups or retries. Your run is going much farther
>>>>>> than the test case. Perhaps it isn't crazy that it has done that many
>>>>>> backups. What happens if you remove the max_number_backups line from your
>>>>>> inlist?
>>>>>>
>>>>>> -B
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jaime Villaseñor
>>>>> Master's student in Astrophysics
>>>>> Universidad de Valparaíso
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pablo Marchant Campos
>>>> M.Sc on Astrophysics, Universidad Católica de Chile
>>>> PhD student, Argelander-Institut für Astronomie
>>>>
>>>
>>>
>>>
>>> --
>>> Pablo Marchant Campos
>>> M.Sc on Astrophysics, Universidad Católica de Chile
>>> PhD student, Argelander-Institut für Astronomie
>>>
>>
>>
>>
>> --
>> Jaime Villaseñor
>> Master's student in Astrophysics
>> Universidad de Valparaíso
>>
>
>
>
> --
> Jaime Villaseñor
> Master's student in Astrophysics
> Universidad de Valparaíso
>
--
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/20131018/a8e63bb3/attachment.html>
More information about the Mesa-users
mailing list