wind vector direction in NAM and NARR data

[wilkin]

The Matlab script nam_narr_2roms.m in the coawst/Tools/mfiles/mtools distribution reads meteorology analysis fields from the NCDC NOMADS analysis archives and makes meteorology forcing files for ROMS. It's a very handy piece of code and easily customized to a new user domain.

But the wind components read are variables 'u_wind_height_above_ground' (and v_wind...) which have the attributes "GRIB_VectorComponentFlag: gridRelative" (see e.g. http://nomads.ncdc.noaa.gov/thredds/dod ... 0.grb.html)

After combing through GRIB documentation I'm pretty sure these are in the direction of the Lambert Conformal coordinates and not east-north. So nam_narr_2roms.m needs extra code to make the vector rotation. At the west and east limits of the NAM grid the u-grid-relative direction differs from east by about 15 degrees.

Anticipating someone might have done this already - would anyone care to share code to correct these wind components?

[jcwarner]

John-

thanks for spotting this. Yes, you are correct. These velocities from NAM/NARR via THREDDS need to be rotated from Lambert Conformal to Earth long lat. I found a set of code in a fortran file called nam2model.F and some corresponding code at the bottom of this page:
http://ruc.noaa.gov/RUC.faq.html
and then added the rotations to the m file for NAM/NARR winds. Also added the option to acquire GFS data as well (GFS does not need rotation because, well, it is the whole globe="G"). I then renamed the m file to nomads_2roms.m. I am going to push this out soon, as well as a few other updates from Rutgers ROMS and some from WRF.

thanks,
john

[stevevangorder]

John W,

Did nomads_2roms.m end up being named ncei_2roms.m?

Thanks,

Steve

[jcwarner]

possibly. they all get data from here:
https://www.ncdc.noaa.gov/nomads/data-products

but there had been some changes at the noaa site. I remember they add the 's' to https and that was a problem in matlab. Matblab had been comparing the first 5 letters of a file, and if it started with http:, then it went to thredds. But when noaa changed to https:, matlab saw https and it thought the file was local. This has been fixed in newer matlab.

but during that confusion Christie had to modify the m file to make it work , and she added the use of nctoolbox to read the data.
but nctoolbox only reads, it does not write, so we still need matlab native calls to write.

... but it should work now. i am sure the saga will continue. let us know.
thanks,
-j

[stevevangorder]

Hi John,

Sorry to take so long to get back on this, got sidetracked on another project ...
Anyway I did get ncei_2roms.m to work. Here is a list of the changes I made. I only worked on the NAM and NARR sections since I didn't use GFS data. Nor did I make any changes to Matlab "ncread" parts of the code since it can't read the grib files. I will email you my version of ncei_2roms.m if you're interested.

Steve

% 1. Added NetCDF 64-bit file option.
% 2. Switched from native Matlab ncread to nctoolbox. ncread can't read grib files.
% 3. Removed several "echo on", "echo off" debugging statements from ncgeodataset.m left by acrosby
% nctoolbox issue #95: "nctoolbox makes MATLAB verbose?" #95
% https://github.com/nctoolbox/nctoolbox/issues/95
% 4. Fixed issue with closing geo when it wasn't successfully created.
% 5. Added report header, additional progress output and save report option.
% 6. Added filenames for GFS, NARR and NAM workspace dump .mat files.
% 7. NARR data: Changed server url from NOMADS to NECI and changed to NCEI variable names.
% 8. Added try catch blocks for ngeodataset creation and each variable download in the NARR and NAM sections.
% 9. NAM data:
% a. Changed server url from NOMADS to NECI.
% b. Added "NAM_grib_ver" switch to select .grb or .grb1 urls.
% c. Added "save_NAM_mask", "load_NAM_mask" switches to avoid recompute of large masks.
% d. Added squeeze_3Dvar function to check for 3D variable before squeezing Tair, Uwind, Vwind.

[chegermiller]

Hi Steve,

Thanks for detailing the changes you made to ncei_2roms.m. I'm glad you got it to work for you. As John mentioned below, when the data was moved to the NCEI server, we made several changes to the script to accommodate issues with the opendap url and ncread, different grib extensions, and different variable names. We also changed some logic and interpolation. Would you mind sharing your script with me, chegermiller@whoi.edu, and John so that we can rectify your changes with ours?

For others, the ncread bug should be resolved in the most recent matlab release:
https://www.mathworks.com/support/bugre ... =ts_R2018a

Thank you,

Christie

[agpc]

Hi Steve
Would you mind sharing your script with me, ntmanh18196@gmail.com.
I also have a problem with the ncei_2roms.m script.
Thank you very much!

[stef]

I noticed this thread just a couple of days ago (when agpc posted), and after reading wilkin's first post from 4 years ago, I'm not sure if I'm doing it right.

I'm using the source

https://www.ncei.noaa.gov/data/north-am ... 00_000.grb

specifically at the variable "10u" (grib parameter with ID 165). This is defined by ECMWF (here) as

... the eastward component of the 10m wind. It is the horizontal speed of air moving towards the east, at a height of ten metres above the surface of the Earth, in metres per second
...

However, the command 'grib_dump' (from eccodes-2.19.0) used on the file above yields the following data:

Code: Select all

 
#==============   MESSAGE 9 ( length=295734 )              ==============
GRIB {
 editionNumber = 1;
 table2Version = 2;
 # US National Weather Service - NCEP  (WMC)  (common/c-1.table)   
 centre = 7;
 generatingProcessIdentifier = 84;
 # U U-component of wind m s**-1 (grib1/2.0.2.table)   
 indicatorOfParameter = 33;
 # Fixed height above ground height in meters  (2 octets)  (grib1/3.table)   
 indicatorOfTypeOfLevel = 105;
 level = 10;
 # Initialized analysis product for reference time  (P1=0)  (grib1/5.table)   
 timeRangeIndicator = 1;
 # Unknown code table entry ()   
 subCentre = 0;
 paramId = 165;
 #-READ ONLY- cfNameECMF = eastward_wind;
 #-READ ONLY- cfName = eastward_wind;
 #-READ ONLY- cfVarNameECMF = u10;
 #-READ ONLY- cfVarName = u10;
 #-READ ONLY- units = m s**-1;
 #-READ ONLY- nameECMF = 10 metre U wind component;
 #-READ ONLY- name = 10 metre U wind component;

 decimalScaleFactor = 0;
 dataDate = 20121027;
 dataTime = 0;
 # Hour (stepUnits.table)   
 stepUnits = 1;
 stepRange = 0;
 startStep = 0;
 endStep = 0;
 #-READ ONLY- marsParam = 33.2;
 shortName = 10u;
 GDSPresent = 1;
 bitmapPresent = 0;
 numberOfVerticalCoordinateValues = 0;
 Nx = 614;
 Ny = 428;
 latitudeOfFirstGridPointInDegrees = 12.19;
 longitudeOfFirstGridPointInDegrees = -133.459;
 earthIsOblate = 0;
 uvRelativeToGrid = 1;
 LoVInDegrees = -95;
 DxInMetres = 12191;
 DyInMetres = 12191;
 projectionCentreFlag = 0;
 iScansNegatively = 0;
 jScansPositively = 1;
 jPointsAreConsecutive = 0;
 #-READ ONLY- alternativeRowScanning = 0;
 Latin1InDegrees = 25;
 #-READ ONLY- LaDInDegrees = 25;
 Latin2InDegrees = 25;
 latitudeOfSouthernPoleInDegrees = 0;
 longitudeOfSouthernPoleInDegrees = 0;
 #-READ ONLY- numberOfDataPoints = 262792;
 #-READ ONLY- numberOfValues = 262792;
 missingValue = 9999;
 #-READ ONLY- binaryScaleFactor = -3;
 #-READ ONLY- referenceValue = -20.5327;
 sphericalHarmonics = 0;
 complexPacking = 0;
 integerPointValues = 0;
 additionalFlagPresent = 0;
 packingType = grid_simple;
 bitsPerValue = 9;
 values(262792) =  {
 -7.28271, -7.28271, -7.28271, -7.28271, -7.28271,
...
 }  
 #-READ ONLY- numberOfCodedValues = 262792;
 #-READ ONLY- maximum = 19.0923;
 #-READ ONLY- minimum = -20.5327;
 #-READ ONLY- average = -0.237469;
 #-READ ONLY- numberOfMissing = 0;
 #-READ ONLY- standardDeviation = 5.05881;
 #-READ ONLY- skewness = -0.354337;
 #-READ ONLY- kurtosis = 1.34136;
 #-READ ONLY- isConstant = 0;
 gridType = lambert;
 #-READ ONLY- getNumberOfValues = 262792;
}

#==============   MESSAGE 10 ( length=295734 )             ==============

....

The grid type is "gridType = lambert;" as I expected, but the variable "uvRelativeToGrid" is set to true, i.e. "uvRelativeToGrid = 1;".

I think this contradicts with the variable Id and name 'u10', since this should be an *eastward* velocity.

Also, I compared the (u10,v10) 2d vector field with scatterometer data, which is gridded independently of any projection (see oceansat2 files), and it looks like 'u10' and 'v10' are indeed eastward/northward components. See e.g.




However, I can't be entirely sure judging from the figures, so I asked the NCEI helpdesk, and if I interpret their email correctly, they agree that u10 is indeed eastward and there is incorrect metadata in the file.

If that's true, then I did everything right because I was too lazy to look at the metadata (should happen more often). Kindly let me know if I'm not doing it right.