wiki:ticket/261/TicketSummary/DescriptionAmv

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-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 trunk code of OPS30.0.0, the locally derived AMV's which have originating centre of 'OrigCtr_BOM' (=1) are assigned the same M.O.T. as JMA-supplied AMV's. This sleight of hand is done in 'OpsMod_Process/Ops_SetObsType.f90',

      CASE (OrigCtr_JMA, OrigCtr_BOM)
        ObsType = ObsTYPEJmawinds

However, the locally modified OPS source that BNOC uses is (ToDo to be confirmed by Ivor),

https://access-svn.nci.org.au/trac/ops/log/branches/local/ops30.0.0

and the corresponding lines have been changed to,

      CASE (OrigCtr_NESDIS, OrigCtr_CIMSS, OrigCtr_BOM)
        ObsType = ObsTYPEGoesbufr

Consequently in the BNOC observation coverage plot,

http://webnm.bom.gov.au/cgi-bin/nm/access/obs_coverage.pl

for the global the blue is GOES. There are some blue dots near Australian region, which are in fact our locally derived AMV's. These are surrounded by red dots which are JMA-produced AMV's

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) (This may not be the case - it's possible locally derived AMV's are given M.O.T. of GOESBUFRIR (01) (22501)???? See ngamai03:/g/sc/ophome/ashare/APS2/OPS/control/StationLists/ATMOS/gl/v406/Satwind_stlist.nl, under 'LOCAL WINDS').
    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.
Last modified 3 years ago Last modified on Mar 7, 2016 12:13:42 PM