SWC files with a single "soma" point

[sgratiy]

Some cells from Neuromorpho.org have somata containing only a single 3d point. Even though NEURON's Import3d tool attempts to fix the problem by assigning one of the adjacent points to soma, the information about soma's morphology is greatly compromised for those cells. What strategy would you recommend to follow in order to "enhance" such cells with more or less realistic somata? In my case the detailed shape of soma is not required, but it is necessary to have a good estimate of the soma's surface area. Since there lots of cells in neuromorpho with this artifact, I doubt that simply looking for a better reconstructions would be the best solution to this particular issue.
Thanks

[ted]

Some cells from Neuromorpho.org have somata containing only a single 3d point. Even though NEURON's Import3d tool attempts to fix the problem by assigning one of the adjacent points to soma, the information about soma's morphology is greatly compromised for those cells.

I never saw such a thing, but then I have only worked with a small subset of the data from NeuroMorpho.org. "Assigning one of the adjacent points to soma" doesn't sound like the right thing to do. My suspicion is that the single 3d point is meant to specify the location and diameter of a sphere that is roughly the same "size" as the soma--if so, it is a very crude estimate that will only very roughly approximate the volume or surface area of the soma.

Another possibility, if the original data were generated in some format other than Neurolucida or SWC, is that the original data _did_ contain multiple measurements from the soma--either as a series of xyzdiam tuples, or as a perimeter outline, but that somehow this was lost when the data were converted to Neurolucida or SWC format.

You might ask the people who run NeuroMorpho.org whether either of these two possibilities is correct, or whether there is some other answer. If they don't know the answer, you may be able to confirm my first suggestion by reading the Methods section of the publications associated with those morphologies, or by contacting the authors of those publications.

Good luck finding out what's going on here, and please be sure to post a followup message when you have found the answer! The question is bound to arise again and again.

[neuromau]

The question is bound to arise again and again.

Yes, I just had related question!

Based on an entry in the Neuromorpho FAQ at http://neuromorpho.org/neuroMorpho/myfaq.jsp, the single point for the soma is indeed meant to specify a spherical soma:

Soma can be a single point or more than one point. When the soma is encoded as one line in the SWC, it is interpreted as a "sphere". When it is encoded by more than 1 line, it could be a set of tapering cylinders (as in some pyramidal cells) or even a 2D projected contour ("circumference").

So here's my question: is there a way to force Import3D to render the soma as a sphere when it is only encoded as one line in the SWC?

Thanks,
Marianne

[neuromau]

After reading some of the other threads in this forum, it seems that I would be better served by just adding a line to the swc file such that the soma is specified as a cylinder with L = diam = 2*sphere_radius. The only other uncertainty I had was the orientation of this cylinder. This (CA1 pyramidal) cell has both apical and basal dendrites, and many of these cells in neuromorpho show the axon originating from the soma near the basal dendrites. Given that the spike detector used to represent the axon is placed at the 1 end of my cell, perhaps I should orient the cylinder such that the basal dendrites connect to the 1 end and the apical dendrites to the 0 end.

[ted]

After reading some of the other threads in this forum, it seems that I would be better served by just adding a line to the swc file such that the soma is specified as a cylinder with L = diam = 2*sphere_radius.

If such swc files are common, I would expect Import3D to already have a policy for dealing with them. Have you such a file, and what did Import3D do?

The only other uncertainty I had was the orientation of this cylinder.

The simplest policy to me would be to arbitrarly orient it along the x or y axis. The policy that makes sense for most elongated neurons would be to orient it parallel to the principal axis, but most elongated neurons that I have seen also have a soma that is elongated and therefore unlikely to have been treated as a sphere by the person or algorithm that generated the morphometric data.

many of these cells in neuromorpho

You got the morphology in question from NeuroMorpo.org? I'd like to see it.

Given that the spike detector used to represent the axon is placed at the 1 end of my cell

at the 1 end of the soma? Seems a strange choice.

perhaps I should orient the cylinder such that the basal dendrites connect to the 1 end and the apical dendrites to the 0 end.

My guess is nobody else on the planet does that. If anybody reuses your customized morphologies in studies that involve algorithmic specification of channel or synapse densities that depend on path lengths, or analyze concentration or membrane potential or currents as functions of distance from a reference point, won't they be surprised.

[neuromau]

If such swc files are common, I would expect Import3D to already have a policy for dealing with them. Have you such a file, and what did Import3D do?

Yes, I downloaded the file from http://neuromorpho.org/neuroMorpho/dableFiles/amaral/CNG%20version/c10261.CNG.swc. The first two data lines of it look like:

Code: Select all

1 1 -3. -0.5714 -0.60710 5.808  -1
2 2 -3. 9.5 -3.5 0.4  1


where the numbers in the second column refer to compartment type (1=soma, 2=axon). So you can see that only the first line refers to the soma (there are no other soma lines later on). NEURON's response is the same as sgratiy got, which is to reassign the second line, which refers to the axon, to the soma so that it defines a cylinder. I can give the exact wording tomorrow if you need it.

You got the morphology in question from NeuroMorpo.org? I'd like to see it.

Yes, it is from NeuroMorpho.org. Here is the link http://neuromorpho.org/neuroMorpho/neuron_info.jsp?neuron_name=c10261 for CA1 pyramidal cell #c10261 from the Amaral lab, and the standardized SWC file for this cell is the one I mentioned above. Should I be using a different model, with a more detailed soma specification?

at the 1 end of the soma? Seems a strange choice.

I'm assuming it is strange because it should usually be at the 0 end? I had always thought it should be at the 0 end, but when I actually looked at what is in the Santhakumar/Morgan model, I saw the following for the connect_pre function, which we call to associate the spike detector to the cell:

Code: Select all

proc connect_pre() {  // $o1 target point process, $o2 returned NetCon
soma $o2 = new NetCon (&v(1), $o1)
}


So that means the spike detector is checking the voltage at the 1 end, correct? I will change this to the 0 end for the next release of the model.

won't they be surprised

That would definitely be bad. So once I put the spike detector on the 0 end and have the basal dendrites also come out of 0, and the apical come out of 1, will that be considered standard?

[ted]

Given a morphometric data file that has only a single soma point, it follows that there is only one point to which child branches can be attached. If the soma is represented as a sphere (and there's no basis for representing it as anything else), it probably won't make any practical difference to electrical signaling if all branches are attached to the node at 0, 0.5, or 1, or divided between these locations.

That said, there can be rational bases for choosing particular sites of attachment. For example, in the case of pyramidal cell morphologies, shape plots will appear most natural if the root branches of apical trees are attached to soma(1) and the root branches of basal trees are attached to soma(0); a few trees of either class might arise from soma(0.5) without damaging the appearance. This strategy favors making soma(0) the reference point for distance measurements.

Where to attach NetCons is a different issue. In some cell classes, the axon arises from the soma, but in others it may arise from a proximal dendrite. In most pyramidal cells the axon typically arises from the basilar end (near soma(0), given the strategy described above).

it is from NeuroMorpho.org. Here is the link http://neuromorpho.org/neuroMorpho/neuron_info.jsp?neuron_name=c10261 for CA1 pyramidal cell #c10261 from the Amaral lab, and the standardized SWC file for this cell is the one I mentioned above. Should I be using a different model, with a more detailed soma specification?

Amaral does good work. Unless detailed soma morphology is important in your particular application, there's no need to switch.

when I actually looked at what is in the Santhakumar/Morgan model, I saw the following for the connect_pre function, which we call to associate the spike detector to the cell:

Code: Select all

proc connect_pre() {  // $o1 target point process, $o2 returned NetCon
soma $o2 = new NetCon (&v(1), $o1)
}


So that means the spike detector is checking the voltage at the 1 end, correct?

Yes.

I will change this to the 0 end for the next release of the model.

I'm not sure I'd bother. Michael Hines would probably say leave it alone, unless you're doing it as part of an overhaul that results in a model that is "new" in some significant way. But then you might be opening yourself to questions such as "how do you know that repositioning the NetCons didn't cause a significant qualitative change in the behavior of your model? How can you distinguish such a possible effect from the effects of the other changes you made?"

won't they be surprised

That would definitely be bad.

As a colleague of mine used to say, "Hey, the heck with everybody else. What did they ever do for you?" Besides, this is truly one of the lesser elements in the set of all arbitrary assumptions that have been embedded in computational models.

So once I put the spike detector on the 0 end and have the basal dendrites also come out of 0, and the apical come out of 1, will that be considered standard?

It's one less thing to have to explain to reviewers. Of course, one can carry "anticipation of critiques" to an extreme. At some point it becomes reminiscent of the folk tale about the man whose son was riding a donkey as they walked along a road . . .

[ted]

it is from NeuroMorpho.org. Here is the link http://neuromorpho.org/neuroMorpho/neuron_info.jsp?neuron_name=c10261 for CA1 pyramidal cell #c10261

Yeow--what are those big red zigzag lines that I see in Import3D? Attempts to trace the boundaries of hippocampal cortical layers?

[neuromau]

what are those big red zigzag lines that I see in Import3D? Attempts to trace the boundaries of hippocampal cortical layers?

Yes, that was my assumption. It has a compartment type of '10', which doesn't correspond to any of the real compartment types, and other cells in the database have similar (or more layerish looking) zigzag lines.

[phendric]

If such swc files are common, I would expect Import3D to already have a policy for dealing with them. Have you such a file, and what did Import3D do?

Yes, I downloaded the file from http://neuromorpho.org/neuroMorpho/dableFiles/amaral/CNG%20version/c10261.CNG.swc. The first two data lines of it look like:

Code: Select all

1 1 -3. -0.5714 -0.60710 5.808  -1
2 2 -3. 9.5 -3.5 0.4  1


where the numbers in the second column refer to compartment type (1=soma, 2=axon). So you can see that only the first line refers to the soma (there are no other soma lines later on). NEURON's response is the same as sgratiy got, which is to reassign the second line, which refers to the axon, to the soma so that it defines a cylinder. I can give the exact wording tomorrow if you need it.

You got the morphology in question from NeuroMorpo.org? I'd like to see it.

Yes, it is from NeuroMorpho.org. Here is the link http://neuromorpho.org/neuroMorpho/neuron_info.jsp?neuron_name=c10261 for CA1 pyramidal cell #c10261 from the Amaral lab, and the standardized SWC file for this cell is the one I mentioned above. Should I be using a different model, with a more detailed soma specification?

I want to resurrect this thread because I don't think this issue has been resolved, because I want to give a better answer to Ted's first question above, and because I want to echo his thought that Import3D should have a policy for dealing with this scenario.

I can verify that there are multiple files on neuromorpho.org that have only a single line for the soma. That's not my problem, however. I'm using L-NEURON (http://krasnow.gmu.edu/cn3/L-Neuron/index.htm) to generate unique cells within a certain morphological class, and any SWC file that it outputs only has a single line for the soma, like so:

Code: Select all

1 1 0.000000 0.000000 0.000000 5.000000 -1
2 3 -2.883534 7.320411 -19.991474 0.568317 1
3 3 -5.146981 13.066614 -35.683907 0.568317 2
4 3 -7.410429 18.812817 -51.376339 0.039782 3


In this case, the soma is a sphere with a radius of 5 micrometers. The second line is the first section of one of the dendritic trees, which connects to the soma.

When you try to import this file (called "output.swc") using Import3D, Neuron returns the following message:

Code: Select all

Notice: ./output.swc:
The first two points have different types (1 and 3) but
    a single point root section is not allowed.
    Changing point id 2 so that it is type 1.
    If this is an incorrect repair, then change the file.


When you look at the generated HOC code, you get the following code after all the sections get connected together:

Code: Select all

proc shape3d_1() {
  soma {pt3dclear()
   pt3dadd(0, 0, 0, 10)
   pt3dadd(-2.88353, 7.32041, -19.9915, 1.13663)
  }
  dend {pt3dclear()
   pt3dadd(-2.88353, 7.32041, -19.9915, 1.13663)
   pt3dadd(-5.14698, 13.0666, -35.6839, 1.13663)
   pt3dadd(-7.41043, 18.8128, -51.3763, 0.079564)
   pt3dadd(-9.67388, 24.559, -67.0688, 0.079564)
   pt3dadd(-9.7437, 24.7363, -70.0627, 0.07975)
   pt3dadd(-10.4404, 26.5051, -72.3835, 0.07975)
   pt3dadd(-10.8431, 27.5273, -75.1751, 0.07975)
   pt3dadd(-11.2457, 28.5494, -77.9667, 0.07975)
  }


Why is the same 3D point being added to both the soma and the first dendritic section?

So it looks like NEURON is basically turning the first dendritic section into an extension of the soma, which could have problematic results for the morphology of the cell, though what's actually happening in the code is not clear to me.

What should Import3D do in this case? And what should users of NEURON do to fix what's actually happening? NEURON explicitly tells us to change the file, but how?

Phillip

[ted]

So it looks like NEURON is basically turning the first dendritic section into an extension of the soma

Not so. Look again at the pt3dadd statements and you'll see that the first dendritic section is unaltered. What has changed is the soma. If the intent of L-Neuron's developers is for the soma to be a sphere with radius specified in the first line, this is where Import3D falls down: its translation specifies a frusta with base diameter 10 um and apex diameter equal to the diameter of the first child section. If soma.nseg is 1, the result is a single compartment with diameter halfway between the two--which has surface area about half that of a 10 um diameter sphere. The manual fix is simple enough: in the resulting hoc file, change the soma's second pt3dadd statement to specify the same diameter as in the first pt3dadd statement. This seems like a reasonable policy to be built into Import3D, and it would make such manual edits unnecessary.

[hines]

I was unaware that neuromorpho used that policy for a single point soma.
3-D Soma shapes are not well defined in most formats. Morphml makes
some attempts in that direction.

I've placed a tentative patch for download at
http://www.neuron.yale.edu/ftp/hines/tm ... oint_patch
and anyone interested in the problem should see what it does with
http://neuromorpho.org/neuroMorpho/dabl ... 61.CNG.swc

Note that the new Notice reads:

Notice: ./c10261.CNG.swc:
The first two points have different types (1 and 2) but
a single point root section is not allowed.
Adding a few points of type 1 before and after the first point
so that it looks like a sphere.
Children will be logically connected to the center point
with pt3dstyle(1,...).
If this is an incorrect repair, then change the file.

However, at present the "Adding a few points" is a lie and all it
is doing is drawing a fat circle at the proper location in the import3d gui.
Since the soma has only one point, it will not be possible to successfully
simulate at present (one can only visualize with the Import3d tool)

By the way, to use the patch in this case, cd to the lib/hoc/import3d folder whose files you want
to modify and type:
patch -p 4 < /where/you/put/import3d_single_point_patch
you may need to think a bit about whether that is really the folder used by nrngui.

With this visualization you can assess whether the spherical soma is a good idea and whether
the sphere is a good indication of the area. The area is the only thing that matters electrically.
In the visualization, all the dendrites (and axon) are connected by wires to the center of the
soma (0.5) from the proximal ends of the dendrites.

I'm happy to take suggestions about how to finish this off before committing to the repository.

[vladimirov]

This seems to be a common issue. I got same problem in swc file for cell http://neuromorpho.org/neuroMorpho/neur ... _name=ca1a

Code: Select all

  1 1 2413. 1468. 1755. 5.  -1
2 3 2412. 1468. 1755. 0.3  1
3 3 2411. 1469. 1755. 0.3  2

Maybe trivial, but worth mentioning: both diameter of soma apex and *its coordinates* must be changed in the resulting hoc file from import3D:
instead of automatically-generated

Code: Select all

  soma {pt3dclear()
   pt3dadd(2413, 1468, 1755, 10)
   pt3dadd(2412, 1468, 1755, 0.6)
  }

make

Code: Select all

  soma {pt3dclear()
   pt3dadd(2413, 1468, 1755, 10)
   pt3dadd(2423, 1468, 1755, 10)
  }

Now soma has diam=10 and L=10, as needed.

[hines]

The neuromorpho curators are in the process of converting all the single point soma swc files
to 3 point somas so the problem will in part go away for that site with respect to electrical properties.
I think the problem continues to be a vexing one in the sense that somas are best represented
as outlines and the first point of a dendrite should be connected to the center of the soma
with a 0 resistance wire instead of with truncated cone area defined by the diameter of the
soma and the diameter of the first dendrite point. The latter is what happens with a neurolucida file
with soma outlines. In that case, both the electrical properties and the visualization are fairly
accurate. Ultimately, I expect it will be useful to extend NEURON's 3-d point styles to encompass
the soma outline explicitly. Of course,then it becomes a question whether we should also
do the same for a stack of soma outlines (as is currently understood by import3d when reading
neurolucida files.)