There are no ion accumulation mechanisms (whose NEURON blocks contain one or more USEION statement that WRITEs a concentration), and no second messengers or other signals that are governed by ODEs or kinetic schemes?
My cell indeed contains mechanisms using USION statements.
But do any of them WRITE a concentration? e.g. a calcium accumulation mechanism would have a NEURON block that contains a WRITE statement of the form
USEION ca READ cai, ica WRITE cai
Your first two statements are pointing toward the fact that I should run the simulation without any input for several seconds to get a steady state for voltage but also for all ionics distributions to be at equilibrium
True, but remember that (1) models can contain many other state variables (e.g. channel gating states, second messengers other than Ca), (2) mechanisms may interact with each other in ways that make steady state initialization difficult or even impossible (consider models of cells that fire spontaneously).
I though that unstable ions concentrations would be reflected by the voltage accross the membrane
Not necessarily. Read enough modeling papers and you will discover that modelers have made many different assumptions about ionic currents, concentrations, and equilibrium potentials. It is very common to see that ionic currents are assumed to have no effect on concentrations or equilibrium potentials. In some models, at least one species of ionic current affects concentration, but not equilibrium potential. In others, some currents affect concentration and equilibrium potential, but others don't. The authors of these models all had reasonable justifications for their assumptions. To maximize the utility of NEURON, it was necessary to be able to accommodate all these different strategies. In most cases, NEURON can automatically determine what should happen based on the details of the mechanisms that are present in a section. However, in some cases, the user must be able to override this, and that's the purpose of the ion_style() function. For more information, read the documentation of the ion_style() function in the Programmer's Reference
https://nrn.readthedocs.io/en/latest/py ... #ion_style
So you're just doing the typical "voltage clamp initialization" in which each state variable is only dependent on local membrane potential, and is initialized to the value it would have if local membrane potential had been held at some specific level? Which in turn means that you're not dealing with spontaneously active cells, or initializing cells to a "dynamic steady state" (as would happen if a cell is embedded in a milieu of ongoing synaptic activation).
Indeed this is what I'm doing right now. Should it be preferable to have a "dynamic steady state" if I want to see the effect of a perturabation ? I'm studying extracellular stimulation and I performed first the steady state (ss) as previously expained, then 2 minutes of activity with synaptic inputs and finally N sec of extra stimulation.
So your model cell is subjected to "background" synaptic activity for some time, and then you add the extracellular stimulus. Is the background synaptic activity stochastic, and does it differ from run to run?
I do not have any knowledge of dynamic steady state, is it only doing a pre-simulation with normal synaptic input for few seconds before the simulation of interest ?
Maybe a better term would be "perturbed steady state" which suggests a system that is subjected to perturbations yet remains "close" to an unperturbed steady state.
I was thiking that maybe I could write easily a script to save . . .
That's asking for trouble.
the pre-activity block of few sec takes hours to run and could be squeezed by restoring the state at the time the stimulation is turn on.
I think your best bet is
For the moment, forget about extracellular stimulation and even forget about your existing model cell.
Instead, make a toy model (a ball and stick model would be good), attach a couple of synaptic mechanisms to it, and run a simulation that lasts maybe 100 ms of model time and generates reproducible results (that is, each run produces the same result).
Then make a copy of this program, and add SaveState functionality to the copy. The new program should stop execution at 100 ms, and after the end of a simulation it should execute a procedure that calls SaveState.save() and then writes the saved states to a file via SaveState.fwrite().
Make a copy of your second program, and add a conditional statement that controls whether the program {does a 100 ms warmup run and calls the procedure that saves states to a file} or {calls a new procedure that uses SaveState.fread() to get states from a file, then uses SaveState.restore() to restore the states, and finally runs a simulation that stops when t is 200 ms}
Verify that your third program works properly by comparing its output to what your first program does when your first program stops at t == 200 ms; it should match the last 100 ms of your first program's output.
At this point your third program will be organized something like this:
1. declarations of important symbolic constants, e.g. you might use a variable called "runfromsaved" to control program execution
2. model setup code
3. def of a procedure that runs a simulation for 100 ms, then saves states and writes to a file
4. def of a procedure that reads states from a file, then restores states and runs a simulation for 100 ms of model time
5. a conditional statement that does
if runfromsaved is FALSE then execute the procedure that runs a simulation and saves states to a file
else execute the procedure that reads states from a file, restores them, and runs a simulation for 100 ms
Now you're ready to make a fourth program. The fourth program differs from the third one in one way: when runfromsaved is not FALSE, instead of doing this
else execute the procedure that reads states from a file, restores them, and runs a simulation for 100 ms
it does
else execute the procedure that reads states from a file, restores them, sets up extracellular stimulation, and runs a simulation for 100 ms
The only drawback of this final version of the program is that it can only be used to do a single run with extracellular stimulation. If you need to do multiple runs, maybe with different simulus amplitudes or patterns, you have to exit NEURON and then execute the program again. How can you tell NEURON to something different in each run? One way might be for your Python code read a parameter file. That could be done after states have been restored but before executing a simulation. Or maybe you could pass a value to Python via the command line (is that doable with Python? hoc allows it, but hoc allows all kinds of potentially problematical things . . .)