9.
Hierarchical Structure
Typically, simulations are constructed of many different types of
elements with different relationships to each other, mediated by the
exchange of messages. In order to keep track of the structure of such
a simulation, elements are organized into a tree hierarchy similar to
that of the directory structure in the UNIX operating system.
Obviously, as a simulation becomes more sophisticated, this tree
structure can become many levels deep. Nevertheless, if you organize
this structure properly, it will reflect the natural organization of
the system.
9.1.
The GENESIS Element Tree Hierarchy
Elements are stored in the GENESIS element tree. A particular element
is uniquely identified by a path name. The root of this tree has a
path of ``/''. The user can attach elements to this tree (at first as
children of the root and then later as children of these children).
The structure mimics that of the UNIX file system.
9.2.
Traversing the Element Tree
You use the following GENESIS routines to navigate the element tree.
______________________________________________________________________
Routine
Description
______________________________________________________________________
le
Displays a list of elements in the element tree.
ce
Changes the current working element.
pwe
Displays full pathname of current working element.
getpath
Returns subpart of full element pathname.
______________________________________________________________________
pushe
Saves current working element on stack (for later
retrieval
with pope) with option to go to new current working
element.
pope
Restores previously stacked element as current working
element.
stack
Displays list of elements on working element stack.
______________________________________________________________________
el
Returns list of elements matching wildcard
specification.
getelementlist
Alias for el routine.
______________________________________________________________________
9.3.
Pathnames and Wildcards
Each element has a unique name which is fully specified by giving its
pathname within the hierarchy. Pathnames are of the form:
name/name
or
/name/name
The first form specifies a path relative to the current element. The
second form is an absolute path from the top or ``root'' of the hierarchy. By analogy with UNIX directory names, the name may be an
actual element name, ``.'' (the current element), or ``..'' (the parent element).
Many commands can operate on more than a single element at a time.
Wildcard paths can be used to specify multiple elements which satisfy
the specified conditions.
A wildcard path is of the form
name[index][condition]
The wildcard name can be absent or can be one of
a#b
a?b
##
#
If an index is specified, it can be one of
index:
[]
[n]
[n-m]
One or more optional conditions may be specified in one of the forms
[field
[CLASS
[OBJECT
[TYPE
[ISA
operator
operator
operator
operator
operator
value]
classname]
objectname]
objectname]
objectname]
where the allowed operators are
= <> != > < >= <=
Note that white space is NOT allowed anywhere in the wildcard
specification. The # matches strings of any length while ? matches
single characters. The ## is a special name which specifies searches
down the entire subtree rather than at a single level.
For example, a path that specified all elements that had name
beginning with ``cell'' with x coordinates greater than 5 and less
than 10 would be:
/cell#[x>5][x<10]
Note that the # and ## DO NOT expand indexed elements.
given the following list of elements:
/TEST[0-5] and /THESE[0-2]
The command
echo {el /#}
For example,
would produce
/TEST /THESE
while
echo {el /#[]}
would give
/TEST /TEST[1] /TEST[2] /TEST[3] /TEST[4] /TEST[5]
/THESE /THESE[1] /THESE[2]
A path which would specify all elements in the hierarchy which belong
to the channel class would be:
/##[CLASS=channel]
The OBJECT identifier (and its older name, TYPE) is used to specify
elements which were created from a given object. For example,
setfield /##[OBJECT=xgraph] bg white
will set the background to white for all graphs which were created
from the xgraph object. The X1compat libray of XODUS 1 compatible
objects and commands uses the xgraph object as the basis of an
extended object, x1graph. Elements which are created from the x1graph
object will not be affected by the statement above. The ISA identifier is used instead of OBJECT to include elements created from
objects that were derived from a specified object. For example,
setfield /##[ISA=xgraph] bg white
It is also possible to specify comma separated lists of wildcard path
specifications, for example:
showfield soma/#[OBJECT=Ca_concen],basal_8/#[OBJECT=Ca_concen] Ca