Based on various questions from NWP users, here are some answers to FAQ regarding the Aeolus L2B BUFR format and its use:
- Why are there extra unexpanded descriptors in the Aeolus BUFR files compared to the WMO BUFR template?
These changes are some modifications to the original published template. We found that the WMO approved template cannot store the satellite range for Aeolus because the decision was taken to go for a lower orbit (this happened after we designed the template). The 20xxxx descriptors modify the number of bits and the scaling so the numbers fit again. The only thing you need to do is allow the changed number of unexpanded descriptors in your code (63 in stead of 51). Actually, after expansion, the number of descriptors will be identical to the original template, i.e. it will be reduced to 51. You should not need any changed BUFR tables at all, since this is part of the official BUFR file format itself.
You should also know that we plan 2 more updates with the same method in our upcoming software version (to be released at roughly 3-4 months after launch, at the end of the Commissioning Phase). In that copy we will also modify the derivatives (dhlos_dT and dhlos_dp) for the Rayleigh channel (so adding another 8 20xxxx descriptors).
Since getting formal registration by WMO is a very lengthy process, and we may need other modifications that we do not yet foresee, we decided to not request any changes with WMO for the time being.
- Is there a description or interpretation of the L2B BUFR variables for use in NWP?
- There is not yet available yet a nice description for users of the meaning/interpretation of the data in the L2B BUFR files (this page attempts to provide some guidance). There is the BUFR template document which gives some idea: AE-TN-ECMWF-L2BP_0073-L2B_BUFR_template.pdf, which is part of the L2B processor documentation download.
- Some basic advice:
- The Aeolus L2B observations are provided as individual wind observations, each with a geolocation (not a profile with one geolocation).
- L2B HLOS winds are classified into different types e.g. Rayleigh-clear, Rayleigh-cloudy, Mie-clear and Mie-cloudy. This is given by the combination of "receiverChannel" and "lidarL2bClassificationType".
- The geolocation of the HLOS winds needed for an observation operator is described by the: "latitude", "longitude", "timeIncrement" (relative to the time given at the start of each message), "height" (altitude relative to geoid) and laser pointing information ("bearingOrAzimuth" and "elevation").
- For a basic "point-like" wind observation operator we recommend using the "coordinatesSignificance" values appropriate for the vertical and horizontal centre-of-gravity of the observation. There is also geolocation information for start/end of the range-bin (horizontally) and top/bottom of the range-bin (vertically) in case people which to do an averaging-type observation operator rather than point-like winds.
- What is the vertical geolocation for the HLOS wind observation?
- The true vertical geolocation information for Aeolus is the geometric height (relative to the geoid) of the lidar range-bin i.e. descriptor 0 07 071 Height (high resolution), for the Vertical Centre of Gravity of the observation. There is also height for the top and bottom of the range-bin, if one likes to consider a more complex "vertical averaging" observation operator.
- That geometric height should be converted to an appropriate geolocation variable for assimilation in your model. Some models are fundamentally using pressure as the vertical reference e.g. the ECMWF IFS model. Hence in our own assimilation code we convert the geometric height to geopotential, and then a standard routine obtained a pressure from the geopotential (using the background forecast) as part of the ECMWF IFS's pre-processsing steps. Alternatively and more correctly one could forward model the geometric heights of the model levels and interpolate model winds to the Aeolus observation geometric height. The Met Office model (UM) has geopotential height as the vertical co-ordinate, so they don't need to convert to a pressure value (but do need to convert observation geometric to geopotential height). Any pressure geolocation that we could provide with Aeolus L2B winds would depend on a priori information from some NWP model, hence I don't think it's a good idea that we provide this. We want the observations (in BUFR) to be as independent of NWP model as possible.
- There is no atmospheric pressure value provided for the vertical geolocation. The descriptor 10004 in the Aeolus L2B BUFR is actually the "reference pressure" used for correcting the Rayleigh HLOS winds for a sensitivity to atmospheric pressure (a so-called Rayleigh-Brillouin correction - see the ATBD in the L2Bp v3.00 documentation). However, I guess this is not written explicitly anywhere for the BUFR description (e.g. in the documentation TN7.3 ADM-Aeolus Level-2B BUFR description, it is not clear). Hence users can mistake it for the proper vertical geolocation of the observation. Our BUFR specialist at ECMWF (who defined the template with us) decided to use the already available (in BUFR) pressure descriptor rather than create a new one specially for Aeolus - the same goes for the temperature descriptor. Associated with these "reference" pressure and temperature values there are other descriptors: "derivative wind to pressure", and "derivative wind to temperature". The idea of providing these "reference" values is that users may which to correct (linear correction) the Aeolus Rayleigh HLOS winds to a value using their own model's pressure and temperature data or use them in a Rayleigh wind observation operator.
Aeolus L2B Rayleigh winds rely on the AUX_MET (auxiliary meteorological) data i.e. a priori information, of the temperature and pressure at the observation's location - which is input to the L2Bp. We create the AUX_MET data from the ECMWF short-range forecasts (i.e. background forecast). However, there was a concern that other users of Aeolus L2B data might want to use their own model's temperature and pressure data, or even include the sensitivity to temperature and pressure in the observation operator. To include it in the forward model, one can use the "reference" temperature and pressure values, and the linear sensitivity of the HLOS wind to temperature and pressure (part dHLOS/dT, and dHLOS/dp). N.B. the typical dHLOS/dT is around 0.1 m/s, so not huge! - Because the Mie HLOS winds do not require AUX_MET data T and p for any corrections, then they may not have these "reference" values available. I'd have to check the code, but I guess the "reference" T and pressure is not guaranteed to be available with each observation - and clearly not based on your experience.
- Of course the "reference pressure" with the Rayleigh winds (via ECMWF model) could be used if you really want to - but then you introduce some dependence on the ECMWF model - and as you say it is sometimes missing values and can't be relied upon.
- Will the Aeolus BUFR be available on the GTS?
- It should be available on the GTS in NRT (BUFR produced by ECMWF and then disseminated to GTS via EUMETSAT), but only when the quality of the observations are deemed to be sufficient for dissemination to the general public, which may be many months after launch.