[ncl-talk] plotting model output where x/y are not lat/lon

Dave Allured - NOAA Affiliate dave.allured at noaa.gov
Fri Sep 11 17:56:05 MDT 2015


Mary and Dennis,

Mary showed several advantages of the use of the lat2d/lon2d special
attributes for 2-D coordinates.  I would like to retract my suggestion for
changing existing examples.

It seems to me that it is best to use sfXArray and sfYArray attributes only
in special cases when lat2d and lon2d are not sufficient.  Also, lat2d and
lon2d seem more understandable to me.  Perhaps the decision process for
which method could be enhanced on the "Overlaying data" documentation page:

http://www.ncl.ucar.edu/Document/Graphics/overlays_on_map.shtml

Dennis mentioned a performance problem:  "Each variable having an
associated @lat2d, @lon2d takes up memory."  Technically, I agree.
However, modern workstations have many Gbytes of RAM, so carrying around a
few extra medium size 2-D arrays is not noticeable unless you are repeating
full variable assignments within major processing loops.  So I think this
is not a significant problem for retaining lat2d/lon2d.

--Dave


On Fri, Sep 11, 2015 at 11:15 AM, Mary Haley <haley at ucar.edu> wrote:

> Hi Dave,
>
> I'm a bit torn about what to do with the examples, because ideally, we
> (NCL) would come up with a way to represent all types of "coordinate
> values" (true 1D coordinate arrays, 2D coordinate arrays, 1D arrays for
> "random" arrays, and something else for unstructured grids, like hexagonal
> or triangular meshes) through the NCL variable model.  We've always tried
> to model the NetCDF way of handling these variables, and it doesn't yet
> have a way to recognize all types of coordinates.
>
> We have kept the use of lat2d/lon2d attributes in the examples partly
> because we have advertised them for so long. Because of our strict
> backwards compatibility rule, we hope to always support this feature unless
> it becomes unreasonable to do so (which I don't foresee).
>
> We also use this method in our ESMF regridding, because it's the only way
> to "sneak" in these special coordinate arrays to the "ESMF_regrid" routine.
> ESMF_regrid will look for "lat2d/lon2d" attached to the variable, and it
> will also return lat2d/lon2d if regridding to a curvilinear grid. The same
> is true for "lon1d/lat1d", which is a quick-and-dirty way to pass in 1D
> arrays of lat/lon for a 1D variable that is potentially "random".
>
> There's one minor correction to what Dennis said about using one method
> over the other for plotting: if you have lat2d/lon2d attributes attached to
> your data when plotting, and you set res at gsnAddCyclic = True, then the
> gsn_csm_xxxx plotting routines will know how to properly add the cyclic
> point.  However, if you use sfXArray and sfYArray resources, gsnAddCyclic
> doesn't know anything about these.
>
> We have it on our list to modernize many of our aging NCL scripts, and we
> will add more examples that show the two ways of doing things.
>
> --Mary
>
>
> On Fri, Aug 28, 2015 at 4:15 PM, Dave Allured - NOAA Affiliate <
> dave.allured at noaa.gov> wrote:
>
>> Dennis,
>>
>> Thank you for the information about preferred resources sfXArray and sfYArray
>> for 2-D coordinates, and the reason why this is optimal.  I learned
>> something new here.
>>
>> Several NCL examples and at least one documentation page are advocating
>> the less optimal method using lat2d and lon2d attributes.  Perhaps these
>> examples and pages could eventually be updated to use sfXArray and sfYArray
>> instead.
>>
>> --Dave
>>
>>
>> On Fri, Aug 28, 2015 at 3:54 PM, Dennis Shea <shea at ucar.edu> wrote:
>>
>>> Will's suggestion is correct.
>>>
>>> -----
>>>
>>> FYI: The ***only*** time you should assign the reserved attributes:
>>> @lat2d,   @lon2d is for plotting.
>>>
>>> In fact, the NCL-team would prefer that people use the following
>>> rather than the reserved attributes.
>>>
>>>      res at sfXArraya   = lon2d
>>>      res at sfYArray     = lat2d
>>>      res at trGridType  = "TriangularMesh"
>>>
>>> ---
>>>
>>> Each variable having an associated  @lat2d, @lon2d takes up memory.
>>> If 5 variables  a, a at lat2d, a at lon2d, ...  b, c, d, e then each will
>>> require the necessary memory.
>>> Firther, if you write to netCDF via
>>>
>>>      fnc->A = a
>>>      fnc->B = b
>>>      fnc->C = c
>>>      fnc->D = d
>>>      fnc->E = e
>>>
>>> Then the lat2d/lon2d arrays will be written 5 times (one for each
>>> variable).
>>>
>>>     fnc->LAT2D = lat2d
>>>     fnc->LON2D = lon2d
>>>
>>> Will write each variable  only once!
>>>
>>> Cheers
>>>
>>>
>>> On Fri, Aug 28, 2015 at 3:38 PM, Will Hobbs <Will.Hobbs at utas.edu.au>
>>> wrote:
>>> > Mira
>>> >
>>> > To keep all the attributes from 'sf'....
>>> >
>>> >> sf_total = sf(0,:,:)     ;sf_total is now a 2-da array with all the
>>> >>attributes and rightmost dimensions of sf
>>> >> sf_total = dim_sum_n(sf,0)
>>> >
>>> > Will
>>> >
>>> >
>>> > On 29/08/15 5:26 AM, "mberdahl at envsci.rutgers.edu"
>>> > <mberdahl at envsci.rutgers.edu> wrote:
>>> >
>>> >>Excellent, this worked!  Thank you!
>>> >>I just have a quick follow-up question.  Once I assign the lat and lon
>>> to
>>> >>my variables (for example:  sf at lon2d = lon2d, sf at lat2d = lat2d), and
>>> then
>>> >>I would like to do a calculation with sf (eg. sf_total =
>>> dim_sum_n(sf,0)),
>>> >>it seems I have to assign the the new variable the lat and lon again.
>>> Is
>>> >>there a way to keep the lat and lon following through the calculations
>>> >>without always reassigning them?
>>> >>I hope that makes sense.
>>> >>Thanks,
>>> >>Mira
>>> >>
>>> >>
>>> >>> Here is more information about dat with 2-D coordinates.  I was
>>> typing
>>> >>> this
>>> >>> up when I saw Will's reply.  Some of the other examples indicate
>>> >>> that trGridTrype may not be needed with some data sets.
>>> >>>
>>> >>> Please see section #2 on this documentation page, for a basic
>>> >>>description.
>>> >>> Notice the several different working examples:
>>> >>> https://www.ncl.ucar.edu/Document/Graphics/overlays_on_map.shtml
>>> >>>
>>> >>> (Please ignore the link "2D vertical coordinates", that is not about
>>> >>> geographic surface maps, and can be confusing.)
>>> >>>
>>> >>> The simplest example for making map plots with 2-D coordinates is
>>> >>>example
>>> >>> 3
>>> >>> on this page:
>>> >>> https://www.ncl.ucar.edu/Applications/ice.shtml
>>> >>>
>>> >>> I also like NARR example 4 because it shows how the 2-D coordinate
>>> >>>method
>>> >>> can be used with different map projections:
>>> >>> http://www.ncl.ucar.edu/Applications/narr.shtml
>>> >>>
>>> >>> --Dave
>>> >>>
>>> >>>
>>> >>> On Thu, Aug 27, 2015 at 9:35 PM, Will Hobbs <Will.Hobbs at utas.edu.au>
>>> >>> wrote:
>>> >>>
>>> >>>> Mira
>>> >>>>
>>> >>>> It looks like you have 2-d lat and lon arrays associated with your
>>> >>>>data,
>>> >>>> as is often the case with models (especially ocean models).
>>> >>>>
>>> >>>> This can be plotted by NCL without regridding, see the examples
>>> here:
>>> >>>> http://www.ncl.ucar.edu/Applications/ease.shtml
>>> >>>> Although you are not using the EASE grid, the principal is exactly
>>> the
>>> >>>> same:
>>> >>>>
>>> >>>> 1. Set your map plot grid type resource
>>> >>>> >res at trGridTrype = "TriangularMesh"
>>> >>>>
>>> >>>> 2. Set the lat and lon arrays as attributes of the array you are
>>> >>>> plotting,
>>> >>>> so if your array is 'x'
>>> >>>> > x at lat2d = LAT
>>> >>>> > x at lon2d = LON
>>> >>>>
>>> >>>> The just use one of the gsn_csm contour map plotting functions as
>>> >>>> normal.
>>> >>>>
>>> >>>> I hope that's clear.
>>> >>>>
>>> >>>> Will
>>> >>>>
>>> >>>>
>>> >>>> On 28/08/15 1:27 PM, "Yuqiang Zhang" <yuqiangzhang.thu at gmail.com>
>>> >>>>wrote:
>>> >>>>
>>> >>>> >Hi Mira,
>>> >>>> >
>>> >>>> >Check the link here
>>> >>>> >http://www.ncl.ucar.edu/FAQ/
>>> >>>> >For Q 27:
>>> >>>> >
>>> >>>> >When I call one of the gsn_csm_xxxx_map plotting scripts, I get an
>>> >>>> error
>>> >>>> >message about a units attribute not being correct.
>>> >>>> >If you are using one of the gsn_csm_xxx_map functions to overlay
>>> data
>>> >>>> on a
>>> >>>> >map, and seeing one or both of the following error messages:
>>> >>>> >
>>> >>>> >    (0)   is_valid_lat_ycoord: Warning: The units attribute of
>>> >>>> >    the Y coordinate array is not set to one of the allowable
>>> >>>> >    units values (i.e. 'degrees_north'). Your latitude labels
>>> >>>> >    may not be correct.
>>> >>>> >
>>> >>>> >    (0)   is_valid_lat_xcoord: Warning: The units attribute of
>>> >>>> >    the X coordinate array is not set to one of the allowable
>>> >>>> >    units values (i.e. 'degrees_east'). Your longitude labels
>>> >>>> >    may not be correct.
>>> >>>> >then this means that your data contains coordinate arrays, but the
>>> >>>> >coordinate arrays either don't have the necessary "units"
>>> attribute,
>>> >>>>or
>>> >>>> >it's
>>> >>>> >not set to one of the allowable values ("degrees_east" for
>>> longitude
>>> >>>> >values
>>> >>>> >and "degrees_north" for latitude values).
>>> >>>> >If your coordinate arrays are indeed degrees east and degrees
>>> north,
>>> >>>> then
>>> >>>> >you can set the units attribute as follows (this code snippet
>>> assumes
>>> >>>> your
>>> >>>> >data array is called "data" and that the coordinate arrays are
>>> called
>>> >>>> >"lat"
>>> >>>> >and "lon"):
>>> >>>> >
>>> >>>> >  data&lat at units = "degrees_north"
>>> >>>> >  data&lon at units = "degrees_east"
>>> >>>> >
>>> >>>> >Regards,
>>> >>>> >Yuqiang
>>> >>>> >
>>> >>>> >-----Original Message-----
>>> >>>> >From: ncl-talk-bounces at ucar.edu [mailto:ncl-talk-bounces at ucar.edu]
>>> On
>>> >>>> >Behalf
>>> >>>> >Of mberdahl at envsci.rutgers.edu
>>> >>>> >Sent: Thursday, August 27, 2015 10:21 PM
>>> >>>> >To: ncl-talk at ucar.edu
>>> >>>> >Subject: [ncl-talk] plotting model output where x/y are not lat/lon
>>> >>>> >
>>> >>>> >Hi all,
>>> >>>> >
>>> >>>> >I'm trying to make a simple plot of cumulative snowfall with data
>>> from
>>> >>>> a
>>> >>>> >model I did not run.  When I try to make a simple plot, I receive
>>> the
>>> >>>> >following error:
>>> >>>> >
>>> >>>> >(0)     check_for_y_lat_coord: Warning: Data either does not
>>> contain a
>>> >>>> >valid latitude coordinate array or doesn't contain one at all.
>>> >>>> >(0)     A valid latitude coordinate array should have a 'units'
>>> >>>> attribute
>>> >>>> >equal to one of the following values:
>>> >>>> >(0)         'degrees_north' 'degrees-north' 'degree_north' 'degrees
>>> >>>> north'
>>> >>>> >'degrees_N' 'Degrees_north' 'degree_N' 'degreeN' 'degreesN' 'deg
>>> >>>>north'
>>> >>>> >(0)     check_for_lon_coord: Warning: Data either does not contain
>>> a
>>> >>>> valid
>>> >>>> >longitude coordinate array or doesn't contain one at all.
>>> >>>> >(0)     A valid longitude coordinate array should have a 'units'
>>> >>>> attribute
>>> >>>> >equal to one of the following values:
>>> >>>> >(0)         'degrees_east' 'degrees-east' 'degree_east' 'degrees
>>> east'
>>> >>>> >'degrees_E' 'Degrees_east' 'degree_E' 'degreeE' 'degreesE' 'deg
>>> east'
>>> >>>> >
>>> >>>> >
>>> >>>>
>>>
>>> >>>>>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>> >>>> >
>>> >>>> >When I dump the file it looks like this:
>>> >>>> >
>>> >>>> >netcdf ICE.1983.01-12.f77 {
>>> >>>> >dimensions:
>>> >>>> >        TIME = UNLIMITED ; // (365 currently)
>>> >>>> >        X10_69 = 60 ;
>>> >>>> >        Y18_127 = 110 ;
>>> >>>> >        SECTOR = 2 ;
>>> >>>> >        SECTOR1_1 = 1 ;
>>> >>>> >        ATMLAY14_23 = 10 ;
>>> >>>> >        bnds = 2 ;
>>> >>>> >        ATMLAY23_23 = 1 ;
>>> >>>> >        ATM6H3_3 = 1 ;
>>> >>>> >        OUTLAY = 20 ;
>>> >>>> >        OUTLAY1_1 = 1 ;
>>> >>>> >
>>> >>>> >variables:
>>> >>>> >        double TIME(TIME) ;
>>> >>>> >                TIME:units = "HOURS since 1901-01-15 00:00:00" ;
>>> >>>> >                TIME:long_name = "time" ;
>>> >>>> >                TIME:time_origin = "15-JAN-1901 00:00:00" ;
>>> >>>> >                TIME:axis = "T" ;
>>> >>>> >        float DATE(TIME) ;
>>> >>>> >                DATE:units = "YYYYMMDDHH" ;
>>> >>>> >                DATE:long_name = "Date(YYYY MM DD HH)" ;
>>> >>>> >                DATE:history = "From ICE.f77.1983.01.01-15" ;
>>> >>>> >        double X10_69(X10_69) ;
>>> >>>> >                X10_69:units = "km" ;
>>> >>>> >                X10_69:long_name = "x" ;
>>> >>>> >                X10_69:point_spacing = "even" ;
>>> >>>> >                X10_69:axis = "X" ;
>>> >>>> >
>>> >>>> > double Y18_127(Y18_127) ;
>>> >>>> >                Y18_127:units = "km" ;
>>> >>>> >                Y18_127:long_name = "y" ;
>>> >>>> >                Y18_127:point_spacing = "even" ;
>>> >>>> >                Y18_127:axis = "Y" ;
>>> >>>> >        float LON(Y18_127, X10_69) ;
>>> >>>> >                LON:units = "degrees" ;
>>> >>>> >                LON:long_name = "Longitude" ;
>>> >>>> >                LON:history = "From ICE.f77.1983.01.01-15" ;
>>> >>>> >        float LAT(Y18_127, X10_69) ;
>>> >>>> >                LAT:units = "degrees" ;
>>> >>>> >                LAT:long_name = "Latitude" ;
>>> >>>> >                LAT:history = "From ICE.f77.1983.01.01-15" ;
>>> >>>> >
>>> >>>> >Clearly there are lats and lons associated with the x and y
>>> spacing,
>>> >>>> but
>>> >>>> >I'm
>>> >>>> >not sure how to tell NCL how to use those.  Does anyone have
>>> advice on
>>> >>>> >this?
>>> >>>> >
>>> >>>> >Thanks in advance,
>>> >>>> >Mira
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20150911/3f30a266/attachment.html 


More information about the ncl-talk mailing list