Your question raises many issues.
In NEURON, the 3-D specification is the most natural way to set up detailed neuronal
geometries--see
5.5 How to specify geometry in The NEURON Book, or
http://www.neuron.yale.edu/neuron/stati ... l#Geometry
in the on-line Programmer's Reference.
That said, if you read the hoc file that sets up the architecture of the cell that you are
interested in
http://senselab.med.yale.edu/senselab/m ... lls\j7.hoc
you will note that everything looks OK until you get to proc define_lengths(). Calling
define_lengths() will destroy the detailed diameter information, as you can see from the
following:
Code: Select all
oc>// I downloaded j7.hoc, then ran NEURON and loaded j7.hoc
oc>//Now I will check the 3-D diameter data for one of the sections
oc>a1_1 for i=0,n3d()-1 print diam3d(i)
3.75
1.75
2
1
0.75
1.5
2
2.5
1.5
1.5
oc>// Good, it's intact. But what happens if I call define_lengths()?
oc>define_lengths()
oc>a1_1 for i=0,n3d()-1 print diam3d(i)
1.61111
1.61111
1.61111
1.61111
1.61111
1.61111
1.61111
1.61111
1.61111
1.61111
oc>// OW!
My guess is that this nasty proc was generated automatically by geometry_to_neuron.pl .
i8.hoc is similarly afflicted.
So whatever you do, DON'T call define_lengths(). Downloading the entire patdemo.zip
file from ModelDB and then grepping all its hoc files finds that define_lengths() is never
called.
Next issue:
Quoting from the Programmer's Reference,
The root section is treated as the origin of the cell with respect to 3-d position. When any section's 3-d shape or length changes, all the sections in the child trees have their 3-d information translated to correspond to the new position.
So just because the geometry specification of a1_1 starts with
Code: Select all
a1_1 {
pt3dclear()
pt3dadd(4.75,-37.75,-9.75,3.75)
it does not automatically follow that the origin of a1_1 lies at (9.5, -43.6, 2.8). Likewise
for any other section, i.e. one cannot assume that the first pt3dadd for any section
is going to be the origin of that section after the model cell has been completely
assembled. If the authors (or the software they used) tinkered with the coordinates
in one of the pt3dadd statements, or grafted an orphan tree (orphan trees are common
in detailed morphometric reconstructions) onto a likely parent section? This would affect
the positions of all child sections in the assembled model.
But how do you discover the coordinates of the 3-D data in the assembled model?
Easy--create a hoc file called truecoords.hoc that contains these statements
Code: Select all
load_file("nrngui.hoc")
load_file("j7.hoc") // true coordinates relative to soma origin are automatically computed
proc truecoords() { local i
forall {
print secname()
for i=0,n3d()-1 print i, " ", x3d(i), " ", y3d(i), " ", z3d(i), " ", diam3d(i)
}
}
truecoords()
You can modify truecoords() so that it writes the data to a file, uses commas or tabs to
separate numerical values, etc..
Last but not least issue:
you still have to deal with the fact that spatial discretization chops your model
into segments whose boundaries will not coincide with the points at which xyzdiam
measurements were made. A section zigzags along a path described by the sequence
of xyz coords, and you need to be able to tell which parts of this zigzag path correspond
to which segment of the discretized section. This can be done with arc3d and the
automatically computed L. Alternatively, if you're dealing with the far field produced by
the cell, you might find it satisfactory to approximate the path of axial current flow in 3
space by the coordinates of a section's nodes, starting at its origin (0 end), marching
over the loci of all its internal nodes, and ending at its 1 end. To see how to find node
locations, get
http://www.neuron.yale.edu/ftp/ted/neur ... nd_rec.zip
Read the readme.txt file, give the program a try, and then see proc grindaway() in
interpxyz.hoc