[Mesa-users] bad dq error

[Jeremy Sakstein]

Hi Pablo,

I was wondering if you would be able to tell me which controls I could
experiment with to try to cut down the rate of time step errors?

mesh_dela_coefficient does work but if I keep pushing it I may need to go
below values of 0.1 I found that increasing scale_max_correction can help
but I do not know the implications of changing this so I've been keeping it
constant. I also get errors of the form:

avg remaining difference, lambda    2.9420078558394049D-05
 9.9964082806195276D-01

                     do1_energy_eqn s% equ(i_dlnE_dt,k)         580
              NaN

                     do1_energy_eqn s% equ(i_dlnE_dt,k)         547
              NaN

which I do not understand.

Ideally, I would like the physics prescriptions to be as consistent as
possible and just vary the numerical controls.

Cheers,

Jeremy

On Fri, Jul 10, 2020 at 11:58 AM Jeremy Sakstein <sakstein at hawaii.edu>
wrote:

> Thanks Pablo,
>
> Yes, I am working with all the recommended values in the inlist. The
> mesh_delta_coeff method seems to be working and gives consistent results.
>
> Cheers,
>
> Jeremy
>
> On Fri, Jul 10, 2020 at 11:58 AM Pablo Marchant <pamarca at gmail.com> wrote:
>
>> If you see the inlists for the test case there are several
>> recommendations on modified values. The test case is designed to run in a
>> reasonable time, so it cuts corners with spatial and temporal resolution.
>> These are still tricky simulations though, so don't be surprised if some
>> cases refuse to work. In such instances slight variations to the initial
>> conditions might help you pass through a difficult phase, although that's a
>> non-ideal option.
>>
>> Cheers
>>
>> On Fri, Jul 10, 2020 at 4:36 PM Jeremy Sakstein <sakstein at hawaii.edu>
>> wrote:
>>
>>> Quick follow up question,
>>>
>>> Sometimes with the PPISN test_suite case I find that the code terminates
>>> due to a min_timestep_limit (this is with plain gcrav off). My solution to
>>> this has been to change mesh_delta_coeff and that usually fixes the
>>> problem. Do you have any other recommendations to try?
>>>
>>> Cheers,
>>>
>>> Jeremy
>>>
>>> On Fri, Jul 10, 2020 at 10:34 AM Jeremy Sakstein <sakstein at hawaii.edu>
>>> wrote:
>>>
>>>> Great, thank you so much!
>>>>
>>>> On Fri, Jul 10, 2020 at 10:32 AM Josiah Schwab <jwschwab at ucsc.edu>
>>>> wrote:
>>>>
>>>>> Thanks Josiah, I am actually setting standard_cgrav =
>>>>>> 1.03*standard_cgrav in extras_controls since other_cgrav seems to cause
>>>>>> problems later on.
>>>>>>
>>>>>
>>>>> Ok, then you can safely ignore my speculation.  Glad the tweaked Tc
>>>>> worked.  The memory of the initial Tc should be erased by the time you get
>>>>> to the MS.  The value of pre_ms_T_c isn't particularly physically
>>>>> meaningful, so there shouldn't be any issue with bumping it up/down a bit.
>>>>>
>>>>> Josiah
>>>>>
>>>>
>>
>> --
>> 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/20200712/be08b125/attachment.htm>