GYRE2.1: Error with n_iter_max

[ehsan]

Hi Rich,

Sorry to submit an issue just a day after the release of the new version. Thanks for the hard work and the new features.
With the attached model and with gyre_nad, I get the following error with the new GYRE.
This has been with me since v.2.0 as well.

Code: Select all

 ASSERT 'n_iter <= this%np%n_iter_max' failed at line 467 <gyre_bvp_nad:mode>:
 Too many iterations

I also have a documentation request.
Would you please provide some example and explanation about what to put in tag and tag_list variables, and how they can impact the result/output.
Also, please explain the meaning of "use_banded".
To me, they are very vague.

Best regards.
Ehsan.

[rhtownsend]

Hi Rich,

Sorry to submit an issue just a day after the release of the new version. Thanks for the hard work and the new features.
With the attached model and with gyre_nad, I get the following error with the new GYRE.
This has been with me since v.2.0 as well.

Code: Select all

 ASSERT 'n_iter <= this%np%n_iter_max' failed at line 467 <gyre_bvp_nad:mode>:
 Too many iterations

That issue is addressedin the FAQs:

https://bitbucket.org/rhdtownsend/gyre/ ... tions-mean

But you already seem to know this, as you've set n_iter_max to a large value in your namelist. What this looks like is a general failure to converge of the root finder. This is a continued problem with gyre_nad when considering modes with high radial orders; I haven't had much time recently to work on it, and so we're no closer right now to fixing it. For the moment, you should try to avoid high-n modes when doing non-adiabatic calculations.

One quick question: what version of MESA are you using to generate your models?

I also have a documentation request.
Would you please provide some example and explanation about what to put in tag and tag_list variables, and how they can impact the result/output.
Also, please explain the meaning of "use_banded".
To me, they are very vague.

Best regards.
Ehsan.

I'll write the documentation for these features when I can, but right now I have other stuff on my plate which takes priority - sorry!

cheers,

Rich

[ehsan]

Thanks Rich for your response.
I use MESA v.4996 to produce the profiles.

Furthermore, to avoid the failure associated with n_iter_max, a bold way around it is to set a maximum mode_order variable in the namelist by the user, so that if a mode has n_g > n_max_order, then the calculation is skipped to the next mode. The reason is that I scan a series of models along the MS for unstable modes in adimentional frequency unit, and I do not want to change the frequency scanning range per model; I rather to have it fixed for the whole models in the row.

Now, n_max_order seems like a feature request, and may not belong to this thread.

Cheers.
Ehsan.

[ehsan]

Hi again.
Back to the above discussion on too many iterations required to converge, I get the same error but with a very low-order pure g-mode in a 12Msun main sequence model.

Code: Select all

       1      -9       1      10    0.9786042776813845E+00    0.6542992461053705E-06    0.4071925472522822E-08     6
       1      -8       1       9    0.1079154360408972E+01    0.3390830239641928E-06    0.4548033002720653E-08     9
       1      -7       1       8    0.1200649203217934E+01    0.4385907704702197E-06    0.2988121722430590E-08     6
       1      -6       1       7    0.1348117665032792E+01    0.3517595812992273E-06    0.6287334839427036E-08     6
       1      -5       1       6    0.1566236488094559E+01    0.1740597863959046E-06    0.4871675280978983E-07     9
       1      -4       1       5    0.1741041185032492E+01    0.1130562757779251E-06    0.2384272652733479E-06    12
       1      -3       1       4    0.2106019909400948E+01    0.1330686078347853E-06    0.1533863929562038E-06    18
       1      -3       0       3    0.2916055005944033E+01   -0.5285636581153358E-06    0.1366858085974413E-06    27
       1      -2       0       2    0.3506090123405456E+01   -0.2833971774075149E-03    0.5542595742452825E-10    15
 ASSERT 'n_iter <= this%np%n_iter_max' failed at line 467 <gyre_bvp_nad:mode>:
 Too many iterations

Playing around with many possibilities did not help at all.
The purpose of this post is to provide a feedback on the issue.
The relevant files are appended.

Best.
Ehsan.

[ehsan]

And some minute after, with just improving from MAGNUS_GL2 to MAGNUS_GL4, the crash is solved with a cost of the following warning message!
I was always thinking the other way around, that GL2 shall be safer!
With GL6, it crashes again.

Code: Select all

 INFO at line 1091 <gyre_mode:E_norm>:
 Surface amplitude is zero; not normalizing inertia

I am then really curious to know if the mode frequencies are robust.
What I find as a comparison between the adiabatic and non-adiabatic mode frequencies and periods is worrisome. Please take a look at the attached plot.

comp-ad-nad.pdf

Figure

(146.08 KiB) Downloaded 343 times

Cheers.
Ehsan.

[rhtownsend]

And some minute after, with just improving from MAGNUS_GL2 to MAGNUS_GL4, the crash is solved with a cost of the following warning message!
I was always thinking the other way around, that GL2 shall be safer!
With GL6, it crashes again.

Code: Select all

 INFO at line 1091 <gyre_mode:E_norm>:
 Surface amplitude is zero; not normalizing inertia

I am then really curious to know if the mode frequencies are robust.
What I find as a comparison between the adiabatic and non-adiabatic mode frequencies and periods is worrisome. Please take a look at the attached plot.

comp-ad-nad.pdf

Cheers.
Ehsan.

Hi Ehsan --

Thanks for the figure -- it does indeed seem that there's something wrong with the non-adiabatic part of the code. Could you share the specific inlists and models that you used in making the plot?

To give you some insight into how I plan on tackling this: I'm going to modify the finite-difference solvers in the code to implement Sugimoto's fix for the non-adiabatic numerical instability. This will then give us an independent (from the Magnus solvers) way of doing the non-ad calculations, and thus help us determine what's going wrong.

cheers,

Rich

[ehsan]

Thanks Rich for responding.
I think all the models and input are bundled in the model.zip file in the first post.
Let me know if that file is corrupt.

Best.
Ehsan.