[Mesa-users] Questions about the debugging controls
Rob Farmer
robert.j.farmer37 at gmail.com
Tue Aug 17 18:33:52 UTC 2021
> I want to use report_hydro_solver_progress correct?
Yes
> I'm using 12778
Always useful information to provide as options can change names over time
Rob
On Tue, 17 Aug 2021 at 19:06, Jeremy Sakstein <sakstein at hawaii.edu> wrote:
> Thanks Rob,
>
> I will do this and send you the output.
>
> Just to check: I want to use report_hydro_solver_progress correct? I
> couldn't find a control called report_solver_progress in the controls (I'm
> using 12778).
>
> Cheers,
>
> Jeremy
>
> On Tue, Aug 17, 2021 at 4:53 AM Rob Farmer <robert.j.farmer37 at gmail.com>
> wrote:
>
>> grep -rinI 'log eps nuc ratio' star/p*/*
>> star/private/timestep.f90:1703: if (s% report_all_dt_limits)
>> write(*,4) 'log eps nuc ratio', &
>>
>> That leads to the function check_dlog_eps_nuc_change, note there are some
>> divide by eps_nuc's in there. So having 0's floating around (when you set
>> eps_nuc_factor to 0) is not going to help. I would suggest just using s%
>> dxdt_nuc_factor = 0d0 which turns off composition change from burning but
>> keeps eps_nuc set. That way your star won't just collapse as it runs out of
>> nuclear energy.
>>
>> Try setting
>> report_solver_progress = .true.
>>
>> and send the output for a step that seems to cause problems.
>>
>> Rob
>>
>>
>>
>> On Mon, 16 Aug 2021 at 20:31, Jeremy Sakstein <sakstein at hawaii.edu>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I've been having some convergence issues so I used the debugging
>>> controls:
>>>
>>> report_why_dt_limits
>>> report_all_dt_limits
>>> report_hydro_dt_info
>>>
>>> To try to figure out what is causing them. These helped a lot and I have
>>> been able to push the model much further but I am still unable to get full
>>> convergence so I wanted to ask a couple of questions.
>>>
>>> Currently, when I turn on report_why_dt_limits it just tells me
>>>
>>> "timestep_hold > model_number, so no timestep increase"
>>>
>>> If I also turn on report_all_dt_limits it tells me "log eps nuc ratio"
>>> followed by some ratios so I assume that eps_nuc is what is limiting the
>>> timestep? Is this the correct interpretation of this information?
>>>
>>> When I set
>>>
>>> delta_log_eps_nuc_limit = -1
>>> delta_log_eps_nuc_hard_limit = -1
>>>
>>> I still get this message, which confused me a bit because surely this
>>> means that eps_nuc should no longer limit the timestep?
>>>
>>> As an extreme test, I updated extras_start_step to set
>>>
>>> s% dxdt_nuc_factor = 0d0
>>>
>>> s% eps_nuc_factor = 0d0
>>>
>>> which I think should effectively turn off nuclear burning. Indeed, the
>>> abundances don't seem to change but I still get the same eps_nuc warning
>>> from report_all_dt_limits.
>>>
>>> Is someone able to tell me whether these changes are doing what I
>>> expected given my output?
>>>
>>> It would be great if someone could suggest either further ways I can
>>> determine what is limiting the timestep, or how to stop eps_nuc limiting
>>> the timestep if this is really what is happening.
>>>
>>> Cheers,
>>>
>>> Jeremy
>>>
>>>
>>>
>>>
>>> --
>>> Jeremy Sakstein (He/Him/His)
>>> Assistant Professor of Theoretical Physics
>>> Department of Physics & Astronomy
>>> University of Hawaiʻi at Mānoa
>>> Watanabe Hall
>>> 2505 Correa Road
>>> Honolulu, HI, 96822, USA
>>> http://www.jeremysakstein.com
>>> _______________________________________________
>>> mesa-users at lists.mesastar.org
>>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>
>>>
>
> --
> Jeremy Sakstein (He/Him/His)
> Assistant Professor of Theoretical Physics
> Department of Physics & Astronomy
> University of Hawaiʻi at Mānoa
> Watanabe Hall
> 2505 Correa Road
> Honolulu, HI, 96822, USA
> http://www.jeremysakstein.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20210817/69f00f30/attachment.htm>
More information about the Mesa-users
mailing list