Opened 7 years ago

Last modified 18 months ago

#50 accepted Enhancement

FLEXPART can crash with some GFS data

Reported by: jbrioude Owned by: jbrioude
Priority: minor Milestone: FLEXPART 9.2
Component: FP coding/compilation Version: FLEXPART 9.0.2
Keywords: Cc:


Ticket #48 reminded me that for GFS files obtained from the NCEP ftp server, I had to fix gridcheck_gfs.f90 and readwind_gfs.f90 for GRIB1 and GRIB2 files because
1) the vertical levels are not sorted
2) additional 2D fields might be wrongly detected as temperature or humidity 2D fields by FLEXPART.

I will had a fix to the new version of FLEXPART.

Change History (5)

comment:1 Changed 7 years ago by jbrioude

  • Status changed from new to accepted

I meant: I will add a fix to the new version.

comment:2 Changed 6 years ago by anphi

Do you think, it might be possible, that due to the use of a grib_filter command, to cut out some vertical levels, there might be a mess in the order of vertical levels or the detection of 2D fields?

Because, before I used the filter everything worked fine. After applying the filter I had the problem with Flexpart error: sorry: t not in [k] see ticket:67

comment:3 Changed 2 years ago by camelia

I use FLEXPART 9.0.3 (the latest stable version) with ECMWF Era Interim data, in GRIB2 format and I had the same Flexpart error " sorry: t not in [k]". I think this problem is related of the conversion from GRIB2 to GRIB1 in gridcheck*.f90 and readwind*.f90, because if I use EI data in GRIB1 format, everything works fine.

comment:4 Changed 2 years ago by pesei

  • Component changed from FP input data to FP coding/compilation
  • Priority changed from major to minor
  • Type changed from Defect to Enhancement

This is discussed in ticket:56. Note that precipitation units also changed from Grib1 to Grib2, so you need to adapt that, otherwise precipitation data will be wrong.

I'll keep the ticket open even if it is a kind of duplicate, as a reminder to improve the the error message in ew.f90, but with some change in the ticket properties.

Last edited 18 months ago by pesei (previous) (diff)

comment:5 Changed 18 months ago by mitchekc

I'm having this same problem and I cannot figure out how to fix it in FLEXPART-WRF. I have tried grib1 data and grib2 data. The same problem occurs. I only get this issue when I specify a run with less than 1 000 000 particles. When I use a run with 10 000 000 particles I get a segmentation fault. Any help would be appreciated.

Note: See TracTickets for help on using tickets.
hosted by ZAMG