Problems instantiating templates

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
stil
Posts: 28
Joined: Thu Jul 01, 2010 8:47 am
Location: Mulhouse - France

Problems instantiating templates

Post by stil »

Hello,

I am building a template of CA1 neuron, on the basis of the model of Jarsky. I have a template of Synapse that i would like to instantiate on this neuron, so that i can build an encapsulated and "clean" code.

My spine template :

Code: Select all

begintemplate SPINE

public PSD, CYTOSOL, NECK
create PSD
create CYTOSOL
create NECK
// section list
public spine
objref spine

//new spine(\ // example of call
//	0.2, // LSPINE=um \
//	0.2 , // diamSPINE=um \
//	0.5, // LNECK=um \
//	0.1, // diamNECK=um \
//	200, // Ra = ohm.cm // cytoplasmic resistivity : from Jarsky_gating_init.hoc \
//	0.75, // Cm = uF.cm-2 - specific membrane capacitance : from Jarsky_gating_init.hoc\
//	-65, // e_pas = mV - leak potential \
//	40e3, // Rm = mV - specific membrane resistivity : from Jarsky_gating_init.hoc \

proc init(){
	PSD{
		L = 0.1*$1 // thivkness of PSD = 10% of total spine length ?
		diam = $2
		Ra = $5 
		Cm = $6
		nseg = 1 // lambda_f(100)
		insert pas 
		e_pas=$7
		g_pas=1.0/$8
	}

	CYTOSOL{
		L = 0.9*$1
		diam = $2
		Ra = $5 
		Cm = $6
		nseg = 9 // lambda_f(100)
		insert pas 
		e_pas=$7
		g_pas=1.0/$8
	}

	NECK{
		L = $3
		diam = $4
		nseg = 5
		Ra = $5 
		Cm = $6
		nseg = 9 // lambda_f(100)
		insert pas 
		e_pas=$7
		g_pas=1.0/$8
	}

	connect PSD(1), CYTOSOL(0)
	connect CYTOSOL(1), NECK(0)

	spine = new SectionList()
	PSD spine.append 
	CYTOSOL spine.append 
	NECK spine.append
}

endtemplate SPINE
Here is my code for the CA1 template, that i simplified :

Code: Select all

// ALE - 2012.07.11 - template de neurone CA1 from Jarsky

load_file("SPINE_template.hoc")

begintemplate CA1

// All Dendrites
public dendA5_0, dendA5_00
create dendA5_0, dendA5_00

//spines
public spineA5_0, spineA5_00
objref spineA5_0, spineA5_00

// section lists
public all_apicals, all
objref all_apicals, all

// parameters 
public global_ra		// internal resistivity in ohm-cm
public Cm				// specific membrane capacitance in uF/cm^2
public Rm				// specific membrane resistivity in ohm-cm^2

public Vleak			// leak reversal -66 in Cs+

proc init(){
	// loads morphology
	xopen("CA1_morpho.nrn")
	// definition of lists of sections
	initlists()
	// initialize biophysics of the neuron
	initchannels()
	// populate dendrites with spines
	initspines(all_apicals, 0.2)
}

proc initchannels(){
	// parameters
	global_ra=200.00 	/* internal resistivity in ohm-cm */
	Cm=0.75			/* specific membrane capacitance in uF/cm^2 */
	Rm=40000		/* specific membrane resistivity in ohm-cm^2 */ 
	Vleak=-70		/* leak reversal -66 in Cs+*/

	// init all sections
	forsec all {
		insert pas
		g_pas=1/(Rm)
		Ra=global_ra
		e_pas=Vleak 
		insert vmax
	}

print "CA1 properties and channels are initialized"

}

proc initlists(){
	all_apicals = new SectionList()
	dendA5_0 all_apicals.subtree()

	// all sections : forsec all is faster than forall - it is better to build this section list once at init
	all = new SectionList()
	forall all.append
}

proc initspines(){ localobj seclist, positions, strobj, tmplist, S
	seclist = $o1
	density = $2

	forsec seclist {
		positions = new Vector()
		Nspines = cpt_positions(positions, L, density)
		print Nspines

		tmplist = new List()
		for i=0, positions.size()-1 {
			S = new SPINE(2, 2, 0.5,0.1, 200, 0.75, -65, 40e3)
			tmplist.append(S)
			secname() connect S.NECK(1), positions.x[i]
		}
		
		strobj = new StringFunctions()
		strdef tmpstr, spineID
		strobj.tail(secname(), "dend", tmpstr)
		sprint(spineID,"spine%s", tmpstr)
		sprint(tmpstr, "%s = new List()", spineID)

		for i=0, tmplist.count - 1 {
		sprint(tmpstr,"%s.append(tmplist.object(%d))", spineID, i)
		print tmpstr
		execute(tmpstr)
		}

//		execute(tmpstr) // error arising here
	}
}

func cpt_positions(){
	length = $2
	density = $3
	NSPINES = int(length*density)
	if (NSPINES != 0){
		dinter = 1.0/NSPINES
		middle = 0.5
		if(NSPINES%2==0) { // NSYN pair
			// en aval
			current_pos = middle + dinter/2.0
			$o1.append(current_pos)
			while (current_pos < (1.0-dinter)){
				current_pos+=dinter
				$o1.append(current_pos)
			}
			// en amont
			current_pos = middle - dinter/2.0
			$o1.append(current_pos)
			while (current_pos > dinter){
				current_pos-=dinter
				$o1.append(current_pos)
			}
		}else{  // NSYN impair
			current_pos = middle
			$o1.append(current_pos)
			// en aval 
			while (current_pos < (1.0-dinter)){
				current_pos+=dinter
				$o1.append(current_pos)
			}
			// en amont
			current_pos = middle
			while (current_pos > dinter){
				current_pos-=dinter
				$o1.append(current_pos)
			}
		}
	}
	$o1.sort()
	return $o1.size()
}

endtemplate CA1
Finally, here is my master hoc code :

Code: Select all

// ALE - 10/07/2012 
// loads the CA1 template several times and place it in different points of space

xopen("CA1_template.hoc")

objref N1
N1 = new CA1()

objref s
s = new Shape()
s.view(-50,-150,500,550,800,0,840,1050) //view(mleft, mbottom, mwidth, height, sleft, stop,swidth, sheight)
s.exec_menu("Show Diam")
s.exec_menu("Zoom in/out")
//s.exec_menu("3D Rotate")
s.exec_menu("View Axis")

//N1.dendA5_0 s.color(2)
forsec N1.all_apicals s.color(3)

I would like to find a good way to instantiate spines from SPINE_template so that i could retrieve then section per section i.e. being able to call them with something like CA1.dendAX_Y.spine[j]

1> I doubt that i can attach an object spine to a section like dendAX_Y, but i would like you to confirm this. This would indeed make the 'dot' notation impossible, am i right

I tried to tackle the problem another way. Creating public members spineAX_Y, attached to each section dendAX_Y, i may be able to retrieve each spine, using stringFunctions (split,tail,...), sprintf and execute(). The problem using the code above comes with the execute statement, that returns me a syntax hoc error :

Code: Select all

NEURON: syntax error
 in test.hoc near line 7
 {spineA5_0.append(tmplist.object(0))}
           ^
        CA1[0].execute("spineA5_0.append(tmplist.object(0))")
      CA1[0].initspines(SectionList[0], 0.2)
    CA1[0].init()
  xopen("test.hoc")
[/color]

I am pretty sure that that can be done in an effecient way, but i admit that i am locked with that problems, as i tried several things without success. I am not very satisfied with the solution using string manipulations, so i was hoping you could suggest me language elements that i might have misunderstood.

Thanks for your help and suggestions.
Arnaud.
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problems instantiating templates

Post by ted »

First, some practical considerations:

It's best to connect the child section's 0 end to the parent's 1 end.

What is the spatial discretization strategy for the pyramidal cell, and where is it executed? Unless this is done _before_ spine attachment, all spines will end up at neurite midpoints.

It can be a trap to build too much detail into a template, because this complicates development and debugging. Furthermore, it doesn't scale well--today you're modeling CA1 pyramidal cells, but tomorrow you may want to model spiny stellate cells. Do you really want to have to embed initspines, cpt_positions, etc. into that cell class's template? When you want to change the algorithm that governs spine positions, or (more likely) when you find a bug in an algorithm you're currently using, do you really want to have to propagate revisions across all the different cell class templates that have this code embedded? It would simplify program development and debugging if these "helper" procs and their associated variables are factored out of the template. Keep the template contents to the minimum required to set up cell topology, geometry, and biophysics. If you want a cell instance to "carry" its own Spine instances, that can be done easily by just adding two public objrefs to the template--specifically
* a SectionList (maybe called "spiny") whose elements are those neurites that have spines; these elements can be appended by code that is executed inside the template or outside of the template--at this moment I'm not sure which would be the best place to do this.
* a List (maybe called list_of_spinelists) that starts out empty but eventually will contain Lists of objrefs to Spine instances. For every element (section) in spiny there will be a corresponding List in list_of_spinelists. Each of these Lists will contain objrefs that point to the Spines that have been attached to the corresponding section in "spiny." Creating each Spine instance and attaching it to the desired location on the proper section can be done by code that lies outside the cell class template. This enables reuse of the same "spine placement code" by every cell class that has spiny neurites.

This change in strategy may allow you to write code that doesn't have to construct and execute strings.

An aside for others who may read this: an advantage of using Lists is that they allow writing code that scales nicely--you never have to remember how many elements are in a List (just use List.count()).

func cpt_positions() is too clever for me. Given a particular section length and spine density, what is it supposed to do?
stil
Posts: 28
Joined: Thu Jul 01, 2010 8:47 am
Location: Mulhouse - France

Re: Problems instantiating templates

Post by stil »

Thank you for the answer, i will work on this.
Embedding objects in other objects seemed a natural way to mee, but i might be wrong.
It's best to connect the child section's 0 end to the parent's 1 end.
Ok, that has advantages such as for subtree() use indeed, but does that have an effect on computational efficiency ?
What is the spatial discretization strategy for the pyramidal cell, and where is it executed? Unless this is done _before_ spine attachment, all spines will end up at neurite midpoints.
Ok, i forgott to join the CA1_morpho.nrn content on my first post. The file is xopened at the beginning of the init() procedure in the CA1_template. It is actually defined before spine attachment, because i want to have the choice to build spines or not.

Code: Select all

//////////////////////////////////////////////////
//------------------DENDRITES-------------------//
//////////////////////////////////////////////////



//{create dendA5_0}
//{somaA connect dendA5_0(0), 0.000001}
{access dendA5_0}
{nseg = 2}
{pt3dclear()}
{pt3dadd(0, 10.20, 0.00, 4.0)}
{pt3dadd(0, 13.43, 0.00, 4.0)}
{pt3dadd(0, 16.17, 0.00, 3.8)}
{pt3dadd(-0.48, 19.90, 0.19, 3.8)}
{pt3dadd(0.00, 24.13, 0.20, 3.8)}
{pt3dadd(0.00, 27.36, 0.20, 3.8)}
{pt3dadd(0.00, 31.59, 0.20, 3.8)}
{pt3dadd(0.00, 34.83, 0.71, 3.8)}
{pt3dadd(-0.24, 37.56, 0.71, 3.8)}

//{create dendA5_00}
{dendA5_0 connect dendA5_00(0), 1}
{access dendA5_00}
{nseg = 20}
{pt3dclear()}
{pt3dadd(-0.24, 37.56, 0.71, 0.96)}
{pt3dadd(3.14, 37.81, 0.04, 0.96)}
{pt3dadd(4.11, 42.54, 0.04, 0.96)}
{pt3dadd(5.31, 45.52, 0.04, 0.96)}
{pt3dadd(7.00, 47.76, 0.04, 0.96)}
{pt3dadd(7.49, 48.01, 0.04, 0.96)}
{pt3dadd(13.53, 51.49, -5.41, 0.54)}
{pt3dadd(14.73, 52.99, -5.44, 0.54)}
{pt3dadd(17.63, 52.99, -5.44, 0.54)}
{pt3dadd(18.12, 52.74, -5.44, 0.54)}
{pt3dadd(20.77, 51.99, -5.44, 0.54)}
{pt3dadd(21.01, 51.99, -5.44, 0.54)}
{pt3dadd(22.95, 52.49, -5.44, 0.54)}
{pt3dadd(23.43, 52.49, -5.44, 0.54)}
{pt3dadd(25.85, 51.99, -5.44, 0.54)}
{pt3dadd(26.09, 51.99, -5.44, 0.54)}
{pt3dadd(30.92, 49.01, -2.79, 0.54)}
{pt3dadd(33.82, 49.50, -2.79, 0.54)}
{pt3dadd(35.99, 50.25, -2.79, 0.54)}
{pt3dadd(36.23, 50.25, -2.79, 0.54)}
{pt3dadd(37.92, 51.00, -2.79, 0.54)}
{pt3dadd(38.41, 51.00, -2.79, 0.54)}
{pt3dadd(40.82, 51.49, -2.79, 0.54)}
{pt3dadd(41.55, 51.49, -2.79, 0.54)}
{pt3dadd(43.48, 51.24, -2.79, 0.54)}
{pt3dadd(43.96, 51.24, -2.79, 0.54)}
{pt3dadd(45.41, 53.73, -2.79, 0.54)}
{pt3dadd(45.89, 53.98, -2.79, 0.54)}
{pt3dadd(47.10, 53.98, -2.79, 0.54)}
{pt3dadd(47.83, 53.73, -2.79, 0.54)}
{pt3dadd(48.79, 52.49, -2.79, 0.54)}
{pt3dadd(49.76, 52.24, -2.79, 0.54)}
{pt3dadd(51.93, 52.24, -2.79, 0.54)}
{pt3dadd(54.35, 52.74, -2.82, 0.54)}
{pt3dadd(56.28, 53.73, 2.31, 0.43)}
{pt3dadd(57.00, 55.72, 2.33, 0.43)}
{pt3dadd(57.25, 55.72, 2.33, 0.43)}
{pt3dadd(58.45, 57.46, 2.35, 0.43)}
{pt3dadd(60.87, 56.72, 2.37, 0.43)}
{pt3dadd(61.11, 56.72, 2.37, 0.43)}
{pt3dadd(61.59, 56.47, 2.37, 0.43)}
{pt3dadd(61.84, 55.22, 2.41, 0.43)}
{pt3dadd(61.84, 55.22, 2.42, 0.43)}
{pt3dadd(62.80, 54.48, 2.71, 0.43)}
{pt3dadd(63.04, 54.48, 2.72, 0.43)}
{pt3dadd(64.01, 54.73, 2.77, 0.43)}
{pt3dadd(64.25, 54.73, 2.86, 0.43)}
{pt3dadd(65.70, 55.22, 3.86, 0.43)}
{pt3dadd(66.18, 55.47, 4.01, 0.43)}
{pt3dadd(68.12, 56.22, 5.04, 0.43)}
{pt3dadd(68.12, 56.22, 5.08, 0.43)}
{pt3dadd(69.32, 56.72, 5.08, 0.43)}
{pt3dadd(69.57, 56.72, 5.08, 0.43)}
{pt3dadd(71.01, 56.97, 5.14, 0.43)}
{pt3dadd(71.01, 56.97, 5.18, 0.43)}
{pt3dadd(72.46, 55.72, 5.37, 0.43)}
{pt3dadd(72.46, 55.72, 5.43, 0.43)}
{pt3dadd(75.36, 51.49, 7.57, 0.43)}
{pt3dadd(75.60, 51.49, 7.58, 0.43)}
{pt3dadd(78.02, 51.99, 7.61, 0.43)}
{pt3dadd(78.02, 52.24, 7.63, 0.43)}
{pt3dadd(82.37, 49.75, 11.60, 0.43)}
{pt3dadd(84.54, 48.26, 12.09, 0.43)}
{pt3dadd(84.54, 48.26, 12.20, 0.43)}
{pt3dadd(88.16, 46.27, 12.59, 0.43)}
{pt3dadd(88.16, 46.27, 12.64, 0.43)}
{pt3dadd(90.82, 45.52, 12.73, 0.43)}
{pt3dadd(91.06, 45.52, 12.74, 0.43)}
{pt3dadd(94.93, 43.28, 15.93, 0.43)}
{pt3dadd(97.10, 44.78, 16.15, 0.43)}
{pt3dadd(98.55, 44.53, 16.15, 0.39)}
{pt3dadd(98.79, 44.03, 16.15, 0.39)}
{pt3dadd(99.28, 43.03, 16.14, 0.39)}
{pt3dadd(98.55, 42.79, 16.14, 0.39)}
{pt3dadd(98.31, 41.79, 16.14, 0.39)}
{pt3dadd(96.86, 40.05, 16.14, 0.39)}
{pt3dadd(95.17, 39.30, 18.64, 0.39)}
{pt3dadd(95.17, 39.30, 19.32, 0.39)}
{pt3dadd(94.69, 37.81, 20.48, 0.39)}
{pt3dadd(94.69, 37.56, 20.68, 0.39)}
{pt3dadd(94.69, 36.57, 20.78, 0.39)}
{pt3dadd(95.17, 35.82, 20.81, 0.39)}
{pt3dadd(95.41, 35.32, 20.81, 0.39)}
{pt3dadd(96.38, 35.07, 20.82, 0.39)}
{pt3dadd(96.86, 35.07, 20.83, 0.39)}
{pt3dadd(97.10, 35.07, 20.85, 0.39)}
{pt3dadd(97.58, 34.33, 20.87, 0.39)}
Do you really want to have to embed initspines, cpt_positions, etc. into that cell class's template?
I am not sure about this. I only know that i want to be able to instantiate multilple CA1 objects, with or without spines. I understand your points, and will try to put these functions in an outide code.
* a SectionList (maybe called "spiny") whose elements are those neurites that have spines; these elements can be appended by code that is executed inside the template or outside of the template--at this moment I'm not sure which would be the best place to do this.
* a List (maybe called list_of_spinelists) that starts out empty but eventually will contain Lists of objrefs to Spine instances. For every element (section) in spiny there will be a corresponding List in list_of_spinelists. Each of these Lists will contain objrefs that point to the Spines that have been attached to the corresponding section in "spiny." Creating each Spine instance and attaching it to the desired location on the proper section can be done by code that lies outside the cell class template. This enables reuse of the same "spine placement code" by every cell class that has spiny neurites.
Ok, thanks for the detailed explanations. I did not realize that i could build lists of lists of objrefs... List is a nice feature indeed.
func cpt_positions() is too clever for me. Given a particular section length and spine density, what is it supposed to do?
This function fills in a vector of positions, given in argument, where spines should be placed, for each neurite. It starts building positions from the middle, and, either the number of spines is odd or even , computes positions evenly along the neurite. Not that clever, actually.
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problems instantiating templates

Post by ted »

Embedding objects in other objects seemed a natural way
It does, but this is not the only case in which theory is more attractive than it is useful.

Code: Select all

connect child(0), parent(1) // for all parents except the root section
// it's ok to attach some children to the root section's 0 end
produces a tree in which traversing from 0 to 1 means moving away from the root of the tree. This makes it easier to write and understand code that iterates over locations. Computational efficiency is unaffected, but it can save programmer time which is actually more important.

My guess is the morphology came from NeuroMorpho? In your code excerpt, nseg is even. Was this your choice, or did that come with the morphology?

NEURON's discretization strategy uses the central difference approximation to the 2nd derivative in space. Consequently a section's internal nodes (the points at which NEURON integrates the discretized cable equation) are located at (0.5+i)/nseg where i=0..nseg-1. These and the nodes at 0 and 1 are locations on the parent to which a child section may be attached. Attempting to attach a child section to a point that lies between 0 and 1 will result in the child section being connected to the nearest internal node.

If nseg is even, there will NOT be a node at 0.5. This has two important consequences.

First, the "shortcut form" for referencing a range variable (that is, without specifying the value of range), e.g.
sectionname.v
or
sectionname statement involving v
will not access that variable at 0.5 (the section midpoint). Instead it will access the range variable at the node to either side of the midpoint, and the choice will be governed by roundoff error, not the programmer.

Likewise, attempting to attach a child section to 0.5 on the parent will result in the child being attached to the node to either side of 0.5, and again the choice will be governed by roundoff error, not the programmer.


The only restriction on the elements of a List is that they must be objrefs.
[cpt_positions()] fills in a vector of positions, given in argument, where spines should be placed, for each neurite. It starts building positions from the middle, and, either the number of spines is odd or even , computes positions evenly along the neurite.
I think that could be done with something like this:

Code: Select all

// call with the affected section on the top of the section stack
// $1 is number of spines to be placed
// returns a List whose elements are the spine instances
objfunc placespines() { local i  localobj tobj
  tobj = new List()
  for i=0,$1-1 {
    tobj.append( new Spine((i+0.5)/$1) )
  }
  return tobj
}

forsec spiny list_of_spinelists.append(placespines(int(L*spinedensity)))

// sections that get no spines have a corresponding spinelist that is empty, i.e. has count == 0
I imagine the above discussion of internal nodes is giving you some concerns about your spine placement strategy--if number of spines is < nseg, they won't be evenly spaced, and if > nseg, then one or more internal nodes will get > 1 spine. If it is absolutely critical for spines to be evenly spaced along a section, nseg must equal int(L*spinedensity). But in a real cell, all neurites have "natural" lengths--not numerically nice ones that a programmer might choose--so there is no guarantee that the spacing along one section will be the same as the spacing along any other section.
stil
Posts: 28
Joined: Thu Jul 01, 2010 8:47 am
Location: Mulhouse - France

Re: Problems instantiating templates

Post by stil »

I took the model from (Golding et al. 2001) as it was. I only extracted pieces of the neuron for illustration purposes, and did not modify nseg. In the whole model, branches contain odd and even numbers of segments. The functional considerations about nseg that you pinpointed here did not seem to be important for the original authors.

I believe i can modify nseg for each branch, while i determine the positions of the spines. I was more or less aware of these aspects about the calculation nodes, and i guess that i cannot specify where the nodes will be placed, in order to obtain one spine per segment. A non-uniform 'mesh size' would not be good for calculation, as far as i know.

Moreover, i was thinking that having one segment per spine was not absolutely critical :
* if nspines > nseg, i will have several spines per segment, which will see more than one afferent sources of current. I do not see that as a problem, as long as i do not want to observe what is happening between those spines.
* if nspines < nseg, spines won't be evenly spaced. As you mention, real dendrites are not uniformly populated with spines, so i have no problem with a little bias in the model, for that aspect at least.

I understand i should take care about having a reasonnable number of segments, according to the number of spines. But i think the 'd_lambda' rule is a more important criterium for the choice of nseg. wrong ?

Thanks for the placespine() idea, this is cleverer, actually :)
Last edited by stil on Mon Jul 23, 2012 3:53 am, edited 1 time in total.
stil
Posts: 28
Joined: Thu Jul 01, 2010 8:47 am
Location: Mulhouse - France

Re: Problems instantiating templates

Post by stil »

By the way, i managed to put spines, using an external code as you proposed :

Code: Select all

{xopen("CA1_template.hoc")}
{xopen("create_spines.hoc")}

objref N1
N1 = new CA1()
initspines(N1,N1.Radiatum_thin, 3.15) // where Radiatum_thin is a sectionlist 
and in "create_spines.hoc" :

Code: Select all

proc initspines(){ local i localobj neuron, seclist, positions, tmplist, tmpspine
	neuron = $o1
	seclist = $o2
	density = $3

	forsec seclist {
		secname() neuron.spiny.append() // will add a reference to the sections that are populated with spines
		positions = new Vector()
		Nspines = cpt_positions(positions, L, density)

		tmplist = new List()
		for i=0, positions.size()-1 {
//			print positions.size(), positions.x[i]
			tmpspine = new SPINE(0.2, 0.2, 0.5,0.1, 200, 0.75, -65, 40e3)
			secname() connect tmpspine.NECK(0), positions.x[i]
			tmplist.append(tmpspine)
		}
		neuron.list_of_spinelists.append(tmplist)
	}

}
From this, i can access the different spines, as in :

Code: Select all

i=0
forsec N1.spiny {
    for j=0, N1.list_of_spinelists.o(i).count()-1 {
        forsec N1.list_of_spinelists.o(i).o(j).spine{
	    {s.color(1)}
	}
    }
    i+=1
}
It is not that easy though, i examine other solutions.
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problems instantiating templates

Post by ted »

A non-uniform 'mesh size' would not be good for calculation, as far as i know.
In any model based on quantitative morphometric data from real cells, the spatial grid will necessarily differ from neurite to neurite, with few exceptions, and in many cases the difference will be quite large.
Moreover, i was thinking that having one segment per spine was not absolutely critical
True.
As you insinuate
This verb carries a pejorative connotation that makes me think of Iago in Othello. "Imply" is much more neutral.
i think the 'd_lambda' rule is a more important criterium for the choice of nseg.
Yes, a rational strategy for discretization is the way to go. And you can always verify the adequacy of your discretization by comparing critical simulation results obtained with two different spatial resolutions and demonstrating that results are qualitatively the same. To do this properly, the grid must be specified _before_ spines are attached (also, if channel densities vary along any section, the grid should be specified before the channel density is set up).
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problems instantiating templates

Post by ted »

stil wrote:i can access the different spines, as in :

Code: Select all

i=0
forsec N1.spiny {
    for j=0, N1.list_of_spinelists.o(i).count()-1 {
        forsec N1.list_of_spinelists.o(i).o(j).spine{
	    {s.color(1)}
	}
    }
    i+=1
}
If you just want to iterate over all spines attached to N1, it is only necessary to iterate over that N1's list_of_spinelists.

Code: Select all

    for j=0, N1.list_of_spinelists.o(i).count()-1 {
 . . . statements that involve a spinelist . . .
    }
stil
Posts: 28
Joined: Thu Jul 01, 2010 8:47 am
Location: Mulhouse - France

Re: Problems instantiating templates

Post by stil »

This verb carries a pejorative connotation that makes me think of Iago in Othello. "Imply" is much more neutral.
I apologize, i was not aware of that connotation. I am not such a villain!

Many thanks for the explanations, i am now ready to go further.
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Problems instantiating templates

Post by ted »

The "Online Etymology Dictionary" has an interesting entry about the origin and connotations of "insinuate"--http://www.etymonline.com/index.php?term=insinuate
Post Reply