Internal scenarios, limiters, shortcomings and coding bugs

Sometimes the user input to SWAN is such that SWAN produces unreliable and sometimes even unrealistic results. This may be the case if the bathymetry or the wave field is not well resolved. Be aware here that the grid on which the computations are performed interpolates from the grids on which the input is provided; different resolutions for these grids (which are allowed) can therefore create unexpected interpolation patterns on the computational grid. In such cases SWAN may invoke some internal scenarios or limiters instead of terminating the computations. The reasons for this model policy is that

• SWAN needs to be robust, and
• the problem may be only very local, or
• the problem needs to be fully computed before it can be diagnosed.

Examples are:

• The user can request that refraction over one spatial grid step is limited to at most the length of a directional sector associated with one sweep (which in the absence of a current is 90$^o$). See command NUMERIC. This may be relevant when the depth varies considerably over one spatial grid step (e.g. at the edge of oceans or near oceanic islands with only one or two grid steps to go from oceanic depths to a shallow coast). This implies inaccurate refraction computations in such grid steps. This may be acceptable when refraction has only local effects that can be ignored but, depending on the topography, the inaccurately computed effects may radiate far into the computational area.
• SWAN cannot handle wave propagation on super-critical current flow. If such flow is encountered during SWAN computations, the current is locally reduced to sub-critical flow.
• If the water depth is less than some user-provided limit, the depth is set at that limit (default is 0.05 m, see command SET).
• The user-imposed wave boundary conditions may not be reproduced by SWAN, as SWAN replaces the imposed waves at the boundaries that propagate into the computational area with the computed waves that move out of the computational area at the boundaries.
• SWAN may have convergence problems. There are three iteration processes in SWAN:
  1. an iteration process for the spatial propagation of the waves,
  2. if ambient currents are present, an iteration process for spectral propagation (current-induced refraction and frequency shift) and
  3. if wave-induced set-up is requested by the user, an iteration process for solving the set-up equation.

  ad 1	For spatial propagation the change of the wave field over one iteration is limited to some realistic value (usually several iterations for stationary conditions or one iteration or upgrade per time step for nonstationary conditions; see command NUMERIC). This is a common problem for all third-generation wave models (such as WAM, WAVEWATCH III and also SWAN). It does not seem to affect the result seriously in many cases but sometimes SWAN fails to converge properly. For curvilinear grids, convergence problems may occur locally where in some points in the grid, the directions separating the 4 sweeping quadrants coincide with the given spectral directions.
  ad 2	For spectral propagation (but only current-induced refraction and frequency shift) SWAN may also not converge.
  ad 3	For the wave-induced set-up SWAN may also not converge.

  Information on the actual convergence of a particular SWAN run is provided in the PRINT file.

Some other problems which the SWAN user may encounter are due to more fundamental shortcomings of SWAN (which may or may not be typical for third-generation wave models) and unintentional coding bugs.


Because of the issues described above, the results may look realistic, but they may (locally) not be accurate. Any change in these scenarios, limiters or shortcomings, in particular newly discovered coding bugs and their fixes, are published on the SWAN web site and implemented in new releases of SWAN.