I am trying to download ERA5 data via flex_extract v7.1.2. I used flex_extract v7.1.2 to download the global ERA5 data (GRIB2 format) for January 2023, but was unable to use the data to drive FLEXPART. Specific error information is as follows:
I checked my OUTGRID file and found that OUTGRID file was correct. According to the Q&A ticket on the flexpart.eu website (https://www.flexpart.eu/ticket/238), I checked the relevant parameter in gridcheck_ecmwf.f90. I found that the GRIB2 file I downloaded and converted through flex_extract outputs xaux1in (longtitude of first grid point in degrees) equals 181 and xaux2in (longtitude of last grid point in degrees) equals 180. The correct GRIB2 file should output xaux1in equals 182 and xaux2in equals 181. I don’t know what went wrong because I didn’t get any errors when downloading the data using flex_extract. I really need your help, thank you!
I think that this is realted to setting the NXSHIFT parameter in your CONTROL file. This is very likely not related to ERA5 data or flex_extract.
Could you, if your issue still exists, open a ticket on the relevant FLEXPART Gitlab (via mail to service email address). Public issues can be found there too.
I ran into the same issue that was originally reported in this thread when trying to drive FLEXPART, but in my case the problem came from RDA (NCAR) FNL data rather than ERA5 from Copernicus. The underlying cause turned out to be the same: an inconsistency in longitude conventions between different downloads.
When I downloaded via the GUI, the files used −180 → 180° longitude.
When I downloaded via a control file (batch/python), the files used 0 → 360° longitude.
This mismatch caused xaux1in and xaux2in to be off by one column during the FLEXPART preprocessing step, leading to the same grid check error described above.
Solution (in my case):
Either shift the longitude grid in post-processing (e.g. with CDO/xarray), or [recommended!]
Adjust the NXSHIFT parameter in the CONTROL file so that the column ordering matches what FLEXPART expects.
To help diagnose such cases, I used a small shell script (see below) that runs grib_compare -r from ecCodes on two files (for example, one downloaded via GUI and one via a control file). It shows very clearly when the longitude and latitude start/end points differ.
Here’s the script i created and used (there is a link inside the bash script, for your reference and more detail):
#!/bin/sh
#Author : Marco Miani
#Version : Tue 10 Aug 2021
#Content : Use grib_compare (-r) to compare the content of two grib files.
#Reference: https://confluence.ecmwf.int/display/UDOC/grib_compare%3A+index+based+comparison+-+ecCodes+GRIB+FAQ
Now=$(date +%d-%b-%H:%M)
echo
echo --------------------------------------------
echo Comparing two grib files using grib_comapre
echo "$Now"
echo --------------------------------------------
echo
echo Reference: https://confluence.ecmwf.int/display/UDOC/grib_compare%3A+index+based+comparison+-+ecCodes+GRIB+FAQ
echo
echo
echo Reference directory
echo $PWD
echo
echo
grib_controlFile="./manual_dwnload/gdas1.fnl0p25.2020010100.f00.grib2.miani506261"
grib_GUI="./controlFile_dwnload/gdas1.fnl0p25.2020010100.f00.grib2.spasub.miani506263"
echo grib_controlFile : $grib_controlFile
echo grib_userInterface: $grib_GUI
grib_compare -r $grib_controlFile $grib_GUI
