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

]]>

You need to generate a stellar model before you can use GYRE. A good tool for doing this is the MESA stellar evolution code:

http://mesa.sourceforge.net/

Best wishes,

Rich

Statistics: Posted by rhtownsend — Mon Feb 02, 2015 7:54 pm

]]>

New features in this release include:

- GYRE no longer needs gfortran 4.10 (aka gfortran 5.0) to compile; it works fine with gfortran 4.9.3
- Implemented dedicated code paths for real and complex arithmetic, resulting in significant speedups in many cases
- Added uniform_rot flag and Omega_uni parameter to &model namelist, to enforce rigid rotation on the model
- Added reconstruct_As flag to &model namelist, controlling numerical reconstruction of the dimensionless Brunt-Vaisala frequency
- Added rotation_method parameter to &osc namelist, to determine how rotation effects are treated. The possible treatments include the traditional approximation
- Added inner_bound parameter to &osc namelist, allowing specification of the inner boundary conditions
- Added r_root_solver and c_root_solver parameters to &num namelist, allowing specification of the real and complex root solvers, respectively
- Added grid_frame and freq_frame parameters to &scan namelist, allowing specification of the frames in which the frequency grid is distributed and the frequency units are defined, respectively
- Added 'GRAVITY_DELTA' and 'ACOUSTIC_DELTA' options for the &freq_units parameter in the &scan and &output namelists
- Added 'MIXED_DELTA' option for the &freq_units parameter in the &scan namelist
- Renamed ivp_solver_type parameter to ivp_solver
- Renamed outer_bound_type parameter to outer_bound
- Renamed inner_bound_type parameter to inner_bound
- Renamed inertia_norm_type parameter to inertia_norm
- Renamed variables_type parameter to variable_set
- Replaced use_banded parameter by matrix_type parameter

As usual, the source code can be downloaded from

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

Rich

Statistics: Posted by rhtownsend — Mon Feb 02, 2015 7:48 pm

]]>

I'm fairly new to asteroseismology, and I have to admit my knowledge is quite limited in that field.

Still, I have a goal : be able to plot a Petersen diagram like this one (the original article is here : http://www.aanda.org/articles/aa/pdf/20 ... 345-09.pdf)

Ok so I have a RR Lyrae star, I want to plot the P1/P0 ratio vs P0, for different values of L, M, etc as described in the article.

1) So my first question is : how do I obtain the stellar model file. I saw that there were different type (MESA type, GYRE type, etc). Can't I just enter the input parameter ? (I'm sorry if it sounds a bit stupid)

2) Once I have the stellar model file, I'll have to put l = 1 in the namelist file, is that right ?

3) Is there anyway to compute a loop fo different mass, luminosity, etc.

Thank you in advance for your answer, and sorry for the low level of my questions.

Statistics: Posted by Lucas1283 — Sun Feb 01, 2015 12:34 pm

]]>

ehsan wrote:

Dear Rich,

I am certain that this message does not belong to here. Perhaps, I should have sent it to the MESA mailing list, or definitely somewhere like MESASDK forum, which for now does not exist

So, this forum is the only discussion place I find useful for my question.

Due to my serious addiction to MESA and its prerequisite SDK, the MESASDK is the only bundle of compiler and libraries that I install on all systems that I work with. Now, for a separate project (that you will hear about soon), I need to link to and use LAPACK library. However, I do not know how to do that in my makefile. Additionally, the HDF5 support that ships for free with the SDK is also very appealing to use.

I would like to kindly ask you to document that, and perhaps provide examples on how to link to these libraries in MESASDK, and call then from within our own fortran programs.

Thanks for your support.

Ehsan

Dear Rich,

I am certain that this message does not belong to here. Perhaps, I should have sent it to the MESA mailing list, or definitely somewhere like MESASDK forum, which for now does not exist

So, this forum is the only discussion place I find useful for my question.

Due to my serious addiction to MESA and its prerequisite SDK, the MESASDK is the only bundle of compiler and libraries that I install on all systems that I work with. Now, for a separate project (that you will hear about soon), I need to link to and use LAPACK library. However, I do not know how to do that in my makefile. Additionally, the HDF5 support that ships for free with the SDK is also very appealing to use.

I would like to kindly ask you to document that, and perhaps provide examples on how to link to these libraries in MESASDK, and call then from within our own fortran programs.

Thanks for your support.

Ehsan

To use the MESASDK version of LAPACK, add the following to the command used to link the executable:

Code:

``mesasdk_lapack_link``

(Note that the `` symbols are backticks, not normal quotes). For instance, if you are creating the executable 'foo' from the object file 'foo.o', you might use a rule like this in the Makefile:

Code:

`foo : foo.o`

gfortran -o $@ $< `mesasdk_lapack_link`

The procedure is similar for linking to the HDF5 library, except you use `mesasdk_hdf5_link` instead of `mesasdk_lapack_link`.

When compiling object files from Fortran 90/95/03 source code, you may have to tell the compiler where to find the appropriate .mod files for modules you use in your code. To do this, add the following to the code used to compile the object file:

Code:

`-I$(MESASDK_ROOT)/include`

For instance, if you are compiling the object file 'foo.o' from the source file 'foo.f90', you might use a rule like this in the Makefile:

Code:

`foo.o : foo.f90`

gfortran -I$(MESASDK_ROOT) -c $<

cheers,

Rich

Statistics: Posted by rhtownsend — Sat Dec 20, 2014 3:59 pm

]]>

*) build_poly -- generate a polytrope of arbitrary index 0 <= n < 5, and write it out in GYRE's POLY format

*) build_poy_hom -- generate a homogeneous incompressible (n=0) polytrope and write it out in GYRE's POLY format

To build these tools, run 'make' in the src/util subdirectory. *NOTE*: you'll need to install the Madison SDK (MADSDK) to compile -- this is a superset of the MESA SDK, which includes the ODEPACK library and a number of other useful things. You can grab the MADSDK from

http://www.astro.wisc.edu/~townsend/sta ... ref=madsdk

To use the tools, you need to create a namelist input file. There's a sample input file, build_poly.in, provided in src/utils -- it specifies an n=4.97 polytrope with a spacing of 1E-2 in the Lane-Emden variable xi. Input files are read from standard input, and so

./build_poly < build_poly.in

...will run build_poly with the build_poly.in namelist input file. In future releases of the code I'm going to make build_poly[_hom] use command-line arguments, but for now we're stuck using namelists.

Statistics: Posted by rhtownsend — Thu Dec 18, 2014 9:26 am

]]>

So, this forum is the only discussion place I find useful for my question.

Due to my serious addiction to MESA and its prerequisite SDK, the MESASDK is the only bundle of compiler and libraries that I install on all systems that I work with. Now, for a separate project (that you will hear about soon), I need to link to and use LAPACK library. However, I do not know how to do that in my makefile. Additionally, the HDF5 support that ships for free with the SDK is also very appealing to use.

I would like to kindly ask you to document that, and perhaps provide examples on how to link to these libraries in MESASDK, and call then from within our own fortran programs.

Thanks for your support.

Ehsan

Statistics: Posted by ehsan — Thu Dec 18, 2014 4:06 am

]]>

Please unzip the attached file. Unfortunately, the .py is not a valid extension for attachments.

I hope you find it useful.

Best

Ehsan.

- polytrope.py.zip

Statistics: Posted by ehsan — Thu Dec 18, 2014 3:56 am

]]>

Thanks!

Statistics: Posted by jguillochon — Fri Nov 21, 2014 12:58 pm

]]>

]]>

Is the following failure what you were referring to from mismatched gfortrans?

Code:

`kleiner:gyre jgoldstein$ make test`

make[1]: Entering directory `/Users/jgoldstein/myApplications/gyre/test'

make[2]: Entering directory `/Users/jgoldstein/myApplications/gyre/test/ad'

TEST homogeneous compressible model (analytic structure) ...succeeded

TEST homogeneous compressible model (polytropic structure) ...succeeded

TEST homogeneous compressible model (OpenMP) ...succeeded

TEST homogeneous compressible model (rotational Doppler shift) ...succeeded

TEST MESA model for beta Cephei star ...succeeded

TEST MESA model for RGB star ...succeeded

TEST MESA model for slowly pulsating B-type star ...succeeded

TEST FGONG solar model S ...succeeded

make[2]: Leaving directory `/Users/jgoldstein/myApplications/gyre/test/ad'

make[2]: Entering directory `/Users/jgoldstein/myApplications/gyre/test/nad'

TEST MESA model for beta Cephei star ...succeeded

TEST MESA model for RGB star59c59

< 3 -852 6 858 0.1151452771661757E+002 0.2254338713810882E-002 0.1151480240127081E+002 0.2268811590471002E-002

--- field 5 relative error 4.17e-12

> 3 -852 6 858 0.1151452771656952E+002 0.2254338704980019E-002 0.1151480240127592E+002 0.2268811577668130E-002

...failed when comparing gyre_nad.txt and ref/gyre_nad.txt.x86_64-Darwin

make[2]: Leaving directory `/Users/jgoldstein/myApplications/gyre/test/nad'

make[1]: Leaving directory `/Users/jgoldstein/myApplications/gyre/test'

kleiner:gyre jgoldstein$

Statistics: Posted by jacquelinegoldstein — Tue Nov 11, 2014 2:15 pm

]]>