wiki:ticket/261/TicketSummary/DescriptionAmv

Version 4 (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,

amv160.2015083121.bufr
amv254.2015083121.bufr
amv254msg.2015083121.bufr
amv34.2015083121.bufr

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-1R, MTSAT-2 and Himawari-8 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 contains METEOSAT First Generation
amv254msg EUMETSAT Operation Centre contains METEOSAT Second Generation)
amv34 JMA MTSAT-1R, MTSAT-2 and Himawari-8

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

ToDo

  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.