Opened 12 years ago

Closed 12 years ago

#104 closed help (fixed)

Error in Replanca routine

Reported by: jeff Owned by: jeff
Component: UM Model Keywords:
Cc: Platform:
UM Version:

Description

UM error message

 REPLANCA: UPDATE REQUIRED FOR FIELD 70
  REPLANCA - time interpolation for field  70
  time,time1,time2  2940.00000000000000 -5832.00000000000000 2928.00000000000000
  hours,int,period  -1 12 12
  Information used in checking ancillary data set: position of lookup table in dataset: 141
  Position of first lookup table referring to data type  1
  Interval between lookup tables referring to data type  1  Number of steps 140
  STASH code in dataset  129   STASH code requested  129
 'Start' position of lookup tables for dataset in overall lookup array  10995
  Information used in interpolation/replacement:
  Time of first data= -5832.00000000000000
  Validity Time for update= 2940.00000000000000
  Time of second data= 2928.00000000000000
  UP_ANCIL : Error in REPLANCA.

The ancillary file is "Elevated fresh soot aerosol emission" and is a time series of annual means. The ancillary file uses a 360 day calendar but is being forced to work in a Gregorian calendar run. The run uses the AMIPII method of updating sea-ice.

The error message is the same as the one you get when your model run date exceeds the date stored in the ancillary file time series, but this was not the case here.

Attachments (1)

bugfix_rpanca1a_2.mf77 (788 bytes) - added by jeff 12 years ago.
mod to fix described problem (only use if you know what your doing)

Download all attachments as: .zip

Change History (2)

Changed 12 years ago by jeff

mod to fix described problem (only use if you know what your doing)

comment:1 Changed 12 years ago by jeff

  • Resolution set to fixed
  • Status changed from new to closed

The UM code which does the updating of the ancillary files (REPLANCA) is very
hard to understand, it basically needs rewriting and rethinking. The UM stores
time information about the data in 2 places the fixed length header and in the
pp headers. The UM usually uses the fixed length header information when
updating ancillaries, but it can use the pp header in certain circumstances. If
you are using the AMIP2 method of updating sea-ice (set in the umui), are using
the Gregorian calendar and the data interval in the ancillary file is in months
or years (years only for non-periodic data), then you will use the pp headers.
The pp headers are used because the fixed length headers cannot handle a
variable number of days per month correctly, hence why 360 day calendars don't
need to use them. The method of updating sea-ice has nothing to do with the
method of time interpolation and it should really be possible to do one without
the other.

Your problem is because the different header values disagree about the time
information for the soot ancillary. The date of the first field is 1850/7/1
according to the fixed length header and 1850/1/1 according to the pp header. As
the data is in fact an annual mean and the date should be for the midpoint of
the meaning period then the fixed length header is correct and the pp header
wrong. In fact the pp header is correct as well because there are 2 dates and
the second one is 1851/1/1 and another header variable says the field is a time
mean between these 2 dates. But the code in REPLANCA only uses the first date in
the pp header and so gets it wrong in this case. There is nothing wrong with the
ancillary file because it is meant to be used for a 360 day calendar run which
won't use the pp header, but you are forcing it to be used in a Gregorian
calendar run which is why it causes problems. Up to the point the model crashed
you where basically running with the annual mean being from July-July and hence
the time interpolation being wrong, this may not matter too much for annual means.

The reason the model crashed is because the code which uses the pp headers isn't
consistent and uses some fixed length header date values as well. Because of the
header mismatch this caused some of the date calculations to go wrong and crash
the model. I can see how to fix this problem and this will allow your run to
continue, but with the annual mean problem. If you wanted to fix this as well I
think the best thing to do would be to have a separate switch for selecting pp
headers/fixed length headers (instead of using LAMIPII), then you can just use the fixed length header. This would mean small errors with monthly mean ancillary data but this is what happens with non-amip2 sea-ice, Gregorian calendar runs anyway.

Note: See TracTickets for help on using tickets.