[Mesa-users] Problem with r12778. Bug?
Bill Paxton
paxton at kitp.ucsb.edu
Tue May 12 11:22:44 EDT 2020
> On May 12, 2020, at 1:24 AM, Ian Foley <ifoley2008 at gmail.com> wrote:
>
> Hi Bill and Josiah,
>
> Working through your suggestions.
>
> Two runs with gold tolerances
>
> 1M2gold.txt - stopped after 2000 models. Has nearly 400 retries and 11 backups but still a long way from reaching the main sequence. My guess would be that I'll need 10 million models to reach a wd.
>
> 1M2goldmod.txt. Modified gold
>
> gold_tol_residual_norm1 = 1d-11
> gold_tol_max_residual1 = 1d-9
> gold_iter_for_resid_tol2 = 5
> gold_tol_residual_norm2 = 1d-8
> gold_tol_max_residual2 = 1d-6
> gold_iter_for_resid_tol3 = 10
> gold_tol_residual_norm3 = 1d99 ! default 1d-6
> gold_tol_max_residual3 = 1d99 ! default 1d-4
> gold_newton_iterations_limit = 11 ! default 14 ! for timestep control
>
> In this case, (if I've understood correctly), if beyond 10 iterations a max_correction will be applied to provide a solution. So time step is not impacted so the previous performance is retained. We hit the man sequence after about 300 models. Problem is that there is one bad lg_LH at model 299. Most of the time the correction applied does not have a significant impact on the energy error. Well within the default 0.02 which
> triggers the default warning message.
ok. gold_tolerances cause more iterations in an attempt to get a better residual. but as you can see the default settings allow the solver to give up on residuals after 10 iterations and just consider the size of corrections. so you must have a case where the corrections are tiny, but they cannot yield small residuals. can you think of why that might happen? consider finding x such that f(x) = 0 where f is making a nearly discontinuous jump from large negative to large positive. tiny changes in x around the root lead to large jumps in f(x). nonlinearity is nasty for a root solver that depends on nicely behaved functions with not-too-extreme jumps. sometimes the extreme nonlinearity is physical; but it can also be a numerical problem. that might turn out to be the issue here since it shows up when using rates that aren’t often included.
>
> Applying
> delta_lgL_H_limit = 0.01d0
> delta_lgL_H_hard_limit = 0.05d0
>
> makes no difference. Still get exactly the same value for lg_LH at the same model number. The large change in lg_LH does not generate
> retries.
? hmm. that is a problem. changes in lg_LH greater than the hard limit should force a retry. if that isn’t happening, please save a model just before an example. send that along with the modified inlists so i can reproduce the problem easily.
>
> My suspicion is that the error occurs when a max_correction is being applied to get an accepted solution. And usually the max_correction works fine so we get reasonable solutions without getting a time step adjustment and without getting too big an energy error.
>
> btw, I do have 2 runs with the o18_and_ne22.net <http://o18_and_ne22.net/> with a mesh coeff of 1.0 for 1M stars
> The first, using gold tolerances, took 12033 models to wd and finished with log_rel_run_E_err = -3.5875688657807161
> The second, without gold tolerances, took 11991 models to wd and finished with log_rel_run_E_err = -3.7343232181208545
> This made me question whether gold tolerances really are the way to go.
gold tolerances can be helpful in many cases, but they are certainly not going to be a miracle cure for all bugs! the experiment of running with them shows that this problem can’t be fixed by having the newton solver just try harder. that’s valuable information. next comes the hard work to find the source of the problem.
b
>
> I will continue to work on the other suggestions.
>
> Kind regards
> ian
>
>
>
>
> On Tue, 12 May 2020 at 14:20, Bill Paxton <paxton at kitp.ucsb.edu <mailto:paxton at kitp.ucsb.edu>> wrote:
>
>> On May 11, 2020, at 8:40 PM, Ian Foley via Mesa-users <mesa-users at lists.mesastar.org <mailto:mesa-users at lists.mesastar.org>> wrote:
>>
>> Ok, I will try to do that. Thanks
>>
>> Personally, I was examining the accumulation of energy energy errors and was puzzled by the occasional huge rel_E_err.
>
> You are right to be puzzled - in fact, you should be horrified! The system has definitely gone astray at step 274. The following are from the log you sent (thank you for including that - it’s a big help).
>
> step lg_Tcntr Teff lg_LH lg_Lnuc Mass H_rich H_cntr N_cntr Y_surf X_avg eta_cntr zones retry
> lg_dt_yr lg_Dcntr lg_R lg_L3a lg_Lneu lg_Mdot He_core He_cntr O_cntr Z_surf Y_avg gam_cntr iters bckup
> age_yr lg_Pcntr lg_L lg_gsurf lg_Psurf lg_Dsurf C_core C_cntr Ne_cntr Z_cntr Z_avg v_div_cs dt_limit
> __________________________________________________________________________________________________________________________________________________
>
> 273 7.149445 5660.570 -0.102621 -0.102620 0.999678 0.999678 0.588152 0.005009 0.280000 0.687990 -1.638059 421 2
> 7.544841 1.992413 -0.033735 -46.026721 -1.760965 -12.689535 0.000000 0.391282 0.009290 0.020000 0.291896 0.094468 6 0
> 1.6342E+09 17.232539 -0.102547 4.505219 4.819642 -6.735807 0.000000 0.000016 0.001942 2.057E-02 2.011E-02 0.000E+00 retry
> rel_E_err -1.1024069047620799D-10
> log_rel_run_E_err -2.6819105959472362
> rel_run_E_err -0.0020801248584473
>
> 274 7.149838 5661.517 0.549531 0.549531 0.999671 0.999671 0.585504 0.005009 0.280000 0.687719 -1.636798 421 2
> 7.544841 1.994223 -0.033378 -45.996348 -1.759985 -12.688180 0.000000 0.393930 0.009288 0.020000 0.292167 0.094680 6 0
> 1.6692E+09 17.233776 -0.101543 4.504503 4.819064 -6.736461 0.000000 0.000016 0.001942 2.057E-02 2.011E-02 0.000E+00 hold
> rel_E_err -3.8973049465573766
> log_rel_run_E_err 0.5905325552405367
> rel_run_E_err 3.8952250568823850
>
> rel_E_err of 10^-10 is fine, so step 273 is ok. but 274 is terrible. let’s change the inlist controls so that it will not allow 274 to be accepted with that large rel_E_err.
>
> one thing to do is turn use_gold_tolerances back on. (i noticed that you’ve turned it off in your inlist for some reason.) with gold_tolerances enabled, the newton solver will keep trying for more iterations to get a better solution with smaller residuals, and that might be enough to drive down the rel_E_err.
>
> also, you should try using the timestep limits for rel_E_err in order to force a retry when a step is accepted but gives a large rel_E_err. try something like the following:
>
> limit_for_abs_rel_E_err = 1d-7
> hard_limit_for_abs_rel_E_err = 1d-4
>
> also note that the lg_LH jumped in a single step from -0.1 to 0.5. you should try limiting the size of that change also. You have a timestep limit for lgL_He. Add one for lgL_H. And add hard limits too to force retries with smaller timesteps if get really large jumps.
>
> delta_lgL_H_limit = 0.01d0
> delta_lgL_H_hard_limit = 0.05d0
>
> Please try these changes and let me know what happens. You should either get a nice clean run keeping rel_E_err and log_rel_run_E_err small, or it will die with tiny timesteps. If that bad result happens, then it will be time to dig deeper to see where the problem is arising. It might be related to the larger nets you are using - especially if the run is ok with the smaller more commonly used ones. So you should certainly check if the problem goes away with a smaller net such as pp_and_cno_extras. I’m not saying you shouldn’t be able to use the larger nets; just that they are not used very much and there may be bugs lurking in them that no one has reported before now (e.g., rarely used reactions may be producing bad rates and/or partials of the rates with respect to T or Rho - either of those could make it impossible for the newton solver to get residuals down).
>
> Thanks for reporting these puzzles. Not all of them will get satisfactory solutions, but looking at them may reveal things that we can do to improve mesa. So I appreciate your feedback.
>
> Cheers,
> Bill
>
>
>
>
>
>
>
>
>> I was trying to track the cause thinking it was related to the solution of the equations in star_newton so I'm not sure if the problem occurs from the lg_LH value or from the equation solution. Normally, I only dump the terminal every 10 models, so could easily have missed seeing the funny lg_LH values.
>>
>> Kind regards
>> Ian
>>
>>
>>
>>
>> On Tue, 12 May 2020 at 13:20, Josiah Schwab <jwschwab at ucsc.edu <mailto:jwschwab at ucsc.edu>> wrote:
>> Hi Ian,
>>
>> Thanks. I can reproduce this. We'll look into it and get back to you.
>>
>> In the future, it would be helpful if you could take the time to reduce the problem further. It is easiest if you send a minimal work directory that we can compile and run and immediately see the problem. For example, save a model 5 or 10 steps before the problem, start the run from that, and only include the inlists needed for that model. I've already done this here, but keep that in mind.
>>
>> Josiah
>> _______________________________________________
>> mesa-users at lists.mesastar.org <mailto:mesa-users at lists.mesastar.org>
>> https://lists.mesastar.org/mailman/listinfo/mesa-users <https://lists.mesastar.org/mailman/listinfo/mesa-users>
>>
>
> <1M2goldmod_299.txt><1M2gold.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200512/e8d284cb/attachment.htm>
More information about the Mesa-users
mailing list