[Mesa-users] Problem with r12778. Bug?

Tue May 12 00:20:06 EDT 2020

> On May 11, 2020, at 8:40 PM, Ian Foley via Mesa-users <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
> https://lists.mesastar.org/mailman/listinfo/mesa-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200511/0bae311f/attachment.htm>