The Ingrid language has both elements and objects. Elements
are a small set of datatypes, fixed in number, which form the nucleus of
the Ingrid language. Objects are one of those elements, and they are
the basis of most of the power that Ingrid has. At one level, objects,
can be used as dictionaries, i.e. lists of words and their definitions.
Ingrid:, PS, SOURCES are examples of such objects.
In these cases the words are kept in separate lists merely to attain
some neatness that would be lost with a single long list of words.
But the streams themselves are also objects. And while many streams
contain the word X signifying one of their grids, in fact the X
grid for many of the streams differ, so the fact that the definition of
X is contained within its parent stream allows the proper grid to be
retrived relatively automatically.
There are three sections that follow. The first gives the objects that should be included in almost all Ingrid input files, so that the needed words are available. The second gives the basic Ingrid elements. And the third gives the basic Ingrid Objects.
When FGFILE starts interpreting a file, the stack is set to be just the Ingrid: object. Thus most files should start with
\begin{ingrid}
PS SOURCES MODEL
\end{ingrid}
`SOURCES' so that the data catalog and `MODEL' are available, `MODEL' so that model variables can be accessed by name (`SSTT', for example), and `PS', so that laser plots can be generated. If you wish to define any words, it is a good idea to do it before PS SOURCES MODEL so that the definitions go into Ingrid:, otherwise the definitions go into MODEL, which may not be what you want.
As far as syntax is concerned, Ingrid is very close to PostScript, and a close reading of the PostScript reference manual will give you an adequate understanding of the subject. Here we present a brief summary, in part from that manual.
When given a file to interpret, Ingrid scans the entire file before
performing any calculations on the data contained in streams. Ingrid
ignores all text outside of \begin{ingrid}
\end{ingrid} pairs, i.e. all such text is considered as
comments. Note that \begin{ingrid} must be a line by itself,
and it must be at the beginning of the line (i.e. text column 1).
All text between \begin{ingrid} and \end{ingrid} is
broken down into tokens, and those tokens are interpreted.
The characters SPC, TAB, and LFD are considered whitespace and are treated equivalently outside of comments and strings. Whitespace separates tokens.
The characters (, ), /, >, [, ],
{, }, and % are special: they delimit syntactic
entities such as strings, procedures, literal names, and comments. Any
of these characters terminate the token preceeding it and are not part
of that preceeding token.
All other characters are regular characters.
Any text between a % and the end of that line is considered a
comment. (The only exception is that % can be within a string).
Thus lines that begin with % are comments. As mentioned before,
any text outside of a \begin{ingrid} \end{ingrid} pair is
also considered a comment.
Like PostScript, the elements that can be on the stack are typed. The types supported in Ingrid are
RANGE or LEVITUSMEAN.
These names are used to extract entries from objects, and sequences of
names are used to create procedures. A name preceded by a / is
treated as a literal, and simply placed on the stack. Otherwise the
name is executed. If the name is preceded by a >, then whatever
is currently on top of the stack is removed (popped) after name
is executed. This allows one to execute name within an object and not
leave that object cluttering the stack.
Internally, names are kept as a single integer (a fact that should not
turn up in ordinary coding).
Ingrid:, for example, contains
all the basic Ingrid words, like add and pop, etc).
Objects also contain the information to access data (streams are
implemented as objects).
Objects differ from dictionaries in two important ways. First of all,
objects have parents, so that a child object can access all the
definitions of its parent. Streams, for example, are implemented by
having a parent object STREAM, which contains all the operators that can
operate on streams, and each stream is then a child object of STREAM.
Secondly, objects are active when they are on the data stack (in
PostScript they have to be moved to the dictionary stack before they are
searched). Thus, if I want the X grid of the HELLERMAN taux data, I
simply say
HELLERMAN taux XThis also means that the defintions of PS and Ingrid: are made available simply by placing them on the stack at the beginning of the session.
What follows is essentially a dictionary, giving the definitions of all the major words within Ingrid. These words are grouped into several objects: Ingrid: which contains all the basic words plus the remaining major objects, SOURCES which contains all the data files in the data catalog plus MODEL, PS which contains the words used to make PostScript (laserwriter) plots, and MODEL which contains all the variables in the model the library is currently attached to (possibly none, in the case of a program that just operates on the data catalog).
Ingrid: is broken into two parts: FastGrid:, which contains the basic
words, and Ingrid:, which contains less fundemental but generally useful
words.
Eventually, FastGrid: will contain all the words in PostScript that
are appropriate, plus the words that are unique to Ingrid but in some
sense just as fundemental. These definitions are contained in
FastGrid: which is the parent of Ingrid:: to get a list of the
currently defined words in FastGrid: one must type within Ingrid:
parent ===
The basic words of Ingrid as as follows:
==
===
NaN
add
aload
and
append
array
astore
begin
cleartomark
copy
counttomark
cvi
cvlit
cvn
cvntos
cvx
def
div
dup
end
eq
exch
exec
false
for
lo to hi by step
by pushing the current value on the stack and executing proc.
forall
proc for each element in
array by pushing the first element onto the stack, executing proc,
pushing the second element onto the stack, etc.
forsome
ge
get
object key -- any ).
getinterval
gt
if
ifelse
index
integerarray
known
le
length
lt
mark
max
maxlength
max==array
min
mul
namearray
ne
not
null
object
parent
pop
print
pstack
put
putinterval
realarray
repeat
roll
round
setmax==array
null means print all the values.
split
procedures in the array [ ] to any, i.e. for each procedure
pushes any onto the stack and then executes proc. Usually used to
split a stream into substreams.
string
sub
type
true
xor
There are some generally useful words that are in the object Ingrid: but are not really fundemental.
!
put with the arguements are reversed.
concat
ensotime
leftlines
inputs
outputs
/myprog {
{ in1 in2 in3 } inputs
/outa in1 in2 add def
/outb in2 in3 sub def
{ outa outb } outputs
} def
Note this example could be written as
/myprog {
{in1 in2 in3 } inputs
begin
in1 in2 add % outa
in2 in3 sub % outb
end
} def
with only a slight loss of clairity, and a gain in efficiency. It is
your choice.
putget
any in object
with name, preserving a copy of any.
set.
..
.
set. and . are intended to simplify command writing by
removing garbage from the stack. For example,
\begin{ingrid}
PS SOURCES set.
HELLERMAN2 taux tauy X Y VECTOR .
HELLERMAN taux X Y CONTOUR .
\end{ingrid}
By ending each command with ., we can be assured that leftover
objects are not accumulating on the stack. Purely a matter of style.
Structures are implemented with a set of words that are in
structureWords. They are intended to be used to communicate with
FORTRAN programs, i.e. a structure containing various parameters is
passed in as the first argument of a FORTRAN subroutine when it is
called as the result of a FGIoper call. Structures are first created,
then used, i.e.
/regridS
structure
/N1 integer
/N2 integer
/N3 integer
/icoor integer
/si integer
/ra 4 realarray
endstructure
def
This structure can now be used to create a realization (called a RECORD in FORTRAN).
/fred
regridS new def % creates a new realization called fred
fred store begin % goes into a mode where each word stores its value
1 N1 % stores a value for N1
2 N2 % stores a value for N2
3 N3
4 icoor
5 si
1. 2. 3. 4. ra % stores 4 real values into the realarray ra
% the last element must be real
end % gets out of `store' mode
We can now use fred where a structure is required (i.e. FGIfunc
routines) or to extract individual values or to print. fred is
now an object whose definitions return values from the structure
realization's record.
fred
N1 N2 add == % adds N1 and N2 and prints
0. ra { add } forall == % sums the elements of ra
== % prints fred
One can also create structures that are equivalent to FORTRAN common blocks. To continue our example with fred, suppose there is a FORTRAN common block declared as
COMMON/fredblk/N1, N2, N3, icoor, si, ra(4)
We could then create a realization of regridS that is equivalent to this common block, namely
CALL FGIcommon('fredblk','regridS',N1)
N1 being the first location in the common block. We can now place values in the common block by using Ingrid,
fredblk store begin % puts fredblk into 'store' mode 10 N1 20 N2 30 N3 40 icoor % stores an integer into icoor 50 si % stores an integer into si 1. 2. 3. 4. ra % stores real data in fredblk end % takes fredblk out of 'store' mode N1 == % prints the value of N1 == % prints the common block fredblk
The words available are as follows.
FGIcommon(NAME,STRUC,COMM)
structure
endstructure
byte
element
integer
integerarray
myname
name
namearray
real
realarray
short
string
length characters to the
structure. This is equivalent to FORTRAN CHARACTER.
STREAM is the parent object to all streams (and indirectly all grids, since grids can be treated as streams). While the object STREAM is never needed directly, the definitions it contains are available whenever a stream is on the stack, and the words can be used to manipulate streams in a number of ways.
stream/netCDF attributes
In the spirit of minimizing differences, we want to support most of the `commonly used' netCDF attributes. These attributes allow one to label datasets with ancillary information, and also allow STREAM filters to carry that information along.
The attributes that have string values (fullname, title,
history) allow one to use a math escape (see section Math Mode) to
put simple mathematical expressions into labels.
A stream can have other attributes as well, these are simply the standard ones that the built-in filters in Ingrid process. Other attributes will be carried along even if they are primarily ignored.
See section Setting STREAM attributes for more explanation of how to modify these attributes for a particular stream.
history
name
fullname
longname
long_name
longname. Exists because it is the
standard netCDF name.
title
units
missing_value
scale_factor
add_offset
FORTRAN_format
STREAM attributes are set by defining the corresponding attribute within the stream. For example
HELLERMAN taux /title (This is HELLERMAN wind stress) def /fullname ($tau sub x$) cvn def
adds a title to the HELLERMAN data and modifies the name used for labelling plots.
It is important to make these definitions within the stream: a definition made elsewhere will just be ignored.
Within some of the attribute strings, a pair of $ signs is used to delimit a "math mode", where words are interpreted specially to create mathematical expressions.
Within the pair $ $, words are blank delimited, and each word is checked
against a list of symbol names (the names of the characters in the
PostScript symbol font, see the PostScript reference manual), to be
replaced by the corresponding symbol if it exists. Two special words,
sub and sup are used for subscripts and superscripts, i.e.
$ alpha sub i $ will give an alpha with a subscript i.
Words that are not translated to a symbol are printed in an italic font.
Outside the pair $ $, text is interpreted normally and printed in the usual font.
For example
/title (This is $partialdiff sub x phi + partialdiff sub y theta$.) def
will give @math{@partial @sub x @phi + @partial @sub y @theta}. This expansion is done in the PostScript printer or in the PostScript previewer, so the strings will appear as you have typed them everywhere else (i.e. netCDF files, the l... files, etc).
While any word is a legal choice for the units attribute, some
units are understood by Ingrid and are handled specially.
C
K
latitude
longitude
integer
real
units attribute
that is not recognized is printed as a real number.
Julian day is defined to be the number of each day, as reckoned consecutively since the beginning of the present Julian period on January 1, 4713 B.C.; the Julian day begins at noon, 12 hours later than the corresponding civil day. Ingrid has several functions to allow using Julian day as units, to allow some control over printing appearance.
julian_day
julian_day.day
julian_day.month
julian_day.year
In this climate prediction group, we have traditionally used units of 'monthtime', i.e. months since January 1960. There are several choices of units which correspond to monthtime: they differ only in print format.
monthtime
date
day
month
year
daymonth
There is a minimal facility for converting data to standard units (MKS). There is a simple access
convertunits
New conversions can be added to the object UnitsConversion.
STREAM
The following words are generally useful and found within the STREAM object. Since STREAM is the parent object for all streams, these words will always be available if there is a stream on the stack.
These words allow one to select portions of the data contained in the STREAM.
RANGE
low is rounded down
and high is rounded up, so that the range requested will be
within the stream.RANGESTEP
step. low is rounded down and
high is rounded up, so that the range requested will be within
the modified stream.
SAMPLE
grid according to grid2. Each element of grid2 is
moved to the nearest grid value.
STEP
step is rounded according to the grid.
VALUE
value is moved to the nearest grid value.
VALUES
array is moved to the nearest grid value.
sirecord==
makeperiodic ( stream grid period -- stream' ) makes a stream
In addition to the basic selection words -- RANGE, VALUE and STEP (see section STREAM selection) -- there are a number of STREAM filters. These are words who take one or more streams as input, and return a stream as output. Some functions also work on real numbers.
Other functions can be added. Read the section on FGIscalarFilter (see section FGIscalarFilter) if you would like to add scalar functions, or read the section on FilterVector (see section FORTRAN routines) to add functions of vectors. More complicated functions require more understanding of Ingrid.
Functions
chunkaverage
chunkmin
chunkmax
chunksum
cos
cosd
eexp
ln
log
pi
sin
sind
sqrt
sqrtsgn
min
max
GRID
low to high by
step ] in variable grid.
REGRID
RESCALE
mul and add, see
below.
SAMPLE
grid according to grid2. Each element of grid2 is
moved to the nearest grid value.
toNaN
FillNaN
stream X 0. FillNaNfills in missing data by carrying data zonally; 0. is used if an entire latitude is invalid data. The function is symmetric: land with ocean on both sides is replaced by values that have a sharp transition in the middle of what used to be land.
removeGRID
renameGRID
grid is
renamed to newname.
replaceNaN
setmissing_value
SM121
add
sub
mul
div
distrib
min to max in
steps of step.
distrib2D
gridtomatch
CALL SetIVAR1('X','longitude',NX,XS,XE) ! defines X grid
CALL SetIVAR1('Y','latitude',NY,YS,YE) ! defines Y grid
CALL SetIVAR1('T','real',NT,TS,TE) ! defines T grid
IDH = NewVar('H','/MODEL /H','XYT','XY') ! defines stream H
IDHIN = IDSTREAM('Hin H gridtomatch') ! defines a stream which is
! Hin regridded to match H
...
DO I = 1 , NT ! loop to retrive the regridded Hin
CALL FGGET(IDHIN,H) ! in blocks of XY, one block for each T
END DO
to read in the stream Hin into the array H, regridded as needed.
gridtomatch can also be used to control regridding in other
situations. For example, if you would like to regrid a climatology to
an anomaly before adding them together,
\begin{ingrid}
GL SOURCES % accesses X/GL graphics and data catalog
CACSSTA ssta % gets sst anomaly
OSUSFC.DATA sstt
CACSSTA ssta gridtomatch % regrids climatology to anomaly's grid
add % adds regridded climotology to anomaly
DATA 20 30 2 RANGESTEP % specifies color scale
X Y COLORCONTOUR % color contour plot
\end{ingrid}
gridtomatchnamed
gridtomatch).
Also names that stream as name in object.
If verbose is true, then a message is printed describing the input
stream. verbose defaults to false.
CALL SetIVAR1('X','longitude',NX,XS,XE) ! defines X grid
CALL SetIVAR1('Y','latitude',NY,YS,YE) ! defines Y grid
CALL SetIVAR1('T','real',NT,TS,TE) ! defines T grid
IDH = NewVar('H','/MODEL /H','XYT','XY') ! defines stream H
IDHIN = IDSTREAM('Hin H MODEL /Hin2 gridtomatchnamed')
...
DO I = 1 , NT ! loop to retrive the regridded Hin
CALL FGGET(IDHIN,H) ! in blocks of XY, one block for each T
END DO
AVERAGE
stream over
grid.
SUM
stream over grid.
mean
AM will
depend on those grids, i.e. AM(grid1, ...). qual is the minimum fraction of data that must be
present to return a value, e.g. if qual is .5, then all points which had
more than half the data missing are marked missing.
meansq
AM will
depend on those grids, i.e. AM(grid1, ...). qual is the minimum fraction of data that must be
present to return a value, e.g. if qual is .5, then all points which had
more than half the data missing are marked missing.
rms
AM will
depend on those grids, i.e. AM(grid1, ...). qual is the minimum fraction of data that must be
present to return a value, e.g. if qual is .5, then all points which had
more than half the data missing are marked missing.
average
qual is the minimum fraction of data that must be
present to return a value, e.g. if qual is .5, then all points which had
more than half the data missing are marked missing.
rmsover
qual is the minimum fraction of data that must be
present to return a value, e.g. if qual is .5, then all points which had
more than half the data missing are marked missing.
standardize
qual is the minimum fraction of data that must be
present to return a value, e.g. if qual is .5, then all points which had
more than half the data missing are marked missing.
correlate
qual is the
minimum fraction of data that must be present to return a value, e.g. if
qual is .5, then all points which had more than half the data
missing are marked missing. Note that the time series are first
renormalized separately, so that if there is a lot of missing data then
the means and standard deviations for the time series could be computed
over very different subdomains of the data, a long-winded way of saying
that in pathological cases you could get correlations greater than 1.
boxAverage ( stream grid interval -- stream ) reduces grid
interval by averaging.
runningAverage ( stream grid interval -- stream ) smooths grid
interval by averaging.
regridAverage ( stream grid grid2 -- stream ) changes grid
grid2. The grid change is done by averaging,
effectively using fractional weights at the edges of intervals if
necessary to center the intervals on the output grid.
evengridAverage ( stream grid low step high -- stream ) changes
grid to an even grid that goes from low to high by
step. This uses regridAverage.
yearly-climatology
splitstreamgrid
grid into a grid that
steps within period and a grid that has step period using
word splitgrid, then alters the stream so that it corresponds to
the new grids. The second grid is renamed by appending a 2. Data
beyond an integral multiple of period is truncated. The values
of the second grid are multiples of the period; the sum of the value of
the first grid and the value of the second grid give the original grid
value for any particular data point.
integral
stream with respect to
grid. This shifts the grid in the opposite sense of
partial, so that the two operators cancel each other, i.e.
partial and integral are inverse operators (modulo the
integration constant if you take the partial first).
Simple 1D streams can be used as grids, i.e. you can fix the units on
the grid by multiplication.
definite-integral
stream with respect to
grid from low to high. It interpolates the end points if
necessary, i.e. the limits do not have to be grid points.
partial
stream with
respect to grid. The partial derivative is computed by taking
the difference between two values of the input stream, normalized by the
grid distance between them. The grid is shifted so that each value of
the new stream is centered between two values of the old stream.
Simple 1D streams can be used as grids, i.e. you can fix the units on
the grid by multiplication.
differences
stream along
grid. These are the pairwise differences that would be
normalized by the grid widths in order to calculation the partial
derivative along grid. The grid is shifted so that each value of
the new stream is centered between two values of the old stream.
sums
stream along
grid. The first value is always zero, the remaining are
successive partial sums. The grid is shifted in the opposite sense to
differences. In fact, this is the inverse function to
differences.
toS
toS will then convert to a grid), and
@math{X} the grid that is being replaced by @math{S @sub 0}. The output is
the new stream @math{T(S @sub 0)}.
For example, to get depth of the @math{20 @sup @circ} isotherm, you would say
temp Z exch 20 Z toSTo get the depth of several isotherms, you would say
temp Z exch [ 20 21 22 ] Z toSTo get the salinity of the @math{20 @sup @circ} isotherm, you would say
sal temp 20 Z toS
transit
shiftdata
There are also filters for the oceanic equation of state. These are
included in the program ingrid: they will be included in a model only
if createEOS is called in addition to calling
createIngrid.
abrat
beta
dens
densa
depth
potemp
pressure
Looping
Looping with streams is possible in an iterative sense. The idea is to create a filter than gives future realizations from earlier ones. Four words are used to implement this: beginLoop, endLoop, and for convenience, loopStream and fullloopStream. In a simple case, you only need beginLoop and endLoop. For example,
PS SOURCES OSUSFC.DATA sstt T 3.5 VALUE % extracts an initial condition /A /integer ordered 1 1 5 NewEvenGRID % loop will iterate 5 times beginLoop 1000 add % x = x + 10000 endLoop X Y CONTOUR
loopStream furnishes an additional copy of the stream that beginLoop returns; fullloopStream furnishes an additional copy of the stream that endLoop will return (fullloopStream includes the final realization; loopStream does not).
beginLoop
endLoop
loopStream
fullloopStream
Explicit:endLoop
L4cycle:endLoop
NewGRIDdef
NewGRID
type should be either
ordered, periodic, or unordered. The array can
either be an array of numbers or of names; if it is names the type
should be unordered. If there is only a single element in the array, the
[] can be omitted.
NewEvenGRID
partialgrid
integralgrid
partialgrid.
splitgrid
period and the second grid has step
period. The second grid is renamed by appending a 2 to the name
of the original grid. If the original grid has units `monthtime', the
output grids have units `month' and `year' respectively (these units
differ only in how they are printed, all correspond to monthtime
values).
first
second
last
low
high
step
name
npts
grideven
gridtype
setgridtype
gridvalues
units
setunits
buffer
SIRecord ( grid -- grid SIRecordid ) returns SIRecord of a grid.
bufferSIRecord ( grid -- grid SIRecordid ) returns SIRecord of a
PrintStream
FORTRAN_format to format the data
values.
To be more exact, PrintStream constructs a FORTRAN format by inserting
FORTRAN_format into a format string
FORMAT(99(FORTRAN_format):/)
and it uses this FORMAT to print each line of the table. So if you set
FORTRAN_format to print a single number, it will print up to 99
numbers per line. If you want fewer numbers per line, set
FORTRAN_format accordingly:
/FORTRAN_format (10F10.0:/) defwill print 10 numbers per line, for example.
See section Setting STREAM attributes for more explanation of how to set
FORTRAN_format.
The information carried along with a stream is similar in concept to the information carried along in a netCDF file. Consequently reading a netCDF file merely requires specifying a file name; writing a netCDF file additionally requires specifying an input stream.
netCDF files are portable binary files: they can be moved to other kinds of machines and read without modification. There are two basic utilities that allow one to examine and create netCDF files.
ncdump is a utility that prints out the header information and
(optionally) the data from a netCDF file
(see section `ncdump' in netCDF User's Guide).
ncgen is a utility that helps generate either netCDF files or the
FORTRAN (or C) code to produce netCDF files
(see section `ncgen' in netCDF User's Guide).
You may, however, find it easier to use Ingrid to read and generate netCDF files.
In each case the file name is specified as a string.
writeCDF
appendCDF
readCDF
SOURCES GLOBALHELLERMAN taux (hellerman.cdf) writeCDF GLOBALHELLERMAN tauy appendCDFThis CDF file can be used later to make plots, namely
PS (hellerman.cdf) readCDF taux T 5.5 VALUE X Y COLORTo read NASA CDF files,
createNASACDF is required after the
createIngrid call, and the /usr/local/CDF/lib/libcdf.a
library must be included when linking.
writeGrADS
string and a GrADS data file with name
string.data (GrADS data files are binary direct access in XYZT
order). At present will only handle a single variable/stream.
writeHDF
writeHDF is not necessarily available with a model.
createHDF is required after the createIngrid call, and the
-ldf library must be included when linking.These words manipulate STREAM documentation.
STREAMDOC
addhistory
2combinehistory
combinehistory
combinefullname
name
or string.
If the arguments are streams rather than fullnames, then single point
grids are appended to the name under special circumstances. If
n<0, then all the single point grids are appended. If
n>0, then only the single point grids that have different
values in different streams are appended to the name. The latter
behavior means that single point grids which have the same value for all
the input streams remain a (single point) grid for the output stream:
single point grids that have different values in different streams
become part of the label. This way
H Z 0 VALUE H Z 100 VALUE subis labeled 'H ( Z=0 - Z=100)' while
H Z 0 VALUE U Z 0 VALUE mulis labeled 'H * U' and has a Z grid with one point (Z=0).
These words are all contained within the STREAM object. They are not called by the ordinary user.
They also have little in the way of safeguards built in. For example,
ReplaceGRID will let you change a grid in the stream. It does
not check, however, whether the new grid has the proper number of points
in it to represent the stream (it assumes you know better than it, and
thus assumes you have written a filter that changes the number of points
in that particular dimension of the stream). So be careful!
TaskStreams
TaskStreams 0 getreturns the first input stream for the function. Frequently used with NewBuffer to define functions which filter streams.
TaskParameterBlock
LastStream
NewBuffer
SetStreamIndex* ... *
SetStreamIndex*
*
2 SetStreamIndex* X Y Z *
gridno
gridstride
ndim
nrdim
chunk
>chunk
achunk
>achunk
streamgrids
>streamgrids
stream from the stack.
chunksize
nchunk
GRIDParent
NewStreamPtr
replaceGRID
setIthGrid
grid.
STREAMGRID
array.
REORDER
MATCH
CommonStream
CopyStream
InStream
FilterStream(NWORDS)
FilterNaNStreams(NSTREAM,NSPACE)
NSTREAM
NSPACE
FilterStreamsNewSize(NSTREAM,NSPACE,NSIZE)
NSTREAM
NSPACE
NSIZE
NewStreamTask1(ROUTINE,NPTS,N,NSPACE)
ROUTINE
NPTS
N
NSPACE
Filtervector(SUBROUTINE,N,M,DGRID,DEFS)
SUBROUTINE
N
M
DGRID
DEFS
These words are useful for debugging. Some, however, require a fairly good understanding of how Ingrid works to be of any use.
DoTasks
DebugTasks
TestStream
TraceStream
StreamTree
LastTaskTree
SOURCES contains streams for all the data sets in the data catalog. It also contains MODEL, the object that contains all the variables defined in a model directly attached to Ingrid.
At the moment, a dataset from the data catalog is returned as a
stream. For example, LEVITUSMEAN is a stream which contains two
special filters temp and sal.
In the future this will be changed so that LEVITUSMEAN is an object that
contains two streams temp and sal. This new behavior is
more consistent with the MODEL object and the netcdf objects that
readCDF returns. At that point the phrase LEVITUSMEAN temp would
become LEVITUSMEAN >temp. This works because >temp is a
special Ingrid shorthand to first execute temp, then remove
LEVITUSMEAN from the stack. Thus > can be thought of as
"extract".
MODEL contains all the variable names for the model. Normally it is put on the stack near the beginning of the command file. It also contains the more internal words that actually implement MODEL variables.
MODEL
GRIDList
RVARParent
NewModel(NAME)
ModelDESC(STRING)
VarDESC(VarName,STRING)
SetIVAR1(COORD,UNITS,NX,XS,XE)
COORD
UNITS
NX
XS
XE ending value
SetIVAR2(COORD,UNITS,NX,XSS)
COORD
UNITS
NX
XSS
NewRVAR(VAR4,VARL,IVARS,IRECEEP)
RECEEP
variable, making it possible to use the data corresponding to that
variable.
Inputs
VAR4
VARL
IVARS
IRECEEP
RECEEP
DoRVARs
NewVAR(VAR4,VARL,IVARS,BVARS)
VAR4
VARL
IVARS
BVARS
NewVar
history, title, or
missing_value.
See section Setup routines for a more complete explanation of how to use the routines of this section.
The routines within PS are used to make PostScript plots. Each plot is put in a separate file: the files are numbered .001 ... .nnn. The files are numbered in the order requested, not in the order generated.
Some of the words--like XOVY, linetype, and linetypelist--are parameters that have default values and need to be set if you wish an alternate value. The simplest way to do this is to extend the current stream and then redefine the values you wish to change. For example,
/XOVY 2 def /linetype KeyLines def
redefines XOVY and linetype.
The remaining words--LINEX, LINE, CONTOUR, DATA xx yy RANGE, and DATA xx STEP-- operate directly on streams.
setplotname
AUTO
null element -- the programs have to deal
with it from there.
XOVY
CSCALE
arrowsperinch
linetype
PLOTGRID
PLOTCOAST
color_smoothing
linetypelist
(\nnn) specifying special
PostScript characters with an octal escape, and square brackets allow
one to have both, e.g. [10 (a)] gives a plain line with an 'a'
marking each point, and [20 (\267)] gives a wider
plain line with a bullet marking each point. Successive line types are
separated by spaces
/linetypelist [ 20 (\267) [11 (a)] ] defspecifies three line types, a plain line, bullets, and a line marked with a's. You can also invoke arbitrary PostScript code, so that you can specify linetypes other than the 10 built-in patterns or colors. For example, to specify varying patterns and colors for three lines, the following declaration will do,
/linetypelist
[
[ 0 { 1 0 0 setrgbcolor } ]
[ 1 { 0 1 0 setrgbcolor } ]
[ 2 { 0 0 1 setrgbcolor } ]
] def
averaging_type
DATA
RANGE
DATA lo hi -- stream' ) modifies stream to have the
given contouring limits.
STEP
DATA step -- stream' ) modifies stream to have the given
contouring interval.
VALUES
DATA [ con1 ... conn ] -- stream' ) modifies
stream to have contours at the specified values.
LINEX
LINE
CONTOUR
COLOR
VECTOR
HISTOGRAM
min to
max in steps of step.
SCATTER
U V [ X Y ] Z SCATTER will give scatter plots of U vs. V with
different symbols for each Z.
Additionally, some of the netCDF attributes are used in creating
labels, namely longname, title, and history.
startcolormap
endcolormap
startcolormap and endcolormap, the following words
are allowed:RANGE
RGB
steps
0 0 255 RGB 23 34 0 RGB 10 steps
value
stripe
... green blue 0 value white stripe blue darkgrey 10 value ...This inserts a white stripe at zero in a colormap that smoothly varies from green to blue to darkgrey otherwise.
RGBdef
R G B RGB. The colors are:
beige, black, blue, brown, burlywood, cyan, darkgrey, gold, green, grey,
khaki, maroon, orange, peru, purple, red, sienna, turquoise, wheat,
white, yellow ... . You can also get a list of the colornames by typing
PS ColorMap {pop ==} forall in Ingrid.rainbowcolormap
grayscale
greyscale
Go to the first, previous, next, last section, table of contents.