Known bugs in NCL

[How to report an NCL bug]

  • In versions 5.1.1 and earlier, there's a bug in rho_mwjf causing it to give the wrong value for depths > 0.

  • In versions 5.1.1 and earlier, you didn't have much control over the drawing order of primitives when you used the functions gsn_add_polygon, gsn_add_polyline, and gsn_add_polymarker.

    Now, when you call these functions, you can additionally set the special tfPolyDrawOrder resource and set it to "PreDraw", "Draw", or "PostDraw" to indicate which phase to draw the primitives, relative to the given plot's other elements (like map fill, map outlines, contour lines, contour labels).

  • In version 5.1.1, the ut_inv_calendar function has a bug in which if you use one of the "360", "360_day", "365", "365_day", or "noleap" calendars, you will get an error: 

      Error, udu_lib_version not set to value value: -1

    A work-around is to call ut_calendar first with dummy data, which internally forces udu_lib_version to be correctly initialized. You can use these three lines: 

      dum_time       = 17522904
  dum_time@units = "hours since 1-1-1 00:00:0.0"
  dum_date       = ut_calendar(dum_time, 0)
    This bug has been fixed and will be available in the next release.

  • In version 5.1.0, the addfiles function had some serious bugs. We hightly recommend upgrading to V5.1.1.

    1. One bug was that striding across the leftmost dimension was not working correctly: 

        f    = addfiles("file*07*.nc","r")
  xnew = f[:]->x(::5,:,:)

    2. The second serious bug is that if the data extracted from the first file of an aggregated variable was reduced to a single value, the returned variable was incorrectly internally tagged as a scalar. When accessed without subscripts, this had the strange effect of returning the proper number of elements but giving them all the value of the first element. Here's an example of the problem: 

        fnames = (/ "file01.nc", "file02.nc" /)
  fp = addfiles(fnames, "r")
  days = fp[:]->days
  print(days)
  days = days / sum(days)
  print(days)

      Adding a subscript makes it work correctly: 

         days(:) = days(:) / sum(days)

  • vinth2p, vinth2p_ecmwf, vintp2p_ecmwf - Mark Branson (Colorado State University) was examining interpolated values at the uppermost interpolated levels. He discovered a bug.

    An example will be used to illustrate the bug:

    Consider temperatures [TM (K)] at the following model hybrid levels [PM (hPa)]: 

              PM      TM        <=== Raw Data
        3.64    226.77
        7.59    225.53
       14.36    224.89
       24.61    221.39
       38.27    213.97
      [snip]
    Let's say that interpolation to the following pressure levels (PI) is desired: 

            PI = (/ 5, 7, 10, 20, 30, 50, ...... /)
    The following shows the values interpolated by the vinth2p and vinth2p_ecmwf functions before (v5.1.0) and after (v5.1.1) the bug fix: 

            PI    v5.1.0    v5.1.1    diff
         5    225.78    226.34   0.564
         7    225.59    225.72   0.129
        10    225.30    225.30   0.000 No differences
        20    222.96    222.96   0.000
    [snip]
    The differences could be 'small' or 'large'. It depends upon the vertical distribution of the variable.

  • If you have version 5.1.0 of NCL for a 64-bit (x86_64) Linux system, then you may have problems reading GRIB2 files. Try downloading the same binary again and reinstalling it; we fixed this bug about a few weeks after 5.1.0 was released.

  • There's a bug in sprintf and sprinti that in some cases causes the second input variable to incorrectly have an extra attribute added. The following script illustrates the problem. This bug has been in NCL for several years, and affects numerous other functions as well.

    A work-around is mentioned below. 

    
  x  = random_uniform(-10,10,(/3,4,5/))
  ix = floattoint(x)

  x!0 = "time"
  x!1 = "lat"
  x!2 = "lon"
  x&time = ispan(0,2,1)
  x&lat  = ispan(0,3,1)
  x&lon  = ispan(0,4,1)
  ix!0 = "time"
  ix!1 = "lat"
  ix!2 = "lon"
  ix&time = ispan(0,2,1)
  ix&lat  = ispan(0,3,1)
  ix&lon  = ispan(0,4,1)

  oldx  = x    ; Save a copy
  oldix = ix   

  print("----------------------- BEFORE -----------------------------")
  printVarSummary(x)    ; Note there's no "time" attribute attached to "x".
  printVarSummary(ix)

  s  = sprintf("%5.2f",x(0,:,:))
  is = sprinti("%2i",ix(0,:,:))

  print("----------------------- AFTER -----------------------------")
  printVarSummary(x)    ; Note "x" and "ix" now have "time" attributes
  printVarSummary(ix)
    A work-around is to use "(/" and "/)" around the variables: 

      s  = sprintf("%5.2f",(/x(0,:,:)/))
  is = sprinti("%2i",(/ix(0,:,:)/))

  • If you are using wrf_user_unstagger to get the diagnostics "ua" and "va", then you will need to download a new WRFUserARW.ncl file.

    Load this file instead of $NCARG_ROOT/lib/ncarg/nclscripts/wrf/WRFUserARW.ncl.

    This bug was fixed after V5.1.0 was released.

  • If you are trying to set "_FillValue" for a logical variable using "True" or "False", you will get an error. Use the new "_Missing" keyword instead, or set the missing value when you use new: 

      l = new(1,logical,False)

    This new behavior was intended to fix a previous oddity with logical missing values, but apparently it introduced other problems.

  • There's a bug if you read a character variable that contains a missing value off a NetCDF file. The missing value will not be set correctly. This was fixed after the release of V5.1.0.

  • If you are using wgt_arearmse on a Sun system, you might get an out-of-the-blue "syntax error" message on the calling line, even though there's no syntax error. This has been fixed in V5.1.0.

  • If you use decimalPlaces with negative numbers, you will get incorrect results. Download this decimalPlaces.ncl script, and load it after "contributed.ncl" is loaded, and it should work: 

    load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl"
load "decimalPlaces.ncl"

  • If you use the version 5.0.0 OPeNDAP-enabled NCL binary, you may see the following error when opening a netCDF file, but only after you leave the NCL script: 

       ncclose: ncid 0: NetCDF: Not a valid ID
    We verified this is a bug created by recent changes to NCL's handling of its internal cleanup and exit procedures. This bug has been fixed and will be available in V5.1.0.

    Note that this does not cause a problem in reading netCDF files. When you write a file, however, you may have to delete the file handler variable before you exit the script, by using the delete procedure: 

    begin
  ...
  f = addfile("newfile.nc","w")
  ...write stuff to file pointed to by 'f'.
  delete(f)
end

  • In the functions dtrend and dtrend_msg, if return_info was set to True and the input y was double and had more than one dimension, then you would get a segmentation fault or incorrect results.

    You can work around this problem by coercing your double input array to float using dble2flt.

    Status: we have fixed this bug and it will be in the 4.3.0 release.

  • lspoly doesn't work if any of the input arrays are not float or double. You can work around this problem by making sure your input arrays are float or double.

    Status: we have fixed this bug and it will be in the 4.3.0 release.

  • numAsciiRow doesn't work in version 4.2.0.a034 (it may appear to cause your program to hang). You can easily fix the problem yourself by editing the file:
    $NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl
    and changing the line: 

      nrow_s    = systemfunc("'wc' -l" + fNam +" | awk '{print $1}'" )
    to have a space after the "-l": 

      nrow_s    = systemfunc("'wc' -l " + fNam +" | awk '{print $1}'" )

    Status: we have fixed this bug and it will be in the 4.3.0 release.

  • If you set xyMarkerSizeF to 0.015, you would notice that the markers got noticeably smaller than if you set them to 0.014 or 0.016.

    Status: we have fixed this bug and it will be in the a034 release.

  • If you set the environment variables NCL_DEF_SCRIPTS_DIR or NCL_DEF_LIB_DIR to invalid directories, you may get a bus error or a segmentation fault, followed by a core dump. To work around this problem, don't set these environment variables, or set them to valid directories.

    Status: we have fixed this bug and it will be in the a034 release.

  • If you use the "-x" option with NCL when running a batch script, and your main program contains a "begin" and "end" statement, every single line of the script will be echoed before the script is even executed. The lines are supposed to be echoed as they are executed, allowing the user to see where a script is failing, if necessary.

    Status: we have not fixed this bug and don't have a projected fix date yet.

  • There was a "bug" encountered with the monthly GODAS files where monthly average variables were given different names depending on the number of days in the month. Now, if the calculations work out properly to show that the first day of the time period is the 1st day of the month and the last day of the time period is the last day of the month, then the suffix applied is "ave1m" instead of "aveXXd". Leap years are accounted for.

    Status: we have fixed this bug and it will be in the a034 release.

  • There's a bug in GRIB code's handling of time indicator index 10 in which the indicator index wasn't being tacked on to the variable name.

    Status: we have fixed this bug and it will be in the a034 release.

  • There's a bug in the exp_tapersh in which if your input values are not double, the weights aren't being applied to the data, and hence you get the same values back.

    Status: we have fixed this bug and it will be in the a034 release. Meanwhile, use the function version, exp_tapershC instead.

  • If you use printing functions like print or printVarSummary interactively in version a033, the output will scroll continuously and not allow paging.

    Status: we have fixed this bug, but probably won't release a new version right away. If you downloaded a033 and want a fix now, email ncladmin@ucar.edu.

  • Some people with color PostScript printers have reported a disparity between colors in a filled contour plot, and the corresponding labelbar. The problem only shows up if you are doing a raster contour plot. We believe the problem is not with NCL, but with how the color printer is interpreting the color instructions in the PS file.

    Status: we did some initial research to try to force the labelbar to be drawn as a raster image as well, but this didn't seem to make a difference. This is on the back burner for now, since it appears to be a PS printer bug.

  • eofunc, eofunc_ts, eofunc_Wrap, eofunc_ts_Wrap functions

    A user has reported an instance where the EOFs returned by eofunc were inconsistent with those from eofcov. eofunc is potentially much faster than the eofcov function, and is the preferrable routine to use. However, to be confident in your results, please try both functions and compare the results. Please send any information on differences to Dennis Shea.

    Status: we did some tests to show that eofunc works just fine on some classic textbook examples. We are currently looking into implementing another version of this routine to compare some more results.

  • qsort

    A problem was reported in which the following short script was using up a bunch of memory: 

    begin 
 do i = 0,200 
  print((/i/)) 
  x1D = new((/4000000/),integer) 
  x1D = 1 
  qsort(x1D) 
  delete(x1D) 
 end do 
end
    Status: this bug was fixed in version 4.2.0.a033.

  • solve_linsys

    This function was not working correctly if the leftmost dimension of B was not the same as the rightmost dimension.

  • Problem with "hours since" time variables in GRIB files

    In release 4.2.0.a032 of NCL, two new time variables were introduced for GRIB data being read in. Of these, the new variable "initial_time0_hours" (units: "hours since 1800-01-01 00:00") was found to be off by 48 hours. The other time related variables "initial_time0_encoded" (units "yyyymmddhh.hh_fraction") and "initial_time0" (units "mm/dd/yyyy (hh:mm)") are correct.

    As a temporary work-around, for times after 1900-01-01 00:00, you must add 48 hours to the values returned by NCL.

    Status: this bug was fixed in version 4.2.0.a033.

  • asciiread

    There was a problem with this function that caused it to read in lone periods (".") as float values equal to "0". For example, if you had the string "The data file is called file.cdf", it would treat the period in "file.cdf" as the value 0.

    Status: this bug was fixed in version 4.2.0.a032.

  • Coordinate subscripting problems

    1. If you subscripted an array using coordinate subscripting, and gave it a "finish" subscript and not a "start" subscript, then you may have gotten one extra coordinate value. For example, the simple script below demonstrates this: 

      begin
  level = (/1.5,2.5,3.5,4.5,5.5/)

  lev   = (/level/)
  lev!0 = "lev"
  lev&lev = level

  lev1 = lev({:3}) 
  lev2 = lev({0:3})

  print(lev1)
  print(lev2)
end
      The two arrays lev1 and lev2 should be identical and equal to (/1.5,2.5/). However,, lev1 was incorrectly getting the values (/1.5,2.5,3.5/).

    2. If you tried to use coordinate subscripting without actually using a subscript value, as in: 

          buf2 = buf({lev|:},{lon|:},{lat|30:50})
      it would sometimes cause a core dump.

    3. There was a problem with coordinate array subselection using double coordinate values: the coordinate values were only being compared to float precision.

      This fix allows the following code to execute correctly: 

        coord = (/1234.5678901230d,1234.5678901231d,1234.5678901232d,\
            1234.5678901233d /)

  h   = (/ 4,5,6,7 /)
  h!0 = "coord"
  h&coord = coord
  printVarSummary(h)
  print(h&coord)

  v1 = 1234.56789012305d
  v2 = 1234.56789012311d
  v  = h({v1:v2})
  print(v)

  v  = h({1234.56789012305d:1234.56789012319d})
  print(v)

      Status: all of these bugs were fixed in version 4.2.0.a032.

  • Problems reading netCDF files that had multi-dimensional variables with the same name as a dimension.

    NCL is now tolerant of netCDF files where a multi-dimensional variable has the same name as a dimension (in other words, something that NCL saw as a coordinate variable, and wanted it to be one-dimensional). NCL no longer assumes that a variable with the same name as a dimension is a coordinate variable unless the variable has a single dimension.

    Status: this bug was fixed in version 4.2.0.a032.