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
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
where \(C_{\rm t}\) is a constant.