Opened 23 months ago
Last modified 4 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 23 months ago by pesei
- Description modified (diff)
comment:2 Changed 23 months ago by pesei
- Owner set to pesei
- Status changed from new to accepted
comment:3 Changed 23 months ago by pesei
- Description modified (diff)
comment:4 follow-up: ↓ 6 Changed 23 months 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 9 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 4 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
Thank you for creating this ticket!