Long Runtimes

gyre

Long runtimes with the gyre frontend occur when the spatial grid and/or frequency grid contain many points. The execution time to process a single &mode namelist group can be approximated by

\[\tau \approx C_{\rm b} N M + C_{\rm s} N N_{\rm m},\]

where \(N\) is the number of spatial points, \(M\) is the number of frequency points, \(N_{\rm m}\) is the number of modes found, and \(C_{\rm b}\) and \(C_{\rm s}\) are constants. The first (\(C_{\rm b}\)) term represents the time take to bracket roots of the discriminant function, and the second (\(C_{\rm s}\)) the time taken to solve for these roots (see the Numerical Methods chapter for details).

The key to ensuring reasonable runtimes lies in judicious choice of parameters in the &scan namelist group(s). The n_freq parameter obviously has an impact on \(\tau\), as it directly sets \(M\). However, the freq_min and freq_max parameters also influence \(\tau\), due to the way the spatial grid is constructed. If the frequency scan includes parts of the star’s oscillation spectrum containing modes with very large radial orders (whether p modes or g modes), then GYRE’s iterative refinement algorithm will insert many grid points in order to resolve the modes’ wavefunctions. This can ultimately lead to huge \(N\) and very long runtimes.

gyre_tides

The narrative is similar with the gyre_tides frontend, although there are no frequency grids involved. The execution time to process a single &orbit namelist group can be approximated by

\[\tau \approx C_{\rm t} N\]

where \(C_{\rm t}\) is a constant.