Several users have now started using the 64 level version UM for various experiments. This version of the model has been designed and set up by Jeff Cole.This document is a set of notes to help users of this version share information.
Users are now able to run the 64 level UM vn 4.5 on Green, the SGI O3000.
Modsets
Modsets are available on Turing, the CSAR T3E, for use with the 64 level version in ~lrjwc/um/mods/vn4.4/mods.
src_car_l64
Cariolle Ozone scheme written by Peter Braesicke, Cambridge. The Cariolle parameters are read in from a file on channel 55 which is hardwired in the code/ehome/lrjwc/um/strat/cariolle/car_par_new_l64.dat
h2ochem2_v1
A simple CH4/H2O chemistry scheme written by Ian Mackenzie, Edinburgh. The methox constants are read in from files hardwired in the code. In the scheme it is assumed that H2O is formed from the reaction CH4 -> H2O with a rate coefficient K read from the table/ehome/lrjwc/um/strat/methox/kh2o.dat
and the O2 slant columns are in
/ehome/lrjwc/um/strat/methox/slantp02.dat
esrad_update_wz.mod
This is a modset for the Edwards/Slingo radiation code written by Wenyi Zhong, Imperial College London, to improve the scheme above 0.1 mbar.
qbo_update_4.4
This modset allows the use of the QBO u ancillary file. You also need to include the modset for the reconfiguration qbo_recon_update_4.4 and you need to include the QBO ancillary file qbo_u_q_l64_2, which can be obtained from jeff/lois@met.rdg.ac.uk together with the ancillary pre-STASH master file uqbouserancil. You will need to initialise from a single time field in a named file, qbo_alpha_l64.There are other modsets which should be included
incr_lev_mod
To increase the hard coded minimum level values.
gsdev44_l64_4
To use Rayleigh friction in the upper layers in conjunction with version 3A of the gravity wave drag scheme.
filter44
To maintain numerical stability at higher latitudes where the CFL criterion is violated the Um uses fourier filtering. This modset fixes a bug that makes the UM fourier filtering 4 times too strong.> 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
Scripts to be used after UMUI processing
These are simple scripts which need to be run after the processing by the UMUI before the scripts are ftped to the Cray T3E. These scripts change namelists and possibly other parts of the scripts which can't easily be changed via the UMUI. The scripts are available from Reading contact jeff/lois@met.rdg.ac.uk if you need to access them.mkqrad_44
If you are using the modset from ~lrum/vn4.4/mods/AMIPII/qrad_update_4.4 then this script needs to be run to reset namelist switches.
mkuqbo
This script switches on the QBO modset described above.