Version 1 (modified by 3 years ago) (diff) | ,
---|
Description of how AMV's are generated and assimilated
AMV Bufr files
There are 4 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. So,
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 |
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
Originating centre of ??? (locally derived AMV's)
ToDo
- The processing of locally generated AMV's should be done properly. Currently locally derived AMV's are assigned the same M.O.T. as JMA-supplied AMV's. In Ops_Satwind_SetObsType.f90,
CASE (OrigCtr_JMA, OrigCtr_BOM) Obs % ObsType(iob) = ObsTYPEJmawinds
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 to process locally generated AMV's differently to JMA-supplied AMV's. Then the code change can be put in the MOSRS OPS trunk.