Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IFI.F can use junk values for hourly accumulated precipitation #1126

Open
SamuelTrahanNOAA opened this issue Jan 29, 2025 · 3 comments · May be fixed by #1127
Open

IFI.F can use junk values for hourly accumulated precipitation #1126

SamuelTrahanNOAA opened this issue Jan 29, 2025 · 3 comments · May be fixed by #1127
Labels
bug Something isn't working

Comments

@SamuelTrahanNOAA
Copy link
Contributor

This code in IFI.F is incorrect:

          if(ifi_apcp(i,j)>9e9 .or. ifi_apcp(i,j)<-9e9 .or. ifi_apcp(i,j)==0) then
              ifi_apcp(i,j) = avgprec_cont(i,j)*to_hourly

It causes the post to send junk data from avgprec_cont in situations where precipitation in ifi_apcp is identically zero. With my HRRR tests, junk data gets through sometimes (eg 1.72E+16) . This leads to the UPP IFI producing different precipitation types in its derived fields.

The correct code is:

          if(ifi_apcp(i,j) == spval) then
              ifi_apcp(i,j) = avgprec_cont(i,j)*to_hourly

Without this bug fix:

  1. Points in the HRRR IFI 1hr apcp field have invalid data in some locations.
  2. UPP sends those values to libIFI, which it then uses as if the data were valid.
  3. The standalone IFI uses -9999 (missing value) in those locations. This results in a mismatch between standalone IFI and IFI in UPP.
  4. The first field that changes is wx_type.

With this bug fix:

  1. Points in HRRR IFI 1hr apcp field appear to be valid.
  2. Standalone IFI and UPP IFI get identical results.
@WenMeng-NOAA
Copy link
Collaborator

@SamuelTrahanNOAA Would this bug have impact on RRFS and MPAS results?

@SamuelTrahanNOAA
Copy link
Contributor Author

The bug and its fix are confined to IFI.F, so it'll only affect the IFI fields, and only if libIFI is enabled. (Without libIFI, the fields are all missing values regardless.) My fix in #1127 also updates a comment in another file to match this bug fix, but it is only a comment, so it'll have no effect on results.

@WenMeng-NOAA WenMeng-NOAA added the bug Something isn't working label Jan 31, 2025
@SamuelTrahanNOAA
Copy link
Contributor Author

The result of this bug is false positives in icing severity category.

Plots of surface precip of test data (2020 June 1, 18Z)

The big red splotches are areas where the surface precip type becomes 7 instead of 0.

The entire 3D precipitation type arrays also differ. I'm plotting only the surface here.

Image

Image

Icing severity category in test data (2020 June 1, 18Z)

Note the differences in the fields just to the west of Florida. Precip types 0 or 4 become 2 or 5.

There are other differences in the central north part of the domain.

Image

Image

Icing severity category with surface precip difference contours in test data (2020 June 1, 18Z)

Here, I plot red contours around areas where the surface precip disagrees between IFI in UPP vs IFI standalone. You can see the differences in icing severity category follow the differences in surface precip.

Image

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants