Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'origin' parameter in multimeter has no effect #670

zbarni opened this issue Mar 3, 2017 · 4 comments

'origin' parameter in multimeter has no effect #670

zbarni opened this issue Mar 3, 2017 · 4 comments


Copy link

@zbarni zbarni commented Mar 3, 2017

nest.SetStatus(voltmeter, {"withtime": True, "record_from": ['V_m'], "interval": 202., "origin":3.})

should sample at 205., 407., 609., etc. Instead, the current version disregards the origin parameter and sample at 202., 404., 606., etc.

Bugfix: modified multimeter to actually consider the origin variable when sampling. Modification of the DataLoggingRequest class was also required to keep track of the origin. Main issue was that the initial sampling timepoint (relative to which the next intervals are calculated) was computed without regard to the origin.

Copy link

@heplesser heplesser commented Mar 6, 2017

@zbarni It is a feature, not a bug, although the documentation is partially incorrect. The correct documentation is in the SLI-style documentation for RecordingDevice in recording_device.h, l 66ff:

Start and stop have the following meaning for stimulating devices
  (origin is just a global offset):
  - Sampling devices sample at times t = nh with start < t <= stop
     (t-start) mod interval == 0

The corresponding Doxygen-documentation for class Multimeter (multimeter.h, l 140ff) is unfortunately incorrect.

The logic behind start, stop, and origin is that they just form a window masking the underlying process and that origin provides a simple way to move this window along the time axis if one wants to stimulate or record at different times during a simulation. For consistency, I would strongly prefer to keep it in this way. There are also technical problems that I will discuss in #669.

If you have an important use case that requires multimeter to sample at other times than multiples of the resolution, please explain it here. Otherwise, I would like to ask you to close the issue.

Copy link

@rcfduarte rcfduarte commented Mar 6, 2017

In our current implementation (with @zbarni ), we're running very long simulations where we need to sample the values of population state variables at regular intervals. For example, we would like to sample the population activity at 100.1, 200.1, 300.1, etc (where the extra 0.1 ms is added to account for a delay of 0.1 ms from an input generator to the network). As @zbarni mentioned, as it is currently implemented, the multimeter doesn't allow this (unless we set interval=0.1, which is not a very efficient solution for long simulations). If we set interval = 100., origin = 0.1, the recorded times will be [100., 200., 300., etc], since these are not set relative to the origin (as suggested in the documentation). The solution for this would be to make sure the sampling interval is initially set relative to the origin, which is achieved in #669 . As @heplesser refers, the documentation is misleading in this respect. I do not know how this fix would affect other devices, particularly the stimulating devices, but it would be helpful to have for recording devices.

Copy link

@zbarni zbarni commented Mar 6, 2017

For multimeter, at least, the part with (t - start) mod interval == 0 is not entirely true. Rather, start seems to be just a cutoff timepoint and doesn't shift the sampling window in any way.

If you run the following code

neuron = nest.Create("iaf_psc_exp")
nest.SetStatus(neuron, {"C_m":   250.0, "tau_m": 10.0, "V_th":  -55.0, "I_e":   375.0001})

mm = nest.Create("multimeter", 1, {"interval": 202., 'start': 0.,
                 "withtime": True, "record_from": ['V_m'], })

#nest.SetStatus(mm, {'origin': 3.})
nest.Connect(mm, neuron)
dVm_s = nest.GetStatus(mm)[0]
Vms_s = dVm_s['events']['V_m']
ts_s  = dVm_s['events']['times']
print ts_s

you will get [ 202. 404. 606. 808.], as expected. Now, you could change start to any value < 201, say "start": 100., and you would get the same output with the first sampled timepoint being 202.0 and not 302 (as (t - 100) mod 202 == 0 suggests) ... If we change "start" = 300., then we get [404, 606, 808]. Setting the origin to 3. would yield [205, 407, ..] with the fix.

So, the documentation is most likely incorrect both regarding to the use of origin (at least as it's currently implemented in multimeter) and the part in recording device with (t - start) mod interval == 0, no?

Maybe my solution is not the best and I have not thought of all the possible implications this modification might have, but this would only be an enhancement and it would be possible to use the multimeter exactly as until now, if origin is not set.

Regarding your note:

The main problem with your proposal here is that the purpose of origin is to allow the user to move the start-stop window along the time axis by changing origin during stimulation breaks. Your intended use of origin would conflict with this.

I don't exactly see how using the origin variable in such a way affects the original purpose of shifting the start-stop window. In fact, there would be no point in "shifting the start-stop window", because it's just possible to change the value of these. Maybe you can give an example on how the start, stop and origin parameters (should) work together in the case of multimeter? I think you referred to shifting the sampling interval (although not sure), which is what we also want, and the start and stop values just constrain (bound) the interval where the samplings are taken.

Again, I'm only referring to the multimeter behaviour, not sure about other devices. Also, any alternatives to the implementation in this commit are welcome as I didn't have other ideas.

Copy link

@heplesser heplesser commented Mar 7, 2017

@zbarni You are right, the documentation is inconsistent in itself. It is the "at times t = nh" that describes what is happening.

I belated realized that I created #505 a while ago to propose a general, modernized solution to windowing stimulation and recording devices. We should pursue that for NEST3; then, start, stop and origin will disappear as parameters.

Your issue here is actually not related to windowing, but to subsampling, and therefore not related to origin in the sense it is currently used in NEST (exclusively related to windowing). Thus, one needs a slightly different terminology and a few additional protections.

I will re-open #669 and make specific suggestions there. Sorry for the back-and-forth.

@zbarni zbarni closed this Mar 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants