# 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.