The Weather Forecasting Forum

I am having a problem with NARR-A data. PCGRIDDS32 appears to be placing the data ~1.5 deg west of the actual longitude. I had this impression from several different plots of different NARR-A datasets, and when I ran the simple command < lon >, the longitude lines are wavy, and are displaced ~1.5 deg west of their correct locations.

Lon,

If you could, please be more specific with your statement "..placing the data ~1.5 deg west." You need to discern whether you are talking about GRIB model parameters like PRES, TEMP, etc. or generated data like Lat, Lon, Coreolis parameter (FFFF), etc. Since you referenced the Longitude data, let me guess... the projection is on either a Lamber Conformal projection or Polar Stereographic projection. In those instances, the calculated longitude points *will* be wavy...so to speak. That is due to the imperfect longitude calculation routine and the imperfect contouring routine to "connect the dots" between those far spaced imperfect longitude lines. The greater the grid resolution (closer the grid points to each other), the more accurate those points and less wavy the contour lines will be. This is a known... "feature" and may be addressed in the future but it does not impact the accuracy of the model data.

Thanks,

Jeff Krob
PCGRIDDS32 System Developer

Apologies for the confusing post, Jeff. It appeared to me that the GRIB model parameters were displaced westward which is what brought me to take a look at the lon command. You are correct, the NARR-A is on the 221 grid which is Lambert conformal. So, after receiving your reply, I took a look at the same NARR-A data file using the NOMADS online plot capability and the GRIB model parameters were plotted in the same locations as in PCGRIDDS32. I conclude, therefore, that there is not a problem with the way PCGRIDDS32 is handling the NARR-A files. Thanks for your input.

Jeff,

One thing I don't understand about this issue is why when I work with a subset of this data the lat/lon lines display correctly in plan view and cross section view but when working with the full grid they do not. ?????

Regards,

Kevin

Jeff,

I think I may have found the issue with the full 221 grid not displaying correctly and the subset displaying correctly. After downloading various subsets of various dimensions it all seems to come down to data that "crosses" over 180 deg. Even sub sets that cross over 180 deg would not display correctly.



Notice all the longitude lines bunched up at 180 deg.

Once I got it to where the subset did not cross 180 deg everything is fine.



No wavy longitude lines! Subset region I used to accomplish this is: Lons: -135 / -65 --- Lats: 70 / 10

I really do think it has to do with the grid crossing over 180 deg. I don't know if this will help you or anyone else in finding a solution to the issue or not and this maybe old news to you Jeff, but these are my thoughts on the deal.

Kevin

Kevin,

OK - if you still have the GRIB files from your experiment, could you please WINZIP both grid projections (grid 221 & subregion) & email them to me so I can play with them?

Thanks,
Jeff

All,

Looking at the 221 grid, I can see the nature of the problem. If you use the following command looking at the full area of the grid;

FULG (shows all grid points)
ALON (shows Longitude grids)

You can see every 20 deg longitude, the contour line start south (from the north) on the east-side of the maps longitude line then, at some point, it "jumps" to the west-side of the longitude side. Now, I don't know "why" it is doing this nor why it is not doing this with the subsectored grid because they use the same calculations. Also, I believe this calculation impacts the way cross sections are calculated if they should happen to come across one of those areas where a "jump" is. The joys of debugging continues.

Jeff

All,

Good News...the problem with the 'wavy' NARR Longitude has been found and a work-around has been developed. I don't know exactly *what* the problem is nor how to *fix* it. The problem is not in the way the longitude gridpoints are calculated but in how the longitude gridpoints are packed into the PCG data files and the bug origionates back to the origional PCGRIDDS.

You see, Ralph Petersen (he wrote PCGRIDDS), in the effort of conserving space, figured out a compression algorithym using the MAX & MIN values in a data display to make the PCGRIDDS data files smaller yet still be able to display all the data points if required. And that is usualy all well & good with your normal data parameters like HGHT & TEMP. However with the Longitude values of the NARR North-hemi Lamber Conic Conformal (NLCC) earth projections, combined with the way the longitude values are calculated, in the upper left corner, you had data going from -180 deg to +180 deg (360 total) in a small area and the compression algorithym was not designed for those situations so it caused the data to be tiered or stepped instead of a smooth slope (you can see this if you zoom into the East Coast or something & enter ALON CIN1 for the longitude at 1 deg interval with the grid 221 and compare to the other grid 255.

This piece of software where the bug is has alot of math formulas & *no* documentation as to what & how the routine is doing what it is doing (thanks Ralph!!). So, the workaround is that when the longitude points are calculated for a NLCC grid, from east to west, as the longitude increases up to +180 deg at the International Date line, instaed of going to -180 & counting down, it will continue increasing in value to 190, 200, 210, etc.

Unless anyone else finds a new bug dealing with NARR or anything else, I'll be releasing a maintenance Beta release next week for everyone to go over & see if these & other bugs have been fixed. Then, I can continue focusing on the new & improved features I'm trying to incorporate.

Merry Christmas & Happy New Year!!!

Jeff Krob
WINGRIDDS System Developer