> Andrew Gregory at Reading University has noticed a bug present at 4.5 &
       > all preceding releases in the UM's Fourier filtering code.
       > 
       > The New Dynamics' filtering seems completely different & so I assume must
       > be unaffected, & though I believe the ocean model has some Fourier
       > filtering, presumably that is Cox code & so unaffected.
       > 
       > The bug makes the Fourier filtering 4 times too strong, which can cause
       > instability at the latitude where filtering starts for a particular
       > wavenumber. It has also allowed the use of what with hindsight seem very
       > low values of the "filtering safety multiplying factor" (set in the umui:
       > Model Selection -> Atmosphere -> Scientific Parameters and Sections ->
       > Section by section choices -> Diffusion and Filtering), so with corrected
       > code expect to need larger filtering safety factors - 0.3 might be a good
       > starting point, but the best choice may depend on resolution, timestep, &c.
       > 
       > Of course if you are running parallel to a standard experiment you
       > shouldn't correct such errors.
       > 
       > Details for those who want them:
       > 
       > Physically one can think of the potential numerical instability as
       > being due to using a timestep too long for the gridlength & windspeed
       > - if the wind will blow all the way from one grid-point to the next in
       > a timestep then the advection scheme's way of altering the numbers to
       > allow for a bit of the next grid-point's numbers blowing in doesn't
       > make physical or numerical sense, & some components will grow
       > exponentially. We want the convenience of a regular lat/long grid,
       > where the points get very close E-W at high latitudes, without the
       > expense of a really short timestep, & so have to remove or damp the
       > components which are unstable on each row (which depends on the
       > geometry & the maximum wind on that row), effectively reducing the
       > model resolution at high latitudes. Removing them entirely (Fourier
       > chopping) creates inconsistencies between dynamics and physics, &
       > discontinuities between one row & the next, both of which can give
       > instabilities, so we damp them.
       > Actually it's more complex than that because as well as the advection
       > the adjustment can cause such an instability, similar but based on
       > the speed of sound rather than the wind, & this actually dominates
       > over most of the model normally.
       > 
       > The error's quite obvious if one checks the code.
       > This works on data transformed to Fourier components, multiplying
       > each one that is unstable according to the CFL criterion by a damping
       > factor which should be the square of the ratio of the highest
       > wavenumber stable on that row to the wavenumber of the component
       > concerned (UMDP 10, section 3.5). Because there are 2 components per
       > wavenumber, the loop index needs to be halved to give the denominator
       > of this ratio - but the code was originally written (FILTER1A.159 &
       > FILTER1A.172) to halve the numerator too, which makes no sense, & this
       > was of course preserved under computational optimization at 4.4 & 4.5.
       > 
       > Thus a marginally unstable wave which should have its size multiplied
       > by a number just under 1 gets a factor just under 0.25 instead,
       > creating a discontinuity with the row immediately equatorwards where
       > no damping will be applied to it. I suspect this may account for at
       > least some of the operational cases (all since the last increase in
       > resolution?) of a strip of noise running EW that were suspected of
       > being related to the limit of filtering - it certainly makes much
       > more sense of such a link.
       > 
       > Andrew notes that the UM's standard 4th order advection is unstable
       > rather sooner than the CFL criterion implies. This presumably means
       > we are relying on the diffusion to take over the filtering's job just
       > outside the limit of filtering, suggesting the filtering ought to be
       > more active where advective instability is a potential issue. In
       > fact the "filtering safety multiplying factor" allows one to do this
       > with no effect away from the jets (at least for standard settings),
       > though it seems to have been intended only to allow for the windspeed
       > increasing between calls to the routine that re-sets what filtering
       > to do (you can choose not to do this every timestep, but just repeat
       > the same filtering for a while). With hindsight this assumption that
       > linear stability theory is always good enough seems rather naive -
       > but it would have appeared to fit the facts if one assumed the
       > filtering code was correct.
       > (BTW, the "filtering safety multiplying factor" is *added* to another
       > term of order one and the advection CFL number *multiplied* by the
       > result.)
       > 
       > In my runs (HadAM3-like but with tracer advection of heat & moisture) a
       > value of 0.33 seems enough to keep all noise out, while 0.25 allows
       > substantial noise around the S polar jet in October in level 18, but it
       > does not spread, cause failure, or last into November. The standard
       > value in climate runs, where we do re-set what filtering to do every
       > timestep, is 0.01.
       > A proper re-tuning should of course involve the diffusion as well.
       > 
       > I can't say what effect the correction & the increase in safety factor
       > have on climatology - ideally & plausibly none, but I could also imagine
       > a significant impact on vertical velocity around the jet stream, & so on
       > moisture / radiation / position of the jet stream & storm track.
       > 
       > William Ingram
       > 
       > wjingram@meto.gov.uk