Implement recording of signals provided by stimulating devices

[appukuttan-shailesh]

This query was originally intended towards the development of the PyNN-NEST interface, but has a more general application within NEST. The objective was to record the profile of injected current, but:

1. the 'multimeter' object in NEST does not appear to allow recording from stimulating devices, and seems to be restricted to neurons. It doesn't throw errors, but returns empty (similar to issue NEST allows multimeter connections to devices that do not support recording #578 )
2. the alternative approach was to attempt to record the currents from the neurons. But different cell types have different sets of 'recordables' and the injected current doesn't seem to be one of them.

@heplesser informed me that this would require small additions to the model, but could be achieved. I plan to look into this, and shall update here if I make any progress.

[appukuttan-shailesh]

I think I have managed to implement the record feature for the AC current source. The modified files are here (not yet ready for a pull):
ac_generator.h
ac_generator.cpp

A sample output for the code here:

@heplesser : It would be great if you could take a look before I move on to the other models.
The lines/blocks that have been added have been tagged issue #658 for a quick look

Some of the queries I had were:

1. I found that I wasn't allowed to give any arbitrary name for the parameter being recorded:

insert_( Name( names::amplitude ), &ac_generator::get_inj_ );

and had to use one of the existing names in the context (e.g. amplitude, phase). I went ahead with 'amplitude' here, but a different name (such as i_inj) would be more appropriate.

2. As this code is based on that for sinusoidal_poisson_generator, do let me know if I have accidentally added bits which are not relevant to the recording feature and can thus be removed.

3. I see that for both the voltage and current traces (in the above figure), values are not obtained for t = t_stop. Is there some workaround for this, or do I simply make a corresponding increment to the simulation runtime?

This is the first time I have used the nest simulator in any capacity, and so apologies if I have made any noobie mistakes.

[appukuttan-shailesh]

I think I have solved my first query by adding:
extern const Name I_inj; //!< Current from StimulatingDevice
to nest_names.h, and adding
const Name I_inj( "I_inj" );
to nest_names.cpp

Changes would accordingly be made in ac_generator files, such as:

insert_( Name( names::amplitude ), &ac_generator::get_inj_ );

changed to:

insert_( Name( names::I_inj ), &ac_generator::get_I_inj_ );

and renaming the earlier variable inj_ with I_inj_ throughout (for better readability)

[heplesser]

@appukuttan-shailesh Your code looks quite fine, but it seems you are working on the basis of NEST 2.10. Please use the most recent code from Github as the basis of any development to minimize the risk of merge conflicts later. You don't seem to have added unnecessary code.

Names are a complex matter. One purpose of the names system is to keep some consistency in naming across models. Also, from the perspective of the current generator, the current is not an injected current---that is the perspective of the neuron. I think the best name to choose would simply be I, also avoiding inj in the code, i.e.,

insert_( names::I ), &ac_generator::get_I_ ):

The comment "specific to Mirollo-Strogatz" on I in nest_names.h should then be removed.

Data is first buffered in the UniversalDataLogger instance of the model and then collected from there by multimeter and written to file (or memory) during the next minimum-delay interval. Therefore, some data will be missing at then end.

[appukuttan-shailesh]

Thanks for pointing that out. I have now updated my repository to the latest version, and made the necessary changes. I have implemented the record feature for the following models:

1. ac_generator
2. dc_generator
3. step_generator
4. noise_generator

A sample output for the above (code):

I shall initiate a pull request so that you can review the changes.