The GYRE Forums

Hi all

I hope you and your family are doing well in this covid time.

I was using so far an old version of GYRE. I decided to download and compile the 5.2 version.

I am probably the only one, but I am using CESAM evolutionary code and so stellar models of type .osc.

The new code (5.2) does not run with these models. There are 2 bugs in gyre_osc_file.f90

ivers is an integer so the output

write(OUTPUT_UNIT, 120) 'File version', ivers
120 format(3X,A,1X,F4.2,1X,A)

won’t work and I replaced it by

write(OUTPUT_UNIT, 120) 'File version', ivers
120 format(3X,A,1X,I0)


then below in this routine the mass m is not calculated correctly

m = EXP(point_data(2,:))

must be replaced by

m = EXP(point_data(2,:))*M_star


Then GYRE 5.2 runs

----------------------------------------------------------------------------------------------------

Moreover, I have issues with the non-adiabatic eigenfunctions

I run a CESAM calibrated solar model for radial p-modes.

I try to check the consistency of the eigenfunctions by checking the well know relations

abs(lag_rho) = abs(deriv(x,xi) + 2/x*xi) (1)
abs(lag_rho) = abs(lag_P/gamma_1-delta*lag_S)

It works for adiabatic calculations but not for non-adiabatic ones; More precisely it depends on the choice of variables : DZIEM, JCD, GYRE, LAGP

it works with DZIEM but not for LAGP and JCD. The shape of the lag_P function is not at all the same for LAGP and JCD

I realized that in the case of variable=LAGP, the lag_P must be corrected

lag_P ---> lag_P/(V_2)^2

and then lag_rho = lag_P/gamma_1 -delta*lag_S is consistent with (1).

I could not figure out where to modify this in the code. Since the eigenfrequencies look ok I suspect a problem in the outputs but I could not find. The problem persists whatever numerical scheme/outer boundary conditions is used. Same problem for l=0 or l=1

I was also surprise to see that by using the VACUUM outer BC, the Lag_P is not zero at the top (and this is a problem for my calculations!). It is zero for adiabatic calculations but not for non-adiabatic ones. Both real and imaginary lag_P are not zero at top. After checking, this was also the case in older version GYRE.


last thing. In gyre_nad_trans.f90 the integer that defines the variables are

integer, parameter :: GYRE_SET = 0
integer, parameter :: DZIEM_SET = 1
integer, parameter :: JCD_SET = 2
integer, parameter :: LAGP_SET = 3

whereas in gyre_ad_trans.f90 it is

integer, parameter :: GYRE_SET = 0
integer, parameter :: DZIEM_SET = 1
integer, parameter :: JCD_SET = 2
integer, parameter :: MIX_SET = 3
integer, parameter :: LAGP_SET = 4

so in the two cases, the LAGP is not defined with the same integer and the MIX type variables are missing in the non-adiabatic calculations.

Any suggestion/help for the non-adiabatic eigenfunctions and the outer BC is welcome.

Cheers
Lionel.

Hi Lionel --

Thanks for all your questions and comments. I'm going to answer them piecemeal, so expect more responses as I work my way through your post!

First, the two issues you found with the OSC code are indeed bugs; I think they haven't been spotted before because I've never actually tested the OSC-reading code (I based it on the description given in the CoRoT/ESTA file formats document).

I've added the fixes to the development version of GYRE, and so they will be included in the next release.

Could you post an example OSC model (e.g., the solar model you mention in your post) so I can add it to the test suite, to check that further issues with the OSC format don't arise in the future?

Many thanks,

Rich

Hi Lionel --

For your questions about the different variables_set choices, I think you've run into a known bug in GYRE 5.2. To fix it, please try applying the patch posted in this thread:

viewtopic.php?f=7&t=221

Regarding the different numerical values of LAGP_SET in gyre_ad_trans.f90 and gyre_nad_trans.f90, this is deliberate and won't affect the correct functioning of the code. Also, MIX_SET is not defined in gyre_nad_trans.f90 because the MIX variables set is not supported for non-adiabatic calculations.

cheers,

Rich

Hi Lionel --

As a final note, the patch should also fix the lag_P /= 0 issue when you use the VACUUM boundary condition.

cheers,

Rich