[Science]   [BAS home]   [Met home]   [Beowulf home]   [Techdb index]	Antarctic Meteorology

Please note: the files here are from the Hadley Centre and presumably remain their intellectual property, assuming the concept applies The files are "read-only" in this place: don't try the "enter problem" etc features... it won't work.

UM System Problems

Select keyword, or page down to browse database

Known bug: do not resize page, after having selected a problem title

MODEL

OCEAN

UMUI

SCRIPTS

RECONFIGURATION

UTILITIES

GENERAL

MPP

Back to ....

Enter problem

Delete entry

Append entry

Edit entry

View problem database

MODEL

OCEAN

UMUI

SCRIPTS

RECONFIGURATION

UTILITIES

GENERAL

MPP

MODEL

Title: Fix to STASH codes (1,237), (1,238), (2,237), (2,238)

Author: Stephen Cusack

First submitted: Wed Apr 25 10:39:41 BST 2001

The STASH diagnostics (1,237), (1,238), (2,237), (2,238) are fine
 at vn5.2 if the climatological aerosol is switched on in the SW and
LW radiation panels in the UMUI, else the values are useless.

If you wish these diagnostics from a model run, then use the mod
ask1503.

______________________________________________

Title: Using tracers in a LAM configuration

Author: Stephen Cusack

First submitted: Wed Apr 25 11:06:41 BST 2001

In a LAM configuration, an advected variable must have values
outside the domain area, in the 'external halo' region. Such data
is normally taken from the LBC file, but all tracers at vn5.2 do not
have any data in the LBC file. Therefore the tracers have unset data
in the external halos, which can cause a crash in tracer advection.
A mod has been written which fixes the problem for the murk variable
in use in the operational UK mes model, called ask2503.

______________________________________________

Title: Correct non bit-reproducible u&v on pressure levels

Author: Stephen Cusack

First submitted: Fri Apr 27 10:14:48 BST 2001

The sections 15 and 30 diagnostics u and v on pressure levels were
altered at vn5.2 to do the vertical interpolation in a linear in
exner fashion. The horizontal staggering of exner w.r.t. the u and v
variables means that such diagnostics require halo data for exner.
A swapbounds must be done toensure bit-reproducible answers for these
diagnostics across different PE configurations.

______________________________________________

Title: Erroneous call to boundval

Author: Zoe Gardner

First submitted: Wed May 30 16:10:27 BST 2001

The if statement around the boundval call in atmstep allowed the 
routine to be entered in the case of a mes run that had been restarted
part way through a boundary update step.  This meant that the initial 
boundary condition values would be incremented erroneously which would
give you incorrect data on your boundaries.

Mod azg0f503.mf77 fixes this bug.

______________________________________________

Title: Extra call to inbound in the atmospheric version of the model

Author: Zoe Gardner

First submitted: Wed May 30 16:16:32 BST 2001

Inbound was being called needlessly at the end of every timestep in 
the case of the atmospheric model.  The lbc header data that is read 
in from this routine is stored in a variable at the beginning of a 
model run so calling the routine again is a waste of resources.  The 
solution is to separate inbound into an atmosphere and ocean part, 
with the ocean version still being called at the end of every timestep
but the atmospheric version only being called at the start of the 
model run.

Use azg0f503.mf77 to fix this. It only affects the mesoscale version
of the model.

______________________________________________

Title: pp header for bottom level of STASH diagnostics on theta levels

Author: Rick Rawlins

First submitted: Tue Jun 5 16:50:32 BST 2001

PP lookup items 53 and 55 (brlev and bhrlev) are wrong for the lowest 
level of diagnostics on theta levels. These items label the bottom
boundary of the layer with appropriate eta values and are only used for
post-processing applications.

At 5.2 the lowest theta level, ie with centre defined by eta_theta_levels(1)
was coded such that the bottom boundary was at eta_rho_levels(1).
For this case, as defined explicitly in the model interface to the 
physics, the bottom boundary should be the surface. 

A correction is available at arr0f503.mf77, which will be incorporated in vn5.3.

______________________________________________

Title: Fix to surface radiation error in MOSES 2.2

Author: Martin Best

First submitted: Thu Jun 7 17:04:32 BST 2001

At vn5.2, the longwave radiation at the surface is incorrectly set to net longwave radiation rather than incoming longwave radiation.
This error is corrected by the following modset:-

$UMDIR/vn5.3/mods/source/amv1503/amv1f503.mf77

______________________________________________

Title: Model crash in GWD in LAM configuration

Author: Stephen Cusack

First submitted: Thu Jun 14 12:25:49 BST 2001

If gravity wave drag is on in a limited area model, the 5.2 code
crashes because some variables interpolate from wind to pressure
points, and at the edge of the domain the field on wind points has
unset values in the external halo. The following mod fixes such a
problem:
/u/um1/vn5.3/mods/source/ask5503/ask5f503.mf77

______________________________________________

Title: Processor configuration in the mes

Author: Zoe Gardner

First submitted: Mon Jun 18 08:32:42 BST 2001

The boundary conditions are not read in properly if too many processors
are chosen in the mes combined with having a large halo size.  The 
existing checks will not catch it as the problem is with how the 
information in the lbcs is arranged and how it is accessed when the
boundaries are being set from the files.

A check has been included in mod azg1f503 which will stop the program
if an unrealistic number of processors has been chosen in either
direction and will tell you the maximum number you can use.

______________________________________________

Title: Error in treatment of 2-level convection

Author: William Ingram

First submitted: Wed Jul 11 13:24:10 BST 2001

In all versions of the convection scheme at all releases up to & 
including 5.2, BCNLV (which is supposed to indicate at each point 
if convection occurs at any level) is set at the wrong stage in the 
loop over levels, so that convection which only affects 2 levels is 
not caught.

This means that such convection misses the convection scheme's 
internal energy correction (COR_ENGY), leaving the energy 
non-conservation to be picked up by the model's overall energy 
correction (Section 14) if that is used (as usual in climate mode)
- wrong but unlikely ever to be a major problem.  Correcting it
will lose bit-comparison in principle, but this may not immediately
be seen in tests - I suspect 2-level convection is rare in most
model configurations.
If *all* convection on a particular PE is affected, though, no 
convective increments will be added in, conceivably leading to 
visibly silly answers or model failure.

Corrections will be placed at 
/u/um1/vn4.6/mods/source/awi4f406 (version 4.x)
/u/um1/vn5.3/mods/source/awi1503 (version 5.x).
For further information see William Ingram or his posting to 
met-office.um.general 11/7/01.

______________________________________________

Title: LW diagnostic (2,207) switch incorrect

Author: Rick Rawlins

First submitted: Mon Jul 16 10:26:14 BST 2001

There is an error in setting of LW diagnostic surface downward flux 
(207,2) from STASHflag. This has been incorrect since vn5.0.

The error is only triggered if diagnostic (2,207) is requested but
(2,205) is not requested, and additionally the BL scheme is not
MOSES II [ie scheme is not A03_8A]. In this case the diagnostic
calculation is not switched on internally within the LW radiation
routine - on output the diagnostic will pick up incorrect, probably
uninitialised values. Then if STASH performs arithmetic processing
rather than just direct extraction, a flop exception could occur.
There is no impact on model evolution.

A correction is at $UMDIR/vn5.3/mods/source/arr1503/arr1f503.mf77
which will be included in vn5.3.

______________________________________________

Title: Set BLEV in pp header output for special levels

Author: Rick Rawlins

First submitted: Wed Jul 25 10:04:51 BST 2001

Fields at a single or unspecified level have pp header item
BLEV explicitly set to 0. for fieldsfile ouput, but only for the 
subset with lbvc (STASHmaster record item) in 
the range 126-138. Other 'special' level fields [eg STASH
3025(bl depth),3225,3226 (10m u,v)] have BLEV set inappropriately 
to -1.0. 
grr1f503.mf77 + grr1h503.mh changes this so that the default is 0.
for all single or unspecified levels.

______________________________________________

Title: Unsafe code in hydrology diagnostics (8,223), (8,225)

Author: Rick Rawlins

First submitted: Mon Jul 30 10:07:30 BST 2001

A correction to extraction of hydrology diagnostics (8,223) and (8,225)
(deep soil moisture and temperature) needed. From UM5.0 these have been
copied over model_levels not soil levels before extraction of 
specific levels into STASH.
This error leads to uninitialised data access when either
of the 2 diagnostics are requested, but will not affect
either model or diagnostic answers. No failures have arisen from
this problem, but this is unsafe code. The correction is at
$UMDIR/vn5.3/mods/source/arr2503/arr2f503.mf77 and will be included
in UM5.3.

______________________________________________

Title: Multiple calling of convection in a timestep

Author: Stephen Cusack

First submitted: Mon Jul 30 16:08:48 BST 2001

The 5.2 code gives the user the option for multiple-calls of 
convection in a timestep. However, the code to do this is wrong in
several respects. 

Mod askaf503.mf77 corrects the known problems.

______________________________________________

Title: Error messages: ERROR EXPPXI for items 52,53

Author: Rick Rawlins

First submitted: Tue Jul 31 13:56:07 BST 2001

Error messages of the form:
 ERROR EXPPXI: INVALID row VALUE: 0
 Im_ident,Sec,Item: 1,  0,  52
 ERROR EXPPXI: INVALID row VALUE: 0
 Im_ident,Sec,Item: 1,  0,  53
will appear when vegetation code (section 19) is switched on.
The messages are harmless in this case. The 2 items,  snow-free albedo and 
deep snow albedo, are not required when the vegetation section code is 
switched on. However, for the standard case when these are required, the fields 
need to be expanded from land points in the dump to  full fields for the lower level 
physics - an unconditional check on grid type is made in ATM_STEP and this 
triggers the EXPPXI error message when the items are missing, though no 
further code is executed. 

______________________________________________

Title: Problems with 3C large-scale precipitation scheme

Author: Damian Wilson

First submitted: Fri Aug 3 10:22:29 BST 2001

The 3C large-scale precipitation scheme was included in the UM
build for the first time at 5.2. Testing revealed an interaction
between the way the fall of ice was treated in the microphysics and
the way the vertical advection of ice was performed in the dynamics.
This led to very large ice contents in regions of very strong ascent
(such as grid point storms) and failure in the microphysics. Changes
have been made to the advection in the microphysics which should avoid
the problem, and the microphysics has been made more robust. Also,
investigation revealed that some of the microphysical parameters
specified were producing inappropriate fall speeds - these have been
changed as well.

No modset is required for 3B large-scale precipitation.

Modsets to fix the above are included as part of the 3C package
of mods, which also include changes to the diagnosis of ice cloud
and iterating the melting and advection of ice.
Please see http://www-hc/~haddm/instructions5p2.html for latest advice
on which modset should be used.

______________________________________________

Title: Negative evaporation of snow falling through hot air.

Author: William Ingram

First submitted: Tue Aug 7 09:54:18 BST 2001

At temperatures above about 301K (+28'C) the evaporation of falling 
snow becomes negative, increasing rapidly with temperature - 
i.e. the layer is heated & more snow created.

This occurs with convective snow (I think all extant versions & 
releases) & large-scale snow at versions before A04_3B, i.e. 4.x
only.

The root of the problem is the familiar one that if one fits a 
polynomial to detailed calculations across some physically 
appropriate range one almost always gets silly results outside that 
range.  In this case it was a quadratic expression in temperature 
which mostly represents the temperature dependence of the diffusivity
of water vapour from -30'C to 0'C (but also includes compensation
for using actual temperature rather than wet-bulb temperature).

Since the code calculates the evaporation of snow before allowing it 
to melt, all it requires is for the temperature to drop over 28 K 
from one layer to the one above, whether because the layer is very 
thick or there is lots of convective instability.  One cannot rely
on the convection scheme to remove such large convective instability
- in a run of mine the negative evaporation dominated all other 
terms so that the overall effect of the convection scheme was to 
increase the convective instability spectacularly & make the model 
fail on the next timestep.

I will be providing modsets, awi2f503 for 5.1-5.3 & awi5f406 at 
4.0-4.5, which just set the evaporation to zero if it is negative, 
as a minimal change to stop really silly things happening.  
Presumably it would be physically more correct to use the value at 
maybe +10'C above that temperature, but that would change a lot 
more answers.
(In the other direction the code is safe though AFAIK without 
physical justification - the fit has a maximum at -50'C & the code 
uses this value below -50'C.)
I will also post to the newsgroup & keep a record on my home page.

______________________________________________

Title: Generating Lateral Boundary Conditions (LBCs)from 5.2

Author: Dave Robinson

First submitted: Fri Aug 10 18:12:40 BST 2001

Several bugs have been found in the new code for generating LBCs. A
fix modset 

~t11dr/lbc/fixes/lbcfix1.mf77

is available. This modset MUST be included in any global model
runs generating LBCs.

The following are not available from 5.2 :-
a) producing LBCs from a LAM run (work in progress)
b) include tracers in a LBC file
c) re-initialised LBC files

______________________________________________

Title: Array overwriting for certain fields when NPROCY=1

Author: Paul Burton

First submitted: Wed Oct 3 10:16:02 BST 2001

If only 1 PE is used North-South (nprocy=1), then fields with one
less V row can cause an array overwrite in the gather/scatter routines, as the global
field is sized correctly, but the communications try and send the extra row beyond
the bounds of the array.
This is corrected by gpb0f503

______________________________________________

Title: Array bound checking error messages from LAM LBC fields

Author: Paul Burton

First submitted: Wed Oct 3 10:20:51 BST 2001

User noticed array bound checking messages from some LBC type fields in a run
where they're not being used. This was because the pointers to these variables
were set at D1_SIZE+1. Not really a problem as no attempt was ever made to read/write
these variables, but the bounds checking picks it up where these variables are
passed through argument lists, ie. D1(JLBC_pointer). 
This is fixed in gpb0f503 which ensures the pointer always point to a sensible
part of D1.

______________________________________________

Title: Corrections to boundary layer code (aal1f503 in SRCE)

Author: Adrian Lock

First submitted: Wed Oct 3 15:06:05 BST 2001

Corrections to the levels used in calculation of mixing length  
and log-profile correction in the local (RI-dependent) scheme.
Correction to use *effective* roughness length in local scheme.
Correction to remove hydrostatic assumption from subroutine KMKHZ.

______________________________________________

Title: Change to formulation of RI in cloudy air

Author: Adrian Lock

First submitted: Wed Oct 3 15:07:45 BST 2001

On the C-P vertical grid RI is calculated on theta-levels. It is  
therefore now possible to calculate the static stability of 
the atmosphere (the numerator of RI) without interpolating 
cloud parameters, only the gradients of theta_l and q_t.

______________________________________________

Title: Failure in mes (flop exception in STEXTC) with diagnostics

Author: Rick Rawlins

First submitted: Wed Oct 10 10:18:07 BST 2001

Occasional mes failures (flop exception in STEXT) occur when writing out
diagnostics generated from fields with halos, ie this is only prognostics with
halos, such as u,v,w. Swapbounds code does not provide valid values for
rim boundaries (because this will overwrite lbcs for prognostics) but 
local fields in SPATIAL were not set at NSEW rim boundaries, giving
uninitialised values.

This is corrected in
$UMDIR/vn5.3/mods/source/arr9503/arr9f503.mf77 to be included in vn5.3
and has no effect on model evolution or values in output diagnostic
fields 

______________________________________________

Title: Failure in STASH_GATHER_FIELD: diagnostic sampling frequency

Author: Rick Rawlins

First submitted: Tue Oct 23 16:00:32 BST 2001

All versions of the UM up to UM5.2.

A failure can occur if sampling frequency for time profile in STASH
diagnostic is set at -1 for minimum or maximum time processing options.
This is a valid value for time accumulations (meaning indefinite end)
but can lead to a failure with minimum/maximum options:

The path of the error is as follows: 

A sampling period frequency (INTV set in STASHC file from profile settings)
set to -1 is interpreted as a negative no. of timesteps 
which is used to construct the start time for a STASH (daughter) 
instruction to place the diagnostic field (eg 1.5m T) in a dump 
location for subsequent min/max operations. 
This start time may be AFTER the start time for STASH (mother) request
to extract and output data from the dump location. 
Sizes (rowlength,etc) for the (mother) request are taken from the 
(daughter) instruction - ie from the appropriate pp lookup header. 
Since the daughter instruction had not yet been initiated, the pp 
lookup positions remain set to mdis. Hence global_N_cols_out=-32768 
instead of something sensible. 
The  GCG gathering routines then attempted to use this (negative) size
information for moving data about, and failed variously in 
STASH_GATHER_FIELD.

An explicit trap will be introduced into UM5.3. 

______________________________________________

Title: z0_tile update error

Author: Richard Betts

First submitted: Thu Mar 7 16:52:10 GMT 2002

The argument list calling VEG_CTL from ATMPHB2 contains Z0M_TILE, but
this should be Z0_TILE.  This means that when interactive vegetation
is used, Z0_TILE does not get updated and unitialised values are 
possible if tile fractions change from zero to non-zero.  This can 
cause the model to fail.

A fix (~t20bx/TRIFFID/vn5.2/mods/triffix.mf77) is being tested.

______________________________________________

Title: Corrupted LBC files from CRUNs

Author: Dave Robinson

First submitted: Fri May 24 10:44:30 BST 2002

If a CRUN is involved when generating a LBC file the the LBC file will
be corrupted. The modset

~t11dr/vn5.4/mods/gdr1f504.mf77

provides the necessary corrections.

(Same as problem 543 for 5.3)

______________________________________________

Title: LBC Files in LAM CRUNs

Author: Dave Robinson

First submitted: Fri May 24 10:48:53 BST 2002

If doing a LAM CRUN then the LBCs are read in for the wrong times 
during a CRUN. The modset

~t11dr/vn5.2/mods/mes_crun.mf77

is required whenever doing a CRUN in a LAM run. The date/times of
the LBCs are now printed out when read in during the model run.

(Same as problem 544 for 5.3)

______________________________________________

OCEAN

Title: Ocean salinity diagnostic halos

Author: R Hill

First submitted: Fri Jun 15 13:52:47 BST 2001

At 5.2, the code to update MPP halos in salinity diagnostics 
contains a bug. This means that the required halos are not updated 
as required. 

Any problem would only show up during spatial or temporal 
averaging in STASH. If a problem is present, the model would 
be expected to crash rather than produce erroneous results.
If your model runs to completion, then there is unlikely to 
be a problem. 

Reccommend inclusion of orh0f503.mf77 in all 5.2 ocean jobs
to be on the safe side.

______________________________________________

Title: Ocean only runs swapbounds problem

Author: Paul Burton

First submitted: Wed Oct 3 10:14:13 BST 2001

If an ocean only run is attempted, swapbounds may not function completely correctly 
as it can think a LAM model is being run rather than a global, due to the
fact that it's getting the LAM/global information from an atmosphere variable.
This is fixed by gpb0f503

______________________________________________

Title: Bug in ICEDRIFT cyclic conditions

Author: R. Hill

First submitted: Mon Jan 21 10:59:41 GMT 2002

Cyclic conditions on ice model related fields
incorrectly populate aice and hsnow with hice
values. This bug has been present in all um 
versions from 3.3 - 5.2.
Modset on t3ea 
~t11rh/mods/vn5.2/tech_probs/fix_icedrift.mf77
should be applied to all ice models using 
icedrift.

______________________________________________

Title: Ocean Stash Sub-areas

Author: R. Hill

First submitted: Thu Apr 11 10:27:33 BST 2002

At UM version 5.2 an attempt to extract STASH diagnostics
on a sub area will fail (the code will run, but produce 
rubbish) . This is because MPP changes
introduced at 5.1 do not account for decomp_nowrap_ocean
decomposition types (as used in STASH) when dealing
with sub-domains.

Use fix mod:
/u/m11/home/user1/t11rh/mods/vn5.3/orh1f504.mf77
This fix will be included in UM vn5.4.


Also note that at 5.2 specifying a user defined
sub area in terms of rows is incorrectly validated
in the UMUI. The UMUI wants the southern limit to be
higher than the northern limit (a hang over from pre-UM5.0 
when the atmosphere worked north-south but the ocean 
worked south-north. The ocean was regarded as "non-standard" 
so the ocean had to set things upside-down).  
Users can get round this by hand editing the DOMAIN 
profile INTH and ISTH fields in the STASHC file. 
This is fixed at 5.3.

______________________________________________

UMUI

SCRIPTS

RECONFIGURATION

Title: pp header for bottom level of dump prognostics on theta levels

Author: Paul Selwood

First submitted: Wed Jun 6 14:25:33 BST 2001

PP lookup items 53 and 55 (brlev and bhrlev) are wrong for the lowest 
level of dump prognostics on theta levels. These items label the bottom
boundary of the layer with appropriate eta values and are only used for
post-processing applications.

At 5.2 the lowest theta level, ie with centre defined by eta_theta_levels(1)
was coded such that the bottom boundary was at eta_rho_levels(1).
For this case, as defined explicitly in the model interface to the 
physics, the bottom boundary should be the surface. 

A correction is available at rps0n503.mf90, which will be incorporated in vn5.3.

This problem corresponds to problem 488 in the model for diagnostics.

______________________________________________

Title: Initialisation of tiled temperatures and snow amounts

Author: Martin Best

First submitted: Thu Jun 7 17:09:45 BST 2001

At vn5.2, the tile surface temepratures and tiled snow amounts are incorrectly set from the grid-box average values.
The tiled variables are land points only whereas the grid-box variables are full fields, but the initialisation did not use the land index.
This is corrected with the following modset:-

$UMDIR/vn5.3/mods/source/amv0503/amv0n503.mf90

______________________________________________

Title: Buffer overrun causes crash when writing fields

Author: Paul Selwood

First submitted: Thu Jun 21 11:45:50 BST 2001

The "compression buffer" compbuf in rcf_writemulti is incorrectly
sized. As such, buffer overruns can occur when writing fields.
This may crash the reconfiguration, but is not expected to 
lead to data corruption.

A fix, rps1n503.mf90 is available and recommended for all 
rebuilt reconfiguration executables.

A rebuilt executable incorporating this fix is also available
at $UMDIR/vn5.2/normal/exec/qxreconf.latest and is recommended
for jobs using packed data.

______________________________________________

Title: Wind Rotation problem in LAM->LAM reconfiguration

Author: Paul Selwood

First submitted: Wed Aug 15 17:45:28 BST 2001

When "unrotating" winds before interpolation, the reconfiguration
at 5.2 is currently doing rotation in the wrong direction. This
only affects winds, but they will be incorrect.

The mod rps2503 will fix this. It requires a new exec_xref 
which includes the deck WEQTOL1A in the reconfiguration section.
An example of such an exec_xref has been set up and can be
utilised from the UMUI, from the window

Model Selection
->Sub-Model Independent
  ->Script Inserts and Modifications

Where an environment variable, EXECXREF should be set up with
the value /u/m11/data3/t11ps/mods/5.3/exec_xref

This problem only affects LAM->LAM reconfigurations which 
perform interpolation (not the operational-trial Mes reconfiguration).

______________________________________________

Title: Problems with ill-formed input files

Author: Paul Selwood

First submitted: Tue Aug 28 10:00:38 BST 2001

The reconfiguration isn't cleanly trapping ill-formed files
on input, but may crash. This is fixed by better error-handling
in the mod rps3503. This mod is non-essential, but may be useful
for people who are using "old" ancillary files that may not yet
have been converted to the well-formed format.

______________________________________________

Title: Non-constant theta sea-points at pole.

Author: Paul Selwood

First submitted: Mon Oct 8 11:28:50 BST 2001

Polar values on sea-only theta grids should be constant.
Interpolation can mean that polar values are not constant.
These values should be averaged, but for STASH grid_code 3
(sea-only theta grid) this wasn't happening.

This could possibly cause a model failure. Fixed in mod
rps7n503.mf90

______________________________________________

Title: Land-Sea mask problems for sea-only atmosphere fields

Author: Paul Selwood

First submitted: Tue Oct 9 13:58:45 BST 2001

Sea-only atmosphere fields can suffer inconsistency between
the field's internal land/sea mask and the dump's land/sea mask.
This mostly occurs after interpolation and may lead to model 
failure. This is fixed in the mod rps8503 (spiral coastal
adjustment scheme may be beneficial also).

______________________________________________

Title: Field initialisation can try to pick up diagnostic

Author: Paul Selwood

First submitted: Thu Oct 11 15:16:52 BST 2001

When a reconfigured dump contains fields that are not present
in the input dump, and the input dump contains diagnostics with
the same stash item code (but different section) to these new
fields, the reconfiguration can confuse the diagnostic with 
the new prognostic. This will tend to lead to a reconfiguration
crash, but may (conceiveably) produce incorrect data.

A fix is available, rps9503, and is required only in the case
of new fields being initialised when diagnostics are contained in the
input dump.

______________________________________________

Title: User Prognostic initialisation from ancillary files

Author: Paul Selwood

First submitted: Tue Oct 30 17:31:00 GMT 2001

Land-only ancillary files cause a crash when used for user-prognostic
initialisation. This is because they are held on full-fields despite
having a STASH grid-code of ppx_atm_compressed. A fix is available
rpsb503.mf90 and will be included in the 5.3 build.

______________________________________________

Title: Non bit reproducability in PSTAR adjustment

Author: Paul Selwood

First submitted: Fri Jan 18 09:13:58 GMT 2002

The adjustment of PSTAR for changes in orography after 
horizontal interpolation had a method for choosing a
reference level that does not necessarily give the same 
answer on different PE configurations. It tends to only
show up when all PEs are at the South Pole however.

Mod rpsd503 fixes the problem - but changes the answers
slightly - by choosing the top boundary layer level as
the reference level

______________________________________________

Title: BLEV error

Author: Clive Jones

First submitted: Thu Mar 7 14:20:37 GMT 2002

When reconfiguring ozone from an ancillary file that is only 
on a sub-set of levels that occupy the top of the model, BLEV 
is incorrectly set to start counting from the bottom of the 
model. 

______________________________________________

UTILITIES

Title: FFREAD

Author: Clive Jones

First submitted: Thu Mar 28 11:20:44 GMT 2002

FFREAD is hardwired to only allow 10000 fields which restricts 
utilities such as qxfieldmod.  Could this limit either be 
increased or better still, the code rewritten to avoid such 
hardwiring.

______________________________________________

GENERAL

MPP

Title: GCOM error in broadcast routines

Author: Paul Burton

First submitted: Wed Aug 29 11:12:54 BST 2001

While testing the latest version of GCOM (SHMEM flavour) for the benchmarking exercise, it has come to light that GCOM
contains a potentially serious error in the broadcast routines:
GC_IBCAST,GC_RBCAST,GCG_IBCAST,GCG_RBCAST.
If large data is used (size > 65536) the broadcast routines could potentially leave
incorrect data in the receiving processor's arrays. This is due to a missing synchronisation in the code, 
and as is typical with this kind of error, is inherently non-reproducible and quite possible has
never actually caused a real problem.

This problem has been present ever since the start of the MPP version of the UM (ie. 4.x + 5.x), but only in the SHMEM version 
(which is the default version that probably everyone uses)

The latest version of GCOM - gcom2.7 has this error fixed. The library is available at:
$UMDIR/gcom/gcom2.7/lib/libgcom_shmem-2.7.a

Appended Title: More details...

Appending Author: Paul Burton

Append submitted: Wed Aug 29 11:28:48 BST 2001

Should have added that the UM doesn't generally do many big data broadcasts. 
Also, although the bug looks like it exists in the GC_I/RBCAST routines, it's only
ever been observed in the GCG variants of the routines. UM 4.x doesn't appear
to have any GCG_I/RBCAST routines with data size > 65536, so I think probably should be OK.

5.2 however contains a number of GCG_I/RBCAST calls, where it's difficult to determine
the likely size of data just looking at the code. I would recommend that 5.x users
run with the new GCOM library.

______________________________________________

Title: Swapbounds error

Author: Zoe Gardner

First submitted: Mon Sep 17 16:26:21 BST 2001

At 5.2 a bug was introduced into swapbounds that meant the external 
halo region in the north and south of a mes model was being overwritten
by data in the internal mes domain.  Mod gzg1f503.mf77 corrects this 
and should be used in all mes runs.

______________________________________________

Title: Portable swapbounds floating point failure

Author: Paul Burton

First submitted: Wed Oct 3 10:18:28 BST 2001

If the 2A (portable) version of SWAPBOUNDS is used, a floating point error will occur when
non-REAL data is passed, due to it trying to multiply polar rows by +/-1 to ensure
the correct sign. 
This is corrected by gpb0f503 which only performs the multipy by -1 when a sign
change is explicitly requested, which should only be the case for REAL data.
This problem doesn NOT occur in the T3E (2B) version of SWAPBOUNDS which is what
all users at UKMO probably use.

______________________________________________