The restriction of gyre_nad to MAGNUS_GL2 is certainly annoying. The next release of GYRE will hopefully include a new set of solvers, which allow non-adiabatic calculations at 2nd, 4th and 6th-order accuracy. Watch this space!

Statistics: Posted by rhtownsend — Thu Jul 16, 2015 4:27 am

]]>

Sorry for spamming the forum.

Best

Ehsan.

Statistics: Posted by ehsan — Wed Jul 15, 2015 4:57 pm

]]>

I have prepared a tarball with the inlist and the input model; however, I cannot attach the file because it is claimed too large! It is actually 388 Kb! I am going to email you the input file.

Thanks for your consideration.

Ehsan.

Statistics: Posted by ehsan — Wed Jul 15, 2015 3:46 pm

]]>

What are your preferred ways to do it? Where to start? What do to?

Your directions will be definitely helpful here.

Cheers

Ehsan.

Statistics: Posted by ehsan — Fri Jul 03, 2015 12:38 pm

]]>

I think this would be a great idea -- it would certainly make the code much more flexible to use.

However, to make this work would require a significant investment of time by multiple developers. Until other members of the community step up and start making contributions to the code, I can't see it happening. I certainly don't have enough time to do it alone.

Best wishes,

Rich

Statistics: Posted by rhtownsend — Fri Jul 03, 2015 12:35 pm

]]>

I was thinking of a possibility of having a user's scripting environment, similar to e.g. run_star_extras in MESA, where public variables and routines are accessible to the user for customised use of the code. The purpose of such environment is to allow user interaction with the code during the runtime, and perform iterative computations, based on the results of the previous step.

Perhaps, one way to do it is to write a Python wrapper around GYRE, and the user would only interact with GYRE through that wrapper; or the best way to do it is indeed similar to MESA in Fortran.

I totally understand that it would be some major time investment into the code architecture.

This scripting environment can perhaps allow the user to intervene in any phase of the GYRE computation, access the input inlist variables, and the intermediate and final outputs.

What do you think here?

Kind regards

Ehsan

Statistics: Posted by ehsan — Thu Jul 02, 2015 4:50 am

]]>

Thanks for spotting this. Turns out there was an oversight when creating the tar archive -- it contained an out-of-date version of the core modules.

I've fixed this now; please try downloading gyre-4.2.tar.gz again.

cheers,

Rich

Statistics: Posted by rhtownsend — Tue Jun 09, 2015 9:54 am

]]>

I've tried to install the latest version (4.2) of gyre but I'm getting some errors.

When I try to install from the source tarball I get the following error:

FC gyre_ad.f90

LD gyre_ad

Undefined symbols for architecture x86_64:

"_xgesvd_", referenced from:

___gyre_linalg_MOD_sing_decompose_c_ in gyre_linalg.o

___gyre_linalg_MOD_sing_decompose_r_ in gyre_linalg.o

ld: symbol(s) not found for architecture x86_64

collect2: error: ld returned 1 exit status

make[2]: *** [gyre_ad] Error 1

If I try to grab the source using Mercurial (using the script from the WiKi) I hit a password block:

24 files updated, 0 files merged, 0 files removed, 0 files unresolved

warning: bitbucket.org certificate with fingerprint 46:de:34:e7:9b:18:cd:7f:ae:fd:8b:e3:bc:f4:1a:5e:38:d7:ac:24 not verified (check hostfingerprints or web.cacerts config setting)

http authorization required for https://bitbucket.org/madstar/astro

realm: Bitbucket.org HTTP

user:

I'm using the latest mesasdk for OS X Yosemite.

Can't wait to try out the new features. Thanks!

Chris

Statistics: Posted by ccameron — Tue Jun 09, 2015 7:59 am

]]>

New features since release 4.0 include:

- Added GYRE_DIR parameter to &constants namelist, as an alternative way of pointing to the top-level GYRE directory
- Added Omega_rot, l_0, eul_phi_ref and deul_phi_ref output items
- Added label parameter to &output namelist
- Added restrict_roots parameter to &num namelist
- Added cowling_approx flag to &osc namelist; set to .TRUE. to turn on the Cowling approximation

As usual, the source code can be downloaded from

https://bitbucket.org/rhdtownsend/gyre/downloads/

Rich

Statistics: Posted by rhtownsend — Tue Jun 02, 2015 9:47 am

]]>

I'm Kevin Gosalim, an undergraduate student from Bandung Institute of Technology (ITB), Indonesia. I'm majoring in Astronomy and Astrophysics and currently working on my thesis. The topic is about stellar nonradial adiabatic pulsation on slow-rotating star and i'm using the latest version of the stellar oscillation code, GYRE v4.0. I'm using it to analyze the eigenfrequencies and pulsation modes of rotating intermediate-mass star (SPB and Beta Cephei). In the latest version, rotation was added to the code and I'm having difficulties on understanding it because there is no modules, tutorials or examples on how GYRE works on rotating star. I want to ask some questions which mostly are basic about rotation in GYRE code (i'm sorry, I hope you all are willing to answer some of these questions).

1. What would the example of GYRE namelist input files with the addition of rotation be like in gedit?

2. How the grid frame and Freq frame (with options: corot_o or corot_i) affect the GYRE running of rotating star?

3. I already tried the traditional approximation in the rotation method parameter (l=2) and GYRE gave an error message. The results are okay if the rotation method is doppler shift. I'm still having difficulties on getting the sense about the input of rotation in GYRE and I hope you all can help me..

Thank you for all your attention. I humbly hope that you are all willing to help me on these questions.

Regards and God bless,

Kevin

Statistics: Posted by Kevin Gosalim — Sat May 09, 2015 8:26 pm

]]>

rhtownsend wrote:

1) You're using a CREATE_CLONE shooting grid, and nothing else. You'll certainly want to use a higher-resolution grid, but CREATE_UNIFORM isn't the way to do that. Have you read the tutorial on grids? If so, you'll see that the correct approach is to put in an additional namelist looking like this:Code:

`&shoot_grid`

op_type = 'RESAMP_DISPERSION' ! Resample the grid based on the local dispersion relation

alpha_osc = 10 ! At least 5 points per oscillatory wavelength

alpha_exp = 2 ! At least 1 point per exponential 'wavelength'

/

I must admit I have missed that tutorial. According to it, I would not need to re-grid for the reconstruction grid, since a rough characterization of the spectrum is exactly what I am looking for (at least for the moment).

rhtownsend wrote:

2) Your frequency scan range is way too wide -- you'll end up getting very high-order modes, which are almost certainly not what your looking for (and will cause the code to crash due to too little RAM). Do you understand what the difference between 'INVERSE' and 'LINEAR' is for grid_type? And do you understand what freq_units = 'NONE' corresponds to? More generally, what sort of mode frequencies are you hoping to find? Answering this latter question will help guide a better choice of the frequency scan.

I tried to vary the frequency range while playing with the code to understand how it works. If I am correct, grid_type determines if we work in the period domain ('INVERSE') or frequency domain ('LINEAR'); and freq_units = 'NONE' means the freq_max and freq_mix are interpreted as being dimensionless as if they where normalized with the inverse of the free-fall time (eq. A4 of the gyre paper ). I was trying to sample from 1/100 of the dynamical frequency to 100 times it (but I agree this is a large interval, and I probably only need a much smaller one). How much is this wrong?

My aim is to investigate the dynamical stability of my models, so in principle I want to find the modes whose frequencies have the largest imaginary parts (i.e. the largest growth rate for the associated instability). Hopefully I will not find any, especially not in the test case in the tarball, which is for a "nice" 15 solar mass model that I (intuitively) expect to be stable. Probably I can limit myself to radial and l=1 modes for the time being, and I would expect only the firsts few order modes to be significant for my present purposes.

I added the grid refinement based on the local dispersion relation (using alpha_osc between 1 and 10, and the same for alpha_exp), I tried narrowing the frequency interval (freq_min>0.1, freq_max<2, freq_units = 'NONE'), changed the n_freq between a few tenths and a few hundreds, and I tried different solvers too. So far I haven't been able to get results, however I never run into "floating point exceptions" anymore. What happens is that both the grid construction and the root bracketing (for l=1) get extremely long (for the moment I am using a single node with 12 cores on a cluster). Also, depending on the values I am trying, I sometimes don't find any radial mode (but I suspect this is because in these cases I am looking to a too narrow frequency interval probably). I was expecting that using a small n_freq(~10) the root bracketing should not be so slow... I am certainly misunderstanding something in the program behavior here, and I would be glad if you could give me some more pointers in the right direction, especially for the choice of the frequency interval and its sampling.

Thank you again!

Mathieu

Statistics: Posted by mathren90 — Tue Feb 24, 2015 11:45 am

]]>

Looking through your namelist input file, there are a couple of potential issues I can spot:

1) You're using a CREATE_CLONE shooting grid, and nothing else. You'll certainly want to use a higher-resolution grid, but CREATE_UNIFORM isn't the way to do that. Have you read the tutorial on grids? If so, you'll see that the correct approach is to put in an additional namelist looking like this:

Code:

`&shoot_grid`

op_type = 'RESAMP_DISPERSION' ! Resample the grid based on the local dispersion relation

alpha_osc = 10 ! At least 5 points per oscillatory wavelength

alpha_exp = 2 ! At least 1 point per exponential 'wavelength'

/

2) Your frequency scan range is way too wide -- you'll end up getting very high-order modes, which are almost certainly not what your looking for (and will cause the code to crash due to too little RAM). Do you understand what the difference between 'INVERSE' and 'LINEAR' is for grid_type? And do you understand what freq_units = 'NONE' corresponds to? More generally, what sort of mode frequencies are you hoping to find? Answering this latter question will help guide a better choice of the frequency scan.

Statistics: Posted by rhtownsend — Mon Feb 23, 2015 6:13 pm

]]>

]]>

Thanks for your post. I'm pretty sure I can help you fix this -- but first, could you re-upload the model you're using? The tarball you linked to contains garbage.

cheers,

Rich

Statistics: Posted by rhtownsend — Mon Feb 23, 2015 11:04 am

]]>

I am trying to verify the stability of some of my MESA models by looking at the imaginary parts of their eigen-frequencies, calculated with GYRE. This is the first time I try to use this tool and I am encountering some problems, described in the following.

First of all I am using:

Code:

`gfortran --version`

GNU Fortran (GCC) 4.10.0 20140710 (experimental)

Copyright (C) 2014 Free Software Foundation, Inc.

and I tried both the GYRE version shipped with MESA 6794 and GYRE 4.0 (installed and tested following the tutorial here: https://bitbucket.org/rhdtownsend/gyre/ ... %20Started ). I encountered similar issues with both. The input file is a MESA 6794 model at oxygen depletion. I produced the GYRE profile by setting in the MESA controls namelist:

Code:

`write_pulse_info_with_profile = .true.`

pulse_info_format = 'GYRE'

You can find the input profile I am using for this tests in a tarball here: http://www.tapir.caltech.edu/~mathren90 ... YRE.tar.gz

With the attached parameter file, I am able to evaluate only the modes with l=0, while modes with l=1,2 (no matter what m is set) give a different problem depending on the ivp_solver used:

* if

Code:

`ivp_solver = 'MAGNUS_GL2'`

Code:

`op_type = 'CREATE_UNIFORM' `

Code:

` ASSERT 'i > 0 .AND. i < this%n' failed at line 433 <gyre_spline:f_1_>:`

Out-of-bounds interpolation

* if

Code:

`ivp_solver = 'MAGNUS_GL4'`

Code:

`'MAGNUS_GL6' `

Code:

`Mode Search`

===========

Mode parameters

l : 2

m : 0

Building omega grid

omega points : 1000

omega range : 0.1500000000000000E+00 -> 0.1500000000000000E+03

Building x grid

x points : 4077 [after CREATE_CLONE op]

x range : 0.0000000000000000E+00 -> 0.9999999999986838E+00

Root bracketing

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

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

Backtrace for this error:

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

Backtrace for this error:

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

Backtrace for this error:

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

Backtrace for this error:

Backtrace for this error:

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

Backtrace for this error:

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#3 0x4BABBA in __gyre_r_ext_MOD_exp_

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#3 0x4BABBA in __gyre_r_ext_MOD_exp_

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#3 0x4BABBA in __gyre_r_ext_MOD_exp_

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#3 0x4BABBA in __gyre_r_ext_MOD_exp_#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#3 0x4BABBA in __gyre_r_ext_MOD_exp_

#6 0x#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

2B2100AC2CDD

#6 0x2B2100AC2CDD#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#7 0x2B210112883C

#5 0x4D1ABF#7 0x2B210112883C

#8 0x2B2101412FCC

#8 0x2B2101412FCC

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

Backtrace for this error:

in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

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

Backtrace for this error:

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

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

Backtrace for this error:

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#3 #3 0x4BABBA in __gyre_r_ext_MOD_exp_

0x4BABBA in #4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

__gyre_r_ext_MOD_exp_

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

Backtrace for this error:

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

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

Backtrace for this error:

#0 0x2B2100520517

#0 0x2B2100520517

#1 0x2B2100520B10

#2 #0 0x2B21005205170x2B210136E02F

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

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

Backtrace for this error:

#1 0x2B2100520B10

#2 0x#3 0x4BABBA in 2B210136E02F

__gyre_r_ext_MOD_exp_

#1 0x2B2100520B10#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#3 0x4BABBA in __gyre_r_ext_MOD_exp_

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#2 #4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

0x#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

2B210136E02F#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#3 0x4BABBA in __gyre_r_ext_MOD_exp_

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#3 0x4BABBA in __gyre_r_ext_MOD_exp_

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#0 0x2B2100520517

#1 0x2B2100520B10

#2 0x2B210136E02F

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#6 0x2B2100ABFBAE

#3 #7 0x4BABBA in __gyre_r_ext_MOD_exp_0x

4D1F1D in __gyre_r_bvp_MOD_build_

#4 0x4E08B7 in __gyre_r_magnus_ivp_MOD_shoot_

#8 0x4CFF2A in __gyre_r_bvp_MOD_discrim_

#5 0x4D1ABF in __gyre_r_bvp_MOD_build_._omp_fn.2 at gyre_r_bvp.f90:0

#6 0x2B2100AC2CDD

#7 0x2B210112883C

#8 0x2B2101412FCC

#9 0x44EEFE in __gyre_r_discfunc_MOD_eval_

#10 0x41A21B in __gyre_r_search_MOD_scan_search

#11 0x40404E in MAIN__ at gyre_ad.f90:0

Floating point exception

This happens with both GYRE version I tried, and with different outer boundary conditions, frequency interval and number of frequencies (n_freq) . Since this is my first attempt with GYRE, it is very likely that I am doing naive errors, and I would be glad if you could help me tracking them down. My aim is to find the imaginary part of the eigenfrequencies of my models (once I can run GYRE I would do this for a large grid of MESA models at different stages of their evolution), I would be glad to hear any suggestion on this problem too if you have any.

Mathieu Renzo

- gyre_ad.in

Statistics: Posted by mathren90 — Mon Feb 23, 2015 5:28 am

]]>