Two issues with cvode.event when using cvode.active(1)

Anything that doesn't fit elsewhere.
Post Reply
JustasB
Posts: 14
Joined: Tue Dec 08, 2015 8:17 pm

Two issues with cvode.event when using cvode.active(1)

Post by JustasB » Sun Mar 04, 2018 6:30 pm

I'm running into issues where h.t runs past h.tstop and cvode.events are triggered too early while using cvode. I've managed to reproduce the issues with this snippet:

Using NEURON 7.5 master (6b4c19f) on Windows (same issue on NRN 7.4 on Ubuntu 16.04), paste the following in python console:

Code: Select all

from neuron import h, gui
h.cvode.active(1)

def hi():
   print('hello from hi, h.t = %g' % h.t)

def test_init():
   h.cvode.event(1.3, hi)
   h.cvode.event(500, hi)
   h.cvode.event(1000, hi)

fih = h.FInitializeHandler(test_init)
h.run()
h.t # Issue 1: Expected: 5, Prints: 500.

h.run() # Issue 2: Expected: "hi" from t=1.3, Prints: "hi" from 1.3 and 500

Same result when using cvode_active() or cvode.active()
Replacing h.run()'s with: h.init(); h.continuerun(5); results in the same behavior
Adding cvode.re_init() does not seem to help

However, the two issues are not present when cvode.active(0)

ted
Site Admin
Posts: 5376
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Two issues with cvode.event when using cvode.active(1)

Post by ted » Mon Mar 05, 2018 12:40 am

What happens when you actually give NEURON something to integrate?
Insert
soma = h.Section()
before the first call to h.run() and see what happens.

JustasB
Posts: 14
Joined: Tue Dec 08, 2015 8:17 pm

Re: Two issues with cvode.event when using cvode.active(1)

Post by JustasB » Mon Mar 05, 2018 12:39 pm

Ok, when I add a section, Issue #2 dissapears, but Issue #1 (h.t >> h.tstop) remains (code below). However, the reason why I'm posting what appears to be a contrived example is because I'm experiencing an intermittent, hard-to-reproduce issue in a script that works with more complex model's I'm working on. The primary symptom of the problem is that h.t >> h.tstop (e.g. tstop = 500, while h.t might become 28,000+), the machine freezes, and I ultimately have to pkill the NEURON process.

The problem appears only when using cvode (with fixed step I've never seen h.t>h.tstop or the freezing issue). I trimmed my code down to the smallest possible, reproducible example of h.t > h.tstop. To be fair, it's possible there are other issues in my script/models, but the h.t >> h.tstop issue seems to be at least one of the causes.

Is there any reason why h.t should ever exceed h.tstop? I did not find anything in the documentation or in this forum that would suggest that this behavior is by design.

Code: Select all

from neuron import h, gui
h.cvode.active(1)

def hi():
   print('hello from hi, h.t = %g' % h.t)

def test_init():
   h.cvode.event(1.3, hi)
   h.cvode.event(500, hi)
   h.cvode.event(1000, hi)

fih = h.FInitializeHandler(test_init)
soma = h.Section()
h.run()
h.t # Issue 1: Expected: 5, Prints: 500.

h.run() # Prints: "hi" from 1.3 as expected

ted
Site Admin
Posts: 5376
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Two issues with cvode.event when using cvode.active(1)

Post by ted » Mon Mar 05, 2018 2:32 pm

Don't use h.cvode.active(1). Use h.cvode_active(1) instead; cvode_active is part of the run control system and does many things to simulation execution that cvode.active doesn't do. What do you see after you make that change?

JustasB
Posts: 14
Joined: Tue Dec 08, 2015 8:17 pm

Re: Two issues with cvode.event when using cvode.active(1)

Post by JustasB » Mon Mar 05, 2018 3:40 pm

Hmmm I had tried cvode_active() in the original code, but without the test section it still produced the same error. However, test section + cvode_active(1) both issues disappear. Thank you for the suggestion. I will try it in my full script.

In the hot tip about using cvode_active(), you mention that it's better than cvode.active(). Would you go as far as to say it's always better to use that method? I.e. are there any situations where cvode.active() should be used instead of cvode_active()?

If you can, will you please add a note with a link to the hot tip in the CVode.active() documention? I expect it will save time for others who might run into a similar issue in the future.

ted
Site Admin
Posts: 5376
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Two issues with cvode.event when using cvode.active(1)

Post by ted » Mon Mar 05, 2018 4:26 pm

JustasB wrote:
Mon Mar 05, 2018 3:40 pm
In the hot tip about using cvode_active(), you mention that it's better than cvode.active(). Would you go as far as to say it's always better to use that method? I.e. are there any situations where cvode.active() should be used instead of cvode_active()?
I haven't seen a situation in which cvode.active would be advantageous in user-written code.

cvode.active() is a direct hoc call to the active() method of hoc's CVode class, which is implemented in compiled C/C++ code. Since it's "built into NEURON," CVode.active() is documented in the Programmer's Reference. cvode_active(), however, is implemented in hoc and is part of NEURON's standard run library, so it has NOT YET been documented in the Programmer's Reference! even though it appears in several blocks of example code in the Programmer's Reference!!

To make cvode_active() available to Python, you need only do something that makes NEURON load its standard run library. Importing gui will do it, as in this example
from neuron import h, gui
but that also gives you a NEURON Main Menu toolbar. If you want to import the standard run library but avoid creating the NEURON Main Menu toolbar, just
from neuron import h
h.load_file("stdgui.hoc")
If you can, will you please add a note with a link to the hot tip in the CVode.active() documention? I expect it will save time for others who might run into a similar issue in the future.
Good idea. I suspect we'll just include a statement about this directly in the Programmer's reference.

JustasB
Posts: 14
Joined: Tue Dec 08, 2015 8:17 pm

Re: Two issues with cvode.event when using cvode.active(1)

Post by JustasB » Mon Mar 05, 2018 5:00 pm

so it has NOT YET been documented in the Programmer's Reference! even though it appears in several blocks of example code in the Programmer's Reference!!
Haha. Understood. Thank you for the explanation. I will make sure I use cvode_active() whenever I use cvode.

Just an update, the problematic models seem to be behaving themselves after I started using cvode_active() in my larger script -- so I believe the use of cvode.active() was the cause of the problems.

ted
Site Admin
Posts: 5376
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Two issues with cvode.event when using cvode.active(1)

Post by ted » Mon Mar 05, 2018 5:11 pm

The moral of today's sermon is that can be easier to fix wicked code than it is to fix wicked documentation. Let us go forth and sin no more.

Post Reply