Finite-ampitude g-modes in convective core

[ehsan]

Dear Rich,

Mathias (and I) are making some tests with MESA+GYRE to look at the mode stability in core helium burning blue supergiant stars, and a possible trace of excitation by the epsilon mechanism. We have come across two curious cases:

• a g-mode penetrating the fully convective core, and having negligible amplitude elsewhere. this has a positive excitation
• a g-mode with positive dW_eps_dx in the convective core, followed by a negative dW_eps_dx in the radiative zone above the core

I have hard time understanding two points here:

• Why a g-mode would penetrate a convective core?
• Why dW_eps_dx be negative (while Unno et al. mentions that it only contributes towards destabilisation of a mode?

Would you please enlighten me on thees questions?

I also compared the work integral for epsilon-mechanism from Unno et al. (Eq. 25.9), and found it different from its implementation in line 1701 of the src/build/gyre_mode.f90 file. How do I track down that formula in Unno or other literature?

I will send you the model and inlist separately, as the file is large.

Kind regards,
Ehsan & Mathias

[rhtownsend]

Dear Rich,

Mathias (and I) are making some tests with MESA+GYRE to look at the mode stability in core helium burning blue supergiant stars, and a possible trace of excitation by the epsilon mechanism. We have come across two curious cases:

• a g-mode penetrating the fully convective core, and having negligible amplitude elsewhere. this has a positive excitation
• a g-mode with positive dW_eps_dx in the convective core, followed by a negative dW_eps_dx in the radiative zone above the core

I have hard time understanding two points here:

• Why a g-mode would penetrate a convective core?
• Why dW_eps_dx be negative (while Unno et al. mentions that it only contributes towards destabilisation of a mode?

Would you please enlighten me on thees questions?

I also compared the work integral for epsilon-mechanism from Unno et al. (Eq. 25.9), and found it different from its implementation in line 1701 of the src/build/gyre_mode.f90 file. How do I track down that formula in Unno or other literature?

I will send you the model and inlist separately, as the file is large.

Kind regards,
Ehsan & Mathias

Hi Ehsan & Mathias --

I've had a look through the inlist you sent me, and I've run it through GYRE with the corresponding model. The curious cases you have found unfortunately demonstrate what happens when you run GYRE outside its limits of validity! For the region of frequency space you are examining, the radial orders of the *adiabatic* modes are in the thousands. For such high-order modes, it is very difficult to obtain accurate numerical approximations to the corresponding *non-adiabatic* modes, due to the finite precision of computer floating-point arithmetic. As a result the non-adiabatic modes returned by GYRE, for the cases you consider, are in effect numerical noise. Increasing the grid resolution won't change this behavior; you've run into a limitation tied to the computer hardware.

This should serve as a cautionary tale: you can't treat GYRE like a black box! As a specific piece of advise for deciding whether you can believe GYRE's results, you should get into the habit of looking at the chi (convergence) parameters printed to the screen during a GYRE run. These should be in the typical range 1E-15 -> 1E-8. Much larger, or much smaller, suggests that GYRE either isn't converging, or is converging to a bogus solution.

Regarding the work integral for the epsilon mechanism: Note that it's only the first (e_N) term inside the parentheses of Unno's eqn. 25.9 which is used in evaluating the nuclear contribution to the work integral.

cheers,

Rich

[ehsan]

Thanks Rich for your thorough reply.

I've had a look through the inlist you sent me, and I've run it through GYRE with the corresponding model. The curious cases you have found unfortunately demonstrate what happens when you run GYRE outside its limits of validity! For the region of frequency space you are examining, the radial orders of the *adiabatic* modes are in the thousands. For such high-order modes, it is very difficult to obtain accurate numerical approximations to the corresponding *non-adiabatic* modes, due to the finite precision of computer floating-point arithmetic. As a result the non-adiabatic modes returned by GYRE, for the cases you consider, are in effect numerical noise. Increasing the grid resolution won't change this behavior; you've run into a limitation tied to the computer hardware.

I admit that this was a pure exploratory experiment, to exploit the challenges that come up. Indeed, the limited floating point arithmetic is the limitation here. That is the reason we did not trust in what we saw in the output.

This should serve as a cautionary tale: you can't treat GYRE like a black box! As a specific piece of advise for deciding whether you can believe GYRE's results, you should get into the habit of looking at the chi (convergence) parameters printed to the screen during a GYRE run. These should be in the typical range 1E-15 -> 1E-8. Much larger, or much smaller, suggests that GYRE either isn't converging, or is converging to a bogus solution.

Admittedly, the chi variable comes very handy in these cases, where we need to decide whether or not to rely on the GYRE output. The slim point here is that we need to run our GYRE computations on a computing cluster, and we typically do not sit in front of the screen looking at the GYRE STDOUT (which we should). We mainly look into the summary and eigenfunction files. Perhaps, this motivates putting chi as an additional output in the summary/eigenfunction files, so the user would not miss this valuable piece of info from the STDOUT.

Thanks again for enlightening us.
Ehsan.

[rhtownsend]

Thanks Rich for your thorough reply.

I've had a look through the inlist you sent me, and I've run it through GYRE with the corresponding model. The curious cases you have found unfortunately demonstrate what happens when you run GYRE outside its limits of validity! For the region of frequency space you are examining, the radial orders of the *adiabatic* modes are in the thousands. For such high-order modes, it is very difficult to obtain accurate numerical approximations to the corresponding *non-adiabatic* modes, due to the finite precision of computer floating-point arithmetic. As a result the non-adiabatic modes returned by GYRE, for the cases you consider, are in effect numerical noise. Increasing the grid resolution won't change this behavior; you've run into a limitation tied to the computer hardware.

I admit that this was a pure exploratory experiment, to exploit the challenges that come up. Indeed, the limited floating point arithmetic is the limitation here. That is the reason we did not trust in what we saw in the output.

It's possible to avoid these sorts of unnecessary calculations by choosing freq_min and freq_max to match the expected frequencies of modes with radial orders in some 'reasonable' range. This is what the ACOUSTC_DELTA and GRAVITY_DELTA frequency units are designed to do. So, for instance, if you're only interested in g modes with radial orders 1 <= n <= 100, you can do this (in GYRE 5.0):

Code: Select all

&scan
   grid_type = 'INVERSE'
   freq_min = 0.01 ! 1/100
   freq_max = 1     ! 1/1
   freq_min_units = 'GRAVITY_DELTA'
   freq_max_units = 'GRAVITY_DELTA'
   n_freq = 500
/

This should serve as a cautionary tale: you can't treat GYRE like a black box! As a specific piece of advise for deciding whether you can believe GYRE's results, you should get into the habit of looking at the chi (convergence) parameters printed to the screen during a GYRE run. These should be in the typical range 1E-15 -> 1E-8. Much larger, or much smaller, suggests that GYRE either isn't converging, or is converging to a bogus solution.

Admittedly, the chi variable comes very handy in these cases, where we need to decide whether or not to rely on the GYRE output. The slim point here is that we need to run our GYRE computations on a computing cluster, and we typically do not sit in front of the screen looking at the GYRE STDOUT (which we should). We mainly look into the summary and eigenfunction files. Perhaps, this motivates putting chi as an additional output in the summary/eigenfunction files, so the user would not miss this valuable piece of info from the STDOUT.

Thanks again for enlightening us.
Ehsan.

I'll see if I can add chi to the variables which are written out to the files.

cheers,

Rich