Installation

Download

We currently don’t provide the code as a standard library that can be easily installed. In future versions, we will try to work on this and improve usability. For the moment, to use the code there is no explicit installation involved. Just fork and clone the Github repository from here.

Dependencies

  • Python 2.7
  • NEST version 2.8.0 or higher
  • numpy version 1.7.0 or higher
  • scipy version 0.12.0 or higher
  • scikit-learn version 0.18.0 or higher
  • matplotlib version 1.2.0 or higher

Optional (for additional functionality):

  • PySpike version 0.5.1
  • h5py version 2.2.1 or higher
  • mayavi version 4.0 or higher
  • networkx version 1.1

Getting Started

After downloading the repository, the framework's configure file, which sets the correct paths, needs to be sourced:

source /{path}/nmsat/configure.sh

where {path} refers to the full path to the main NMSAT directory in your system. This last step requires the user to manually specify all the paths for his system, by editing the paths dictionary in /defaults/paths.py, as:

paths = {
    'system_label': {
        'data_path':            NMSAT_HOME + '/data/',
        'jdf_template':         NMSAT_HOME + '/defaults/cluster_templates/Cluster_jdf.sh',
        'matplotlib_rc':        NMSAT_HOME + '/defaults/matplotlib_rc',
        'remote_directory':     NMSAT_HOME + '/export/',
        'queueing_system':      'slurm'}
        }

The system_label specifies the name of the system. If running simulations on a local machine, the name must be set as 'local' (which is the default), otherwise, it can be any arbitrary name, as long as it is used consistently throughout (see examples). The remaining entries in this dictionary refer to:

  • data_path - specify where to store the output data generated by an experiment
  • jdf_template - path to a system-specific job description file (see example in /defaults/cluster_templates); if running locally set to None
  • matplotlibrc - in case the user wants to customize matplotlib
  • remote_directory - folder where the job submission files will be written (only applicable if not running locally, but must be specified anyway)
  • queueing_system - type of job schedulling system used (current options include only 'slurm' and 'sge').

And that should be it. After specifying all these for the systems where the code is intended to be executed, it should be possible to run the framework (see standard use case).