This is a compilation of the known differences presented by the output data when generated by the present Products Generation software (PRODGEN) vs the new one (PGEN).
It does not explain the differences between the software itself.
See further details of the new Products Generation including the project timeline.
Users requesting reduced Gaussian grids will need to update the version of ecCodes to 2.8.2 (or follow up versions ) |
PGEN software uses MIR interpolation library and therefore data values will not be exactly the same. Prodgen uses EMOSLIB which is no longer supported .See MARS interpolation with MIR for further information about differences between EMOSLIB and MIR.
Specific cases for reduced Gaussian grids present different point count.
PGEN does not deliver duplicated fields configured in the requirements. e.g. In the request below the parameter 2T will be delivered twice by PRODGEN and only once by PGEN
DIS, TARGET = ECM:EC, STREAM = DA, TYPE = FC, GRID = 0.125/0.125, AREA = 55/2.5/47/15.5, TIME = 00, LEVTYPE = SFC, STEP = 0/to/168/by/3, PARAM = 2T/SSRD/2T |
PGEN is encoding the west/east longitudes differently in GRIB1.
User input | PRODGEN | PGEN |
area=90/-180/-90/179.5 grid=0.5/0.5 | area=90/180/-90/179.5 | area=90/-180/-90/179.5 |
area=90/0/-90/359 grid=1/1 | area=90/0/-90/-1 | area=90/0/-90/359 |
area=90/-60/25/60 grid=640 gaussian=reduced | area=89.892/300/25.092/60 | area=89.892/-60/25.092/60 |
In GRIB1, the precision is millidegrees; in GRIB2, it is microdegrees. PGEN lets ecCodes decide on the best precision. PRODGEN encodes the areas in millidegrees, therefore the encoded values in GRIB2 can be different.
This case will affect mostly to gaussian grids e.g. :
User input | PRODGEN | PGEN |
area=90/-60/25/60 grid=640 gaussian=regular form=GRIB2 | area=89.892/300.093/25.092/59.906 | area=89.8924/300.094/25.0918/59.9062 |
e.g.
User input | PRODGEN | PGEN |
area=90/-60/25/60 grid=640 gaussian=regular | area=89.892/-59.907/25.092/59.906 | area=89.892/-59.906/25.092/59.906 |
When gausssian grid are requested, PRODGEN sets the east latitude in the GRIB header to the user provided value (modulo 360 and modulo the GRIB1 precision). pgen will put the longitude of the most eastern point.
e.g
User input | PRODGEN | PGEN |
area=90/0/-90/359.9 grid=128 gaussian=reduced | area=89.463/0/-89.463/359.9 gridname=N128 | area=89.463/0/-89.463/359.297 gridname=N128 |
Fields that may contain constant values are packed by PGEN with bitsPerValue=0. This is a more efficient way to encode such fields and leads to smaller files.
An example of such field is CLWC on model levels high in the atmosphere where the values are zero at all grid points.
As a result, file sizes may change from one day to the next.
PRODGEN encodes these with a bitsPerValue=8 so file sizes are constant from one day to the next.
PRODGEN does not produce files in GRIB1 with local definitions for 00 and 12 UTC HRES fields. They are kept for 06 and 18 BC and ENS (including ENS-extended and SEAS).
The local definition are (currently) retained by PGEN.
E.g given two files:
H1D09060000091600001.pgen
H1D09060000091600001
Please retain the order of the files when doing the comparison
grib_compare -H H1D09060000091600001.pgen H1D09060000091600001 -- GRIB #1 -- shortName=sd paramId=141 stepRange=240 levelType=sfc level=0 packingType= gridType= -- long [totalLength]: [26534] != [26510] long [section1Length]: [52] != [28] [reservedNeedNotBePresent] not found in 2nd field [localDefinitionNumber] not found in 2nd field [marsClass] not found in 2nd field [marsType] not found in 2nd field [marsStream] not found in 2nd field [experimentVersionNumber] not found in 2nd field [perturbationNumber] not found in 2nd field [numberOfForecastsInEnsemble] not found in 2nd field [padding_local1_1] not found in 2nd field |