[mesa-users] hydro_failed_to_converge

[Pablo Marchant]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131013/624fce7d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_project
Type: application/octet-stream
Size: 565 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131013/624fce7d/attachment.obj>