[mesa-users] hydro_failed_to_converge

[Pablo Marchant]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131013/b443b774/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist
Type: application/octet-stream
Size: 458 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131013/b443b774/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist1
Type: application/octet-stream
Size: 9938 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131013/b443b774/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist2
Type: application/octet-stream
Size: 9938 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131013/b443b774/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_project
Type: application/octet-stream
Size: 567 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131013/b443b774/attachment-0003.obj>