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

[hcpxvi]

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.

[pesei]

Thank you for creating this ticket!

[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

[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 ?

[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