www.neuron.yale.edu

From The NEURON Book (pp.87, emphasis added): Although the Crank–Nicholson method is formally stable, models with stiff equations require small del_t to avoid numerical oscillations (Fig. 4.8). It is unusable in the presence of voltage clamps, extracellular mechanisms , or linear circuits, since the...

I found this post which indicates CN ought not to be used when using voltage clamps. Is it possible that this same logic applies to extracellular stimulation?

I've been continuing to try to understand my inconsistent results (as outlined in previous posts on this forum). My most recent attempt involved taking the stimsphere.py file in stimsphere.zip, hosted here , and adapting it to my scenario. In the code below, I have tried to retain as much of the ori...

I have a question related to my last post . From implementing different solvers, I learned that CVode().use_daspk() chooses its own time step sizes. (Right?) This is fine for stimuli in the normal physiological time range. When I try to stimulate the cell with pulses shorter than this, I get the NEU...

Update 4: I believe I've solved this. For anyone else facing the same problem, I recommend the following procedure: from neuron import h cvode = h.CVode() # let's say we want to activate the DASPK solver cvode.active(True) cvode.use_daspk(True) cvode.use_mxb(1) # I think this is optional, in that NE...

Update 3: Based on documentation here , I think (part of) the correct command order is: h.CVode().active(True) h.CVode().use_daspk(True) # or whatever solver you want.. This appears to produce (negligible) differences in simulation output with constant time step methods, suggesting the solver has no...

Update: I ran a percent error calculation comparing the results of all the solver settings in the post above. For all conditions except Crank-Nicholson, the error between any two solver settings is 0%. I interpret this to mean I have failed to actually change the solver, since I would expect at leas...

I'm trying to compare the results of different solvers offered in NEURON. My strategy goes something like this: moi_switch = 1 match moi_switch: case 0: h.CVode().use_daspk() self.cell.integration_method = 'SUNDIALS - DASPK' case 1: h.secondorder = 2 self.cell.integration_method = 'Crank-Nicholson' ...

I think I need help understanding the relationship of h.run(), h.continuerun(), and h.tstop. Below is a snippet of your code containing calls for all three. def erun(): # prepdatastores() h.tstop = EPOCHDUR h.tstop_changed() myinit() # model-specific initialization for ii in range(NUM): h.continueru...

I've avoided hoc as much as I could thus far, so let me check that I understand what's happening between the .py and .ses files. pyrig.ses recreates the h.IClamp() instance (which can also be created in Python), the RunControl window, and the h.Graph() object. pysyndrive.ses creates the h.NetStim() ...

I haven't yet been able to resolve this issue

The code below is meant to run a simulation in small chunks (basically useless for the toy script here, but useful to control RAM consumption for very large datasets). The h.ExpSyn() / h.NetStim() / h.NetCon() trio causes NEURON to deliver the error message NEURON: ExpSyn[0] :Event arrived out of or...

zip up just enough code to reproduce what you describe Will do, I thought it may have more to do with NEURON than any specific code chunk. If you're really concerned about numerical accuracy, use secondorder and a dt of 0.001 ms, or use adaptive integration (but make sure that the various states' e...

Why would NEURON give different results when I vary the time step outside the stimulus period? Below, I contextualize this question in the abstract, but I can provide a code example if necessary. My situation: I have an extremely short-duration E-field pulse I'm applying to a neuron model to assess ...

The CTNG Python tool to convert .swc data to watertight 3D models (introduced in 2013 here: https://www.sciencedirect.com/science/article/abs/pii/S0165027013003221) appears not to have been updated in some time. On my machine, I seem to be required to roll a few packages back to much earlier version...