Opened 3 years ago

Last modified 13 months ago

#305 accepted Defect

FLEXTRA fails with NCEP GFS data after 2021-03-22

Reported by: hcpxvi Owned by: pesei
Priority: critical Milestone: FLEXTRA 6
Component: FLEXTRA Version: FLEXTRA 5
Keywords: Fails Cc:

Description (last modified by pesei)

FLEXTRA fails when used with NCEP GFS data for dates after (approximately) 2021-03-22. The error message is typically

TEMP:    0.00000000    
STOP SORRY: T NOT IN [K]

This is a known issue with FLEXPART and has been discussed in the mailing list (initial post from Richard Damoah dated 2021-05-09 with subject line "FLEXPART 10.4 Error with GFS met fields"). I believe there is a fix in development versions of FLEXPART. I am only creating this ticket to ensure that FLEXTRA gets the fix too. I have set the priority to critical, but that is only true for dates after 2021-03-22. For dates before that, there is no problem.

Change History (6)

comment:1 Changed 3 years ago by pesei

  • Description modified (diff)

comment:2 Changed 3 years ago by pesei

  • Owner set to pesei
  • Status changed from new to accepted

Thank you for creating this ticket!

comment:3 Changed 3 years ago by pesei

  • Description modified (diff)

comment:4 follow-up: Changed 3 years ago by pesei

Information from the mailing list:

Starting with 20210322_12, FNL files had extra levels and extra fields
including vertical levels lower than 1 mb, which Flexpart set to 0
because it uses an integer (isec1(8) in readwind_gfs.f90)

Flexpart error was "STOP sorry: t not in [k]" because temperature field was not read
correctly for top levels (< 1 mb)

Curiously, before 20210322_12, 15 mb and 40 mb do not have u and v variables
After 20210322_12 there are the same set of variables for 15 mb and 40 mb
as for all the other levels.

There was also a memory problem in Flexpart when reading some of the later records.

Solution: remove all the records in the files starting with 20210322_12 that are
not in the files before that time. This can be done using wgrib2.


There is a fix for this in the current "dev" branch of flexpart
changeset:941195203f079ad9ae7ec538a34d372530ee821d/flexpart.git/flexpart_code/checkgrib

comment:5 Changed 18 months ago by mqzhang

Now I meet the same problem on FLEXPART V10.4. When I carefully flipped through the ticket system, I found some discussion of this problem. On the comment #4 by pesei, the url "There is a fix for this in the current "dev" branch of flexpart
changeset:941195203f079ad9ae7ec538a34d372530ee821d/flexpart.git/flexpart_code/checkgrib" just fits version 9.3 of FLEXPART. So, does the fixing code have applied to version 10.4 ?

comment:6 in reply to: ↑ 4 Changed 13 months ago by hshen

Deleting all the inventories with mb < 1 is working for the necp FNL files after 20210322_12. Specifically inventories 15 - 94 (by 20221231_18).

Also, the memory problem in FLEXPART when using the necp FNL files after 20210322_12 is due to inventory 597: ...SOTYP:surface:anl:(by 20221231_18). Deleting this inventory will solve it. I really wonder why.

Replying to pesei:

Information from the mailing list:

Starting with 20210322_12, FNL files had extra levels and extra fields
including vertical levels lower than 1 mb, which Flexpart set to 0
because it uses an integer (isec1(8) in readwind_gfs.f90)

Flexpart error was "STOP sorry: t not in [k]" because temperature field was not read
correctly for top levels (< 1 mb)

Curiously, before 20210322_12, 15 mb and 40 mb do not have u and v variables
After 20210322_12 there are the same set of variables for 15 mb and 40 mb
as for all the other levels.

There was also a memory problem in Flexpart when reading some of the later records.

Solution: remove all the records in the files starting with 20210322_12 that are
not in the files before that time. This can be done using wgrib2.


There is a fix for this in the current "dev" branch of flexpart
changeset:941195203f079ad9ae7ec538a34d372530ee821d/flexpart.git/flexpart_code/checkgrib

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