Version 7 (modified by Jin Lee, 3 years ago) (diff)


AMV Bufr files and OPS processing of AMV's

AMV Bufr files

For each assimilation cycle there are 4 separate Bufr files which contain AMV's: e.g. for the assimilation basetime of 20150901 00Z,


The numbers refer to originating centres. Here's a description of what Bufr files contain:

Bufr file originating centre satellite platforms notes
amv160 NESDIS GOES-E, GOES-W, Aqua/MODIS, locally generated AMV's from MTSAT-2 The originating centre for the loally generated AMV's from MTSAT-1R, MTSAT-2 and Himawari-8 is ???.

Note also that the expected error values are converted to QI values to allow OPS to process them as if they are JMA-supplied winds.

Q. Is Himawari-8 given the satellite ID of 173 in the Bufr file?
amv254 EUMETSAT Operation Centre METEOSAT First Generation: METEOSAT-7
amv254msg EUMETSAT Operation Centre METEOSAT Second Generation: METEOSAT-8, -9, -10
amv34 JMA MTSAT-2 (and Himawari-8????)

Note 1. AMV's from Himawari-8 were not assimilated for the trial period (Q. even JMA-generated AMS's?)

How Ops_ExtractAndProcess processes AMV's

In the OPS code in the trunk, the locally derived AMV's which have originating centre of ??? are assigned the same M.O.T. as JMA-supplied AMV's. This sleight of hand is done in Ops_Satwind_SetObsType.f90,

 CASE (OrigCtr_JMA, OrigCtr_BOM)
   Obs % ObsType(iob) = ObsTYPEJmawinds


  1. The processing of locally generated AMV's should be done properly.
    1. Currently locally derived AMV's are assigned the same M.O.T. as JMA-supplied AMV's (see under How Ops_ExtractAndProcess processes AMV's).
    2. UKMO agreed that Bureau can use M.O.T. of 235?? to assign to locally generated AMV's. We should use this and modify OPS code so that Ops_ExtractAndProcess processes the locally generated AMV's differently to JMA-supplied AMV's.
    3. The code change then should be put in the MOSRS OPS trunk.