-
Notifications
You must be signed in to change notification settings - Fork 39
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
missing or all zero values for some variables in RRFS grib2 product #212
Comments
@JiliDong-NOAA thank you for reporting this issue. @EricJames-NOAA @jaymes-kenyon @AndrewBenjamin-NOAA Wen already left to visit family in China and won't be back till Feb. 21. I'm leaving soon for Taiwan and won't return till Feb. 23. Any chance you can take a look until then? Thank you! |
@MatthewPyle-NOAA |
@HuiyaChuang-NOAA Hopefully we'll get this sorted out well before then, but thanks. Enjoy your time away! |
Thank you! Will be my first time to make Chinese New Year family reunion in 2 decades. |
@HuiyaChuang-NOAA enjoy your vacation! @AndrewBenjamin-NOAA should be able to tell us how many of these are actually needed for RRFS. We may be able to get rid of many of them, although I'm not as familiar with the NAM related ones. |
@EricJames-NOAA: yes I can. Products that can be removed/retired:
Products that should be in RRFS:
|
@AndrewBenjamin-NOAA thanks! The only notes I would add are that the variables currently named FFLDRO and GWLOWS are fields that I have added which we don't want to remove. They are binary QPF exceedances of various precipitation thresholds. It makes sense they would all be zero for some times in the winter, but they will highlight grid points with heavy rainfall during the warm season. I think we were working on getting some new GRIB2 names for these fields, but I'm not sure where that stands. Also, the AEMFLX is the smoke emission for the smoke component of RRFS, so it should not be zero. I'm going to look into what's going on there. |
@EricJames-NOAA Smoke is currently off in RRFS_A owing to a bug. That likely explains why AEMFLX is currently zero. |
@JacobCarley-NOAA thanks! That makes sense. Let's retain that output field. |
Regarding the "HAIL" field, I am finding non-zero values in our beta retros. So, the missing values in some RRFS members may be limited to members with non-standard physics. Even so, the "HAIL" values that I am seeing are quite small (fractions of a mm), even during periods of confirmed large hail. I am investigating. |
Thanks for the follow ups everyone. I am based my list on what was currently in operations. So if products were already agreed upon to be added, then it obviously makes sense to keep them. AEMFLX would be an example of this.
@EricJames-NOAA are these the same values that we added to the NCEP grib2 tables last year? Take a look at https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-2-1-1.shtml 196 and 197 are new exceedance grid we coordinated on. If these are the same products, please use the new IDS in Table 4.2-1-1. |
What is the status of the other products that need to be fixed? Some of these I can remember seeing for some time in the parallels.
|
@AndrewBenjamin-NOAA I think Tanya and should be able to get BGRUN working. I was just looking at CSDSF in UPP...I see this message in the code where the field is set to missing instead of read in: ! inst incoming clear sky sfc shortwave Does anyone know if FV3 can output clear sky downward solar irradiance? |
@EricJames-NOAA Thats good news on BGRUN, please keep me posted. I also noticed that WEASD is only being output hourly, with no run-total accumulations written to the grib2 files i.e a 0-7 hour acc fcst at f007). This was previously on the parallels, but is now missing. Was this taken offline for some reason? |
@AndrewBenjamin-NOAA I think we moved to TSNOWP for the run total accumulated snow output. WEASD is now only used for the snow water equivalent on the ground. Hopefully @ericaligo-NOAA agrees with this explanation. |
That's correct. Note TSNOWP does not use the variable precip ice density. It's just the water equivalent of snow at the surface directly from the microphysics. There's a run-time accumulated field, and one that's emptied according to the defined buckets. |
@AndrewBenjamin-NOAA is CSDSF an instantaneous flux? I don't see that in RAP/HRRR....is it something we are carrying over from NAM? Thanks. |
@EricJames-NOAA, Yes CSDSF is an instantaneous flux. And you are correct, CSDSF is an operational product from the NAMnest |
@AndrewBenjamin-NOAA with the latest UPP code we can get instantaneous ULWRF at top of atmosphere. Tanya reports that BGRUN will be all zero with the RUC LSM since it is not coupled to hydrology. So it should be OK to remove this field. I believe @jaymes-kenyon was looking into HAIL. I'm working on the other ones. |
@AndrewBenjamin-NOAA — Regarding HAIL, the UPP code seems to be working fine. There are some runs with universal zero values, but most most runs contain nonzero instances. However, unrelated to the UPP code, there is an underlying FV3 bug (in the HAILCAST routine) that is dividing hail sizes by 1000, yielding gridded values that are just fractions of a millimeter. A PR to fix this has been introduced: NOAA-GFDL/GFDL_atmos_cubed_sphere#320 @EricJames-NOAA — Since HAIL is in good shape (in UPP), let me know if I can help tackle any of the remaining trouble spots. Thanks! |
@jaymes-kenyon thanks! I will touch base with Tanya next week and let you know if we need help with anything. |
When working on the fix for missing reflectivity of rrfs members using inline post, I noticed there are several variables in the real-time rrfs_a products with all missing or zero values across the whole domain. I quickly scanned one of the real-time rrfs_a grib2 file and have these variables listed below (sample file: rrfs_a.20240112/00/control/rrfs.t00z.prslev.f012.conus_3km.grib2). Some of the variables have been discussed (i.e. REFZR and REFZI). Some of them will be fixed if not already (NCPCP). Some of them may be zero due to physics reasons (Hail and Snow melt?). But I still see quite a few variables which should have valid values but not: such as 10m potential temp/specific humidity, Blackadars Mixing Length Scale, Planetary Boundary Layer Regime, Upward Long-Wave Rad. Flux at TOA, albedo, u/v momentum fluxes etc.
I am curious if these variables are needed/required by stakeholders/forecasters/downstream users? If yes, these missing/zero values should be fixed. If not, should we consider removing these variables from grib2 product?
The text was updated successfully, but these errors were encountered: