Use of ground based GNSS data in NWP at Météo-France

Use of ground based GNSS datain NWP at Météo-France

Patrick Moll1 , Paul Poli2 and Véronique Ducrocq1

1 Centre National de Recherches Météorologiques CNRS/GAME, Toulouse, France

2 ECMWF, Reading, UK

E-GVAP workshop Copenhagen, 6 nov. 2008

2

Outline

1. Status of ground-based GPS ZTD assimilation at Météo-France

3. Implementation method of ground based GPS ZTD

5. Monitoring and use of ground based GPS ZTD

7. Impact of the ground based GPS ZTD in the operational models

9. Conclusion

1. Status of ground-based GPS ZTD in the assimilation systems at Météo-France


4

The operational assimilations at Météo-France

ARPEGE

ALADIN

Global model and 4DVAR assimilation system ARPEGE– Vertical: 60 levels, model top at 0.1 hPa (~65 km altitude)– Horizontal: T538, stretched model: highest horizontal resolution over France (~15 km)– 4DVAR assimilation (non-stretched) with two minimizations: T107 / T224– Analysis horizontal resolution is about 90 km (globally)– Assimilates European GPS ZTD data since 19 September 2006– Note: there are still operational runs of our non-stretched global model

European limited-ared model and 3DVAR assimilation system ALADIN

– Horizontal resolution 9.5 km, same vertical levels as ARPEGE– 3DVAR assimilation with 1 minimization at full resolution (6h period)– One version running over France– Assimilates European GPS ZTD data since 19 September 2006– Other versions running for La Réunion Island (Eastern Indian Ocean) and specific areas of interest : do not assimilate any GPS ZTD data

High-resolution mesoscale non-hydrostatic model with a 3DVAR assimilation system AROME over France

– Horizontal resolution 2.5 km, 41 levels– 3DVAR assimilation with 1 minimization at full resolution (3h period)– Assimilates European GPS ZTD data over France since 22 April 2008

AROME

2. Implementation method of ground-based GPS ZTD


6

The specificity of E-GVAP ZTD data

E-GVAP ZTD data are a special kind of meteorological data :– Processing upgrades, network expansion, new analysis centers…

• List of station identifiers (STATCENT) evolves in time• Global improvement of the quantity and quality of data, but still sudden modifications

Objectives :1. Be able to use GPS ZTD data operationally2. Be able to monitor the improvements in GPS ZTD data

Corresponding requirements– Objective 1: approximately stable data quality and quantity (we cannot assimilate data

whose data quality and quantity evolve too much in time)– Objective 2: acceptance by the screening phase of ALL ZTD data arriving to us (we want to

monitor all the data in order to build up statistics and follow evolutions)

Problem:– Objectives 1 and 2 are not easy to reconcile…


7

Usual data filtering solutions at MF

« Black list method »– Default behaviour is that all data are active, that is, intended for assimilation– Black list:

• Filter that makes data originating from suspicious sites/sources passive– Typically used for

• Radiosonde data• Ground data• Satellite remote sensing channels/frequencies which we cannot model properly

– Problem with that method• Only works if one knows the complete list of data providers beforehand

Because of the increasing number of sites, GPS ZTD data required a different approach

« White list method »– Default behaviour is that all data are passive, that is, excluded from assimilation– White list:

• Filter that makes data originating only from trusted sites active– First and only application so far : GPS ZTD– We have to upgrade this white list regularly


8

Selection rules for European ZTD

Station location– Station is located in, or close to, Europe (i.e. no isolated stations outside Europe)– Station altitude is below xx meters altitude, within yy meters of the model orography– Next closest station is located more than zz km away, and station coordinates do not change over time

Quantity– Data from the station are present more than 50% of the time

Quality– Observation minus background departures for the station are gaussian with a χ2-test

• Parameters: threshold: 0.1%; nbins=70, or less if ndata in any bin < 10

– Absolute bias must be less than 20 mm and stdev less than 30 mm

Timeseries considered to carry out this selection– At least 10 days long– Must contain different weather types, ideally a combination of dry and wet events– Avoid really wet events because our models are not such good references then

Notes:– Thresholds xx, yy, zz are model-dependent– For the 4DVAR assimilation, we exclude data at 60 minute freq. (not sure of the exact time of these

data)– If there are several analysis centers meeting all the criteria for a given station:

• Retain the one for which observation minus background standard deviation is the smallest, if the difference is more than 0.2 mm with the other centers, otherwise:

• Retain the one for which max (observation minus background standard) minus min (observation minus background standard) per period is smallest, if the difference is more than 5 mm with the other centers, otherwise: (last resort)

• Retain the one which presents the most stable bias (smallest stdev of the mean as calculated per period)


9

Monitoring of stations solutions over ~FranceExample: standard deviations


10

Analysis/production data flow

GPS stations

Analysis centres(SGN, METO, GFZ, …)

GTSRaw data bufr


11

GPS ZTD data flow at Météo-France

« Active » observations « Passive » observations

Observations

Observation Database

GTS

ASSIMILATION

Background: forecast

Obs. Extraction

MONITORING ONLY

GPS ZTD Pre-processing

Screening (compare obs with background)

3. Monitoring and use of ground-based GPS ZTD


13

Monitoring example (time-series)

DPREVI/COMPAS


14


DPREVI/COMPAS


15


DPREVI/COMPAS


16

Monitoring example (problem detection)

DPREVI/COMPAS


17

The EGVAP monitoring

Europe SGN


18

The EGVAP monitoring


19

Global minimisation of a cost function:

J(X) = Jo(X) + Jb(X)

The “problem” of cut off in the 4DVAR

21h 00h 03h

Jb

Jo

Jo

Jo

obs

obs

obs

analysis

xa

xb

guess

Short cut off


20

Current operational selection list for ARPEGE [global model with analysis at 90 km resolution]

58 stations, station inter-distance : 100 km


21

Example of data usage (ARPEGE)

ARPEGE at 00H

(6h period, long cut-off)


22


ARPEGE at 00H

(6h period, short cut-off)


23

Current operational selection list for ALADIN[9.5 km resolution model over Europe]



24

Example of data usage (ALADIN)

ALADIN at 00H

(6h period)

169


25

Current operational selection list for AROME [2.5 km resolution model over France]



26

Example of data usage (AROME)

AROME at 00H

(3h period)

4. Impact of the ground-based GPS ZTD in the operational models


28

Relative weight of GPS ZTD data in our assimilation system

Data assimilation system:– A competitive environment– Not all data are equal– Unfair competition: we attribute the

weights -- not [yet] an automatic and dynamic process

Periodically evaluate the Degrees of Freedom for Signal (DFS)

Methodology:– Generate perturbed observations– Assimilate these observations– Compare the analysis with that

obtained with un-perturbed observations; in observation space

– Difference indication of how much each data influences the analysis

Weather stations, buoys, …

Commer-cial

aircraft

Upper-air in situ and

remote obs.

Cloud-track and

water vapor

tracking imagery, scattero-meters

Passive IR and MW

radiancesBending angles

Hyper-spectral infrared (AIRS &

IASI)

ARPEGE

GPS ZTD : 0.0830


29

Impact on AROME forecast (OSE experiment)

Cumulated rainfall between 03UTC and 15UTC, 19 july 2008

WITHOUT ZTD dataassimilation

AROME, 15h forecast starting from the 00UTC analysis, 19 july 2008

WITH ZTD dataassimilation

Observations

5. Conclusions


31

ConclusionsGPS ZTD operational assimilation

– Started at Météo-France more than 2 years ago– Initially in global and European models– Now in operational mesoscale AROME model

Methodology– Chose a « white list » approach to accomodate expanding/improving

networks/methods

All GPS-related problems were solved rapidly by E-GVAP

Importance of quality and short delays of arrival of the data

Very good impact on our high resolution Limited area models (ALADIN and AROME)

Very good job done by E-GVAP team. To reinforce operational robustness, act perhaps towards :

– Either a centralized BUFR encoder, with operational status– Or distributed BUFR encoders

Thank you for your attention

[email protected]

EGVAP 3rd User MeetingE-GVAP workshop

6-7 May 2008, GFZ PotsdamCopenhagen, 6 nov. 2008

33

Nz dz dz

ne utral part o f the atm osphe re

wate r vapour s pe c ific part

The zenital delays : ZTD, ZHD, ZWD

fonction de projection

ZTD

ajustement d’un délaireprésentatif au zénith

v

’


34

Impact sur la prévision AROME

Précipitations cumuléesentre 03UTC et 15UTC,19 juillet 2008

sans assimilation de données de ZTD

AROME, initialisé à partir de l’analyse 00UTC, 19 juillet 2008

avec assimilation de données de ZTD

Observations

Equitable Threat Score

Plu

s pr

oche

des

obs

erva

tions


35

Operational aspects: experience feed-back (1/2)

List of events: (problems that we reported to EGVAP)

– Sept 2006: data from stations processed by analysis center MIS (missing) instead of KNMI

– Jan 2007: no data following faulty UPS replacement for BUFR encoder server

– Mar 2007: data with missing lat/lon from KNMI Operational model crash

– Apr 2007: data flowing from an un-announced center, NGAA– Apr 2007: no data because of a frozen job on BUFR encoder server– Feb 2008: no data except for METO because of an OS upgrade on

BUFR encoder server– Mar 2008: no data from METO, no data from GFZ, large errors with

SGN solutions -- 3 non-related problems


36

Operational aspects: experience feed-back (2/2)

Conclusions– Only one crash because of missing lat/lon coordinates: failure of our database QC

which should have caught that problem– Most, if not all, events were resolved the same day the problems were reported, or

sometimes had already been resolved by the time we reported them– Overall: quick turnaround for problem solving

Elements for discussion:– Most visible point of failure from my POV: single point-of-entry for GTS data:

• One BUFR encoder, apparently not doubled– Suggested way forward: each NMS implement and run the BUFR encoder courtesy of

the MetOffice (part of GRAS-SAF ROPP?)• Advantage: Reduces to near-zero the possibility that all BUFR encoders fail simultaneously• Disadvantage: Risk of implementing several encoders: increase likelihood of bad practices

and faulty data flowing on the GTS

– Ideally: as a user, I would prefer to continue with one single point of contact for all data … rather than several …


37

GPS ZTD Pre-processing

Pre-processing input:

GPS ZTD dataSelection list (white list)

Pre-processing steps:

6. Selection of the observations coming from stations in the mapCheck all values within physical rangeVerify that latitude, longitude, altitude, time significance have not changed (*)

7. Time thinning:In 4DVAR : average observations by time-slot (30 minutes or 1 hour)In 3DVAR : retain only the ‘most central’ obs (closest to analysis time)

8. Observation minus background bias correction

9. Observation standard deviation error assignment


38


ARPEGE at 00H

(6h period, very short cut-off)


39

A typical distribution of GPS data in AROME


40

Documents

Use of ground based GNSS data in NWP at Météo-France