								4/20/89  (MW)
1.4.1 What are clocks.

Each element in a simulation has an interval timer or 'clock' associated
with it. This clock is used to determine how frequently it will be
executed during the simulation process. 
This is particularly useful when components of a simulation run at
significantly different time scale. 
The simulator contains a array of 100 independent clocks.
Each clock is identified by a number from 1 to 100 corresponding to its
position in the clock array. By convention clock number 0 is the global
simulation clock or the basic simulation time step. All other clocks values must
be larger than clock 0, and should be integer multiples as well for
maxmimal timing precision.
By default all elements use clock 0, the basic simulation time step.

For example:
    we assign clock 0 the value 1.0 
    and clock 1 the value 5

    using clock 1 for a graph would cause it to plot every 5 simulation
    steps.

1.8 Schedules

When a request is made to execute a simulation (see the step command),
the simulator refers to a list (schedule) of operations (tasks) which are to
be performed in the specified order for each simulation step. 
A task is simply a compiled function with optional arguments.
The 'Simulate' task is the most basic and handles the simulation of
the model elements (see 'Simulate').
The 'check' function will analyze the simulation schedule to check for
conflicts or inconsistencies and should always be performed after
changing the schedule or adding or removing simulation elements. 


1.8.3 Simulate

This task function invokes a list of elements with the specified action.
The element list is typically specified using the wildcard path notation.
A default simulation schedule is provided which handles most simulation
configurations.
The basic syntax to add a list of element for simulation is:

addschedule Simulate  [elements]  -action [actionname]

where elements would be a path specification of the form

/test/element
/##
/neuron[]
etc.

and actioname would be selected from the list of available actions
(see listactions). For example:

INIT
PROCESS

Care must be taken to avoid multiple references to elements with the
same action. This will be detected during checking.
For instance given a model containing six element /test[1-6], the schedule

addschedule Simulate  /test[1]  -action PROCESS
addschedule Simulate  /test[1-6]  -action PROCESS

would be an invalid specification since this would cause test[1] to be invoked
twice on each simulation step. Running the 'check' function following this
specification would generate the following message

** Error - '/test[1]' multiply invoked with action 'PROCESS'. Check task [2]

Task [2] refers to the second addschedule 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' function.
For instance, given the model of six elements used above, the following
schedule

addschedule Simulate  /test[1-5]  -action PROCESS

would produce this error message upon checking

* Warning - '/test[6]' is not scheduled for simulation.

A valid schedule for this set of elements would be 

addschedule Simulate  /test[1]  -action PROCESS
addschedule Simulate  /test[2-6]  -action PROCESS

or

addschedule Simulate  /test[1-6]  -action PROCESS

1.9 Actions

Each object in the 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. A list of actions which an object can
perform and the function(s) which perform them can be displayed using the
'showobject' function.
As an example the object 'compartment' can perform the actions
CHECK
RESET
PROCESS  and
INIT

Each of these possible actions is performed by the function
called 'Compartment'
(see also section 1.8 Scheduling, section 1.12 Objects, and command 'call')

1.12 Objects
An object contains specification information needed to construct a 
particular type of element.
Examples of different types of objects would be 'compartments', 'axons', 
and 'channels'.
The information contained in a object are the functions needed to
create and simulate this type of element, and its data structure, as well as
the messages that are needed, and the actions that can be performed.
Objects can also contain additional information such as a description of
the object and its data fields, and the author of the object.
(see also the 'create' command).

information contained in an object:
    name
    data structure
    function
    environment variables local to the object
    list of classes to which it belongs
    list of actions which it can perform
    list of messages which it can handle
    list of data fields which the user has access to
    description of the object
    author of the object

1.12.1 newclass
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.
The 'newclass' command is used to add a new named class to the available
list of classes (see 'listclasses').
This class name can be used in subsequent specification of new 
objects using the object command or in the modification of object classes 
using the 'objectclass'

1.12.2 object

Example:

object	nernst		nernst_type Nernst  segment channel \
	-author 	"M.Wilson Caltech 3/89" \
	-actions 	PROCESS RESET CHECK \
	-messages	CIN 0		1 Cin \
			COUT 1		1 Cout \
			TEMP 2		1 T \
	-fields		"E = equilibrium potential" \
			"T = temperature in degrees celsius"  \
			"valency = ionic valency z"  \
			"scale = voltage scale factor"  \
	-description	"Calculates the Nernst potential for the given" \
			"ionic concentrations and temperature." \
			"E = scale*(RT/zF)*ln(Cout/Cin)" \
			"A scale factor of 1 gives E in volts." \
			"A scale factor of 1e3 gives E in millivolts."

