Auryn simulator

Per default Auryn does not record any information. To see what is happening in your network, you will have to define Monitor objects. Each Monitor specializes on reading out one specific quantity from a network simulation. For instance, a SpikeMonitor records the spikes generated from one specific SpikingGroup or NeuronGroup. Typically you will at least use one of those. If you would like to know about the membrane voltage of one specific neuron in a NeuronGroup you can use an instance of VoltageMonitor. If you are interested in other internal states of a Neuron (e.g. conductances, etc…), have a look at StateMonitor. Think carefully which information you actually need from your simulation, because recording values slows your simulation down and quickly produces enormous amounts of data.

Auryn was specifically designed to study synaptic plasticity. To see plasticity in action you can monitor single synaptic weights or groups of them using a WeightMonitor object. If you are only interested in let's say the mean weight change in one of the plastic Connection objects your defined (i.e. the mean weight between two neuronal populations in your simulation), you can use WeightStatsMonitor. You will find other Monitor classes in the Auryn src directory (see also the Class index; Monitor classes should be suffixes with Monitor) or you can write your own for your specific needs.

In most cases Auryn Monitor instances will individually record data to separate files on disk and perform a minimum of on-line analysis (here are some default extensions I am using for these output files). This can be cumbersome if you would for instance like to monitor the activity in your network and stop a simulation if the activity explodes or the network falls quiescent. To tackle this problem, Auryn has a specific class which allows minimalistic online monitoring. They are called Checkers.

Suppose you are running a simulation of a plastic network, but every now and then the activity in your simulations explodes, because something is wrong with your plasticity parameters. Instead of storing hours and gigabytes of synchronous high frequency spiking from this run you can define a RateChecker with specific firing rate limits of one specific target population in your simulation. If the firing rate goes out of your predefined bounds the Checker will terminate the run. You can define multiple Checkers for different populations and you can write your own Checker with the functionality you need.