Rotational splittings in summary files

[warrick]

If you can point me to somewhere else in the code that does such caching, I can give it a try, though I probably won't get a chance for some time still. (Computing the rotational splittings was something I had to do anyway, and I figured I could try to add it to GYRE just as much as I could set up some Python post-processing!)

Also, I don't have my heart set on a pull request—just trying to raise my coding game—so if it's too much of a faff, you can reject it and ingest my changes by hand.

[warrick]

I don't have the time to work out another pull request but I thought I should follow this up because I did hack something together to avoid recomputing the mode inertia for every point in the kernel. For simplicity, here's the link to the commit in my fork of GYRE. I just created another item which is the partial unnormalised rotation kernel, and then I multiply it by the mode inertia if the user asks for the rotation splittings.

[rhtownsend]

I don't have the time to work out another pull request but I thought I should follow this up because I did hack something together to avoid recomputing the mode inertia for every point in the kernel. For simplicity, here's the link to the commit in my fork of GYRE. I just created another item which is the partial unnormalised rotation kernel, and then I multiply it by the mode inertia if the user asks for the rotation splittings.

I think I've already resolved this problem -- the inertia calculation is now done once and cached. This change will appear in the next public release. Sorry for not telling you sooner!

[warrick]

No problem! I made that hack ages ago and I have no doubt that your solution is both more elegant and more general anyway.

[amiszuda]

Hi all.

I'm new to the GYRE tool and I was looking for the rotational splitting method since using a simple splitting formula when trying to compute (l,m)=(1,-1),(1,0),(1,1) does not work properly for me and results in code termination with:
ASSERT 'ALL(SIGN(1._WP, omega_c) == SIGN(1._WP, omega_c_prev))' failed at line 230 <gyre_r_search:check_scan>:
Transition between prograde and retrograde

Have you resolved the issue from this toppic? I can't find neither dfreq_rot nor domega_rot functions in the gyre_output.fpp

Cheers, Amadeusz

[rhtownsend]

Hi all.

I'm new to the GYRE tool and I was looking for the rotational splitting method since using a simple splitting formula when trying to compute (l,m)=(1,-1),(1,0),(1,1) does not work properly for me and results in code termination with:
ASSERT 'ALL(SIGN(1._WP, omega_c) == SIGN(1._WP, omega_c_prev))' failed at line 230 <gyre_r_search:check_scan>:
Transition between prograde and retrograde

Have you resolved the issue from this toppic? I can't find neither dfreq_rot nor domega_rot functions in the gyre_output.fpp

Cheers, Amadeusz

Hi Amadeusz --

Can you post the GYRE inlist file, plus the model file you are using? This will help to diagnose the problem.

cheers,

Rich

[amiszuda]

Hi Rich!

Thanks for Your reply. Although, this was not my major concern I think it will be useful to me if this issue is resolved You can find those files in the attachments.

Thanks!

gyre.in

(1.82 KiB) Downloaded 402 times

profile5.data.GYRE

(473.35 KiB) Downloaded 398 times

[rhtownsend]

Hi Amadeusz --

You request a frequency search spanning 0.2 -> 20 cycles per day, with 500 points. For each of these frequencies sigma, GYRE calculates the corresponding dimensionless frequency omega via

omega = SQRT(G*M/R^3) * sigma

It then calculates the dimensionless frequency in the co-rotating frame via

omega_c = omega - m*Omega_rot

where Omega_rot is the dimensionless rotation frequency of the star (calculated in a similar manner to omega).

Problems arise when omega_c changes sign somewhere in the search range; this implies that omega_c must pass through zero, and this causes a singularity in the governing pulsation equations. GYRE cannot follow such cases, and so stops with an error message (the message that you reported).

To fix, you need to adjust your frequency scan range to avoid omega_c passing through zero. If your star is uniformly rotating, one simple approach is to specify the frequency scan range in the co-rotating frame rather than the inertial frame; to do this, set the 'freq_min_frame' and 'freq_max_frame' parameters to 'COROT_I' or 'COROT_O'.

cheers,

Rich