The GYRE Forums

Hi all,

I'm looking at whether non-adiabatic effects are important in a particular class of helium core-burning stars. In the adiabatic case the calculations look fine, but in the non-adiabatic case I get very small chi values (~1e-20) and in some cases, non-monotonic mode orders.

I understand that this might be an issue with the numerical discretisation, but am not sure how to fix it (increasing the grid points to 100 in the oscillation regions and 20 in the evanescent regions doesn't fix the problem).

In short: Does anyone have any idea whether this is likely to be an issue with the model (I've already set double point at density jumps to true in MESA) or with the search parameters I'm using? My aim is to identify whether the differences between the adiabatic and non-adiabatic modes are genuine or not.

If it helps, the models were computed a few years ago using a rather old version of MESA. I'm using the latest version of GYRE though.

Thanks
Ben

As requested: initial model (which I inherited), an example inlist (I've tried uncommenting the last two lines of &controls to change the grid), and the final model from which I take the pulsation data. Thanks!

Hi Ben,

The non-monotonicity is the result of a weakness in the root solver when searching for non-adiabatic frequencies, which are complex. The root solver needs an initial trial frequency, and right now those are the adiabatic frequencies, which are purely real. The more non-adiabatic a frequency, the further it is from the adiabatic frequency, and the harder it is for the root solver to find it from an adiabatic initial trial frequency. We're aware of this weakness and are in the process of developing a new method for finding initial trial frequencies that is more robust.

Also, if you use the magnus GL2 scheme you'll see the monotonicity is better, but it is still incomplete.

I've attached an image comparing the two methods on the complex frequency plane. Here the grey filled circles are the adiabatic frequencies and the black filled circles are the non-adiabatic frequencies found using your inlist. Each non-adiabatic frequency is connected with a line back to the adiabatic frequency that was used as its initial trial frequency. Some adiabatic frequencies without lines didn't converge to a non-adiabaic frequency at all; the root solver wandered off into the woods. Some non-adiabatic frequencies were found by subsequent adiabatic frequencies (resulting in the non-monotonicity), and some non-adiabatic frequencies were never found.

The red open circles are the non-adiabatic frequencies found using our new method. They are monotonic in order and include the non-adiabatic frequencies that were previously missed. We are in the process of developing the new method for release in GYRE and it is in preparation for publication.

Sincerely,
Jacqueline

Hi Jacqueline,

Thanks very much for your reply - I look forward to the new release!

Best
Ben

Hi Jacqueline,

Sorry to revive a months-old thread, but I'm realising that this discussion has some parallels to the issues I'm currently having, mentioned in my recent post on the forum, located here:

viewtopic.php?f=7&t=207

In my case, the main mode which fails to be located in the non-adiabatic calculation is the radial fundamental mode. Should these upcoming changes to GYRE be able to find the missing fundamental modes in my case also? The models have an enhanced iron abundance and thus a significant iron opacity bump leading to highly non-adiabatic conditions. Some trial calculations by H. Saio have identified some of the modes which GYRE is failing to locate and has confirmed that these modes are strongly non-adiabatic.

On a related note, in the most extreme of the examples I mention in my post, the lowest order mode identified has n_p = 3 and n_g = 1. Can someone explain how the mode identification is carried out in GYRE, because I don't think g-mode coupling to radial modes is an expected behaviour? From my interpretation of the radial displacement curve, I can't see where the n_g is coming from, maybe I'm missing something.

Thanks,

Conor.