[GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL)

Added by John 7 months ago

Aloha. I'm setting off on a new adventure to compute a vector parameter from the output of the WRF atmospheric model. Here's the approach and the current problematic results. I'd appreciate your advice since some fundamental data issues are an immediate problem. Hopefully not fatal to the approach.

1. From WRF model output ($INPUT_FILE), in netcdf4, extract two variables IVTU and IVTV using NCO to write into two 32-bit Float netcdf3 files.

ncks -v IVTU --fl_fmt=classic $INPUT_FILE $IVTU
ncks -v IVTV --fl_fmt=classic $INPUT_FILE $IVTV

This appears to work and produces files that gdal_info understands and, for $IVTU, produces:

gdalinfo $IVTU
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Driver: netCDF/Network Common Data Format
Files: /Users/hellyj/Archive-local/Project-WWRF/data/level1/WWRF-Two-III-2017-12-02-12-wrfout_d01_2016-12-13_06:00:00-IVTU.nc
Size is 484, 323
Coordinate System is `'
Metadata:
IVTU#coordinates=XLONG_U XLAT_U
IVTU#description=ZONAL INTEGRATED VAPOR TRANSPORT
IVTU#FieldType=104
IVTU#MemoryOrder=XY
IVTU#stagger=X
IVTU#units=kg m-1 s-1
...
(deleted the netcdf metadata in here)
...
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 323.0)
Upper Right ( 484.0, 0.0)
Lower Right ( 484.0, 323.0)
Center ( 242.0, 161.5)
Band 1 Block=484x1 Type=Float32, ColorInterp=Undefined
NoData Value=9.96920996838686905e+36
Metadata:
coordinates=XLONG_U XLAT_U
description=ZONAL INTEGRATED VAPOR TRANSPORT
FieldType=104
MemoryOrder=XY
NETCDF_DIM_Time=1
NETCDF_VARNAME=IVTU
stagger=X
units=kg m-1 s-1

2. However, grdinfo is not happy:
grdinfo $IVTU=nf

results in:
grdinfo (GMTAPI_Import_Grid): No 2-D variable in file [$IVTU=nf]

I might be missing something basic but I think I see a 2D variable with 2 spatial indexes and dimensions of (484.0 x 323.0). However, I also see

Band 1 Block=484x1 Type=Float32

which I don't really understand.

Any insight that you might offer would be very helpful.
Mahalo.
J.


Replies (27)

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Joaquim 7 months ago

That happens likely because the NCL program created grids that have one singleton dimension (for example 1x300x200). But why don't you access directly the specific array with GMT? The CookBook explains how to access multidimension nc files. And you can also force the reading via GDAL with the =gd suffix.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 7 months ago

That gets me farther but still no cigar. This isn't a particularly large grid so suspect there is some other problem, no?
J.

+ grdinfo -Ir /Users/hellyj/Archive-local/Project-WWRF/data/level1/WWRF-Two-III-2017-12-02-12-wrfout_d01_2016-12-13_06:00:00-IVTU.nc=gd
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
REGION=-R0.5/483.5/0.5/322.5
+ grdinfo /Users/hellyj/Archive-local/Project-WWRF/data/level1/WWRF-Two-III-2017-12-02-12-wrfout_d01_2016-12-13_06:00:00-IVTU.nc=gd
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
$IVTU: Title: Grid imported via GDAL
IVTU.nc: Command:
: Remark:
IVTU: Gridline node registration used [Cartesian grid]
IVTU: Grid file format: gd = Import/export through GDAL
IVTU: x_min: 0.5 x_max: 483.5 x_inc: 1 name: x nx: 484
IVTU: y_min: 0.5 y_max: 322.5 y_inc: 1 name: y ny: 323
IVTU: z_min: -558.326049805 z_max: 686.242919922 name: z
IVTU: scale_factor: 1 add_offset: 0
+ grdmath -R0.5/483.5/0.5/322.5 $IVTU.nc=gd $IVTV.nc=gd R2 SUM SQRT = $IVT
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
grdmath: Warning: Region exceeds grid domain. Region reduced to grid domain.
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
grdmath: gdalread: failure to allocate enough memory
grdmath: ERROR reading file with gdalread.
grdmath (GMTAPI_Import_Grid): Could not open file [$IVTV=gd]
[Session grdmath (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdmath (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdmath (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Joaquim 7 months ago

Than, a I think grdconvert to extract the layers would give a good lighter.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 7 months ago

I'll try that but here's another weirdo. When I use the file?variable method, the Z-values are converted to NaNs. Sorry but I didn't edit out all the path info this time.

MFS-Desktop:~/Archive-local/Project-WWRF>./src/bin/make-frame-IVT.bash
+ INPUT_FILE=/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00
+ OUTPUT_DIR=/Users/hellyj/Archive-local/Project-WWRF/data/level1
+ IVTU=/Users/hellyj/Archive-local/Project-WWRF/data/level1/WWRF-Two-III-2017-12-02-12-wrfout_d01_2016-12-13_06:00:00-IVTU.nc
+ IVTV=/Users/hellyj/Archive-local/Project-WWRF/data/level1/WWRF-Two-III-2017-12-02-12-wrfout_d01_2016-12-13_06:00:00-IVTV.nc
+ grdinfo '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00?IVTU'
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Title:
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Command:
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Remark:
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Gridline node registration used [Cartesian grid]
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: x_min: 0 x_max: 483 x_inc: 1 name: nx: 484
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: y_min: 0 y_max: 322 y_inc: 1 name: ny: 323
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: z_min: NaN z_max: NaN name: IVTU [kg m-1 s-1]
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: scale_factor: 1 add_offset: 0
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: format: classic
+ grdinfo -I*r '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00?IVTU'
REGION=-R0/483/0/322
+ *grdinfo
'/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00?IVTV'
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Title:
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Command:
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Remark:
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Gridline node registration used [Cartesian grid]
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: x_min: 0 x_max: 482 x_inc: 1 name: nx: 483
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: y_min: 0 y_max: 323 y_inc: 1 name: ny: 324
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: z_min: NaN z_max: NaN name: IVTV [kg m-1 s-1]
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: scale_factor: 1 add_offset: 0
/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00: format: classic
+ grdmath -R0/483/0/322 '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00?IVTU' '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2016-12-12-12/wrfout_d01_2016-12-14_00:00:00?IVTV' R2 SUM SQRT = /Users/hellyj/Archive-local/Project-WWRF/data/level1/IVT.nc
grdmath: Warning: Region exceeds grid domain. Region reduced to grid domain.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 7 months ago

grdconvert seems to do the trick but wonder about the other methods that apparently also should?
J.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Joaquim 7 months ago

When GMT saves a file it recomputes some metadata (header stuff) so you get a well behaved data. Direct access uses data as is, and if it fails ... weather fault. Weather is not what it used to be. At least here in Algarve (no rain).

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 7 months ago

Yeah. Dry here too but we have some nasty wildfires going in Ventura County. Ciao.
J.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 7 months ago

Continuing saga. Almost there but here is some weirdness:

1. I'm computing the vector sum of two components and that all looks good except:
1.1 The computed value in the output grdfile from grdmath has the name of the X-component (IVTU) and I don't seem to be able to change it to IVT.
1.2 When I run grdproject to convert from rectangular to geographic coordinates the z-values are changed (possibly back to the original IVTU values).
1.3 I cannot figure out what is going on.

2. Here is the script sequence and the output of the grdinfo's is below that.
3. All the z-values should be positive and they are after the grdmath step but something happens in the grdproject step that alters them. Makes no sense to me.

REGION=`grdinfo -Ir $fullfile?IVTU`
gmt grdconvert $REGION $fullfile?IVTU $WORK_DIR/IVTU.nc
gmt grdconvert $REGION $fullfile?IVTV $WORK_DIR/IVTV.nc

  1. gmt grdmath $REGION -N $WORK_DIR/IVTU.nc $WORK_DIR/IVTV.nc R2 SQRT = $WORK_DIR/IVT.nc?IVT
    gmt grdinfo $WORK_DIR/IVT.nc

  2. gmt grdproject $WORK_DIR/IVT.nc $D01_REGION $PROJECTION -I -G$WORK_DIR/IVT-GC.nc
    gmt grdinfo $WORK_DIR/IVT-GC.nc #

================================ Output of command sequence ===========================
+ gmt grdmath -R0/483/0/322 -N IVTU.nc IVTV.nc R2 SQRT = 'IVT.nc?IVT'
grdmath: Warning: Region exceeds grid domain. Region reduced to grid domain.
+ gmt grdinfo IVT.nc
IVT.nc: Title: Produced by grdmath
IVT.nc: Command: grdmath -R0/483/0/322 -N IVTU.nc IVTV.nc R2 SQRT = IVT.nc?IVT
IVT.nc: Remark:
IVT.nc: Gridline node registration used [Cartesian grid]
IVT.nc: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
IVT.nc: x_min: 0 x_max: 483 x_inc: 1 name: x nx: 484
IVT.nc: y_min: 0 y_max: 322 y_inc: 1 name: y ny: 323
IVT.nc: z_min: 0 z_max: 874.96282959 name: IVTU [kg m-1 s-1]
IVT.nc: scale_factor: 1 add_offset: 0
IVT.nc: format: netCDF-4 chunk_size: 162,162 shuffle: on deflation_level: 3
+ gmt grdproject IVT.nc -R-163.96600/-108.23660/19.36550/47.59611 -JM16c -I -GIVT-GC.nc
+ gmt grdinfo IVT-GC.nc
IVT-GC.nc: Title: Produced by grdproject
IVT-GC.nc: Command: grdproject IVT.nc -R-163.96600/-108.23660/19.36550/47.59611 -JM16c -I -GIVT-GC.nc
IVT-GC.nc: Remark:
IVT-GC.nc: Gridline node registration used [Geographic grid]
IVT-GC.nc: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
IVT-GC.nc: x_min: -163.966 x_max: -108.2366 x_inc: 0.115381780538 name: longitude [degrees_east] nx: 484
IVT-GC.nc: y_min: 19.3655 y_max: 47.59611 y_inc: 0.0876727018634 name: latitude [degrees_north] ny: 323
IVT-GC.nc: z_min: -0.309782356024 z_max: 110.026092529 name: IVTU [kg m-1 s-1]
IVT-GC.nc: scale_factor: 1 add_offset: 0
IVT-GC.nc: format: netCDF-4 chunk_size: 162,162 shuffle: on deflation_level: 3

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Joaquim 7 months ago

I don't know what this do "= 'IVT.nc?IVT'". The ? is for reading, not for writing.
And it keeps complaining that

grdmath: Warning: Region exceeds grid domain. Region reduced to grid domain.

so something not right. Can you make us a small data set example?

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 6 months ago

Thanks. Here are the two files that have been created using grdconvert. These are both from the same model time step and should have the domain. However, at first grdmath complained that they were not the same size so I added a Region statement to grdconvert and that seemed to fix that problem, maybe not.

1. IVTU
2. IVTV

IVTU.nc (18.5 KB)

IVTV.nc (489 KB)

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Joaquim 6 months ago

Grids have not the same size.
Grid U has only zeros

Grids have no coordinates. X and Y seam to be the ncol, nrows dimension. I don't know the structure of the original file but this makes me guess that it has the coordinates stored in separate arrays.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 6 months ago

The drawing board led me to this approach which finally works although I reverted to R to do the vector sum.

grd2xyz $INPUT_FILE?XLAT > $OUTPUT_DIR/XLAT.xyz
grd2xyz $INPUT_FILE?XLONG > $OUTPUT_DIR/XLONG.xyz
grd2xyz $INPUT_FILE?IVTU > $OUTPUT_DIR/IVTU.xyz
grd2xyz $INPUT_FILE?IVTV > $OUTPUT_DIR/IVTV.xyz

Page 107 of the GMT Doc, specifically,

gmt psxy "file.nc?lon/lat" ...
gmt convert "file.nc?time/lat/lon" 

leads me to believe I might be able to achieve the same thing in one-step but I haven't tested it yet.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 6 months ago

It looks like the WRF model outputs are not COARDS-compliant

+ INPUT_FILE=/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2017-02-08-12/wrfout_d01_2017-02-10_00:00:00
+ gmt gmtinfo '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2017-02-08-12/wrfout_d01_2017-02-10_00:00:00?XLONG'
gmtinfo: NetCDF variable XLONG has 3 dimensions, showing only 2
./test-netcdf.bash: line 28: 26633 Abort trap: 6           gmt gmtinfo $INPUT_FILE?XLONG
+ gmt gmtinfo '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2017-02-08-12/wrfout_d01_2017-02-10_00:00:00?XLAT'
gmtinfo: NetCDF variable XLAT has 3 dimensions, showing only 2
./test-netcdf.bash: line 29: 26644 Abort trap: 6           gmt gmtinfo $INPUT_FILE?XLAT
+ gmt gmtinfo '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2017-02-08-12/wrfout_d01_2017-02-10_00:00:00?IWV'
gmtinfo: NetCDF variable IWV has 3 dimensions, showing only 2
./test-netcdf.bash: line 30: 26647 Abort trap: 6           gmt gmtinfo $INPUT_FILE?IWV
+ gmt grdconvert '/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2017-02-08-12/wrfout_d01_2017-02-10_00:00:00?XLONG/XLAT/IWV' /Users/hellyj/Archive-local/Project-WWRF/data/level1/Test-XLONG-XLAT-IWV.nc
grdconvert (GMT_grdconvert): Named variable does not exist in file [/Volumes/Pegasus2R6/WWRF-Output-Data/WWRF-Two-III-2017-02-08-12/wrfout_d01_2017-02-10_00:00:00?XLONG/XLAT/IWV]

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 6 months ago

Yikes.

I did all this work on a development machine running 5.2.1 and then attempted to port it to a production machine running a new install of 5.4.2 and I get this new big problem
that seems like COARDS compliance is differently enforced in this version?

+ grd2xyz '/data/Helly-Work/WWRF-Output-Data/WWRF-Two-III-2017-12-08-12/wrfout_d01_2017-12-08_12:00:00?XLAT'
grd2xyz (api_import_grid): NetCDF grid is not COARDS compliant [/data/Helly-Work/WWRF-Output-Data/WWRF-Two-III-2017-12-08-12/wrfout_d01_2017-12-08_12:00:00?XLAT]
[Session grd2xyz (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grd2xyz (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grd2xyz (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Paul 6 months ago

Could you post one of those files or a link if easily downloadable?

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 6 months ago

I developed a work-around doing this with gdal, so I don't understand why GMT is complaining. It gives me x and y indices that are pixel-aligned but otherwise seems ok. I had to copy the files to another naming convention since the model has colons embedded in the name and gdal uses those as delimiters in the gdal_translate command.

NEWNAME_FILE=`echo $INPUT_FILE | tr ":" "-"`
cp $INPUT_FILE $NEWNAME_FILE

gdal_translate -of XYZ NETCDF:$NEWNAME_FILE:XLAT $OUTPUT_DIR/XLAT.xyz

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Paul 6 months ago

GMT is complaining because the netcdf file does not conform to the COARDS convention for grids. The file contains numerous 2-d and 3-d layers and have their own definitions of names and conventions. We cannot spend time developing read procedures to read anyone's crazy and custom format. However, that is what GDAL aims for: to read any grid type. XLAT is a 3-D variable so not sure what layer the gdal_translate output reflects. Run ncdump -h on this file and compare to a regular GMT netcdf grid.
Anyway, off to AGU.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 6 months ago

I'm with you on that. I didn't mean that GMT 'should' be doing something, rather, 'what' is it that GDAL is doing that differs. I'm just happy that something works and I was surprised that what worked in GMT 5.2.1 no longer works in GMT 5.4.2. I was reporting it to find out if that is expected behavior. I also find that I cannot compile 5.2.1 on the new machine for reasons I don't understand but appear to be compiler difference: although I'm not sure. It's probably not worth figuring out and I'm not suggesting that anyone spend time on it. Nonetheless, I've learned a bit in solving this problem two out of three different ways. Maybe the discussion will help others.

I recognize the rather adhoc nature of the WRF output files. By way of explanation, it is one of the most ancient, but widely used, weather models. It more or less started at the beginning of netCDF and hasn't spent any effort to keep up AFAIK. I'm trying to break away from the resultant community-dependence on NCL (NCAR graphics) by example. This model is going to be around for sometime yet and it would benefit a couple of generations of grad students to have alternate means of visualization. GMT is, by far, the best alternative and this may be the first time it has been used in it this way. I think that has value

Here's a sample of the movie resulting from your help and the fine work on GMT, if it's any consolation. It's a forecast that captures the biggest atmospheric river event from early 2017. This is a West-WRF model instance, a WRF variant that we have developed and run at SIO, and it depicts one of the events that forced the crisis at Oroville Dam last year.

Enjoy AGU. If you care to, perhaps you can find a guy name Andrew Martin from SIO in New Orleans. He's my colleague in this and taught me how to use WRF. He would be typical of a early career scientist who doesn't yet know much about GMT other than my mentioning it. I'm trying to be a missionary to the meteorological community in this way.

Mahalo. J.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Paul 6 months ago

We added a more strict test on COARDS as GMT quietly tried to read some non-COARD grids and got things all wrong and crashed, and we wanted to prevent that. If Remko decides to have a look then perhaps things could change. The movie is nice though!

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by Joaquim 6 months ago

But a problem is that we had a regression and things like the NDVI example in the CookBook or the example 4 in our Matlab paper were broken. Restored in r19502. We can now (again) do

grdconvert wrfout_d02_2017-12-16_03_00_00.nc=gd?NETCDF:"wrfout_d02_2017-12-16_03_00_00.nc:XLONG" xlong.grd

Also, as I guessed xlong & xlat are 3D but with one singleton dimension. GMT should be able to read them even if those arrays are not COARDS compliant.

RE: [GMT5 5.2.1] Adventures in processing the NCAR WRF model output using grdmath (as alternative to NCL) - Added by John 6 months ago

No joy although gdalinfo can read this file. I can't find any syntax error but maybe?

grdconvert input=gd?NETCDF:"input:XLONG" xlong.grd
grdconvert: Unable to find NETCDF:input:XLONG.
grdconvert: Unable to open NETCDF:input:XLONG.
grdconvert: ERROR reading file with gdalread.
grdconvert (api_import_grid): Could not open file [input=gd?NETCDF:input:XLONG]
[Session grdconvert (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdconvert (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdconvert (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)

1 2 (1-25/27)