ncar / ncl Goto Github PK

WRF-NCL and WRF-Python were originally based off the same Fortran routines. There have been several improvements made to WRF-Python that need to be integrated back into NCL.

from: Daniel Adriaansen - NCAR [email protected]
to: Ncl-talk [email protected]
date: Thu, Aug 23, 2018 at 1:53 PM
subject: [ncl-talk] gsnPanelLabelBar with gsn_csm_blank_plot

Hello,

I am paneling some contour plots using gsn_panel. Each panel is a contour plot corresponding to different data from unique files. If a file is missing, in lieu of calling gsn_csm_contour, I call gsn_csm_blank_plot to keep the workspace symmetric. This works except when gsn_csm_blank_plot is the "upper-left-most" panel. In that case, gsn_panel fails and returns the error:

fatal:Variable (mono_fill_scl) is undefined

I found this old ncl-talk ticket from 2017:
http://mailman.ucar.edu/pipermail/ncl-talk/2017-April/008585.html

There it describes how the gsnPanelLabelBar resource doesn't play nicely when the plots being paneled are X-Y plots. Indeed, when I set this resource to False my code runs successfully, however I am not creating any X-Y plots. To make matters more confusing, if I call gsn_csm_blank plot in any other position than the "upper-left-most", then it works just fine. It's only when the "upper-left-most" panel is gsn_csm_blank_plot that my script fails.

It looks like based on the NCL documentation that "The common label bar is draw from the first plot, and assumes all are the same." (https://www.ncl.ucar.edu/Applications/panel.shtml). Also on that page, I see a resource called "gsnPanelScalePlotIndex", which is used to control which plot in the list of plots to panel to obtain scale factor information from. Is there a way to control the same thing but for the common label bar?

Thanks in advance!

-Dan

NCAR/UCAR has a new Code of Conduct documentation that is required for all software projects that needs to be incorporated into the next release of NCL.

ncarg2d/src/libncarg/ezmapCC/c_mdfnme.c

"#else" must be added between line 36 and line 37.
If not added, function c_mdfnme will not work and return only NULL('\0'').

NCAR/nclcomp#1

See Jira NCL-2744. It appears Alan Brammer contributed a fix for this. There's a lingering issue of the script not creating the correct/desired file suffix ( ":.nc" instead of ".nc4" ). This issue came in and was investigated late into the 6.5.0 release, and so did not make it into that release. Should be relatively trivial to fix, but needs testing.

This is based on JIRA NCL-2634

An example needs to be created on the "drawing locations of data values using marker or lines" examples page. Originally the ticket was to update gsn_coordinates:

In order to use gsn_coordinates to draw things like hexagonal or triangular meshes, the code needs to be updated to allow for edges to be input.

See datagrid_9.ncl, which at the time this ticket was created hadn't been added to the NCL website.

This worked in NCL V6.3.0 and was broken in V6.4.0 and V6.5.0. See attached two images.

As part of improving NCL for open development, the NCL source code may be factored into three components, each which will become a separate repository:

Core - this represents the NCL language itself, and will also contain NCL file I/O (addfile) since this is tied directly with the NCL variable model

Visualization - this will include the HLU library, NCAR Graphics, and any programs (idt, rasxxx, ctrans) that are associated with graphics

Computational - this will include the computational routines associated with NCL, and will mainly consist of C and Fortran codes.

It would be nice if NCL had an autotools based build system. ;-)

@marylhaley and I have been discussing in email, but I am transferring the discussion here so that the info is in one place.

The initial goals are:

• An autotools build for NCAR graphics library and related files.
• New build system to exist alongside existing build system, will not interfere with existing builds.
• Improvements in build process will be deferred until new build system correctly matches the existing build.

See issue #19

WRF-Python has some new interpolation functionality that needs to be incorporated back into NCL.

Sam McClatchie reported this problem. If either the Y or X axes is reversed, then the contour plot disappears. See the attached NCL script and sample images, which were generated with NCL V6.4.0. The second image is missing the contours.

In ncarg port in MacPorts that I maintain, setfileoption is problematic. With 6.4.0 a call to setfileoption seems to destroy the symbol table (example).

More seriously, segmentation fault 11 is raised with 6.5.0. I tried gcc6, 7, and 8 on Sierra and High Sierra only to fail.

In the past (6.1.2) setfileoption also caused seg fault, disappeared with a newer version of gcc at that time (ticket).

I looked at the source code, but I was not able to figure out a solution.

Dennis reported that WRAPIT was failing with the attached code, reporting only "error while parsing" and no other indication as to why. Long story short - the fortran code contains CR/NL line delimiters and wrapit77's grammar does not expect nor while tolerate them. This was verified by stripping out the CR's:

cat test.NCL.f | sed 's/\r$//' | cat >testNCL_noCR.f

Its an easy patch to the grammar, one that I had done for NCL's grammar sometime back.

(See Jira NCL-2752 for a code with CR-NLs that exercises this issue.)

NCL has an internal test suite that is not visible to users. We want to integrate components of this into GitHub, either as a separate repo or part of the NCL repo. It will also become part of the continuous integration process.

See this article about the cividis colormap:

https://www.scientificamerican.com/article/end-of-the-rainbow-new-map-scale-is-more-readable-by-people-who-are-color-blind/

The color table as it could be used by NCL is attached.

[Ticket carried over from JIRA NCL-2766]

This bug seems to be related to convergence & tolerance behaviors in the fortran code. Am putting it into 6.6.0, as there is another bug for this release that involved eoffunc_variman(). See Jira NCL-2481 for discussion and test files.

I use both ncl 6.3.0 and 6.4.0 to do a varimax rotation eof. But the result is not what I expected, although the eof is right.

This is the related code:

neof=10
opteof = True
opteof@jopt = 1;0:covariance matrix,1:correlation matrix
opteofts=False
opteofts@jopt=1;0:original data for ts(default),1:standerized data for ts

;TP
latS  = -60
latN  = 60
lonW = 120
lonE = 300

x:=wSST({lat|latS:latN},{lon|lonW:lonE},time|:)

eof_tp    = eofunc_Wrap( x, neof, opteof)                        ;(neof,lat,lon)
eof_tp_ts = eofunc_ts_Wrap( x, eof_tp, opteofts)                    ;(neof,time)
printVarSummary(eof_tp)
printVarSummary(eof_tp_ts)
print(eof_tp@pcvar)
print(eof_tp@eval)

nreof=3
;a=v*^
eof_tp_scaled=eof_tp
do i=0,neof-1
        eof_tp_scaled(i,:,:)=eof_tp(i,:,:)*sqrt(eof_tp@eval(i))
        copy_VarMeta(eof_tp,eof_tp_scaled)
end do

eof_tp_rot = eofunc_varimax_Wrap(eof_tp_scaled,0)
printVarSummary(eof_tp_rot)
print(eof_tp_rot@pcvar_varimax)
print(eof_tp_rot@variance_varimax)

print("reordering")
eofunc_varimax_reorder ( eof_tp_rot ) ; reorder the information
eof_tp_rot_ts  = eofunc_ts_Wrap(x, eof_tp_rot, False)
printVarSummary(eof_tp_rot)
;printVarSummary(eof_tp_rot_ts)
print(eof_tp_rot@pcvar_varimax)
print(eof_tp_rot@variance_varimax)

And it produce this(the problem is pcvar_varimax is a constant value,and the eof_rot is not reordered correctly):

Variable: eof_tp_rot
Type: float
Total Size: 222040 bytes
            55510 values
Number of Dimensions: 3
Dimensions and sizes:   [evn | 10] x [lat | 61] x [lon | 91]
Coordinates:
            evn: [1..10]
            lat: [-60..60]
            lon: [120..300]
Number Of Attributes: 4
  pcvar_varimax :       ( 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477 )
  variance_varimax :    ( 815.7307, 448.0886, 312.4609, 268.2115, 318.7249, 194.9084, 240.9596, 241.9983, 216.6671, 178.1755 )
  _FillValue :  -999
  op :  Kaiser Varimax Rotation: opt=0
(0)     0.01801477
(1)     0.01801477
(2)     0.01801477
(3)     0.01801477
(4)     0.01801477
(5)     0.01801477
(6)     0.01801477
(7)     0.01801477
(8)     0.01801477
(9)     0.01801477
(0)     815.7307
(1)     448.0886
(2)     312.4609
(3)     268.2115
(4)     318.7249
(5)     194.9084
(6)     240.9596
(7)     241.9983
(8)     216.6671
(9)     178.1755
(0)     reordering

Variable: eof_tp_rot
Type: float
Total Size: 222040 bytes
            55510 values
Number of Dimensions: 3
Dimensions and sizes:   [evn | 10] x [lat | 61] x [lon | 91]
Coordinates:
            evn: [1..10]
            lat: [-60..60]
            lon: [120..300]
Number Of Attributes: 4
  pcvar_varimax :       ( 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477, 0.01801477 )
  variance_varimax :    ( 815.7307, 240.9596, 241.9983, 216.6671, 194.9084, 318.7249, 448.0886, 312.4609, 268.2115, 178.1755 )
  _FillValue :  -999
  op :  Kaiser Varimax Rotation: opt=0
(0)     0.01801477
(1)     0.01801477
(2)     0.01801477
(3)     0.01801477
(4)     0.01801477
(5)     0.01801477
(6)     0.01801477
(7)     0.01801477
(8)     0.01801477
(9)     0.01801477
(0)     815.7307
(1)     240.9596
(2)     241.9983
(3)     216.6671
(4)     194.9084
(5)     318.7249
(6)     448.0886
(7)     312.4609
(8)     268.2115
(9)     178.1755

Am I doing something wrong or this is a bug?

Thanks!

See Jira NCL-2671 for extensive discussion on this issue. This is an "in progress" issue.

I followed the building guide http://www.ncl.ucar.edu/Download/build_from_src.shtml

and everything seems to be 'fine', but I can not locate where 'ncl' executable file is placed.

The following is the executables in the NCARG_ROOT/bin

-rwxr-xr-x 1 root root   18400 Oct 21 15:08 ConvertMapData
-rwxr-xr-x 1 root root   27782 Oct 21 15:09 WRAPIT
-rwxr-xr-x 1 root root   18520 Oct 21 15:08 WriteLineFile
-rwxr-xr-x 1 root root   22848 Oct 21 15:08 WriteNameFile
-rwxr-xr-x 1 root root   27624 Oct 21 15:08 WritePlotcharData
-rwxr-xr-x 1 root root   34144 Oct 21 15:09 cgm2ncgm
-rwxr-xr-x 1 root root     835 Oct 21 15:09 ctlib
-rwxr-xr-x 1 root root     851 Oct 21 15:09 fcaps
-rwxr-xr-x 1 root root   23152 Oct 21 15:08 findg
-rwxr-xr-x 1 root root   57040 Oct 21 15:07 fontc
-rwxr-xr-x 1 root root    1003 Oct 21 15:09 gcaps
-rwxr-xr-x 1 root root   43160 Oct 21 15:07 graphc
-rwxr-xr-x 1 root root   71216 Oct 21 15:09 med
-rwxr-xr-x 1 root root    4274 Oct 21 15:08 ncargcc
-rwxr-xr-x 1 root root   58690 Oct 21 15:08 ncargex
-rwxr-xr-x 1 root root    4709 Oct 21 15:08 ncargf77
-rwxr-xr-x 1 root root    4709 Oct 21 15:08 ncargf90
-rwxr-xr-x 1 root root    1307 Oct 21 15:08 ncargfile
-rwxr-xr-x 1 root root   28712 Oct 21 15:07 ncargpath
-rwxr-xr-x 1 root root     740 Oct 21 15:08 ncargrun
-rwxr-xr-x 1 root root     633 Oct 21 15:08 ncargversion
-rwxr-xr-x 1 root root 1152616 Oct 21 15:08 ncargworld
-rwxr-xr-x 1 root root  263336 Oct 21 15:08 ncarlogo2ps
-rwxr-xr-x 1 root root     533 Oct 21 15:09 ncarvversion
-rwxr-xr-x 1 root root   33944 Oct 21 15:09 ncgm2cgm
-rwxr-xr-x 1 root root   48632 Oct 21 15:09 ncgmstat
-rwxr-xr-x 1 root root   64866 Oct 21 15:09 ncl_convert2nc
-rwxr-xr-x 1 root root   17468 Oct 21 15:09 ncl_filedump
-rwxr-xr-x 1 root root    2540 Oct 21 15:09 ncl_grib2nc
-rwxr-xr-x 1 root root   35934 Oct 21 15:09 ng4ex
-rwxr-xr-x 1 root root    2441 Oct 21 15:09 nhlcc
-rwxr-xr-x 1 root root    2237 Oct 21 15:09 nhlf77
-rwxr-xr-x 1 root root    2237 Oct 21 15:09 nhlf90
-rwxr-xr-x 1 root root     228 Oct 21 15:08 pre2ncgm
-rwxr-xr-x 1 root root  354056 Oct 21 15:08 pre2ncgm.prog
-rwxr-xr-x 1 root root   17832 Oct 21 15:08 psblack
-rwxr-xr-x 1 root root   34184 Oct 21 15:08 psplit
-rwxr-xr-x 1 root root   17784 Oct 21 15:08 pswhite
-rwxr-xr-x 1 root root   28184 Oct 21 15:08 pwritxnt
-rwxr-xr-x 1 root root    6322 Oct 21 15:09 scrip_check_input
-rwxr-xr-x 1 root root  283864 Oct 21 15:08 tgks0a
-rwxr-xr-x 1 root root   47976 Oct 21 15:08 tlocal

I can not find 'ncl' executable anywhere in my system.

https://github.com/NCAR/nviz/issues/2

Had a user on ncl-talk try to use wrf_user_ll_to_ij to check if observations are within the WRF domain. The current ll_to_ij routines are simple lat/lon to x/y converters that don't care what the domain size is. A new function should be created to add a check to see if the points are outside of the domain bounds. Not sure how the return should be -- either an array of booleans, or sequences of values for in and out of domain. The boolean way seems to be the more common way of doing this in NCL.

Amy Steikder of NSIDC came across some ICESat-2 HDF5 files that ncl_filedump produces errors on. These files are not yet public, but I have them and will make them available.

Here's a sample script to read each of the files and print some information. The error message is included in the comments.

  h5_files = (/"ATL03_20181018033532_02980106_201_01.h5",\
               "ATL04_20181018030401_02980101_201_01.h5",\
               "ATL09_20181018012943_02970101_201_01.h5"/)
  nh5 = dimsizes(h5_files)

  numeric_types = (/"integer","float","double"/)

;
;  Loop through each ATL file and print some information about the 
;  variables. Using NCL V6.5.0, this script produces the following
;  error for the ATL09 file:
;
;     Snow Ice Flag (1) : min=0   max=3
;       var name : /profile_2/high_rate/solar_azimuth
;       var type : float
;       var atts : DIMENSION_LIST,contentType,coordinates,description,long_name,source,units
;     solar azimuth (degrees_east) : min=64.6875   max=295.HDF5-DIAG: Error detected in HDF5 (1.10.1) thread 0:
;  #000: H5Dio.c line 159 in H5Dread(): selection+offset not within extent
;      major: Dataspace
;      minor: Out of range
;
;  Error in file: NclNewHDF5.c, line: 4586
;  HDF5-DIAG: Error detected in HDF5 (1.10.1) thread 0:
;  #000: H5Dio.c line 159 in H5Dread(): selection+offset not within extent
;      major: Dataspace
;      minor: Out of range
;
  do nh=0,nh5-1
    print("======================================================================")
    print("File      : " + h5_files(nh))
    a = addfile(h5_files(nh),"r")
    vnames := getfilevarnames(a)
    vtypes := getfilevartypes(a,vnames)
    nvars = dimsizes(vnames)
    do nv=0,nvars-1
      vatts := getfilevaratts(a,vnames(nv))
      print("  var name : " + vnames(nv))
      print("  var type : " + vtypes(nv))
      print("  var atts : " + str_join(vatts,","))
      if(any(vtypes(nv).eq.numeric_types))
        printMinMax(a->$vnames(nv)$,0)
      end if
    end do
  end do

See Jira NCL-2692 for file which demonstrates this issue.

Sometimes in the build, libraries are built.

Other times, .o files are built, where a library would be expected. For example the ngmath library is compiled from ngmathbd.f to ngmathbd.o. Here's the yMakefile:

SUBDIRS = lib bin examples

OBJECTS = ngmathbd.o
FSOURCES = ngmathbd.f

RelocatableTarget(libngmathbd.o,$(OBJECTS))

Here's the Makefile.am in that directory:

# This is an automake file for NCL
# Ed Hartnett 9/5/18

SUBDIRS = lib bin examples

libngmathbd.o: ngmathbd.o
	ld -r -o $@ $^

ngmathbd.o: ngmathbd.f
	$(FC) -c ${FCFLAGS} -o $@ $^

# Install this "lib" file.
robjdir = $(prefix)/lib/ncarg/robj
robj_HEADERS = libngmathbd.o

EXTRA_DIST = ngmathbd.f

CLEANFILES = *.o

This would be a lot simpler if we just compiled ngmathbd into a library.

I also not that ngmathbd.o is seemingly never used anywhere else in the build. Is it needed?

But even if not, the question still applies, since there are other cases of this. So can I make these into proper libraries? It would be easier and more correct, and would work the same. But different files would end up being installed. Instead of libngmathbd.o we would have libngmathdb.a (for static only builds) and a bunch of additional files for shared library builds.

running a given script using ncl 6.5.0 I get a fatal error which does'nt occur running the same script in ncl 6.4.0
The error happens using setfileoption("nc", "Format", "NetCDF4Classic")
To show the error I use a simple code named test.nc (at the end of this text) which creates the file test.nc
I run test.nc both ncl 6.4.0 and 6.5.0
As you can see running it on 6.4.0 there are no errors, but running on 6.5.0 a fatal error is reported (but the file is properly created)

export NCARG_ROOT=/usr/local/ncarg_6.4
export PATH=$NCARG_ROOT/bin:$PATH
ncl test.ncl
Copyright (C) 1995-2017 - All Rights Reserved
University Corporation for Atmospheric Research
NCAR Command Language Version 6.4.0
The use of this software is governed by a License Agreement.
See http://www.ncl.ucar.edu/ for more details.
(0) done!

export NCARG_ROOT=/usr/local/ncarg_6.5.0
export PATH=$NCARG_ROOT/bin:$PATH
ncl test.ncl
Copyright (C) 1995-2018 - All Rights Reserved
University Corporation for Atmospheric Research
NCAR Command Language Version 6.5.0
The use of this software is governed by a License Agreement.
See http://www.ncl.ucar.edu/ for more details.
ncattput: ncid 65536: NetCDF: Attempt to define fill value when data already exists.
fatal:Attempt to delete undefined attribute from variable
(0) done!

;-----------------------------------------------------------
load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl"
load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_csm.ncl"
load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl"
;-----------------------------------------------------------
begin
ofile = "test.nc"

;--- set dimensions ---
nlon = 100
nlat = 200
nlev = 100

data = new((/ nlev, nlat, nlon /), "float", 1.0e20)

;--- create new file ---
system("/bin/rm -f "+ofile)
setfileoption("nc", "Format", "NetCDF4Classic")
ncout = addfile(ofile, "c")

;--- define mode on ---
setfileoption(ncout, "DefineMode", True)

;--- define dimensions ---
dimNames = (/ "lev", "iy", "jx" /)
dimSizes = (/ nlev, nlat, nlon /)
dimUnlim = (/ False, False, False /)
filedimdef(ncout, dimNames, dimSizes, dimUnlim)

;--- define variables ---
filevardef(ncout, "lat", "float", (/ "iy", "jx" /))
filevardef(ncout, "lon", "float", (/ "iy", "jx" /))
filevardef(ncout, "lev" , "float", "lev")
filevardef(ncout, "THETA", "float", (/ "lev", "iy", "jx" /))

;Define the compress level
filevarcompressleveldef(ncout, "THETA", 9)

;--- exit file definition mode ---
setfileoption(ncout, "DefineMode", False)

lat=0.
lon=1.
depth=100.

;--- fill data ---
ncout->lat = (/ lat /)
ncout->lon = (/ lon /)
ncout->lev = (/ depth /)
data(:,:,:) = -5.
ncout->THETA(:,:,:) = (/ data(:,:,:) /)
print ("done!")
end

Original note below. See Jira NCL-2777 for scripts, data files and sample plots, along with further commentary from Mary's initial investigation.

from: Maud Leriche [email protected] via ucar.edu
date: Fri, Sep 28, 2018 at 1:03 PM
subject: [ncl-talk] Unable to get the latitude on Y axis on a map

Hello everybody,

With one of my student, we possibly found a bug in ncl (6.5.0).
We want to plot the orography of our domain simulation on a map. We are using the MesoNH model (http://mesonh.aero.obs-mip.fr/mesonh54/, 5.4.1) with a polar projection defined with :
Latitude at the centre of the domain (LAT0) = 78.5°N
Longitude of the centre of the domain (LON0) = -86.41°O
Parameter of the conformal projection (RPK) = 1 (corresponding to stereographic polar projection)

The graph obtained from our ncl script doesn’t indicate the latitude on the Y axis. Instead the Y axis indicates longitude.

We think that the problem comes to ncl because if the conformal projection parameter is inferior to 0.72, the plot is right but if this parameter is > 0.71, ncl doesn’t indicate the latitude on the Y axis.

The tar file containing our ncl script, the netcdf file output of our simulation and the obtained plot can be downloaded here:
https://framadrop.org/r/uKKEspjOMJ#DWaQaXTd2jhmXGXuJpz85vVjfgWJB2HqSFZTdZR09Qc=

Below is the obtained plot using a RPK = 0.71.

Many thanks in advance for your help.

Regards,

Maud

Starting in NCL 6.5, gsLineThicknessF no longer had any effect on table/cell line thicknesses. After discussing with NCL-talk, Mary confirmed this was a bug, and identified a fix as:

"One is to fix the $NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl script. Edit this line:
gsres_tmp = get_res_eq(res2,"gs") ; Get resource list for lines. Remove gsFill
; and change "res2" to "res":
gsres_tmp = get_res_eq(res,"gs") ; Get resource list for lines. Remove gsFill "

Linked are two relevant sample scripts Mary provided.

gsn_table_fix.ncl.txt
table_1.ncl.txt

;
; Illustrates a bug with cnLowLabelFontHeightF and cnLowLabelAngleF.
; These resources have no effect, but setting cnHighLabelAngleF
; cnHighLableFontHeightF affects both the high and low labels.
;
begin
f = addfile ("$NCARG_ROOT/lib/ncarg/data/cdf/uv300.nc", "r")
u = f->U ; (time,lat,lon)
v = f->V

div = uv2dvG_Wrap(u,v) ; u,v ==> divergence
chi = ilapsG_Wrap ( div , 0)
chi = (/chi/1e6/)
chi@long_name = "velocity potential"
chi@units = "m/s"

wks = gsn_open_wks("x11","low_label_font_bug")

res = True

res@cnInfoLabelOn = False ; no contour info label

res@cnHighLabelsOn = True ; high labels on
"low_label_font_bug.doc" 55L, 1938C

Printing or accessing the value of any variable in an HDF5 file seems to cause a memory leak related to each of its attributes I am not sure whether it is also true for global attributes or for NetCDF4 files. I believe the leak is in the "advanced" file system code and not in the HDF5-specific code but I am not sure of that yet.

NCLers

This problem might be at our end but I was hopeful somene might have some insight on how to debug and it's short (and multiple people have tried to figure it out).

Running this on our linux server (version 6.5.0 x86_64 GNU/Linux)

ncl 'ylabel="Standardized Anomalies"' < reallyshort.ncl

where reallyshort.ncl is

begin
wks = gsn_open_wks ("png","teset")
res = True ; plot mods desired
res@tiYAxisString = ylabel ; add an axis title
end

fails when it used to work with error

fatal: can't find file "Anomalies""

Testing shows NCL didn't like the space. If it's there, it tries to open up the word after the space as a file. An underline instead of a space does works I tried reversing the quote types, backslahing the space, and different shells, and a different variable name.

It does work on a MAC same version of NCL.

Any ideas of where to look to fix? It may not be NCL that is the problem. Other NCL scripts are working.
Cathy

Hi,

I was using the qsort routine in a user-defined function and got an unexpected result. I've replicated it here with a simple example using ncl 6.4.0:

Example Script "test_qsort_infunction.ncl"

load "my_lib.ncl" ;this is where I store my simple user-defined function "sort_test"

begin
a = (/10, 9, 8, 7, 6, 5, 4, 3, 2, 1/)
print(a)

c = sort_test(a)
print(c)

print(a)
end

Example Function "sort_test"

undef("sort_test")
function sort_test(array)

begin
qsort(array)

b = array
return(b)
end

When I run the ncl script "test_qsort_infunction.ncl" I get the following output:

Copyright (C) 1995-2017 - All Rights Reserved
University Corporation for Atmospheric Research
NCAR Command Language Version 6.4.0
The use of this software is governed by a License Agreement.
See http://www.ncl.ucar.edu/ for more details

Variable: a
Type: integer
Total Size: 40 bytes
10 values
Number of Dimensions: 1
Dimensions and sizes: [10]
Coordinates:
(0) 10
(1) 9
(2) 8
(3) 7
(4) 6
(5) 5
(6) 4
(7) 3
(8) 2
(9) 1

Variable: c
Type: integer
Total Size: 40 bytes
10 values
Number of Dimensions: 1
Dimensions and sizes: [10]
Coordinates:
(0) 1
(1) 2
(2) 3
(3) 4
(4) 5
(5) 6
(6) 7
(7) 8
(8) 9
(9) 10

Variable: a
Type: integer
Total Size: 40 bytes
10 values
Number of Dimensions: 1
Dimensions and sizes: [10]
Coordinates:
(0) 1
(1) 2
(2) 3
(3) 4
(4) 5
(5) 6
(6) 7
(7) 8
(8) 9
(9) 10

Perhaps this is already known and expected, but I didn't expect the user-defined function to influence the order of the a array within my script (ie, it sorted the a values, but I didn't want it to).

• Chris

With the new WRF routines added in this release, some WRF routines will still be available but will be deprecated. They need to be documented as such:

http://www.ncl.ucar.edu/Document/Functions/WRF_arw/wrf_user_ll_to_ij.shtml
http://www.ncl.ucar.edu/Document/Functions/WRF_arw/wrf_user_ij_to_ll.shtml
http://www.ncl.ucar.edu/Document/Functions/WRF_arw/wrf_user_intrp2d.shtml
http://www.ncl.ucar.edu/Document/Functions/WRF_arw/wrf_user_intrp3d.shtml

Text to use:

(C) 2018 - University Corporation for Atmospheric Research. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

For the polar stereographic projection in wrf_map_resources, the code is trying to set mpCenterLatF using the 'cen_lat' parameter from the NetCDF file. This is incorrect, as cen_lat only gives the center of the grid, not the center of the projection. Since WRF only supports polar stereographic, mpCenterLatF is either 90.0 for the northern hemisphere, or -90.0 for the southern hemisphere. Some code will need to be added to determine the hemisphere type (either use ref_lat or cen_lat for this), then set mpCenterLatF accordingly.

Hi -

We are unable to read grids from GRIB2 files using JPEG 2000 packing
using NCL (6.4.0). These data files are readable via a number of other
libraries/tools (PyNIO, ecCodes, NetCDF-Java-based tools (e.g.,
THREDDS, PanoplyJ)).

The NCL reads always seem to fail within GDAL:

Example:
ncl 0> nc = addfile("2mtemp-jpeg.grib2","r")
ncl 1> data = nc->TMP_P0_L103_GLL0
ERROR 4: `/vsimem/work_grib_0x8d2f761.jpc' not recognized as a
supported file format.
dec_jpeg2000: Unable to open JPEG2000 image within GRIB file.

This was tested on several machines (RHEL-like OSs (CentOS 7.3,
Scientific Linux 7.2)) with identical results using a conda-installed
ncl via either:

conda create -n ncl_stable -c conda-forge ncl=6.4.0

or

conda create -n ncl_stable -c NCAR -c conda-forge -c defaults ncl

We tested gdal by itself by creating a conda environment using the
same libgdal as installed in the ncl environment (2.2.2) and running a
simple gdal_translate on the data:

gdal_translate 2mtemp-jpeg.grib2 2mtemp.tiff

gdal_translate successfully reads the grid and creates a GeoTIFF.

I have placed a sample file (2mtemp-jpeg.grib2) in the incoming dir of
the ftp site for you to test against.

Please let me know if we're missing something obvious here.

NCL has an internal build system that needs to be replaced with more standard build system that uses GNU auto tools (#4) or CMAKE.

Both systems have already been applied to the NCL source code, but they have not yet been fully tested by the NCL team. Also, when/if the NCL source code is refactored (#18), then one or both build systems will need to be refactored as well.

Please update readAsciiTable and similar NCL text input functions to automatically recognize and remove both DOS and Unix line endings. Thank you.

A conservative approach would be to recognize and strip two cases which are equivalent to single line termination. Those cases are LF alone (Unix/Linux), and CR-LF (DOS). Both types are common in the Real World.

I would also suggest that you accept a mixture of both LF and CR-LF in the same file. This easily happens when pieces of different files are pasted together. In other words, don't try to determine a single line ending rule for an entire file.

Less commonly, there are other oddball cases, such as CR alone. I suggest leaving these cases untouched until they are encountered in a real use case.

A basic contributor's guide for NCL already exists. We plan to write a more extensive one that documents how to enhance various components of NCL, for example, how to:

• Add a new NCL-based computational function
• Add a C- or Fortran-based computational function
• Add to a new color table
• Fix an existing NCL function

https://github.com/NCAR/nviz/issues/1

curvilinear_to_SCRIP calculates incorrect grid corners for grid cell center at longitude 180degE

ncl_curvilinear_to_SCRIP.pism-no_mask.ncl converts the curvilinear grid PICO_mask2.nc to the SCRIP description pism_grid-no_mask.SCRIP.nc

ncdump -v grid_corner_lon pism_grid.SCRIP.nc

...
-179.623060172952, -179.773834015524, -179.773535647662, -179.622562906993,
-179.773834015524, 0.0753890095419791, 0.0754884668772178, -179.773535647662,
0.0753890095419791, 179.924610990458, 179.924511533123, 0.0754884668772178,
179.924610990458, 179.773834015524, 179.773535647662, 179.924511533123,
...

I am using ncl version 6.5.0 on a linux cluster.

NCAR/nclcomp#2

Some grib extensions I had never seen.
I think this should be 'easy.' Where ever the recognized file extensions are listed, just add 'g1' and 'g2'

grib, grib1, grib2, grb1, grb2, .....

Some sample files are at:

/glade/p/ncldev/data/grib1
WRFPRS_d01.00_30.g1
WRFPRS_d01.00_20.g1

/glade/p/ncldev/data/grib2
wrfprs_d01.00_30.g2
wrfprs_d01.00_20.g2

When the projection type is lat-lon, the rotation of the winds to earth coordinates is not performed when 'uvmet' is requested via wrf_user_getvar. This is only valid if the domain is the default. When the pole is rotated, then wind rotation is required.

Creating filled contours of large grids or meshes can cause NCL to take several minutes to render one image. While some parallelism has been applied internally to the raster contouring algorithm, there may be other methods worth implementing for performance speed-up.