n_iter_max crash

[ehsan]

Hi.
Due to some difficulties installing v.3.3, I step back to 3.2.2. I'm playing around with gyre_nad and a SPB model. Surprisingly, when the mode scanning reaches the p-mode range, the number of needed iterations blows up, and it crashes.
Here is an example. The input mesa model cannot be attached and I put it in the following address:
ftp://ftp.ster.kuleuven.be/dist/ehsan/spb.zip

Code: Select all

Root Solving
       l    n_pg     n_p     n_g                 Re(omega)                 Im(omega)                       chi  n_iter        n
       1     -21       0      21    0.1053044611901553E+00    0.3074808127671726E-02    0.2425731187790549E-39      90     2669
       1     -21       0      21    0.1102981212015390E+00    0.3068939476566495E-02    0.1110369286220513E-39      91     2669
       1     -20       0      20    0.1156289399982193E+00    0.3068834821607738E-02    0.5979210286883418E-40      93     2669
       1     -19       0      19    0.1207085971977698E+00    0.3051274249616014E-03    0.1124511806940885E-16      23     2669
       1     -18       0      18    0.1274016422354686E+00    0.2262683806231158E-03    0.2461605823559336E-16      20     2669
       1     -17       0      17    0.1348772805658228E+00    0.1659149927411520E-03    0.2481672874065077E-16      21     2669
       1     -16       0      16    0.1431852099353113E+00    0.1222861255485319E-03    0.8127540912974545E-15      16     2669
       1     -15       0      15    0.1523742226649451E+00    0.8548762989315771E-04    0.2647806444223950E-14      19     2669
       1     -14       0      14    0.1626778230088158E+00    0.5174166256545726E-04    0.7705012521809986E-14      13     2669
       1     -13       0      13    0.1745804727794208E+00    0.2665488024406155E-04    0.7343876543244164E-13      11     2669
       1     -12       0      12    0.1886509936642592E+00    0.1269116233021738E-04    0.5650999636374490E-13       9     2669
       1     -11       0      11    0.2052995485865396E+00    0.6097746866664252E-05    0.4898864858315047E-12       8     2669
       1     -10       0      10    0.2248940978897628E+00    0.2836798099861107E-05    0.1255217602981003E-11      10     2669
       1      -9       0       9    0.2485997882155957E+00    0.1112493975142555E-05    0.7139747415607887E-11       7     2669
       1      -8       0       8    0.2789477075319455E+00    0.3441928071693050E-06    0.2054634125325697E-10       8     2669
       1      -7       0       7    0.3195100435954504E+00    0.7313303102517932E-07    0.5230953725931713E-09      12     2669
       1      -6       0       6    0.3754829415157918E+00   -0.4394361049436026E-08    0.1639549153611175E-08       9     2669
       1      -5       0       5    0.4550341007493130E+00   -0.5134970897118441E-07    0.2424063809766565E-08       8     2669
       1      -4       0       4    0.5748377010511790E+00   -0.9021178961558204E-07    0.6656448162282388E-09      16     2669
       1      -1       1       2    0.7714350369244387E+00   -0.9832462838110110E-07    0.6324953192528974E-09      13     2669
       1      -1       0       1    0.1161216896695029E+01   -0.3380432661454510E-07    0.2486943312426605E-07      29     2669
       1       2       1       0    0.3581021616935468E+01    0.5769042670056635E-06    0.7600412021620271E-10      11     2669
       1       2       1       0    0.4206751302408210E+01    0.1540192098200663E+00    0.0000000000000000E+00    5188     2669
 ASSERT 'n_iter <= this%np%n_iter_max' failed at line 473 <gyre_nad_bvp:mode_old_>:
 Too many iterations

Please consider the number of iterations for the last few models being found!

I would like to know the reason, and also help solving it out.

Actually, the restriction on n_iter_max is too strict. If the iteration count exceed this limit, the code exits, and the whole calculation is lost. This is a pity, specially when computing a grid of models. Then, once has to change inlist, and repeat for the problematic cases, which makes the inlist setup inhomogenous.
Perhaps, one workaround is to skip those modes that exceed n_iter_max, and proceed with the rest. Indeed, this is an awful suggestion, and I am aware, but something to discuss.

Can you please try to reproduce my crash?

Best regards
Ehsan.

[rhtownsend]

Hi Ehsan --

I notice you're using the MAGNUS_GL4 solver. I haven't yet found a way to get this working well for non-adiabatic calculations. Could you try switching to MAGNUS_GL2, and repeat the calculation?

cheers,

Rich

[ehsan]

Thanks Rich for your pointer.
Indeed, MAGNUS_GL2 solved it.
Yet, I'm curious to know the best options for the following inlist variables when doing non-adiabatic computations, and if they really matter:

Code: Select all

  deriv_type  = 'MONO' 
  regularize = .false. 
  ivp_solver_type = 'MAGNUS_GL2' 
  use_banded = .false. 
  outer_bound_type = 'DZIEM' 
  variables_type = 'DZIEM' 

What would you do, if you were to set up an inlist for gyre_nad that would give stable frequencies?

Cheers
Ehsan.

[rhtownsend]

Thanks Rich for your pointer.
Indeed, MAGNUS_GL2 solved it.
Yet, I'm curious to know the best options for the following inlist variables when doing non-adiabatic computations, and if they really matter:

Here's my take:

Code: Select all

   deriv_type  = 'MONO' 

Mainly a matter of taste. I like MONO because it doesn't introduce any additional maxima or minima during interpolation. But to predict how it will differ from, e.g., NATURAL, is difficult -- best to actually do some experiments. Note that since MONO is the default, you can leave out deriv_type altogether.

Code: Select all

  regularize = .false. 

The preferred choice is .false., since .true. will actually modify the stellar model. But sometimes useful to use .true. if the model is not very well converged.

Code: Select all

  ivp_solver_type = 'MAGNUS_GL2' 

Best choice for non-adiabatic calculations. For adiabatic calculations MAGNUS_GL4 is usually more accurate.

Code: Select all

  use_banded = .false. 

Best choice; setting it to .true. is only really for testing (and will result in a big slowdown).

Code: Select all

  outer_bound_type = 'DZIEM' 
  variables_type = 'DZIEM' 

Both reasonable choices. These settings are unimportant if the stellar model is in exact hydrostatic equilibrium and mass conservation. However, differences between the DZIEM and JCD settings can arise if the stellar model isn't quite converged. Then, you may have to do some comparisons to figure out which is correct.