The role of mozaik is to coordinate the workings of number of tools to provide a consistent workflow experience for the user. Consequently the root mozaik package is very light, and majority of functionality is in the number of subpackages each addressing different parts of the workflow. In future the number of subpackages is likely to grow, as the number of areas that the mozaik workflow covers increases. It is also likely that in future some of the subpackages will be removed (or replaced with dedicated packages) as the individual external tools overcome the ‘coordination’ issues that mozaik is currently trying to address.
This module exposes several parameters to the rest of mozaik:
- rng : nest.RandomState
- The global mozaik random number generator. It is crucially any mozaik code using it has to make sure that it will ensure that the random number generator will be in the same state on all processes after the codes execution.
- pynn_rng : pynn.random.NumpyRNG
- The random number generator that should be passed to all pynn objects requiring rng.
- mpi_comm : mpi4py.Comm
- The mpi communication object, None if MPI not available.
Tests the presence of MPI and sets up mozaik wide random number generator.
Notes
To obtain results repeatable over identical runs of mozaik one should use the mozaik.pynn_rng as the random noise generator passed to all pyNN functions that accept pynn_rng as one of their paramters
Any other code using random numbers should instead use the mozaik.rng that hold a numpy RandomState instance. It is important to make sure that any piece of code using this random generator draws from it exactly the same number of numbers in each process, so that once the code is executed, the rng is in exactly the same state in each mpi process!
This methods returns a set of inetegers that can be used as random seeds for RNGs. The main purpose is that these numbers are large and random, with extremely low probability that two of the same numbers are returned in a single simulation run.
Returns : | A set of long integer as a ndarray of shape size. If size==None returns single seed. The integers have 64bit size. : |
---|
Notes
We recommand users to use this method whenever seeding a new random generator. It is important that the same number of seeds are requested in each MPI process to ensure reproducability of simulations!
To maintain consistent logging settings around mozaik use this method to obtain the logger isntance.
This function loads a model component (represented by a class instance) located with the path varialble.
Parameters : | path : str
|
---|---|
Returns : | component : object
|
Definition of the component interfaces. These interfaces are not currently directly checked or enforced.
Bases: object
Base class for for all Mozaik objects using the dynamic parameterization framework. See `getting_started`_ for more details.
Parameters : | parameters : dict
|
---|
This is a function that checks whether all required (and no other) parameters have been specified and all their values have matching types. This function gets automatically executed during initialization of each :class:.ParametrizedObject object.
Parameters : | parameters : dict
|
---|
Bases: mozaik.core.ParametrizedObject
Base class for mozaik model components.
Parameters : | model : Model
|
---|
Bases: mozaik.core.BaseComponent
Abstract API of sensory input component. Each mozaik sensory input component should inherit from this class and implement its two abstrac methods.
See also
This method is responsible for presenting the content of input_space to the sensory input component, and all the mechanisms that are responsible to passing the output of the retina (in whatever form desired) to the Sheet objects that are connected to it and thus represent the interface between the input space component and the rest of the model.
The method should return the sensory input that has been effectivitly presented to the model, currently the format of it is not specified.
This method is responsible generating sensory input in the case of no stimulus. This method should correspond to the special case of process_input method where the input_space contains ‘zero’ input. This methods exists for optimization purposes as the ‘zero’ input is presented often due to it’s presentation between different sensory stimuli to allow for models to return to spontaneous activity state.
This modules implements the API for input space.
Bases: mozaik.core.ParametrizedObject
A class to structure and unify operations taking place in the respective sensory space, such as stimulus presentation.
The basic idea of the InputSpace API is following:
The InputSpace assumes there is a scene, and a set of stimuli in this scene (visual objects, sounds, smells etc.). These objects can be removed or added to the scene. After each interval lasting update_interval miliseconds all the stimuli in the scene are sequentially updated (following some rules of overlapping, this is left for the specific implementation of the input space). After that update the scene is ready to be pased to the associated input sheet of the given model, which will use it to generate the responses of neurons in the input sheet.
Other Parameters: | |
---|---|
update_interval : float (ms)
|
Add an inputObject to the input scene.
Reset each Object in the scene to its initial state.
Reset the input space and clear stimuli in it.
Tell each Object in the scene to update itself. Returns the current time within the scene.
The maximum duration of any of the stimuli in the inpust space.
Get the duration of the stimulation in the input space.
Set the duration of the stimulation in the input space.
Returns the time points of updates in the period 0,duration.
Bases: mozaik.space.InputSpace
A class to structure and simplify operations taking place in visual space, such as stimulus presentation.
In VisualSpace the stimuli are sequentially drawn into the scene in the order in which thay have been added to the scene (thus later stimuli will draw over earlier added ones). Stimuli can specify areas in which they are transparent by using the TRANSPARENT value.
The key operation of VisualSpace is the view() function that recieves a region and resolution and returns rendered scene as a 2D array, within that region and down-sampled to the specified resolution. This allows for implementation of a visual system that changes the viewed area of the scene. The view() function itself makes sequential calls to the mozaik.visual_stimulus.VisualStimulus.display() function passing the region and pixel size, which have to render themselves within the region and return 2D array of luminance values. view() then assambles the final scene rendering from this data.
Notes
For now, we deal only with two-dimensions, i.e. everything projected onto a plane. We ignore distortions in going from a flat plane to the curved retina. Could consider using matplotlib.transforms for some of this.
Show the scene within a specific region.
Parameters : | region : VisualRegion
pixel_size : float (degrees)
|
---|---|
Returns : | array : nd_array
|
Returns the maximum luminance in the scene.
Export a sequence of views of the visual space as image files. Return a list of file paths.
Bases: object
A rectangular region of visual space.
Parameters : | location_x : float (degrees)
location_y : float (degrees)
size_x : float (degrees)
size_y : float (degrees)
|
---|
Returns whether this region overlaps with the one in the another_region argument.
Returns VisualRegion corresponding to the intersection of this VisualRegion and the one in the another_region argument.
This is the nexus of workflow execution controll of mozaik.
global variable container currently only containing the root_directory variable that points to the root directory of the model specification
This functions sets up logging.
This is the main function that executes a workflow.
It expects it gets the simulation, class of the model, and a function that will create_experiments. The create experiments function get a instance of a model as the only parameter and it is expected to return a list of Experiment instances that should be executed over the model.
The run workflow will automatically parse the command line to determine the simulator to be used and the path to the root parameter file. It will also accept . (point) delimited path to parameteres in the configuration tree, and corresponding values. It will replace each such provided parameter’s value with the provided one on the command line.
Parameters : | simulation_name : str
model_class : class
create_experiments : func
|
---|
Examples
The intended syntax of the commandline is as follows (note that the simulation run name is the last argument):
>>> python userscript simulator_name num_threads parameter_file_path modified_parameter_path_1 modified_parameter_value_1 ... modified_parameter_path_n modified_parameter_value_n simulation_run_name
This is function called by :func:.run_workflow that executes the experiments in the experiment_list over the model. Alternatively, if load_from is specified it will load an existing simulation from the path specified in load_from.
Parameters : | model : Model
experiment_list : list
load_from : str
|
---|---|
Returns : | data_store : DataStore
|