Hi Ted,
I am working from a package of files that I downloaded ...its basically a NTS neuron that has a soma with about 10 types of diff ion channels/pumps etc....( this a NEURON file)
The files defining the na, k , naca pumps etc are all "O" type files...
ie na.o and nacax.o etc
I can open them in neuron....but I can't do anything else.
How can I view the source of these files to see how it is setup?
Thanks in advance and appreciate all your time.
Meena
O files
The sources are in the mod-files, but considering your other question aswell I would advice you to read and try one of the tutorials you find under documentation.
A nice one to get you started with the basics you can find here:
http://www.anc.ed.ac.uk/school/neuron/
A nice one to get you started with the basics you can find here:
http://www.anc.ed.ac.uk/school/neuron/
-
ted
- Site Admin
- Posts: 6300
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Raj made a good suggestion. All I have to add is this: .o and .c files are
byproducts of compiling mod files. They may be useful to advanced
programmers in rare situations, but you can safely discard them--they are
not meant to be read by humans.
If you retrieved the files from ModelDB, I should also inform you that the
NEURON files that are actually _in_ ModelDB (as distinct from files that
reside on other fileservers, e.g. the Dendritica collection) have been
packaged in a way that allows them to autorun on download. The "master
file" that starts everything is mosinit.hoc. After you have downloaded a
model and compiled its mod files, double click on mosinit.hoc and you will
see the simulation execute.
Another comment: many of the models in ModelDB do not make use of
NEURON's standard run system. Instead, simulation execution is controlled
by custom control code. This is an OK way to develop one's own models,
and many years ago--when there was no standard run system--it was the
only way to do it. Many experienced and prolific NEURON users still work
this way--that's how they learned to do it, and that's what they're going to
do forever because for them it's too much work to try to learn something
new. People who are just starting NEURON should avoid this style of
program development, because idiosyncratic programming practices
prevent one's code from being widely reusable and competing for mind
share. Also, it prevents you from using the standard run system's
simulation control and model analysis tools that would be difficult or
impossible for users to replicate on their own (e.g. the Multiple Run Fitter
and the ModelView tool), and it precludes use of NEURON's powerful
and efficient adaptive integration methods (i.e. CVODE).
It is possible to update such code so that it makes appropriate use of the
standard run system. Generally the best strategy is to try to isolate just
the part that specifies the anatomy and biophysics of the model, and
abandon anything that has to do with graphics or simulation control. In
doing this, it is always a good idea to watch out for tricky stuff like
simluation control code (especially initialization code) that changes
anatomical and/or biophysical properties.
byproducts of compiling mod files. They may be useful to advanced
programmers in rare situations, but you can safely discard them--they are
not meant to be read by humans.
If you retrieved the files from ModelDB, I should also inform you that the
NEURON files that are actually _in_ ModelDB (as distinct from files that
reside on other fileservers, e.g. the Dendritica collection) have been
packaged in a way that allows them to autorun on download. The "master
file" that starts everything is mosinit.hoc. After you have downloaded a
model and compiled its mod files, double click on mosinit.hoc and you will
see the simulation execute.
Another comment: many of the models in ModelDB do not make use of
NEURON's standard run system. Instead, simulation execution is controlled
by custom control code. This is an OK way to develop one's own models,
and many years ago--when there was no standard run system--it was the
only way to do it. Many experienced and prolific NEURON users still work
this way--that's how they learned to do it, and that's what they're going to
do forever because for them it's too much work to try to learn something
new. People who are just starting NEURON should avoid this style of
program development, because idiosyncratic programming practices
prevent one's code from being widely reusable and competing for mind
share. Also, it prevents you from using the standard run system's
simulation control and model analysis tools that would be difficult or
impossible for users to replicate on their own (e.g. the Multiple Run Fitter
and the ModelView tool), and it precludes use of NEURON's powerful
and efficient adaptive integration methods (i.e. CVODE).
It is possible to update such code so that it makes appropriate use of the
standard run system. Generally the best strategy is to try to isolate just
the part that specifies the anatomy and biophysics of the model, and
abandon anything that has to do with graphics or simulation control. In
doing this, it is always a good idea to watch out for tricky stuff like
simluation control code (especially initialization code) that changes
anatomical and/or biophysical properties.