You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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 BUFR compared to the WMO BUFR template?
    • These changes are indeed 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 usage 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.  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.
    • 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".
    • Ignore "localLatitude".  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.There is a reference pressure value ("nonCoordinatePressure") but don't use that for the vertical geolocation since it the value used in the L2B processor for the Rayleigh-Brillouin correction using AUX_MET data (ECMWF model a priori information).
  • Will the Aeolus BUFR be available on the GTS?
    • It should be available on the GTS in NRT (produced by ECMWF and then disseminated 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.
  • No labels