Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
'origin' parameter in multimeter has no effect #670
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.
The corresponding Doxygen-documentation for
The logic behind
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.
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
For multimeter, at least, the part with
If you run the following code
you will get
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
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
Regarding your note:
I don't exactly see how using the
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.
@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,
Your issue here is actually not related to windowing, but to subsampling, and therefore not related to
I will re-open #669 and make specific suggestions there. Sorry for the back-and-forth.