...
The second time you run the import for the same T0, the import will be much faster (as long as you don't restart FEWS), because FEWS caches the .gpx files in the temp folder. This makes the import easier to test/debug.
Known issues/warnings
- The first time importing a certain forecast (with a specific T0), you may occasionally miss a timestep and get this warning: "WARN - Bad GRIB2 record in file cdms3://ecmwf-forecasts.s3.eu-central-1.amazonaws.com/ecmwf-forecasts?20250807/00z/ifs/0p25/oper/20250807000000-129h-oper-fc.grib2, skipping pos=85720605 cause=Please reduce your request rate. (Service: S3, Status Code: 503, Request ID: GT6E0AJF2J2GT1CZ, Extended Request ID: 0dj/YW262Zwm6s8wg8n4mKOwp1yzZqxNS38x9GnoGQ3o2hlBKu02xOzgHs/IdVT3wl3n5comEM1d/z2FF14+MFrmr7tntDg+9aY85Jns1KA=)". This is a problem and we're working on this (see FEWS-32610).
- The first time importing a certain forecast (with a specific T0), you'll see several warnings like "WARN - Table ecmf/name line scaledValueOfSecondWavelength = missing() ;" → This is not a problem, you can ignore this warning.
- When importing accumulated parameters, the first timestep (00h) will always give a warning like "WARN - Exception while parsing NetCDF data from url cdms3://ecmwf-forecasts.s3.eu-central-1.amazonaws.com/ecmwf-forecasts?20250807/00z/ifs/0p25/oper/20250807000000-0h-oper-fc.grib2. This url will be skipped. Message was: Allocation size must be greater than zero". → This is not a problem, you can ignore this warning.
- The units defined in the .grib2 files don't always seem to be correct (e.g. radiation flux says W/m2 in the .grib2, but it actually seems to be a 3-hour accumulated J/m2 value).
...