Known bugs in NCL

• Misleading error message with OPeNDAP-enabled version of NCL. - fixed for version 5.0.1
• dtrend and dtrend_msg don't work under a certain set of conditions. - fixed in version 4.3.0
• lspoly doesn't work if any of the input arrays are not float or double. - fixed in version 4.3.0
• numAsciiRow doesn't work in version 4.2.0.a034. - fixed in version 4.3.0
• Bug if xyMarkerSizeF was set to exactly 0.015 - fixed
• Bug if NCL_DEF_SCRIPTS_DIR or NCL_DEF_LIB_DIR are set to invalid directories - fixed
• Bug with "-x" option in NCL - pending
• Bug in reading monthly GODAS GRIB files - fixed
• Bug in GRIB code's handling of time indicator index 10 - fixed
• Bug in exp_tapersh - fixed
• Paging turned off for various "print" functions - fixed
• Possible disparity in labelbar colors - pending
• Possible bugs in eofunc* routines - fixed
• Bug in solve_linsys function - fixed
• Bug in qsort procedure - fixed
• Problem with "hours since" time variables in GRIB files - fixed
• Bug in asciiread routine - fixed
• Coordinate subscripting problems - fixed
• Problems reading netCDF files that had multi-dimensional variables with the same name as a dimension - fixed

• 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.0.1.

  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 Mary Haley.

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

How to report an NCL bug

If you'd like to report an NCL bug, send email to the ncl-talk list. At a minimum, please email the following information along with your bug report:

• The version of NCL you are running (ncl -V)

• The type of system you are on, and what operating system you are running (if you don't know, then the output from "uname -a" can be sent instead).

• The exact error message you are getting. If there is no error message, then a detailed description of the problem or an actual picture (like a PostScript or PDF or NCGM file) is useful.

• What is really useful (but not required unless we can't reproduce the bug) is a simplified version of your script and any necessary data files so we can run it at our end.