Code:

` `

subroutine gyre_call_back(md, ipar, rpar, ierr)

use astero_data, only: store_new_oscillation_results

type(mode_t), intent(in) :: md

integer, intent(inout) :: ipar(:)

real(dp), intent(inout) :: rpar(:)

integer, intent(out) :: ierr

integer :: new_el, new_order, new_em

real(dp) :: new_inertia, new_linear_freq, omeg_r, omeg_i, &

dmp_freq, p_in_days, eta

include 'formats'

ierr = 0

new_el = md% mp% l

new_order = md% n_pg

new_inertia = md% E_norm()

new_linear_freq = md% freq('UHZ')

new_em = 0

call store_new_oscillation_results( &

new_el, new_order, new_em, new_inertia, new_linear_freq, ierr)

!>afg - experimental

omeg_r = REALPART(md% omega) ! dimensionless frequency

omeg_i = IMAGPART(md% omega)

write (*,*) omeg_i, omeg_r

p_in_days = 1.15741d1/new_linear_freq

eta = omeg_i/omeg_r

Apparently I am doing something weird here, but what? If the digits of the omeg's would differ, I would presume that I tap the wrong variable; but the current situation just beats me.

Any advice of what I could do or check - or what not to touch?

Thanks, Alfred

Statistics: Posted by afg — Sat Apr 09, 2016 5:28 pm

]]>

afg wrote:

Rich

I am just trying to scan the classical instability strip. Convergence with Version 4.4 is good, just as as tried out last night on two selected models.

However, I have the impression that the time dependence is back to exp(i*omega*t) as it was in the GYRE versions before 4.3 -- or somehow the instability strip has turned inside out . Is that choice a feature?

Alfred

Rich

I am just trying to scan the classical instability strip. Convergence with Version 4.4 is good, just as as tried out last night on two selected models.

However, I have the impression that the time dependence is back to exp(i*omega*t) as it was in the GYRE versions before 4.3 -- or somehow the instability strip has turned inside out . Is that choice a feature?

Alfred

Hmmm, that's puzzling. The time dependence is still exp(-i*omega*t), as one can see from running the test cases in test/nad/mesa (the unstable modes show up as having Im(omega) > 0). So I'm not sure what's going on with your calculations.

cheers,

Rich

Statistics: Posted by rhtownsend — Sat Apr 09, 2016 2:37 pm

]]>

However, I have the impression that the time dependence is back to exp(i*omega*t) as it was in the GYRE versions before 4.3 -- or somehow the instability strip has turned inside out . Is that choice a feature?

Alfred

Statistics: Posted by afg — Sat Apr 09, 2016 11:18 am

]]>

Glad to hear things are working!

You'll be pleased to hear that GYRE 4.4 is already included in the development version of MESA, and we are planning a MESA release soon (in good time for the summer school).

cheers,

Rich

Statistics: Posted by rhtownsend — Fri Apr 08, 2016 11:24 am

]]>

Thanks so much for Version 4.4. - and sorry for my sloppy realizing of the activities in the GYRE forum.

I just downloaded Version 4.4 and compiled it for standalone operation. This works very well. Now, I have convergence on the models which did not work before; i.e. I find continuous NAD mode orders with MAGNUS_GL2 with a convergence speed that is comparable with that on AD modes.

As of now, I just failed to embed the Version 4.4. in MESA so that I can call the correct GYRE version from within MESA. When I do a build_and_test from mesa/gyre/ (with the correct version plugged in in build_and_test) the process fails during the test stage. If Version 4.4. succeeds in all tests on your machines, I would be happy (also for the students next summer) if you could add V. 4.4. to the next MESA distribution!

I am extremely grateful for your efforts and your willingness to help. Now, I am very positive that I can successfully continue with my original plans for the summer school.

Alfred

Statistics: Posted by afg — Fri Apr 08, 2016 7:47 am

]]>

Benard wrote:

Hello,

I am new to Gyre code. I am obtaining very high radial orders for my frequencies for some of my models. I kindly request for your help to figure what could be causing this. I also believe my frequencies may not be correct.

I have attached two models, the output files and the Gyre input file.

Thank you,

Cheers,

Benard

Hello,

I am new to Gyre code. I am obtaining very high radial orders for my frequencies for some of my models. I kindly request for your help to figure what could be causing this. I also believe my frequencies may not be correct.

I have attached two models, the output files and the Gyre input file.

Thank you,

Cheers,

Benard

Hi Benard --

I moved your post to the "Bug Reports" forum, since it doesn't fit well in "Feature Requests". However, the code appears to be working correctly. The reason why your radial orders are so high, is that you're searching in a frequency range which is the domain of high-order p modes.

To find lower-order modes, try reducing the frequency range. You could also try specifying the frequencies in units of the atmospheric acoustic cutoff. For instance:

Code:

`&scan`

grid_type = 'LINEAR' ! Scan for modes using a uniform-in-frequency grid; best for p modes

freq_units = 'ACOUSTIC_CUTOFF' ! Interpret freq_min and freq_max as fractions of the acoustic cutoff

freq_min = 0.1 ! Minimum frequency to scan from

freq_max = 0.9 ! Maximum frequency to scan to

n_freq = 500 ! Number of frequency points in scan

tag_list = 'l=0'

/

I hope this helps!

cheers,

Rich

Statistics: Posted by rhtownsend — Wed Apr 06, 2016 12:54 pm

]]>

rhtownsend wrote:

Hope this explains!

Rich

Hope this explains!

Rich

Ultimately.

Thanks for your swift reply.

Regards

Ehsan.

Statistics: Posted by ehsan — Wed Apr 06, 2016 12:51 pm

]]>

The interpretation of R_star is largely set by the evolutionary code -- GYRE then uses what it's given.

In the case of MESA models, R_star represents the photospheric radius. If an atmosphere is included with the model, then some of the outermost grid points may have r > R_star.

Hope this explains!

cheers,

Rich

Statistics: Posted by rhtownsend — Wed Apr 06, 2016 12:39 pm

]]>

Therefore, the ratio of the two is:

0.194141167554E+12 / 1.9478956761917606e+11 = 0.9966712793036036

Would you please enlighten me on this difference?

Regards

Ehsan.

Statistics: Posted by ehsan — Wed Apr 06, 2016 5:22 am

]]>

I am new to Gyre code. I am obtaining very high radial orders for my frequencies for some of my models. I kindly request for your help to figure what could be causing this. I also believe my frequencies may not be correct.

I have attached two models, the output files and the Gyre input file.

Thank you,

Cheers,

Benard

- files.tar.gz

- template.in

Statistics: Posted by Benard — Wed Apr 06, 2016 2:39 am

]]>

Please could you try upgrading to GYRE 4.4, and using the MAGNUS_GL2 scheme.

cheers,

Rich

Statistics: Posted by rhtownsend — Tue Apr 05, 2016 4:52 pm

]]>

This version introduces no new features, but fixes a couple of bugs, and restores the capability of the MAGNUS_GL2 IVP scheme to converge well during non-adiabatic calculations on certain types of stars.

Although the COLLOC_GL[2,4,6] remain the preferred schemes for non-adiabatic calculations, there are some circumstances where they require many iterations to converge, or fail to converge at all. The MAGNUS_GL2 scheme can work well in these circumstances, using a numerical approach I term "eigenvalue rescaling". In version 4.1 of GYRE the code which performs the eigenvalue rescaling was modified, in a way that sometimes doesn't work correctly. Version 4.4 reverts the code back to the original functionality.

As usual, the source code can be downloaded from

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

Rich

Statistics: Posted by rhtownsend — Sun Apr 03, 2016 10:58 pm

]]>

intermediate-mass stars in the classical instability strip while the

stars are on their blue loops.

I do manage to get nonadiabatic radial fundamental, first-, and

second-overtone results when the stars cross the strip for the first

time (i.e. as long as they are decently compact) but not anymore once

they are more puffed up.

Typically, what I get to see in a GYRE (V. 4.3 is running here) session is:

Code:

`Mode Search`

===========

Mode parameters

l : 0

m : 0

Building omega grid

added scan interval : 0.1500000000000000E+01 -> 0.7500000000000000E+01 (60 points, LINEAR)

Building x grid

x points : 1601 [after CREATE_MIDPOINT op]

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

Root bracketing

Time elapsed : 0.364 s

Root Solving

l n_pg n_p n_g Re(omega) Im(omega) chi n_iter n

0 1 1 0 0.2655955222291173E+01 0.0000000000000000E+00 0.5018777496194273E-14 7 1601

0 2 2 0 0.3889235307472945E+01 0.0000000000000000E+00 0.1058218887806180E-13 6 1601

0 3 3 0 0.5344936627626918E+01 0.0000000000000000E+00 0.6300390309901204E-14 6 1601

Time elapsed : 0.162 s

Root Solving

l n_pg n_p n_g Re(omega) Im(omega) chi n_iter n

0 1 1 0 0.2661960010712412E+01 0.2627637059281112E-02 0.5084080344596849E-12 6 1601

Failed during deflate narrow : maximum iterations exceeded

n_iter_def : 51

n_iter : 0

omega_a : 0.1583803223265424E+01 -0.1268621277039857E+01

omega_b : 0.1539169900795748E+01 -0.1271863390338167E+01

0 3 3 0 0.5299325378482669E+01 -0.1708691639619444E-01 0.1246651790965083E-12 7 1601

Time elapsed : 7.197 s

It is not always the 1st overtone, which goes haywire. It can be any of the 3 modes I am interested in.

Adiabatic computations are no problem at all, independent of the IVP

solver used (as suggested in the GYRE forum, I use usually one of the

COLLOC_GL<*> integrators. To me, the problem seems to be associated

with the (complex) root finding process. Actually, only the RIDDERS

method works reliably, if at all. To my surprise, even the SECANT

method fails most of the time.

To overcome the convergence problems I decided to try to set the

innermost grid point not at the star's center but resort to "envelope"

computations only (Just in case this all should be connected after all

to the full-star integration of the nonadiabatic problem). Therefore,

in the gyre.in file I request:

Code:

`&shoot_grid ! If left empty, adoption of defaults only`

op_type = 'CREATE_MIDPOINT'

x_i = 0.1

/

&recon_grid ! If left empty, adoption of defaults only

op_type = 'CREATE_CLONE'

x_i = 0.1

/

... and

&osc

inner_bound = 'ZERO'

At startup, I get the stopping message:

Code:

`Root bracketing`

ASSERT 'this%x_i /= 0._WP' failed at line 210 <gyre_rad_bound:B_i_zero_>:

Boundary condition invalid for x_i == 0

Checking the source of GYRE, I also got the impression that setting

x_i =/ 0 has no effect in nad/gyre_grid_par.f90. I admit though, that

I do not understand every single assignment in the routine.

Is it possible that x_i, x_o can be set via namelist but are not yet wired

for the intended use in the NAD case?

Any help is appreciated

Alfred

Statistics: Posted by afg — Fri Mar 18, 2016 11:29 am

]]>

Cheers,

Ehsan.

Statistics: Posted by ehsan — Mon Feb 08, 2016 3:28 am

]]>

This is a very good suggestion, and one that I have considered implementing for some time now. Since it relies on mode identifications to figure out how many modes are in a given interval, my recent focus with GYRE has been getting the mode id's correct -- and in turn, this requires proper handling of density discontinuities.

I'm currently readinying GYRE 5.0 for release -- this includes the density-discontinuity code. With that done, I'll be working on adaptive frequency searching, such as you describe above.

cheers,

Rich

Statistics: Posted by rhtownsend — Sun Feb 07, 2016 2:54 pm

]]>