More than one integrating SOLVE statement in an BREAKPOINT

NMODL and the Channel Builder.
Post Reply
Malbolge

More than one integrating SOLVE statement in an BREAKPOINT

Post by Malbolge »

Hello,

I'm trying to get some advice or information about a warning I receive when trying to compile a NMODL point process for my simulations. The message I receive is...

Code: Select all

Warning:  More than one integrating SOLVE statement in an BREAKPOINT block.
The simulation will be incorrect if more than one is used at a time.
This is the code for my .mod. It (hopefully) produces a sine wave of given frequency and amplitude, works out a random noise component every 2ms, and sums them together.

Code: Select all

INDEPENDENT {t FROM 0 TO 1 WITH 1 (ms)}

NEURON {
	POINT_PROCESS model1_PP
	RANGE del, dur, amp, frequ, i, randNoise, randVar, randMean, oscInput, x, oldT, nCon
	NONSPECIFIC_CURRENT i
}

UNITS {
	(nA) = (nanoamp)
	PI = (pi) (1)
}

PARAMETER {
	del (ms)
	dur (ms)
	oldT (ms)
	nCon (ms)
	amp (nA)
	frequ (/sec)
	dt  (ms)
	randVar (/ms)
	randSeed (/ms)
	randMean (/ms)
	x (/ms)
}

ASSIGNED { 	i (nA)
		randNoise (nA)
    oscInput (nA)	
	 }
	 
INITIAL {
    seed(x)
    oldT = del - nCon
}	 

BREAKPOINT {
	if (t < del + dur && t > del) {		
		SOLVE foo
		SOLVE bar
		i = randNoise + oscInput 
	}else{
		i = 0
	}
}

PROCEDURE seed(x) {
        set_seed(x)
}

PROCEDURE foo() {
	oscInput = (-amp*sin(2*PI*(t-del)*frequ/1000))
}

PROCEDURE bar() {
  if (t == oldT + nCon){
  oldT = t
	randNoise = normrand(randMean, randVar)
	}else{
  randNoise = randNoise
  }
} 
I'm figuring the warning comes from having SOLVE foo and SOLVE bar... more than one SOLVE statement, in the BREAKPOINT. But, I'm a little stumped as to the implications. Does it mean that if I require BOTH foo and bar solved at each time step (which I do) there will be problems? Or does it mean I'll have problems if I use more than of these mechanisms in my simulations (which I don't)? Would I be better splitting the Noise and Sine Wave components into separate mechanisms, and treating them independently? Or, could I change it so I only have SOLVE foobar, which works out the Sine Wave component, then the Random Noise component, and then sums them together? So, I'm only calling 1 SOLVE statement?

Other details for the compilation... Its on Unix, on a parallel build. Neuron 6.1 (I think, certainly 6.x).
Malbolge

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by Malbolge »

I think I found the answer to this... Only one SOLVE statement per BREAKPOINT, and only one BREAKPOINT per .mod. I re-jigged the code so there is only one SOLVE statement called, which works out the Sine component, and the Noise component, and sums them together. I did some testing (single serial runs, low dt, low duration, rigged values) and it appears to be working as intended. For those that are interested, here is the finished code I'm going to run with...

Code: Select all

INDEPENDENT {t FROM 0 TO 1 WITH 1 (ms)}

NEURON {
	POINT_PROCESS model1_PP
	RANGE del, dur, amp, frequ, i, randNoise, randVar, randMean, oscInput, x, oldT, nCon, sumInp
	NONSPECIFIC_CURRENT i
}

UNITS {
	(nA) = (nanoamp)
	PI = (pi) (1)
}

PARAMETER {
	del (ms)
	dur (ms)
	oldT (ms)
	nCon (ms)
	amp (nA)
	frequ (/sec)
	dt  (ms)
	randVar (/ms)
	randSeed (/ms)
	randMean (/ms)
	x (/ms)
}

ASSIGNED { 	i (nA)
		randNoise (nA)
    oscInput (nA)
    sumInp (nA)	
	 }
	 
INITIAL {
    seed(x)
    oldT = del - nCon
    randNoise = amp
}	 

BREAKPOINT {
	if (t < del + dur && t > del) {		
		SOLVE foo
		i = sumInp 
	}else{
		i = 0
	}
}

PROCEDURE seed(x) {
        set_seed(x)
}

PROCEDURE foo() {
	
	if (t == oldT + nCon){
	oscInput = (-amp*sin(2*PI*(t-del)*frequ/1000))
  oldT = t
	randNoise = normrand(randMean, randVar)
	sumInp = randNoise + oscInput
	}else{
	oscInput = (-amp*sin(2*PI*(t-del)*frequ/1000))
  randNoise = randNoise
  sumInp = randNoise + oscInput
  }
}
No problems/warnings with compilation etc. Seems to be running fine.
ted
Site Admin
Posts: 6299
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by ted »

it appears to be working as intended
Generates a noisy sinusoidal current?
Malbolge

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by Malbolge »

The following is working, for producing the noisy sine current. I noticed my first batch didn't give me the results I was expecting, so I investigated and found I was only getting 1 value of noise constant throughout the simulation. So I reworked the conditional, and some of the initial values, and it's working now, as follows.

Code: Select all

INDEPENDENT {t FROM 0 TO 1 WITH 1 (ms)}

NEURON {
	POINT_PROCESS model1_PP
	RANGE del, dur, amp, frequ, i, randNoise, randVar, randMean, oscInput, x, oldT, nCon, sumInp
	NONSPECIFIC_CURRENT i
}

UNITS {
	(nA) = (nanoamp)
	PI = (pi) (1)
}

PARAMETER {
	del (ms)
	dur (ms)
	oldT (ms)
	nCon (ms)
	amp (nA)
	frequ (/sec)
	dt  (ms)
	randVar (/ms)
	randSeed (/ms)
	randMean (/ms)
	x (/ms)
}

ASSIGNED { 	i (nA)
		randNoise (nA)
    oscInput (nA)
    sumInp (nA)	
	 }
	 
INITIAL {
    seed(x)
}	 

BREAKPOINT {
	if (t < del + dur && t > del) {		
		SOLVE foo
		i = sumInp 
	}else{
		i = 0
	}
}

PROCEDURE seed(x) {
        set_seed(x)
        randNoise = normrand(randMean, randVar)
        oldT = del - nCon
}

PROCEDURE foo() {
	
	if (t > oldT + nCon) {
  oldT = t
	randNoise = normrand(randMean, randVar)
	}else{
  randNoise = randNoise
  }
  oscInput = (-amp*sin(2*PI*(t-del)*frequ/1000))
  sumInp = randNoise + oscInput
}
ted
Site Admin
Posts: 6299
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by ted »

Depends on the definition of "it works." It generates a fluctuating current, but does the current fluctuate in the way you think it does?
Consider this set of parameters
del = 1 ms
dur = 1e9 ms
nCon = 0.5 ms
amp = 0 nA
frequ = 0 Hz
randVar = 0.01
randMean = 0.01
x = 0
(by the way, for this mechanism the units of randVar, randMean, and x should really be nA, nA2, and nA, respectively).*
With these parameters, at what times do you expect the current to jump to a new value? Test your prediction by running a simulation that lasts 5 ms. What are the actual times at which the current jumps to a new value?

*--Correction 6/12/2010
randVar units should be nA2
randMean and x should be nA
ted
Site Admin
Posts: 6299
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by ted »

One would expect the noise current jumps to start at intervals of 0.5 ms. Instead, with the above parameters, they
1
1.55
2.075
. . .
After changing del to 0, the jumps begin at
0.025
0.525
1.05
1.575
2.1
2.6
. . .
The intervals between jumps show jitter between 0.5 and 0.525 ms, so that jumps occur at progressively later times in the course of a simulation. This happens because comparisons between numbers with nonzero fractional parts are vulnerable to roundoff error.

Also, as written, this mechanism will not work with adaptive integration.

These problems can be overcome by revising the mechanism so that it uses self events to control jump times.
Malbolge

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by Malbolge »

Hi Ted,

Thanks for the advice... Been at a conference since Wednesday, so didn't have a chance to check back here until now. I'll have to check my mechanism and make sure it is exactly functioning as I'm expecting. I do have diagnostic statements in my serial code (I'm running the parallel context Bulletin/Black Board System for large batches), and I did run some, albeit brief, checks to see if I was getting what I was expecting, and from those cursory checks, it seemed to be doing what I wanted, for values around about what I'm using for the actual simulations.

Is Adaptive Integration the variable time step method? Because I'm running all my simulations with a Constant Time step... I seem to remember reading that normrand wouldn't work with Variable Time Step, so I've stuck with Constant. In the actual simulations it is dt = 0.01, or steps per ms = 1/0.01. For my brief checks, I think I ran with dt = 0.1 or 0.5. So, with these I shouldn't be getting any discontinuity between the values of t and the oldT + nCon values for the changes of the noise... unless there'll be round off for at 100th ms level? Also, delay is always 500ms, duration 3500ms, nCon = 2.0, freq 8, 12, 16, 20, amp between 0.05 and 0.2. Noise Mean and Var are 0 and 0.06 respectively, but I am thinking about looking at other values of this. I suppose the design, and my assumptions about how it should be functioning are based on this strict-ish range of parameters. But I'll check it more thoroughly and see how it goes.

I'll change the units for randMean/var/seed(x)... but can I ask what you mean by Mean should be nA2?

I'll also have a look tomorrow at the Self Events you mentioned, but I haven't had any experience with the Event delivery system.
ted
Site Admin
Posts: 6299
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by ted »

Roundoff errors can potentially affect all floating point calculations that involve a nonzero fractional part, especially when binary arithmetic is used with decimal numbers--because anything that isn't an integer power of 1/2 is represented in binary with a nonfinite string of 0s and 1s (financial calculations use "binary coded decimal" encodings that, at the cost of increased storage requirement, allow exact representation of decimal numbers). So unless your particular installation of NEURON used a BCD math library, you will definitely find similar slippage with dt = 0.01.

Adaptive integration is shorter (the main reason why I use the term), and more descriptive than "variable time step integration" when it comes to describing what NEURON's adaptive integrators can do (they change both dt and the order of integration as necessary to satisfy an error criterion).

normrand works with fixed or variable time step integration. The chief problem with using random sequences to emulate noise during adaptive integration is the fact that, if a new value is drawn at every time step, the power spectrum of the noise will vary (more power at higher frequency when dt short, and more power at lower frequency when dt is long). That would be just silly, because the statistical properties of the noise signal would not be under the explicit control of the modeler, but instead would be an accident of the stability and accuracy of the set of equations that is being solved.

A possible workaround is to implement a noise mechanism that picks a new number at a predetermined, fixed interval. It is possible to implement such a mechanism, but the integrator will be re-initialized every time a new sample is drawn. This imposes a computational cost, so if the noise bandwidth must be high (the samples must be drawn frequently), you're better off just using fixed time step integration because the adaptive integrator will never be able to increase dt to the point where it can save run time. However, your code suggested that you were OK with new random samples at 0.1 ms intervals, which is 10 x your fixed dt, so maybe you could get a small speedup (maybe twice as fast).

But the ability to use adaptive integration isn't reason to revise the mechanism. The reason is to eliminate the roundoff error problem, and you can get that benefit merely by using self-events to control the sampling times.
can I ask what you mean by Mean should be nA2?
That's my mistake--a mismatch between what was in my head and what I typed. Mean of course should be in nA. Variance should be in nA2. (now you see one of the reasons why I check my code for units inconsistencies)
Malbolge

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by Malbolge »

Hi Ted,

Again, thanks very much for the advice. As well as helping to improve my models and simulations, this has given me a good insight into some of the issues and intricacies with modelling, and given me plenty to think about and talk about, which I appreciate.

I think I understand the problem I'm having now, although it's been a number of years since I did anything with binary arithmetic/maths, so I'm perhaps a little rusty there... but I understand the principle of the round-off errors. For the immediate future, as I'm needing some results to show-off and to look at, I am going to continue with the current model, but with the understanding and the knowledge of the less than 100% reliability of the results we get (just now I'm running large batches to look at parameters/variations across large populations etc.). As those simulations are running (this week), I'll try to get to grips with the Event system, and use the self-events for the mechanism, and then re-run the simulations with that Event based mechanism, to get the more reliable/robust results.

That will actually be quite good for me, because I'll have the 2 (actually 3, I had a previous noise production method) ways of modelling the Noise to compare and contrast, and to discuss and describe (I'm a 1st year PhD student, so picking up and learning these sorts of things not directly related to my research, but HOW I do the research, is great).
ted
Site Admin
Posts: 6299
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: More than one integrating SOLVE statement in an BREAKPOINT

Post by ted »

Malbolge wrote:I'll have the 2 (actually 3, I had a previous noise production method) ways of modelling the Noise to compare and contrast, and to discuss and describe
So you have multiple conceptual models for noise generation that you want to compare. It is therefore essential that there be a close match between each conceptual model and its computational implementation. Otherwise the computational results will not be a true reflection of the conceptual model, and their use as a means for comparing different conceptual models becomes problematical.
Post Reply