Modifying morphological data

Managing anatomically complex model cells with the CellBuilder. Importing morphometric data with NEURON's Import3D tool or Robert Cannon's CVAPP. Where to find detailed morphometric data.
Post Reply
Sherif
Posts: 27
Joined: Thu Oct 13, 2005 4:32 pm

Modifying morphological data

Post by Sherif »

Hello,

I work with detailed morphological models in which the dendrites are described by 3D points imported from an external file to NEURON. I want to modify the morphology of the dendrites by, for example, increasing the length of each dendritic compartment by 10%. Given that the length of each compartment is computed from the x,y,z coordinates of the 3D points at the 0 and 1 ends, I need to change the x,y,z of these 3D points to implement the change in dendritic length. After that, I would like to save the modified morphology to an external file.

1) Does anyone know an easy way to do these morphological changes?

2) How can the new x,y,z coordinates be obtained knowing the original coordinates of 3D points at the 0 and 1 ends and the percent increase in length?

Thank you very much.
-S
ted
Site Admin
Posts: 6300
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Modifying morphological data

Post by ted »

Sherif wrote:I want to modify the morphology of the dendrites by, for example, increasing the length of each dendritic compartment by 10%.
The first step can be done by scaling the xyz coordinates of each pt3d point.

Code: Select all

// argument multiplies pt3d lengths, leaves diameters unchanged
// example:  stretch(2) doubles all distances
proc stretch() { local ii, m
  m = $1
  forall for ii=0,n3d()-1 {
    pt3dchange(ii, m*x3d(ii), m*y3d(ii), m*z3d(ii), diam3d(ii))
  }
}
Length increases that are greater than ~10-20% may require adjusting nseg for the sake
of spatial accuracy.
After that, I would like to save the modified morphology to an external file.
The best way to do this depends on how many times you have to do it. If you only have
to do it 2-3 times, just import the stretched cell into a CellBuilder, then save the
CellBuilder to a new session file.

If you need to do this on many cells, it would be better to do all of the scaling with a small
program written in a language such as awk or perl. Assuming that the cell geometry is
specified in a hoc file, the program would scan for each occurrence of the string
pt3dadd
and then replace the following three numeric values with the values multiplied by the
scale factor. Come to think of it, even NEURON probably has sufficient text
manipulation capability to do this.
Sherif
Posts: 27
Joined: Thu Oct 13, 2005 4:32 pm

Post by Sherif »

Thanks Ted very much for your reply. This was really helpful.

-S
ted
Site Admin
Posts: 6300
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Post by ted »

Thanks for using NEURON in your research, Sherif!
Corinne
Posts: 38
Joined: Wed Feb 09, 2011 7:13 pm

Re: Modifying morphological data

Post by Corinne »

I would like to resurrect this thread with a closely related question.

In the Mainen & Sejnowski model, I was curious if the spiking behavior would be similar if I scaled up the size of the small L3 Aspiny neuron (lcAS3.hoc in the demofig1.hoc code), so that its surface area was equal to that of the large L5 Pyramidal cell (j4a.hoc in the demofig1.hoc code).

If all of the segment lengths of the small Aspiny neuron (dendrites, axon and soma) are multiplied by ~12.77 then the surface areas of the (formerly) small neuron and the large Pyramidal neuron would be the same.

In order to scale up the small neuron, after loading it, I ran the following one line of code:

Code: Select all

forall {L=12.77*L}
I then checked to make sure the surface area was as expected using your recommended surface area calculation code (from another thread):

Code: Select all

proc totalarea() { local sum
  finitialize()
  sum = 0
  forall for (x,0) sum += area(x)
  print "total surface area = ", sum, " um2"
}
totalarea() // returns total surface area
When I then initialized and ran the code I got some results that surprised me: 1. The frequency of the spiking is now faster in the larger size-scaled version of the neuron than it was in the original smaller version. I would expect the opposite, as there should be a larger capacitance in a larger neuron that should take longer to "charge up". 2. The delay to the first spike was much shorter in the larger model. Here I am surprised for the same reason. 3. The threshold for spiking appears to be lower for the larger neuron i.e. the voltage at which the sudden rise in voltage occurs due to the sodium channels opening seems to happen at a lower voltage in the larger size-scaled neuron. This surprises me because I think the activation potential of sodium should always be the same.

So, I am wondering if something is amiss with my simple scaling method. From your previous post, I see that nseg might need to be changed for size scaling larger than 10-20%. I would have tried altering nseg but I am not sure how to do this simply for the whole neuron. Also, I am not sure if changing nseg should account for my three surprises. Do you think nseg would cause these phenomena? If so, do you have any advice on how to change the nseg of all the segments? Or, is the observed spiking behavior perhaps a real result?

Thanks in advance!!
ted
Site Admin
Posts: 6300
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Modifying morphological data

Post by ted »

Interesting question.
Corinne wrote:In order to scale up the small neuron, after loading it, I ran the following one line of code:

Code: Select all

forall {L=12.77*L}
I then checked to make sure the surface area was as expected
It would also be a good idea to verify that
forall L*=k
where k is some constant
stretches the distances between pt3d points by the same scale factor, and that the discretized model has only been stretched lengthwise without affecting diameters. Easiest way to verify this is with a simple model, as done with this code:

Code: Select all

load_file("nrngui.hoc")

create soma, dend
access soma

soma {
  pt3dclear()
  pt3dadd(0,0,0, 1)
  pt3dadd(10,0,0, 2)
}

dend {
  pt3dclear()
  pt3dadd(0,0,0, 1)
  pt3dadd(0,10,0, 2)
  pt3dadd(5,15,0, 3)
}

forall nseg*=3

proc report() { local i
  forall {
    print secname()
    print "3d data"
    for i = 0,n3d()-1 print x3d(i), y3d(i), z3d(i), diam3d(i)
    print "discretized representation"
    for (x,0) print x, x*L, diam(x)
  }
}

{ finitialize() } // ensure geometric specification has been fully executed/updated
  // curly brackets suppress printing of "1"
print "original lengths"
report()
print "-----"
print "after forall L*=10"
forall L*=10
{ finitialize() } // ensure geometric specification has been fully executed/updated
report()
quit()
What would you expect to happen? Does it indeed occur?
When I then initialized and ran the code I got some results that surprised me . . . because I think the activation potential of sodium should always be the same.
You mean you'd expect spike threshold to be unchanged. My guess is that most if not all experimentalists and modelers would have a similar expectation to yours.

But all observations are artefact until proven otherwise. Most surprises are merely revelations that one's intuition was incorrect.
So, I am wondering if something is amiss with my simple scaling method.
Healthy skepticism. One possibility is simply that forall L*=k does _not_ simply stretch sections lengthwise. What did the code I posted above suggest?
From your previous post, I see that nseg might need to be changed for size scaling larger than 10-20%.
Yes. Suggest you do the following:
First, rerun your tests on the original (unstretched) model, but make sure that the spatial grid is sufficiently fine by
forall nseg*=3
then doing another run, and repeating if you see a significant change in any of your measures of model performance (after all, you have no guarantee that the original model's discretization was fine enough for these new tests you are running). Make a note of the number of times you had to increase nseg by a factor of 3. Also note the effect that increasing nseg has on these measures.

Next stretch your model, and run another series of simulations, increasing nseg by a factor of 3 each time and noting what this does to simulation results.

What happened, and what might account for these results?

Next try a much simpler model: an axon comprised of two sections, each 1 um in diameter and at least 300 um long, with nseg = 1 for each. Make one passive, and put hh in the other (be sure to set e_pas to -65 mV). Attach an IClamp to their junction and apply a long depolarizing current. Adjust its amplitude to find the lowest frequency of repetitive spiking (let it run for at least 300 ms to make sure it fires repeatedly), then double the current amplitude so it's spiking at a somewhat higher rate. Finally, execute
forall nseg*=3
and see what happens. Repeat again and again to see how apparent excitability is affected by discretization.

Now what do you think is going on?
Post Reply