# After using flex\_extract and CDS api download ERA5, longitude is wrong while reading ERA5 data **URL:** \ **Category:** API\ **Tags:** era5\ **Created:** [22 July 2024 09:08 UTC](https://forum.ecmwf.int/t/after-using-flex-extract-and-cds-api-download-era5-longitude-is-wrong-while-reading-era5-data/3374 "2024-07-22T09:08:04Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Liting\_Hu](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/l/d9b06d/32.png) [@Liting\_Hu](https://forum.ecmwf.int/u/Liting_Hu)\ **Post date:** [22 July 2024 09:08 UTC](https://forum.ecmwf.int/t/after-using-flex-extract-and-cds-api-download-era5-longitude-is-wrong-while-reading-era5-data/3374/1 "2024-07-22T09:08:04Z")
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: ![image](https://forum.ecmwf.int/uploads/default/original/1X/798f8758f02ed032c68fcab19f320d1052313962.png) 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](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! ---
**Author:** ![Michael\_Blaschek](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/m/e99b99/32.png) [@Michael\_Blaschek](https://forum.ecmwf.int/u/Michael_Blaschek)\ **Post date:** [31 January 2025 07:37 UTC](https://forum.ecmwf.int/t/after-using-flex-extract-and-cds-api-download-era5-longitude-is-wrong-while-reading-era5-data/3374/2 "2025-01-31T07:37:43Z")
Dear Liting Hu, 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](https://gitlab.phaidra.org/flexpart/flexpart) (via mail to service email address). [Public issues can be found there too.](https://gitlab.phaidra.org/flexpart/flexpart/-/issues) Thank you best wishes Michael ---
**Author:** ![Liu\_Bo](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/l/9e8a1a/32.png) [@Liu\_Bo](https://forum.ecmwf.int/u/Liu_Bo)\ **Post date:** [4 September 2025 08:21 UTC](https://forum.ecmwf.int/t/after-using-flex-extract-and-cds-api-download-era5-longitude-is-wrong-while-reading-era5-data/3374/3 "2025-09-04T08:21:21Z")
Hello, I’ve encountered the same issue. How did you resolve it? ---
**Author:** ![Gea\_Computing](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/g/d78d45/32.png) [@Gea\_Computing](https://forum.ecmwf.int/u/Gea_Computing)\ **Post date:** [9 September 2025 08:11 UTC](https://forum.ecmwf.int/t/after-using-flex-extract-and-cds-api-download-era5-longitude-is-wrong-while-reading-era5-data/3374/4 "2025-09-09T08:11:45Z")
Hello everyone, 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: a **n 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): ```bash #!/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 ``` ```auto The output (a snippet) will show something like: ``` ```auto – GRIB #1 – shortName=10u paramId=165 stepRange=0 levelType=sfc level=10 packingType=grid_complex_spatial_differencing gridType=regular_ll –long [totalLength]: [945255] != [1297979]long [latitudeOfFirstGridPoint]: [90000000] != [-90000000]long [longitudeOfFirstGridPoint]: [0] != [180000000]long [latitudeOfLastGridPoint]: [-90000000] != [90000000]long [longitudeOfLastGridPoint]: [359750000] != [179750000]long [scanningMode]: [0] != [64] ([00000000] != [01000000]) ``` Hope this helps. Happy coding, Marco