-
Notifications
You must be signed in to change notification settings - Fork 9
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
add support for rotated lat/lon in ip2 code to support wgrib2 #211
Comments
@AlexanderRichert-NOAA we need this to be fixed to get the new wgrib2 build working. |
Okay, looking into this now |
@webisu @edwardhartnett would you be able to point me to the missing routines? I seem to recall Kyle's merge of ip2 into ip was fairly comprehensive, but I may be missing something. |
Alex,
If my old discussions with George Gayno, ip2lib did not
support parameters 32768 and 32769
https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table3-1.shtml
When interpolating NAM and RFFS rotated lat-lon grids, the grib2 files will
use
a grid template value of 32768 or 32769. Wgrib2 would convert these values
to
a grib1 gds of 203 or 205. Then it would call the grib1 version of iplib
You can search for 203 and 205 in the grib1 version of the library. That
may
or may not help you to find the codes that need to be fixed in the grib2
ipolates
library,
The grib2 iplib supports rotated lat-lon grids, so supporting 32768 and
32769 means
you have to map the NCEP definition of the rotation to the the WMO
definition of
the rotation. Probably straight forward if you knowledgeable. However, it
is outside
of my expertise.
Wesley
…On Fri, Mar 1, 2024 at 12:39 PM Alex Richert ***@***.***> wrote:
@webisu <https://github.com/webisu> @edwardhartnett
<https://github.com/edwardhartnett> would you be able to point me to the
missing routines? I seem to recall Kyle's merge of ip2 into ip was fairly
comprehensive, but I may be missing something.
—
Reply to this email directly, view it on GitHub
<#211 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIB7ZTDFDFDKCX5KAA7DP3YWC4LVAVCNFSM6AAAAABAZ3GUD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTGYYTCNJUGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Is there a file (or couple files if there are two grid numbers to test) and a wgrib2 command+expected result that I can test with? I'm assuming this will involve the I'll have to refresh myself on grib standards/grid definitions/etc. but I'm hoping the consolidated ip code will help here. |
@webisu if I've understood the requirement correctly, the idea is to be able to provide the ip library directly with GDT value 32768 or 32769. If that is the case, please see #231 and see if that looks reasonable. In short, the current ip library supports those grids for grib2, but uses GDT number 1 for both (which I'm not sure I understand), then infers E vs. B based on some offsets in the GDT data. The PR would allow it take the 3276x values directly. If that seems like the right idea I can add unit testing and push the changes. |
Alex,
You have the requirement right. When you have the GDT == 1, then you
are supporting
the WMO definition of the rotated lat-lon grid. The grib2 version of
iplibs supports rotated
lat-lon grids from the regional FV3, Canadian regional, and some of the
European regional models.
(I am not aware of any that isn't supported but I didn't do a search.) I
don't know whether the
models are providing a full or staggered grid.
The NAM, RRFS and perhaps the hurricane model are using GDT 32768 or
32769.
I really don't pay attention to the regional models. Dusan added the code
to support
these models. He is a regional guy and understands what a "rotate
latitude/longitude
(Arakawa Non-E Staggered grid)" means.
Wesley
…On Fri, Mar 1, 2024 at 6:53 PM Alex Richert ***@***.***> wrote:
@webisu <https://github.com/webisu> if I've understood the requirement
correctly, the idea is to be able to provide the ip library directly with
GDT value 32768 or 32769. If that is the case, please see #231
<#231> and see if that looks
reasonable. In short, the current ip library supports those grids for
grib2, but uses GDT number 1 for both (which I'm not sure I understand),
then infers E vs. B based on some offsets in the GDT data. The PR would
allow it take the 3276x values directly. If that seems like the right idea
I can add unit testing and push the changes.
—
Reply to this email directly, view it on GitHub
<#211 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIB7ZWJMAHCZZQ3NOJJLQ3YWEIF3AVCNFSM6AAAAABAZ3GUD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGA4TKNJWGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
wgrib2 has it's own internal copy of the ip2 code, with come changes to support rotated lat/lon grids.
These need to be supported in NCEPLIBS-ip.
When @webisu gets back from vacation in January he can provide details.
Somehow the lack of rotated lat/lon is causing two different versions of wgrib2 to be built, one with, and one without. See NOAA-EMC/wgrib2#70.
This is needed for the wgrib2-3.3.0 release, but first we have to do the wgrib2-3.2.0 release. So this will be needed sometime in Q1 of 2024 (as a new release of NCEPLIBS-ip which can handle rotated lat/lon and can be used by wgrib2.)
The text was updated successfully, but these errors were encountered: