Routine Name: abort Description: Cleanly interrupts simulation in progress. Usage: abort Example: abort Notes:See also: stop , step
Routine Name: abs
Description: Returns absolute value of number.
Usage: positive-number = abs any-number
positive-number returned as absolute value of
any_number
any-number number (float or int) for which to
compute absolute value
Example: genesis > echo { abs -22 }
22
genesis > int x
genesis > float y
genesis > y = -33.333
genesis > echo { abs {y} }
33.333000183
genesis > x = {abs {y}}
genesis > echo {x}
33
Notes:
Routine Name: acos
Description: Returns angle (in radians) corresponding to given cosine.
Usage: angle-in-radians = {acos cosine}
Example: genesis > echo { acos 1 }
0
genesis > float degrees_per_radian = 360 / (2 * 3.1415926)
genesis > echo {{ acos 0.707} * degrees_per_radian}
45.00865245
Notes:
See also:
cos
Routine Name: addaction
Description: Adds a named action to the action table used by element types.
Usage: addaction name action_func
addaction name id-number
Example: addaction NEWACTION 10
addaction K_squid_hh K_squid_hh_SET
(see Scripts/tutorials/hhchan_K.g)
Notes: Each object in a simulation is capable of performing one or
more "actions". An action can be described as an operation
that an object performs on its data. Actions are defined
within compiled functions which are attached to each object.
(You can display a list of actions which an object can perform
and the function(s) which perform using the showobject
routine.) For instance, objects of type compartment can
perform the actions:
RESTORE2 SAVE2 SET CHECK RESET PROCESS INIT
(The actions are actually performed by an underlying C
function associated with the compartment element type.)
You use the addaction routine to add the named action to the
action table. Actions are passed to the handler routines
associated with each type of GENESIS object. The handler is
expected to perform the necessary actions when a given action
type is passed to it by the simulator.
For the most part this routine will only be used when adding
new object types which require use of additional (non-default)
actions already known to GENESIS.
You use the addaction routine to define new actions to be used
by elements. There are a number of predefined actions
which are typically used by objects. PROCESS is one of them.
New actions can be added in any object. Use the 'addaction'
routine in the object definition script to inform the
simulator of the new action. The case number assigned to new
actions is relatively arbitrary as long as it does not
conflict with the case numbers of other actions defined in the
object. (you should get a compiler error if there is a
conflict).
When used as a GENESIS command, addaction is primarily used
in the construction of extended objects. It is also used as
a library intialization command during the compilation of
GENESIS libraries.
See also:
object ,
Extended Objects, Defining New
Objects and Commands (
NewObjects )
Routine Name: addalias
Description: Associates alternative name with existing GENESIS command.
Usage: addalias alias-name command-name
Example: addalias set setfield
Notes: You may put a number of addalias statements in a file and
use an include statement in the .simrc file to include the
file when GENESIS is started.
See also:
addescape
Command Name: addclass
Description: Adds a new class to list of currently recognized GENESIS
element classes.
Adds a new class tag to a given element.
Usage: addclass [element] class-name
Example: addclass /sine device
Notes: The addclass routine adds a class tag to a given element
identifying it as belonging to the given class. Omitting
the element defines a class name without assigning any
element to the class. (This is a deprecated usage which
may not be supported in future releases).
Objects can be grouped into named classes. This
grouping can be used to facilitate the specification of
operations to be performed on functionally related
elements. See scheduling (e.g., the addtask
routine, and Schedules) for an example of class use.
Classes are simply used for grouping of related
elements and do not alter the element functionality in
any way. Classes in GENESIS don't carry the full
connotations of classes within a true object-oriented
programming environment. They are simply convenient
ways of creating named groupings to which objects can be
assigned.
See also: listclasses,
deleteclass ,
showobject ,
Extended
Routine Name: addescape
Description: Adds an escape-key macro binding.
Usage: addescape esc_sequence command-string [-execute] [-id string]
esc_sequence actual keystrokes (or representation)
to associate with escape action
command-string string to insert in place when escape
sequence is issued (should be in
quotation marks if it contains blank
spaces)
-execute flag to have command-string executed
when escape sequence is called
(this puts the field EXEC in the
listescape table; if -exec is left
out, default is REPLACE, i.e., insert
command-string, unexecuted, in command
line at point escape sequence is
issued)
-id string label for this escape sequence, used
typically to identify the escape
sequence in user-understandable
language
Example: genesis > addescape [15~ "/xproto" -id "F5"
genesis > le <F5>
[line changes to:]
genesis > le /xproto
/draw
[associate command string 'echo "I am not a duck"' with key
stroke sequence escape-a:]
genesis > addescape a "echo I am not a duck" -execute
genesis > <escape-a>
I am not a duck
[from escapelist.g file, included in startup:]
addescape [A <^P> -id "up arrow"
addescape [B <^N> -id "down arrow"
addescape [C <^F> -id "right arrow"
addescape [D <^H> -id "left arrow"
addescape [1~ "execute movebol" -exec -id Find
addescape [2~ <^I> -id "Insert Here"
addescape [3~ <^D> -id Remove
addescape [11~ stop -exec -id F1
addescape [17~ "status -process" -exec -id F6
addescape [18~ status -exec -id F7
addescape [28~ "commands | more" -exec -id Help
addescape [29~ step<CR> -id Do
Notes: You use the addescape routine to create escape-key macros for
commonly used command lines. Here, the key is the key you
will depress after the escape key, and command-string is the
string which will be substituted into the SLI interpreter when
the the escape sequence occurs. (When the key is preceded by
escape -- ctrl [ -- during keyboard input, the command-string
is substituted.)
A standard set of escape-key macros is specified during
startup through the file escapelist.g.
See also:
listescape
Routine Name: addfield
Description: Add an extended (user-defined) field to an element.
Usage: addfield [element] field-name [-indirect element field]
[-description text]
field-name name of the new field to be added to element
-indirect make the field-name an alias for the a field
in another element
-description add a descriptive text string
Example: addfield /cell/soma area -d "Area of the compartment"
Notes: If you have a compartment, /soma, with a hh_channel
/soma/hh_Na, then
addfield /soma Gk -indirect hh_Na Gk
will add a field to /soma called Gk which is an alias for
/soma/hh_na Gk. Note that the path in the -indirect option
is relative to the element to which you are adding the
field. The indirect element path can also be an absolute
path.
See also:
deletefield
Routine Name: addforwmsg
Description: Forwards an incoming message to one element to another
element.
Usage: addforwmsg source-element message-number destination-element
source-element element from which the message will be
forwarded
msg-number number (index) of message in message list
(messages are numbered from 0 up)
destination-element
element to which the message will be forwarded
Notes: The destination element must accept messages of the same
name and with the same number of data slots as the message
being forwarded.
See also:
deleteforwmsg ,
showmsg ,
Extended
Routine Name: addglobal
Description: Declares a global variable of the specified type, allowing the
name of the global variable to be held in a string variable.
Usage: addglobal type name [value]
type must be one of int, float or str.
Example:
genesis > str name = "foo"
genesis > addglobal float {name} 5.55
genesis > listglobals
float foo = 5.55
str name = "foo"
(plus many others)
Notes:
Often it is useful to use a string variable name to hold the name of a
global variable. For example, one may want to pass the name of a global
variable to a function that declares a global variable, or that sets or
returns its value. However, normal GENESIS syntax for declarations and
assignments does not permit a variable name to be specified by a string
variable. The routines addglobal, getglobal, and setglobal are designed
to overcome this limitation.
Note that if addglobal is used within a function definition, the declared
variable will nevertheless be global, and not local to the function.
See also:
Variables ,
setglobal ,
getglobal ,
listglobals
Routine Name: addmsg
Description: Establishes message links between two elements.
Usage: addmsg source-element dest-delement msg-type [msg-fields]
Example: addmsg /cell/dend /cell/soma RAXIAL Ra previous_state
addmsg /cell/soma /cell/dend AXIAL previous_state
addmsg /cell/soma /graphs/Vmgraph PLOT Vm *voltage *red
Notes: addmsg sets up communication links to pass information
between elements. Messages flow along message links created
by the addmsg routine each time a simulation timestep is
executed.
For example, an asymmetric compartment connected to another
asymmetric compartment needs to send both its axial
resistance, Ra, and its membrane potential at the previous
simulation step to the second compartment. In order to update
its state, it needs to receive the second compartment's
previous membrane potential.
See also:
deletemsg ,
showmsg ,
getmsg , gen3dmsg, dd3dmsg
Routine Name: addmsgdef
Description: Adds a new message type allowing messages of that type
to be added to the element.
Usage: addmsgdef element message-name [message-arguments...]
-type message-type
element element for which to add the message
definition
message-name name of the message (the convention is
to use all upper case)
messages-arguments
zero or more names for the data slots
of the message
-type option to set the message type number
explicitly
Notes: It is normally unnecessary use the -type option as
addmsgdef assigns an unused message type number
automatically. -type should be necessary only for
specifying active messages.
See also:
deletemsgdef ,
showobject ,
Extended
Routine Name: addobject
Description: Adds a new object to GENESIS defined by the fields, message,
actions and class tags of the given element. The element
is removed and used as a prototype for initial field values
of new elements created from the new object.
Usage: addobject object-name element -author author-info
-description descriptive-text ...
object-name the new name for the object
element element from which to create the new object
-author Information about the author of the object
-description A description of the object; multiple
arguments to -description may be given
resulting in multiple lines of descriptive
text
Notes: The object name must not be the same as an existing
object. Currently, there is no corresponding
deleteobject command.
See also:
listobjects ,
showobject ,
Extended
Routine Name: addtask
Description: Adds a simulation event to the simulation schedule.
Usage: addtask function [arguments...]
function a compiled C function to be executed at each
step in the simulation phase according to its
order in the schedule table (almost always,
this fucntion will be "Simulate")
arguments arguments for the specified function
[practically speaking this means:]
addtask Simulate path -action action-name
path path specification of elements affected
(typically a wildcard path designation
with a CLASS-conditioned selection to
identify all elements of a specific type)
action-name action to perform on specified elements
(usually INIT or PROCESS; must be a valid
action, as determined by listactions)
Example:
addtask Simulate /##[CLASS=myclass] -action PROCESS
addtask myfunction myargs
from startup/schedule.g:]
deletetasks
addtask Simulate /##[CLASS=buffer] -action INIT
addtask Simulate /##[CLASS=segment] -action INIT
addtask Simulate /##[CLASS=device] -action INIT
addtask Simulate /##[CLASS=buffer] -action PROCESS
addtask Simulate /##[CLASS=projection] -action PROCESS
addtask Simulate /##[CLASS=spiking] -action PROCESS
addtask Simulate /##[CLASS=gate] -action PROCESS
addtask Simulate /##[CLASS=segment][CLASS!=membrane][CLASS!=gate]\
[CLASS!=concentration][CLASS!=concbuffer] -action PROCESS
addtask Simulate /##[CLASS=membrane] -action PROCESS
addtask Simulate /##[CLASS=hsolver] -action PROCESS
addtask Simulate /##[CLASS=concentration] -action PROCESS
addtask Simulate /##[CLASS=concbuffer] -action PROCESS
addtask Simulate /##[CLASS=device] -action PROCESS
addtask Simulate /##[CLASS=output] -action PROCESS
resched
Notes: GENESIS provides a default simulation schedule that handles
most simulation configurations (see above), but for your
simulation you may need to specify a different order in which
the simulator should process elements in the simulation. You
use addtask to enter simulation events to the simulation
schedule.
You must be careful to avoid multiple references to elements
with the same action. For instance, given a model containing
the six elements /test[1-6], the following schedule would be
an invalid specification since it would cause test[1] to be
invoked twice on each simulation step.
addtask Simulate /test[1] -action PROCESS
addtask Simulate /test[1-6] -action PROCESS
With broad path specifications, it is easy to accidentally
include multiple reference. However, you can check for these
occurrences by running the check routine. In the above case,
calling check after entering the above specifications would
generate the following message:
** Error - '/test[1]' multiply invoked
with action 'PROCESS'. Check task [2]
Task [2] refers to the second addtask command. This
command was responsible for the conflict.
Alternately, not scheduling all enabled elements (see enable)
for simulation is detected as an error by the check routine.
For instance, given the model of six elements used above, you
might define a schedule with one addtask call as follows:
addtask Simulate /test[1-5] -action PROCESS
Running check would produce the following message:
* Warning - '/test[6]' is not scheduled for simulation.
A valid schedule for this set of elements might be:
addtask Simulate /test[1] -action PROCESS
addtask Simulate /test[2-6] -action PROCESS
or
addtask Simulate /test[1-6] -action PROCESS
See also: <href id="Schedules">, <href id="resched">,
<href id="deletetasks">, <href id="showsched">, <href id="check">
Routine Name: argc
Description: Returns argument count (number of arguments passed to a
function).
Usage: int-value = {argc}
Example: if ({argc} > 3)
echo usage: foo a b c
return
end
Notes:
See also:
argc ,
argv ,
getarg ,
printargs
Routine Name: arglist
Description: Converts list of items into an argument list.
Usage: arglist string
Example:
genesis > str s ="a b c d"
genesis > echo { getarg {arglist {s}} -arg 3}
c
str s
str thingys = "foo bar baz"
foreach s ({arglist {thingys}})
echo {s}
end
Notes: In each of these examples, a single string consisting of
items separated by spaces has been converted into a list.
See also:
argc ,
argv ,
getarg ,
printargs
Routine Name: argv
Description: An array of strings containing the arguments passed to
a function.
Usage: argv position-number
Example:
function echoargs
int i
echo "Number of arguments = "{argc}
for(i=1;i<= {argc};i=i+1)
echo {argv {i}}
end
end
genesis > echoargs foo 5 1.23
Number of arguments = 3
foo
5
1.23
Notes: As with C, indices of argv should start with 1.
See also:
argc ,
arglist ,
getarg ,
printargs
Routine Name: asciidata
Description:
Converts a FMT1 formatted binary file (as produced by the
disk_out object, for example) to ASCII. Output is to stdout.
Usage:
asciidata file-name -time t -cell cell -gain g -old -xy -skip n -header
One of options -cell, -time or -header must be given.
Example: (using the horiz_disk file from Scripts/orient_tut)
genesis > asciidata horiz_disk -header
FMT1
start time = 0.000000e+00
time step = 1.000000e-05
cellnum = 25
data type = 4
data size = 4
genesis > asciidata horiz_disk -cell 24 | more
-7.006086e-02
-7.012120e-02
.
.
-7.597300e-02
-7.596859e-02
//(provides Vm at each time step; adding -xy option gives t and Vm)
genesis > asciidata horiz_disk -time 1.e-4 -xy
0 -0.0706427
1 -0.0706427
2 -0.0706427
.
.
23 -0.0706427
24 -0.0706427
//(cell number and Vm for each of the 25 cells)
See also:
disk_out
Routine Name: asin
Description: Returns angle (in radians) corresponding to given sine.
Usage: angle-in-radians = {asin sine}
Example: genesis > echo {{ asin 0.5 }*(180/3.1415926)}
30.00000135
Notes:
See also:
sin
Routine Name: atan
Description: Returns angle (in radians) corresponding to given tangent.
Usage: angle-in-radians = {atan tangent}
Example: genesis > echo { atan 0.876 }
Notes:
See also:
tan
Routine Name: call
Description: Allows an element to execute the function associated with the
named action.
Usage: call path action [args...] -parent -virtual
-parent call the action on the element using the parent object
of the current object context as the new object
context
-virtual call the action on the element using the element's
object as the object context during the action.
Example: call /form/graph RESET
call /form/graph/plot ADDPTS {x} {y}
Notes: The call routine allows the user to send an action to an
element's handler routine (outside of the simulation cycle).
An action executes in the context of a specific object which
is either the element's object or some base object for the
element. The object context determines what fields,
actions, messages and classes are known and accessibility of
fields during execution of the action function. Without any
other options to call, the object context during the call is
the element's object or the current object context if the
element is already executing an action. The -parent and
-virtual options modify this. These options are to be used
when an action is called within the function definition of
an action to be added with the addaction command. They have
no affect when used outside an action function.
See also:
addaction ,
Extended
Routine Name: callfunc
Description: Allows you to call a function whose name is stored in a
string variable.
Usage: callfunc funcname ...
Example: genesis > str foo = "echo"
genesis > callfunc {foo} a b c
a b c
Notes:
See also:
Routine Name: cd
Description: Changes current working operating system directory.
Usage: cd directory
Example: genesis > cd /usr/genesis/Scripts/neuron
Notes: This is a GENESIS implementation of the operating system
command cd, to assure that any change you make in the working
directory is known to GENESIS. (If you just issued a normal
cd command directly, via "sh cd" for instance, the
change in the current working directory would last only as
long as the subshell created to enact the command, and future
actions in GENESIS would not recognize a change. The GENESIS
implementation of cd fixes this.)
See also:
sh
Routine Name: ce
Description: Changes the current working element.
Usage: ce element-path
element-path complete or relative pathname of element to
make current working element; can also be
operating-system style hierarchy
abbreviations, such as . (current),
.. (element above current)
Example: ce /
ce /proto
ce output
ce ..
genesis > create compartment foo
genesis > ce ^
genesis > pwe
/foo
Notes: All GENESIS elements exist in a hierarchy. The root element
lives at the top of the tree (designated by /) and child
elements are created beneath the root. You use the ce routine
to move about the tree (much as you can use the "cd" command
to move about the operating system file system).
If the element-path specified in a ce call starts with a /
then the path is assumed to be an absolute path from the root
of the element hierarchy. If the first character of the path
specified is not a / then the path is assumed to be relative
to the current working element.
See also:
pwe ,
le ,
pushe ,
pope ,
stack
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is passed to a command through a script variable
or as the result of a command or script function will not be
translated. For example, if leoptions is a script string variable
holding the value "-R" (a recursive listing), then the following code
will not be converted:
le {leoptions}
The cong t 25.25 cellsheet
Routine Name: cellsheet
Description: Copies prototype cells into a 3-D sheet specified by
coordinates in a file.
Usage: cellsheet prototype dest filename [-orient][-curve]
[-randomise x y z] [-twirl theta]
prototype existing cell to copy to create cells in the
sheet (prototype is not changed by the
routine; all operations are done on the
copies)
destination element to become parent of all cells in sheet
filename file defining position and orientation of
cells (ascii file with 3 numbers for each
coordinate (cartesian only), followed by 3
coordinates for the normal vector to the
surface of the sheet at that point; this
vector does not have to be normalised; each
set of 6 numbers should be on different lines)
-orient reorients the cell to be normal to the local
region of the sheet
-curve distorts copies of prototype cell to follow
curvature of sheet of cells; the lengths (and
electrical properties) of the cell are not
changed (this option assumes that length of
each compartment is less than the radius of
curvature of the surface; also, the sampling
density over the cell sheet should be high
enough that the spacing between the points is
smaller than the length of each compartment;
does not attempt to curve compartments where
the angle of rotation would be less than 10
degrees, or more than 60)
-randomise x y z
randomises the coordinates of copied cells by
the specified factors in x, y and z before the
orienting/positioning/curving steps
(randomisation involves finding length of each
compartment in each direction, scaling it by a
random number within the range of the
specified factor, and adding it to the
original; e.g., a factor of 1 would permit a
change of up to the original length of the
compartment; the electrical properties and
channel conductances in each compartment are
scaled according to the total length change)
-twirl theta rotates the finally positioned cell about its
normal by a random angle from 0 to theta
degrees
Example:
include protodefs.g // copied from Scripts/tutorials
readcell cell.p /library/cell // use cell.p from Scripts/tutorials
plane planepoints 400e-6 400e-6 100e-6 100e-6 -normal
egg eggpoints 400e-6 400e-6 400e-6 100e-6 -normal
create neutral /planenet
create neutral /eggnet
rotcoord /library/cell {-3.1415927/2} -y // point dendrite up along z-axis
cellsheet /library/cell /planenet planepoints -orient
cellsheet /library/cell /eggnet eggpoints -orient
showfield /planenet/cell[]/dend x y z
Notes: Creates a sheet of cells by copying from a prototype, and
placing them at 3-D positions specified by an ascii file. A
number of options permit the cells to be oriented, conformed
to the curvature of the surface, randomised, and rotated, in
order to make the geometry more natural.
In the example above, the prototype cell had the apical
dendrite pointing along the x-axis, so rotcoord was used to
rotate it 90 degrees about the y-axis to point outward along
the z-axis. Then, cellsheet was used, first on a file
containing points in a plane, and then on a file containing
points distributed over the surface of an ovoid. In both
cases, the orient option was used to point the dendrite along
the outward normal to the surface.
25.26 check
Routine Name: check
Description: Checks various aspects of simulation to catch specification
errors.
Usage: check
Example: check
genesis > setfield /soma Rm -5000 Cm 0
genesis > check
** Error - Compartment : Invalid Rm. '/soma'
** Error - Compartment : Invalid Cm. '/soma'
Notes: The check routine sends the CHECK action to the handlers for
all enabled elements. The CHECK action should verify the
consistency and well being of the element and report any
problems with it to the user. (Each element which supports
self-checking will be invoked with the CHECK action and report
any problems.)
In the example above, the CHECK action of the compartment
checks to be sure that the Rm and Cm fields are set to
positive values, and running a check prints an error message.
See also:
addtask ,
setclock ,
enable ,
reset
25.27 chr
Routine Name: chr
Description: Returns ASCII character specified by number code.
Usage: character = {chr ASCII-number}
Example: genesis > echo { chr 64 }
@
genesis > echo {chr 65}
A
genesis > echo {chr 97}
a
Notes:
25.28 clearerrors
Routine Name: clearerrors
Description: Resets error count to 0.
Usage: clearerrors
Example: clearerrors
Notes: When the number of errors reaches its maximum value (default:
10 syntax errors or 20 warnings) the current action is
interrupted, the simulator goes back to the command line, and
the errors are reset. The clearerrors routine can be used to
reset the error count before this occurs, allowing a
simulation to continue running despite errors.
See also:
maxerrors ,
maxwarnings
25.29 closefile
Routine Name: closefile
Description: Closes an ASCII file opened with the openfile routine.
Usage: closefile filename
Example: openfile myfile w
writefile myfile 10 20 30
closefile myfile
Notes: When you open a file using openfile, you work on a copy of
the file. The closefile routine writes your changes back
into the actual file and eliminates it from the list of open
files. (Closefile is automatically called for all opened
files when you exit from GENESIS).
See also:
openfile ,
listfiles ,
writefile
25.30 convert
Converting GENESIS 1.4 Scripts to GENESIS 2.0
What Does Convert Do?
GENESIS 2.0 includes a major revision of command format and command
option naming, script language syntax changes and changes in various
GENESIS features. The convert program converts GENESIS 1.4 compatible
scripts to use GENESIS 2.0 syntax, commands and features. Some
features have changed dramatically enough that an automatic conversion
to the new features is not feasible. In these cases, convert generates
script code for compatibility libraries which support the GENESIS 1.4
features.
Some scripts can be converted and run successfully without any manual
changes to the converted scripts. In most cases, however, some changes
to the converted scripts will be necessary.
The Conversion Process
Below is the process through which a GENESIS 1.4 script is converted
to run under GENESIS 2.0.
1 - Use the convert program to convert scripts from 1.4 to
2.0 syntax.
2 - Fix any known problem areas (See, Convert Problem Areas).
3 - Try the script out and fix any remaining problems.
Using the Convert Program
The easiest way to use convert is to create a new directory for the new
scripts, cd to the new directory and convert the files from the old
directory. A simple shell procedure may be used to convert an entire
directory. For example, if your 1.4 script files are in the directory
../oldscript, then the following shell commands will convert the entire
directory placing the converted scripts in the current working
directory:
csh:
foreach script (../oldscript/*.g)
convert $script
end
sh:
for script in (../oldscript/*.g)
convert $script
end
Global Script Variables
In order for convert to handle certain script expressions involving
global script variables, it must know what globals exist for a given
set of scripts. (This is not a problem for a self contained script
where global variables are defined and used within the script.)
Often a single script file is devoted to defining and initializing
global variables and constants for a given set of scripts.
The -constants option of the convert program gives a list of script
files which define the global variables for the script set. For
example, if the file constants.g contains global variable definitions
which are used througout a set of scripts in the ../oldscripts
directory then the following csh code would convert the scripts:
foreach script (../oldscripts/*.g)
convert $script -constants ../oldscripts/constants,g
end
The -constants option will allow one or more scripts to be given.
Compatibility Libraries
Two areas of major change in GENESIS 2.0 are the Xodus GUI and support
for network modeling (e.g. GENESIS 1.4 connections). Support for use
of these facilities in GENESIS 2.0 is provided by compatibility
libraries.
While the compatibility libraries allow faster conversion of GENESIS
1.4 scripts for use under GENESIS 2.0, these libraries will not be
aggresively supported and should be viewed as a transitional step in
converting scripts to GENESIS 2.0 facilities. Those areas of your
scripts which use these libraries should eventually be recoded to use
the new GENESIS 2.0 features. Assistance for recoding of these
features may be found in the new GENESIS 2.0 Reference Manual (not
available at this time).
The X1compat Library
Compatibility for GENESIS 1.4 features of Xodus is provided as a set of
scripts using GENESIS 2.0 extended objects to implement the old Xodus
objects and script functions to implement old Xodus commands. To load
the X1compat library, include Scripts/X1compat in your SIMPATH and
include X1compat from your .simrc or your main simulation script.
Convert will not add an include statement for X1compat to your
scripts.
X1compat defines a set of old Xodus compatible objects which are named
using the prefix "x1" in place of the normal "x" prefix for Xodus
objects (e.g. xform becomes x1form, etc). Convert will automatically
transform create statements from Xodus objects in 1.4 scripts to use
the X1compat objects. Some support for field naming of old Xodus
objects is included in the new Xodus objects, which may allow direct
use of the new Xodus objects. The -noX1compat convert option causes
convert not to perform the translation to X1compat objects. This is
likely to be useful for only those scripts which use the basic Xodus
widgets (i.e. xform, xlabel, xbutton, xtoggle and xdialog). Uses of
xdraw or xgraph are likely to require use of X1compat.
Convert and the X1compat library cannot address various issues of
layout of widgets on a form. See, Convert Problem Areas, for more
information.
The Connection Compatibility Library
While GENESIS 1.4 connections are not a standard part of GENESIS 2.0, a
compatibility library may be compiled into GENESIS 2.0 which supports
the old connection feature. (See, src/Makefile or Usermake for
instructions on including the library.) The library defines the
connection related objects (e.g. axon, synapses, etc) and the
connection related commands (e.g. region_connect, expweight,
radialdelay, etc) as well as connection specific commands which support
set/get/show of connections (e.g. setconn, getconn and showconn).
Access to connection fields is not supported by the GENESIS 2.0
setfield, getfield and showfield commands.
Convert will change connection related script statements as needed to
use the Connection Compatibility Library. In particular, it will
convert uses of set, get and show on connections to use setconn, et
al. In some cases, convert will be unable to convert these statements
(See, Convert Problem Areas).
Converting User Libraries
Objects and commands defined in user libraries (for the most part) will
not need to change to run under GENESIS 2.0. To compile your libraries
and create a new GENESIS you will need to replace and update your
Usermake, Libmake(s), liblist and perhaps the library startup script.
Copy the Usermake and liblist files from the GENESIS 2.0 installation
directory to your local GENESIS directory renaming Usermake to
Makefile. Add your user libraries to the Makefile and liblist files.
In each user library you must copy the Libmake from the GENESIS 2.0
installation directory into the library directory renaming it
Makefile. Add your library specific information and files to the
Makefile.
The convert program cannot be used to convert startup scripts. The
only changes you should need to make are to modify any GENESIS 1.4
script language features which change in 2.0 and to remove any
non-startup commands from the script. (Startup commands are object,
addfunc, hashfunc, newclass and addaction.) Since a startup script is
usually straight line code and the typical commands in a 1.4 startup
script are the above named commands, there are normally no changes
required. There are, however, some GENESIS 2.0 features you may want
to take advantage of in your startup scripts. See the new GENESIS
Reference Manual section on library startup scripts for details.
Convert Problem Areas
There are a number of areas in which convert will be unable to
transform script statements or where the converted code will perform in
a less than optimal manner. Each problem area described below must be
found and fixed manually.
Script Callbacks
Commands used as callbacks to script commands or functions are not
translated by convert. As such, script callbacks like the following
would fail:
create xbutton echoButton -script "echo -n this is a test"
create xdialog vmDialog -script "set /mycompt Vm <v>"
The echoButton will result in a usage error when pressed and the
vmDialog will fail because the set command no longer exists.
Command Options in Script Variables
A command option which is p