Different adiabatic radial frequencies with JCD or DZIEM var

[warrick]

Hi, me again...

I think I've relocated the previous issue I found when using variables_type = JCD. I've attached an inlist and model file for a Sun-like model produced by MESA (release 5527). I've also attached a file that has the output frequencies for a calculation with the default Dziembowski formulation (column DZIEM), frequencies with JCD's formulation (column JCD), and the differences, all in uHz (microhertz). Here is a snippet for about half of the l=0 and l=1 modes:

Code: Select all

n  l JCD                     DZIEM                  diff
0  3 0.5880991957344057E+03  0.5517936087489700E+03  36.3056        
0  4 0.7385115682894975E+03  0.7027710926357122E+03  35.7405        
0  5 0.8873526516617749E+03  0.8534576590847404E+03  33.895         
0  6 0.1038325333400842E+04  0.1006405376292911E+04  31.92          
0  7 0.1188669128513245E+04  0.1156990156035679E+04  31.679         
0  8 0.1338444888678261E+04  0.1307709428998159E+04  30.7355        
0  9 0.1487875899855938E+04  0.1457288864669831E+04  30.587         
0 10 0.1633967349440270E+04  0.1603993926473577E+04  29.9734        
0 11 0.1777388908803230E+04  0.1748099700565121E+04  29.2892        
0 12 0.1918286926637526E+04  0.1888934985667081E+04  29.3519        
0 13 0.2058680725800944E+04  0.2029241235729571E+04  29.4395        
0 14 0.2200075281399677E+04  0.2170264397677784E+04  29.8109        
0 15 0.2340931894788871E+04  0.2311017131710949E+04  29.9148        
0 16 0.2480867195671524E+04  0.2451173204789553E+04  29.694         
0 17 0.2620001230058012E+04  0.2590125539341500E+04  29.8757        
0 18 0.2759095304017077E+04  0.2728987990765716E+04  30.1073        
...
1  4 0.6173992034657327E+03  0.6174065338892742E+03 -0.00733042 
1  5 0.7726941064460073E+03  0.7727006756491630E+03 -0.0065692  
1  6 0.9248624122413197E+03  0.9248682695627788E+03 -0.00585732 
1  6 0.1075905275832139E+04  0.1075910137326461E+04 -0.00486149 
1  7 0.1227119368127110E+04  0.1227123536317778E+04 -0.00416819 
1  8 0.1376539019866965E+04  0.1376542569756537E+04 -0.00354989 
1  9 0.1525467806588984E+04  0.1525470816492057E+04 -0.0030099  
1 10 0.1671033853251784E+04  0.1671036455074897E+04 -0.00260182 
1 11 0.1813438362105685E+04  0.1813440601224611E+04 -0.00223912 
1 12 0.1954324641370541E+04  0.1954326639841765E+04 -0.00199847 
1 13 0.2094837521653158E+04  0.2094839338225996E+04 -0.00181657 
1 14 0.2236234980632266E+04  0.2236236631815374E+04 -0.00165118 
1 15 0.2377083871774487E+04  0.2377085393018386E+04 -0.00152124 
1 16 0.2516605884688179E+04  0.2516607287187283E+04 -0.0014025  
1 17 0.2655764599685214E+04  0.2655765916519922E+04 -0.00131683 
1 18 0.2795121266695898E+04  0.2795122523273155E+04 -0.00125658 
1 19 0.2935478827344302E+04  0.2935480024090108E+04 -0.00119675 
...

As you can see, the l=1 modes aren't significantly different. I won't haggle over a few nHz here and there. However, the radial orders are all off by about 30 uHz. Given that my comparison between GYRE (in DZIEM mode) and ADIPLS showed that the results are the same, I suspect something is up with the radial orders with the JCD formulation.

I'm aware that the order of the radial equation is reduced to two, so I tried setting reduce_order=.FALSE. in the &num input list. But this gave me the following error:

Code: Select all

> $GYRE_DIR/bin/gyre_ad gyre_ad.in

gyre_ad [2.2]
=============

Compiler         : GCC version 4.9.0 20130408 (experimental)
Compiler options : -I /usr/users/wball/mesa/sdk/include -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=20480 -mtune=corei7-avx -mno-avx -mno-bmi2 -O2 -std=f2008 -finit-real=snan -ffpe-trap=invalid,overflow,zero -fbacktrace -fopenmp
OpenMP Threads   : 2
MPI Processors   : 1

Initialization
==============

Reading from FGONG file model.fgong
  Initial points : 2942
  File version   : 300

Discriminant Scan
=================


Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x2AAAAB6474C7
#1  0x2AAAAB647ACE
#2  0x2AAAAC48891F
#3  0x4ABD48 in __gyre_jacobian_ad_jcd_MOD_trans_matrix
#4  0x41490D in __gyre_bound_ad_jcd_MOD_inner_bound
#5  0x41563B in __gyre_bvp_ad_MOD_build
#6  0x41574D in __gyre_bvp_ad_MOD_discrim
#7  0x418887 in __gyre_search_MOD_scan_search
#8  0x4047C1 in MAIN__ at gyre_ad.f90:0
Floating point exception

My guess was that might fix the issue, but I only found a new one instead.

Let me know if there's anything I can do to try to find (or fix) the problem. This is GYRE 2.2, compiled with the MESA SDK (April 2013 release) on Scientific Linux 6.4 (Carbon).

Cheers,
Warrick

[rhtownsend]

Hi Warrick --

This is fixed in version 2.3, which I've just released. (However, don't take my word for it -- please check!).

cheers,

Rich

[warrick]

Rich,

I just took version 2.3 out for a test drive, and the frequencies of the radial orders now match with both formulations, at least to the same precision as the non-radial modes.

However, the error when trying to use reduce_order = .FALSE. persists. Here's the output I get now, although it looks the same as before.

Code: Select all

> $GYRE_DIR/bin/gyre_ad gyre_ad.in 

gyre_ad [2.3]
=============


Compiler         : GCC version 4.9.0 20130408 (experimental)
Compiler options : -I /home/astro84/wball/mesa/sdk/include -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=10240 -mtune=corei7-avx -mno-avx -mno-bmi2 -O2 -std=f2008 -finit-real=snan -ffpe-trap=invalid,overflow,zero -fbacktrace -fopenmp
OpenMP Threads   : 4
MPI Processors   : 1

Initialization
==============

Reading from FGONG file model.fgong
  Initial points : 2942
  File version   : 300

Discriminant Scan
=================


Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7FE6EEED34C7
#1  0x7FE6EEED3ACE
#2  0x7FE6EDFD5D9F
#3  0x4ADF57 in __gyre_jacobian_ad_jcd_MOD_trans_matrix
#4  0x414A0D in __gyre_bound_ad_jcd_MOD_inner_bound
#5  0x41573E in __gyre_bvp_ad_MOD_build
#6  0x4158AD in __gyre_bvp_ad_MOD_discrim
#7  0x4189CF in __gyre_search_MOD_scan_search
#8  0x404933 in MAIN__ at gyre_ad.f90:0
Floating point exception

An example offending inlist is attached. You can use the same model as in the first post.

I should note that when I compiled on this machine (running openSUSE 12.2 "Mantis", MESA SDK April 2013 version), I got a lot of warnings during compilation. Here's an example snippet:

Code: Select all

...
FC gyre_jacobian_nad_dziem.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_bound_nad_unno.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_bound_nad_jcd.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_jacobian_nad_jcd.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_ivp_findiff_upw.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_bound_nad_dziem.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
...

I don't think it's relevant to this problem, but I thought I'd put it in just in case.

Cheers,
Warrick

[rhtownsend]

Rich,

I just took version 2.3 out for a test drive, and the frequencies of the radial orders now match with both formulations, at least to the same precision as the non-radial modes.

However, the error when trying to use reduce_order = .FALSE. persists. Here's the output I get now, although it looks the same as before.

Code: Select all

> $GYRE_DIR/bin/gyre_ad gyre_ad.in 

gyre_ad [2.3]
=============


Compiler         : GCC version 4.9.0 20130408 (experimental)
Compiler options : -I /home/astro84/wball/mesa/sdk/include -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=10240 -mtune=corei7-avx -mno-avx -mno-bmi2 -O2 -std=f2008 -finit-real=snan -ffpe-trap=invalid,overflow,zero -fbacktrace -fopenmp
OpenMP Threads   : 4
MPI Processors   : 1

Initialization
==============

Reading from FGONG file model.fgong
  Initial points : 2942
  File version   : 300

Discriminant Scan
=================


Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7FE6EEED34C7
#1  0x7FE6EEED3ACE
#2  0x7FE6EDFD5D9F
#3  0x4ADF57 in __gyre_jacobian_ad_jcd_MOD_trans_matrix
#4  0x414A0D in __gyre_bound_ad_jcd_MOD_inner_bound
#5  0x41573E in __gyre_bvp_ad_MOD_build
#6  0x4158AD in __gyre_bvp_ad_MOD_discrim
#7  0x4189CF in __gyre_search_MOD_scan_search
#8  0x404933 in MAIN__ at gyre_ad.f90:0
Floating point exception

An example offending inlist is attached. You can use the same model as in the first post.

OK, I'll look into that. Should be a pretty simple fix. I'll also add a test case to check the fix remains fixed.

I should note that when I compiled on this machine (running openSUSE 12.2 "Mantis", MESA SDK April 2013 version), I got a lot of warnings during compilation. Here's an example snippet:

Code: Select all

...
FC gyre_jacobian_nad_dziem.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_bound_nad_unno.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_bound_nad_jcd.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_jacobian_nad_jcd.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_ivp_findiff_upw.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
FC gyre_bound_nad_dziem.f90
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1272.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1278.
	(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /home/astro84/wball/mesa/sdk/bin/fpx3 line 1283.
	(Maybe you should just omit the defined()?)
...

I don't think it's relevant to this problem, but I thought I'd put it in just in case.

Cheers,
Warrick

This will be fixed in the next SDK release -- it's nothing to worry about.

Thanks for the feedback.

cheers,

Rich

[rhtownsend]

OK, the crash is now fixed in the development version of GYRE.

cheers,

Rich

[warrick]

Great stuff. It's not urgent, so I'll wait for the next release.

Incidentally, is there any reason to prefer the DZIEM or JCD formulations, at least on the main sequence? As shown above, I can only find at most a few nHz difference between them now.

W

[rhtownsend]

Great stuff. It's not urgent, so I'll wait for the next release.

Incidentally, is there any reason to prefer the DZIEM or JCD formulations, at least on the main sequence? As shown above, I can only find at most a few nHz difference between them now.

W

Probably not -- but for RGB stars, we're finding puzzling differences between the two formulations, as I think I've already mentioned. I'm still trying to track down the reasons for this.

cheers,

R