The GYRE Forums

Dear Rich,

I am posting an error with v.4.4, since I just realised that the shiny new v.5.0 is just out. Will try that soon ...
I am "playing around" with different possible models of KIC 7760680 (our recent work), including rotational mixing and AM transport in MESA.
Two issues arise:

Issue 1. In my &shoot_grid, if I uncomment alpha_osc, the gyre_ad just blows up! Thus, I've been so far commenting it out. This is the first time I am observing this behaviour.

Issue 2. I start the ZAMS with different initial rotation velocities v_ini (between 80 and 150 km/sec), and store a GYRE model once Xc=0.35. Up to v_ini=115 km/sec the model ends up with surface velocity v_eq=78 km/sec, and GYRE can safely compute adiabatic frequencies, using TRAD. However, exceeding this v_ini limit, and starting off with e.g. v_ini=120 km/sec, then MESA reaches Xc=0.35 with higher surface and internal velocities. In such circumstances, GYRE requires an embarrassingly huge x-mesh, and eventually crashes.
I would like to know if this is due to the limitation of the TRAD tables w.r.t. to the spin parameter?
And if there is a way to circumvent this? Are there new extended tables available?

Kind regards,
Ehsan.

PS: I have attached the inlist. I will email you the input file.

ehsan wrote:Dear Rich,

I am posting an error with v.4.4, since I just realised that the shiny new v.5.0 is just out. Will try that soon ...
I am "playing around" with different possible models of KIC 7760680 (our recent work), including rotational mixing and AM transport in MESA.
Two issues arise:

Issue 1. In my &shoot_grid, if I uncomment alpha_osc, the gyre_ad just blows up! Thus, I've been so far commenting it out. This is the first time I am observing this behaviour.

Almost certainly because the oscillation frequency in the co-rotating frame approaches (or passes through zero) at some point within the star. This means that the radial wavenumber of modes diverges, and GYRE ends up wanting to insert a huge number of grid points to resolve the oscillation.

Issue 2. I start the ZAMS with different initial rotation velocities v_ini (between 80 and 150 km/sec), and store a GYRE model once Xc=0.35. Up to v_ini=115 km/sec the model ends up with surface velocity v_eq=78 km/sec, and GYRE can safely compute adiabatic frequencies, using TRAD. However, exceeding this v_ini limit, and starting off with e.g. v_ini=120 km/sec, then MESA reaches Xc=0.35 with higher surface and internal velocities. In such circumstances, GYRE requires an embarrassingly huge x-mesh, and eventually crashes.
I would like to know if this is due to the limitation of the TRAD tables w.r.t. to the spin parameter?
And if there is a way to circumvent this? Are there new extended tables available?

No, the TRAD tables should handle all possible spin parameters. The issue, again, is that somewhere in the star there is a critical point where omega_c -> 0; and in trying to resolve eigenfunctions through this layer, GYRE ends up using an absurd number of grid points.

I'm currently working on approaches which fix this by capping the maximum number of points GYRE uses in its spatial grid. I'll keep you posted.

cheers,

Rich

Thanks Rich for your reply.

Would you please define what exactly you mean by omega_c here?
I would like to locate this critical layer and figure out where it lies.

Thanks,
Ehsan.

ehsan wrote:Thanks Rich for your reply.

Would you please define what exactly you mean by omega_c here?
I would like to locate this critical layer and figure out where it lies.

Thanks,
Ehsan.

Hi Ehsan --

omega_c is the mode frequency in the local co-rotating frame:

omega_c = omega - m*Omega_rot

...where omega is the mode frequency in the inertial frame, Omega_rot is the rotation angular frequency, and m is the mode azimuthal order.

cheers,

Rich

Hi Rich,

Thanks for the clarification. omega_c is sometimes referred to as the cut-off frequency; so I liked to avoid a confusion here.

Regards,
Ehsan.