Opened 10 years ago

Last modified 4 years 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:

Description

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 (8)

comment:1 Changed 10 years ago by jbrioude

  • Status changed from new to accepted

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

comment:2 Changed 10 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 6 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 6 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 5 years ago by pesei (previous) (diff)

comment:5 follow-up: Changed 5 years 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.

comment:6 Changed 4 years ago by pesei

Note that errors are reported in #64 as well. However, we should use only this ticket.

comment:7 Changed 4 years ago by pesei

Replying to srakesh (#50):

I am using Flexpart 10.4 and I am using NCEP dataset ds093.0 from here: ​https://rda.ucar.edu/datasets/ds093.0/

Probably the Climate Forecast System Reanalysis data set is not supported by FLEXPART currently. As these data are available only at 6 h interval, they are also less useful as input for a transport model. For recommended NCEP input, see FpInputMetGfs.

comment:8 in reply to: ↑ 5 Changed 4 years ago by pesei

Replying to 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.

This behaviour indicates a reference to an array element out of bounds. It would be useful to re-run with array bounds checking and traceback enabled.

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