Hi All,
Is there a tool to compute advective Courant numbers from ROMS grid and history files? I tried to use "courant" from http://www.atmos.ucla.edu/~alex/ROMS/tools.tar, but it expects to find global attributes (e.g. dt, VertCoordType) that are not in the files.
Thanks
Steve
Courant number Tool
-
- Posts: 5
- Joined: Wed Jun 04, 2014 10:46 pm
- Location: Florida State University
Re: Courant number Tool
Hi Steve,
Remember me in Florida State back from 1992-1993? It was a nice time back then.
You problem will take only a few minutes to overcome because the very same package
you have compiled contains command-line operators nc_add_att and nc_del_att which
allow you to put all the necessary attributes from UNIX command shell.
Background: The problem you are referring to is because Rutgers ROMS insists
on archaic legacy way of keeping descriptive information in netCDF files. It is
practically useless to negotiate standards because things need to evolve and go
forward, and there is always someone who complains that his Matlab script stops
working and he is unwilling to modify it.
Huh, there is no such thing C-preprocessor in Matlab.
The underlining principle: keep it the simplest mathematically sufficient way.
The second principle is ergonomics: the files and everything else should be
convenient to use.
With respect to netCDF format: there are netCDF variables and attributes.
Variables require double-step process: at first variable(s) needs to be created
during the definition mode of netCDF file creation, then file should be switched
into input mode value(s) should be written into variable(s). Throughout the years
I saw a lot of instances when variables are created, but not written. In contrast,
netCDF global attributes are created in a single stage during the definition mode.
Same applies to reading: netCDF variable need 2-stage process: inquire ID, then
read it from that ID. In contrast, getting info from global attribute is a single
stage process.
So for things like time step size, vertical coordinate parametrs, S-curves, and
other information of such kind one can either create variables, or keep this info
as netCDF attributes.
Ergonomics: we often use ncview to make glance at netCDF file. Looking at Rutgers
format ncview command window is cluttered by dozen of buttons for all these auxiliary
variables, but actually you do not want to see them Same applies to WRF, but in
much more grotesque manner.
When such files are looked by ncdump -h, again, you screen will be cluttered by
useless information, AND, if you need, for example, to get things like dt, vcoords,
vstretching, Thetas, hc, S-curves, you have to use ncdump -v varname filename.nc
for each variable individually. And you will hate doing this if you have to do it
too often. In contrast, is all this descriptive data is kept as a set of global
attributes, a simple ncdump -h exposes them all in a nice easy-to-look at summary.
So the bottom line is: when it is use sufficient to use a global attribite
instead of variable I use global attribute.Same applies to AGRIF/CROCO conventions.
You problem will take only a few minutes to overcome because the very same package
you have compiled contains command-line operators nc_add_att and nc_del_all which
allow you to put all the necessary attributes from UNIX shell. First, execute
nc_add_att without any argument: it gives you self-explanation of what it does and
how to use it.
This applies to every other command in the package: once you compiled and installed
it, you discover that there are 50 or so executable files and you have no idea what
they are for and what they are doing - no problem: just execute them one-by-one
without argument - they print instruction of how to use it. All of them meant to
be self-explanatory.
So to add the necessary attributes you should, for example
use ncdump -h to check what it did.
Above VertCoordType='SM09' corresponds to Rutgers vtransform=2 vstretching=2,
and dt=200 means 200 seconds (obviously you have to get the actual value first
by ncdump -v dt. Same applies to all other variable-to-attribute.
Remember me in Florida State back from 1992-1993? It was a nice time back then.
You problem will take only a few minutes to overcome because the very same package
you have compiled contains command-line operators nc_add_att and nc_del_att which
allow you to put all the necessary attributes from UNIX command shell.
Background: The problem you are referring to is because Rutgers ROMS insists
on archaic legacy way of keeping descriptive information in netCDF files. It is
practically useless to negotiate standards because things need to evolve and go
forward, and there is always someone who complains that his Matlab script stops
working and he is unwilling to modify it.
Huh, there is no such thing C-preprocessor in Matlab.
The underlining principle: keep it the simplest mathematically sufficient way.
The second principle is ergonomics: the files and everything else should be
convenient to use.
With respect to netCDF format: there are netCDF variables and attributes.
Variables require double-step process: at first variable(s) needs to be created
during the definition mode of netCDF file creation, then file should be switched
into input mode value(s) should be written into variable(s). Throughout the years
I saw a lot of instances when variables are created, but not written. In contrast,
netCDF global attributes are created in a single stage during the definition mode.
Same applies to reading: netCDF variable need 2-stage process: inquire ID, then
read it from that ID. In contrast, getting info from global attribute is a single
stage process.
So for things like time step size, vertical coordinate parametrs, S-curves, and
other information of such kind one can either create variables, or keep this info
as netCDF attributes.
Ergonomics: we often use ncview to make glance at netCDF file. Looking at Rutgers
format ncview command window is cluttered by dozen of buttons for all these auxiliary
variables, but actually you do not want to see them Same applies to WRF, but in
much more grotesque manner.
When such files are looked by ncdump -h, again, you screen will be cluttered by
useless information, AND, if you need, for example, to get things like dt, vcoords,
vstretching, Thetas, hc, S-curves, you have to use ncdump -v varname filename.nc
for each variable individually. And you will hate doing this if you have to do it
too often. In contrast, is all this descriptive data is kept as a set of global
attributes, a simple ncdump -h exposes them all in a nice easy-to-look at summary.
So the bottom line is: when it is use sufficient to use a global attribite
instead of variable I use global attribute.Same applies to AGRIF/CROCO conventions.
You problem will take only a few minutes to overcome because the very same package
you have compiled contains command-line operators nc_add_att and nc_del_all which
allow you to put all the necessary attributes from UNIX shell. First, execute
nc_add_att without any argument: it gives you self-explanation of what it does and
how to use it.
This applies to every other command in the package: once you compiled and installed
it, you discover that there are 50 or so executable files and you have no idea what
they are for and what they are doing - no problem: just execute them one-by-one
without argument - they print instruction of how to use it. All of them meant to
be self-explanatory.
So to add the necessary attributes you should, for example
Code: Select all
nc_add_att nf_global VertCoordType='SM09' file.nc [file2.nc file3.nc]
nc_add_att nf_global theta_s=3.5 file.nc [file2.nc file3.nc]
nc_add_att nf_global dt=250 file.nc [file2.nc file3.nc]
....
Above VertCoordType='SM09' corresponds to Rutgers vtransform=2 vstretching=2,
and dt=200 means 200 seconds (obviously you have to get the actual value first
by ncdump -v dt. Same applies to all other variable-to-attribute.