Neosim interfaces
-
The runnable cells of a model must implement the Neosim Runnable
interface in order to be run under Neosim.
New : Neosim is now able to cope with modules using the NeuroML interface. A new chapter is to be develloped about the NeuroM interfaces.
/** Handle icoming list of spike events. Notify the cell synapses
* of the incoming spikes.
*/
public void handleSpikeEvent( EntityID localeid, int input, double t );
/** Advance allows to update cell intern calculation, even when there is
* no incoming spikes.
*/
public void advance( EntityID localeid, double t );
/** This function allows to synapses to the cell according to the
* connections creation, linking the synapses to their
* correspondent source cell through the Neosim connection ID.
*/
public void setSynapseParams( EntityID localeid, int input, String params);
/** The query method is called when a Control Module sends a query
* concerning this cell. The cell behaviour rely then on the
* query parameters.
*/
public void query( EntityID eid, String qname, DataObject d );
}
New classes implementing this Runnable interface should be written on
top of each model's entity class.Another new class is required which will act as the runnable entity factory, implementig the Neosim EntityClass interface.
/** Provides a method to
* create an instance of the entity
*/
public Entity makeEntity(Population p, int index);
/** Initialise from a module with its parameters
*/
public void init( String name, Hashtable args );
/** If this entity requires extra
* global initialisation
* this method can be used to initialise the module.
*/
void initModule( ScriptReader sr );
}
The Control Module just uses the sendQuery( ) function, which parameters
are the name of the native query and the name of the targeted
population or entity.
The queries can be used for requesting values. The sendQuery( ) function returns a vector of DataObject objects, which fields are the data required :
New spike processing
In a Neosim driven simulation, the spikes are events the Neosim kernel
dispatches through all the source entity connections.
In this fashion, the destination cell will only receive spikes
travelling on her incoming connections and then, in this
model, update the status of the synapses corresponding to
these connections.
Simulation specification
The specification of the simulation is parlty made by Neosim so the
model's program doesn't have to code for everything.
In more details :
See the Population definition
See the Projection definition
See the Control definition.
The Population definition
The structure of the population can be defined through standard internal
definition or through external module code implementing the
Neosim Population Interface.
The structure used can for example be a three dimension array, which is
part of the standard definition. It's specification will then
be only present in the parametrisation file (see the parametrisation chapter for more details.
The Projection definition
The projection can also be defined as a standard one or a more complex
one in a Projection Module implementing the Neosim Projection
Interface.
The standard projectin is actually a bunch of connections explicitely specified
one by one. It is also possible to use already written modules
for the most common projection like "one-to-all".
The Projection Modules implements all the two following interfaces :
/** Connect from a specified output port to (potentially) all
* entities in destination population.
*
* This is the superclass for user source methods.
*/
public class SourceMethodImpl implements SourceMethod {
// send a request to specified members of the destination population
public void sendRequests( Entity srce, Population destPop, DestMethod dm ) {
}
}
/** The part of a general projection which runs on
* a destination entity and decides to fulfil/deny
* connection requests.
*/
public class DestMethodImpl implements DestMethod {
/** The considerRequest method checks the source entity's details
* against the dest entity's details, and returns True or False
* depending on whether or not the connection will be made.
* param deste : the destination entity
* param cr : the connection request from the source entity
* return : connection if a connection made, null otherwise.
*/
public Connection considerRequest( Entity deste, ConnectionRequest cr ) {
}
}
For more details about implemented modules see examples of modules
The Control definition
The control of the simulation is given to the Control Module.
The Control Module implements the following interface :
/**
* Superclass for plug-in control modules
* called by a script reader.
*/
public class ControlModuleImpl implements ControlModule {
/** Initialise given the parameters
* param : params the hashtable of parameters (strings)
*/
public void init(Hashtable params) {
}
/** Perform simulation tasks
* param : sr the script reader
*/
public void run( ScriptReader sr ) {
}
}
For more details about implemented modules see examples of modules
Queries
The control of the simulation is done through Neosim queries, so the
actual location of an entity (processor,...) is totally
invisible.
The queries are sent by the Control Module and caught by the
query( ) method of the Runnable Interface, implemented in the
Neosim entities classes.
public class DataObject {
public int intData;
public String[] stringData;
public double[] doubleData;
}
These entities deals internaly with the query : the neosim interface
brings the query to the entity who then calls its own
coresponding function.
Parametrisation using NeuroML
The parametrisation of the simulation is now made using NeuroML.
The NeuroML file describes the whole model with its structure and
environment parameters. It lists the Neosim Modules required
and their actual parameters for this simulation.
A parametrisation file for this model is shown in this linked Example.
The "How to use NeuroML" chapter explains how to use NeuroML to parametrize the
converted model.
Next Page