NCL Website header
NCL Home > Documentation > Graphics

Common Graphical Error Messages

Wrong Coordinate Variables

    (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)    check_for_lon_coord: Warning: Data either does 
    not contain a valid longitude coordinate array or doesn't 
    contain one at all
    

The gsn_csm plot templates look for lat/lon coordinate array with one of the following names:

    lon, Lon, LON
    Longitude, longitude, LONGITUDE
    hlon,  long
    lon_u, lon_t
    xc
    

If your coordinate variable are geographic, rename them to one of the above:

    x!0="lat"
    x!1="lon"
    

Coordinate Variables do not have correct units attribute

    (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.
    

In addition to the correct coordinate variable name, the lat/lon cooridinate arrays are required to have a units attribute of one of the following forms:

    degrees_north, degree_north, degrees north, degrees_N
    degrees_east,  degree_east,  degrees east,  degrees_E
    

If appropriate, you can rename your units attribute to conform to the list above:

    x&lat@units="degrees_north"
    x&lon@units="degrees_east"
    

Non-gobal data

    (0)  gsn_add_cyclic: Warning: The range of your longitude data is not 360.
     You may want to set gsnAddCyclic to False to avoid a warning
     message from the spline function.
     

Several of the gsn_csm plot templates expect global data. As such they add a cyclic point to data to make the plotting accurate. If you have non-global (e.g. regional) data, you will see this error message. To fix the problem, you must specifically tell the template not to add the cyclic point.

     res@gsnAddCyclic = False
     

Map zoom techniques

     (0) gsn_csm_map_ce: Warning: you cannot use mpLimitMode = xxxx with
     the gsm_csm_map routines.
     

Only mpLimitMode equal to "LatLon", or "Corners" is accepted by this template.

Non-monotonic coordinate variables

     (0) warning:_NhlCreateSplineCoordApprox: Attempt to create spline
     approximation for Y axis failed: consider adjusting trYTensionF value
     warning:IrTransInitialize: error creating spline approximation for
     trYCoordPoints; defaulting to linear
     

Y (or X) coordinate array values are spaced irregularly enough that NCL can't figure out how to "interpolate" them to a linear axis.

This error is most commonly seen when there is a gap in the coordinate variable. The first step is to print out the deltas between the values in the coordinate array to see if they are constant.

Data too large to plot

     fatal:ContourPlotDraw: Workspace reallocation would exceed maximum size 16777216
     fatal:ContourPlotDraw: draw error
     fatal:PlotManagerDraw: error in plot draw
     fatal:_NhlPlotManagerDraw: Draw error
     

This error occurs when you are trying to contour a variable and the result is larger than 16mb. A 1000x1000 grid would certainly generate this message. I have not tested for the exact limit.

To fix, you can switch to raster mode (res@cnFillMode="RasterFill") which does not take as much memory, or increase the workspace memory. THE LATTER MAY BE ACCOMPLISHED BY PLACING THE FOLLOWING IMMEDIATELY AFTER OPENING THE WORKSTATION

     setvalues NhlGetWorkspaceObjectId()
       "wsMaximumSize": 300000000
     end setvalues
     

You can also permanately bump up your workspace size in your .hluresfile:

     *wsMaximumSize: desired value
     

You are missing a .hluresfile

 
     PLCHHQ - CHARACTER NUMBER 16 (x) IS NOT A LEGAL FUNCTION CODE

     PLCHHQ - CHARACTER NUMBER 19 (b) IS NOT A LEGAL FUNCTION CODE
     

this occurs because we have changed the default function code from a ":" to a "~" in our .hlurefiles, which has influenced all the examples on this web site.

ARSCAM/ARPRAM algorithm failure

 
ARSCAM/ARPRAM ALGORITHM FAILURE
This error message usually means something happened in a very low algorithm for generating the contours, cause by a precision error.

Unfortunately, there's no instant fix for this. We found that if you tweak certain things, like the size of the plot, the contour levels, the number of contours, etc, you might be able to get rid of this error message.

Meanwhile, we are interested in hearing from folks who run into this problem. We are particularly interested in examples that involve relatively simple input datasets. You can help us debug the problem by setting an additional resource along with your other contour resources:

  res@cnDumpAreaMap = True
When you run your script, it should echo a message like:
   Dumping areamap to file NhlAreaMap.0
Please send the "NhlAreaMap.0" file to Mary Haley and we'll take a look. We may also contact you to ask for more information.

More detailed description
There's a low-level package called AREAS that accepts as input groups of boundary lines in a plane (for example, contour lines generated by CONPACK/CONPACKT or geopolitical boundaries generated by EZMAP), puts them in a structure called an "area map", and then processes that structure to determine the collection of areas formed by the superimposed groups of lines. One of the routines of AREAS, called ARPRAM, performs a multi-step process to prepare the area map for use during subsequent calls to other routines of AREAS. The algorithm used by ARPRAM is inherently geometric in nature and would be exact if carried out using infinite-precision real arithmetic; unfortunately, it is not exact when carried out using the available limited-precision arithmetic. Practically speaking, what this means is that one of the steps leaves the area map in a state such that, when the next step is attempted, something unexpected happens, something that should not be possible, something that prevents that step, and subsequent steps, from being completed correctly and makes it unsafe to allow other AREAS routines to be called (because they might loop forever or produce completely incorrect results). At the moment, we understand what happens well enough to detect when it happens, to produce an error message (the infamous "ALGORITHM FAILURE"), and to quit trying to process the area map, but not well enough to fix whatever has gone wrong.

We have plans to look into this situation. Initially, we need to build tools allowing us to see exactly what it is that goes wrong in the area map to cause a failure. The resulting insight may allow us to either amend the algorithms to entirely avoid failures or to take remedial action allowing all the steps of the algorithm to complete (perhaps at the expense of a small glitch in the resulting output).