[gradsusr] Saving NetCDF lon parameter in geographic
Jennifer Adams
jma at cola.iges.org
Wed Apr 18 10:20:52 EDT 2012
Mark,
If your original data set "wraps" the globe, then it should work fine:
'sdfopen foo.nc
'set lon -180 180'
'define var'
'sdfwrite var'
If not, please send the output from ncdump -c on your original file, your script to generate a new netcdf file using sdfwrite, and the output from ncdump -c on your new netcdf file. Your GrADS version would be helpful too.
--Jennifer
On Apr 13, 2012, at 7:36 PM, Mark Hess wrote:
> Thanks Chuck - Looks like that validates my suspicion that I cannot change
> the lon coordinates from the 0-360 to world coordinates 180 to -180 when
> extracting a subset of the original file to a smaller .nc file. I'll
> consider different options. Thanks. Mark.
>
>
> ----- Original Message -----
> From: "Charles Seman" <charles.seman at noaa.gov>
> To: "GrADS Users Forum" <gradsusr at gradsusr.org>
> Sent: Thursday, April 12, 2012 3:44 PM
> Subject: Re: [gradsusr] Saving NetCDF lon parameter in geographic
>
>
>> Mark,
>>
>> The documentation at
>> http://grads.iges.org/grads/gadoc/gradcomdsdfwrite.html states:
>> "By default, the output file will have a coordinate variable only for
>> varying dimensions in the defined variable; non-varying dimensions will
>> not appear as a coordinate variable with a size of 1. However, as of
>> version 2.0.a5, options have been added to the set sdfwrite command to
>> force the variable in the output file to have at least 4 or all 5
>> dimensions. When either of these options to set sdfwrite are used, the
>> output file will retain information about the values of the dimensions
>> that were fixed when the variable was defined; non-varying dimensions
>> will appear as a coordinate variable of size 1. For example, if your
>> defined variable is 500mb height on14may2002 (a 2D variable that varies
>> only in lon and lat), and you use the -4d option, the output file with
>> show height as a 4D variable with a Z dimension of size 1 called 'lev'
>> with a value "500 mb", and a T dimension of size 1 called 'time' with a
>> value of "0 minutes since 2002-05-14 00:00".
>>
>> Seems the key phrase seems to be "the output file will retain
>> information about the values of the dimensions that were fixed when the
>> variable was defined"... I confirmed what I thought this meant on a file
>> which has grid longitudes in the -180 to 180 range and found the
>> following results:
>> --------------------------------------------------------------------
>> ...using "native" longitude range:
>> ga-> sdfopen 3B42.1002.V6.nc
>> Scanning self-describing file: 3B42.1002.V6.nc
>> SDF file 3B42.1002.V6.nc is open as file 1
>> LON set to 0 360
>> LAT set to -49.875 49.875
>> LEV set to 0 0
>> Time values set: 2010:2:14:22 2010:2:14:22
>> E set to 1 1
>> ga-> q file
>> File 1 : NASA TRMM 3B42 3-Hourly 0.25 degree TRMM and Other Satellites
>> Precipitation Product (Version 6)
>> Descriptor: 3B42.1002.V6.nc
>> Binary: 3B42.1002.V6.nc
>> Type = Gridded
>> Xsize = 1440 Ysize = 400 Zsize = 1 Tsize = 1 Esize = 1
>> Number of Variables = 2
>> precipitation 0 t,y,x precipitation
>> relativeerror 0 t,y,x relativeError
>> ga-> set lon -180 180
>> LON set to -180 180
>> ga-> set lat -90 90
>> LAT set to -90 90
>> ga-> set sdfwrite precipitation.3B42.1002.V6.nc
>> SDFWrite file name = precipitation.3B42.1002.V6.nc
>> SDFWrite will replace an existing file
>> ga-> sdfwrite precipitation
>> SDFWRITE error: no defined variables
>> ga-> define precipitation = precipitation
>> Define memory allocation size = 8328992 bytes
>> ga-> sdfwrite precipitation
>> Wrote variable precipitation to precipitation.3B42.1002.V6.nc
>> ...
>> cjs: /tmp/data/precip/trmm/3B42.V6/pp/0.25x0.25/av/monthly/update/ -->
>> \ncdump -c precipitation.3B42.1002.V6.nc
>> netcdf precipitation.3B42.1002.V6 {
>> dimensions:
>> longitude = 1442 ;
>> latitude = 722 ;
>> ...
>> longitude = -180.125,...,180.125
>> latitude = -90.125,...,90.125
>> ...
>> ...so the output file runs from longitude = -180.125 to 180.125 and from
>> latitude = -90.125 to 90.125 (a couple extra points added in each
>> direction, so be careful)
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> ...using a "global" longitude range, using x,y coordinates to define
>> exact boundaries:
>> ga-> sdfopen 3B42.1002.V6.nc
>> Scanning self-describing file: 3B42.1002.V6.nc
>> SDF file 3B42.1002.V6.nc is open as file 1
>> LON set to 0 360
>> LAT set to -49.875 49.875
>> LEV set to 0 0
>> Time values set: 2010:2:14:22 2010:2:14:22
>> E set to 1 1
>> ...
>> ga-> set y 1 400
>> LAT set to -49.875 49.875
>> ga-> set x 721 2160
>> LON set to 0.125 359.875
>> ga-> set sdfwrite precipitation.3B42.1002.V6.nc
>> SDFWrite file name = precipitation.3B42.1002.V6.nc
>> SDFWrite will replace an existing file
>> ga-> define precipitation = precipitation
>> Define memory allocation size = 4608000 bytes
>> ga-> sdfwrite precipitation
>> Wrote variable precipitation to precipitation.3B42.1002.V6.nc
>> cjs: /tmp/data/precip/trmm/3B42.V6/pp/0.25x0.25/av/monthly/update/ -->
>> \ncdump -c precipitation.3B42.1002.V6.nc
>> netcdf precipitation.3B42.1002.V6 {
>> dimensions:
>> longitude = 1440 ;
>> latitude = 400 ;
>> longitude = 0.125,...,359.875
>> latitude = -49.875,...,49.875
>> ...
>> ...so the output file runs from longitude = 0.125,...,359.8755 and from
>> latitude = -49.875,...,49.875
>> --------------------------------------------------------------------
>>
>> Could you try defining the variable to sdfwrite using parameters
>> appropriate to the netCDF file's original grid?
>>
>> Hope this helps,
>> Chuck
>>
>> On 04/12/2012 03:57 PM, Mark Hess wrote:
>>> I have a NetCDF file which I can ingest and display in GrADS with out a
>>> problem. The LON parameter is set to a 0-360 grid as opposed to 0-180W &
>>> 0-180E (or 0 to 180 for east and 0 to -180 for west). If I "set lon 239
>>> 244" and then display my variable of interest (in this case U), the data
>>> display properly showing the data between 116W-121W (116W equaling
>>> -116=244-360 and 121W equaling -121=360-239). That all is fine until I
>>> try to save my geographically subsetted area to a new .nc file using the
>>> sdfwrite function. The file saves fine, but it saves the LON information
>>> in the 0-360 format instead of the 0 to -180 format which I need for
>>> another application. Is there a way to either 1) save the new, subsetted
>>> .nc file with the lons converting to the in 0 to -180 format as part of
>>> the process or 2) convert the lon format within GrADS first and then
>>> save the new .nc file with the lon values in the format I want? Can I
>>> subtract 360 from my "lon" variable to create a 'new' lon variable?
>>> Thanks,
>>> Mark
>>>
>>>
>>> _______________________________________________
>>> gradsusr mailing list
>>> gradsusr at gradsusr.org
>>> http://gradsusr.org/mailman/listinfo/gradsusr
>>
>> --
>>
>> Please note that Charles.Seman at noaa.gov should be considered my NOAA
>> email address, not cjs at gfdl.noaa.gov.
>>
>> ********************************************************************
>> Charles Seman Charles.Seman at noaa.gov
>> U.S. Department of Commerce / NOAA / OAR
>> Geophysical Fluid Dynamics Laboratory voice: (609) 452-6547
>> 201 Forrestal Road fax: (609) 987-5063
>> Princeton, NJ 08540-6649 http://www.gfdl.noaa.gov/~cjs/
>> ********************************************************************
>>
>> "The contents of this message are mine personally and do not reflect any
>> official or unofficial position of the United States Federal Government,
>> the United States Department of Commerce, or NOAA."
>> _______________________________________________
>> gradsusr mailing list
>> gradsusr at gradsusr.org
>> http://gradsusr.org/mailman/listinfo/gradsusr
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jma at cola.iges.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20120418/e364ba27/attachment-0003.html
More information about the gradsusr
mailing list