The GYRE Forums

Hello everybody,

I'm an undergraduate student in physics from Germany and I have recently started
using Mesa and Gyre to model stellar evolutions and to compute oscillations frequencies
that take place in stars. For this I followed the instructions given at the Gyre Wiki by
Richard Townsend ("Getting started" and "Running Gyre"). Computing SPB and solar-like
stars works very well but Gyre has problems to converge if I choose to work with
RGB stars. In that case the convergence parameter chi is in the range of 1E^-7 to 1E^-11
in contrast to ideal 1E-9 to 1E-13. The number of iterations requiered for convergence is
also not moderate but close to 20 (sometimes even larger). My namelist file that
controls the Gyre Run is the same as the one from "Running Gyre"
(see also attachment). I can only imagine the following two reasons:
1. I commented out the line photostep = 0 in the inlist_project file for RGB models
because otherwise I get the error message "Fortran runtime error: Cannot match namelist
object to photostep". Maybe this could have some impact on the convergence.
2. The other reason I can think about is the scanning region of the frequencies
from the namelist file (In my case I took freq_min = 0.5 and freq_max = 1 but that could
be the wrong intervall).
So all in all my question is: Which parameters can or should
I change to allow a better convergence of the code? I thank you for your help.

Kind regards
Gyre_Beginner

Hi,

Gyre_Beginner wrote: ↑

Mon Nov 18, 2019 6:33 am

1. I commented out the line photostep = 0 in the inlist_project file for RGB models because otherwise I get the error message "Fortran runtime error: Cannot match namelist object to photostep". Maybe this could have some impact on the convergence.

This is a MESA issue, not a GYRE issue but since I can answer this anyway, it's because the "photostep" control changed to "photo_interval" in r8845. It won't have affected the stellar model, though.

Gyre_Beginner wrote: ↑

Mon Nov 18, 2019 6:33 am

2. The other reason I can think about is the scanning region of the frequencies from the namelist file (In my case I took freq_min = 0.5 and freq_max = 1 but that could be the wrong intervall).

This is almost certainly the issue. You probably want to think about what range of frequencies you actually want to solve for, then adjust GYRE's controls to reflect that. Also bear in mind that the spectrum of non-radial modes in red giants becomes very dense in frequency as they evolve and I doubt `n_freq = 250` will be enough to capture them all (unless you specify quite a narrow frequency range).

Cheers,
Warrick

Hi Warrick,

thank you very much for the answere. I will try the approach of adjusting the range of the frequencies. I have a further (more general) question concerning the computation of the oscillation frequencies of red giants. So far I have used the RGB model for red giant calculations. My goal is to calculate oscillation frequencies for red giants of different masses. My previous considerations were to adjust the masses and the mixing length in the RGB model file (since the mixing length changes with the mass) and than do the calculations for different harmonic degrees l (the different m's I will consider later). Is this approach justified in order to calculate oscillation frequencies of red giants or do other parameters have to be adjusted or changed in the RGB model ? Thanks for the help

greetings

Gyre_Beginner

Gyre_Beginner wrote: ↑

Thu Nov 21, 2019 4:43 am

Is this approach justified in order to calculate oscillation frequencies of red giants or do other parameters have to be adjusted or changed in the RGB model?

If you mean other parameters in the GYRE input file, you'll possibly have to change the frequency range that you search (depending on how you set it up) and the resolution of the frequency search.

Gyre_Beginner wrote: ↑

Thu Nov 21, 2019 4:43 am

My previous considerations were to adjust the masses and the mixing length in the RGB model file...

I'm not completely sure what you mean here but I wouldn't change any numbers in the stellar model file itself. If you want a different stellar model, you'll need to obtain one from somewhere or use a stellar structure/evolution code (e.g. MESA) to compute one.