dendrograms

[ybanitt]

[/b]Does anyone have a code to display a dendrogram of a detailed model?

Thanks
Yoav

[ted]

You are welcome to try dendrogram.hoc, which is contained in
http://www.neuron.yale.edu/ftp/ted/neur ... rogram.zip
Unzip it, then execute init.hoc to see it work (the "test" cell is
the amputated pyramidal neuron that is part of NEURON's
demo program). Be sure to read the comments at the start
of dendrogram.hoc

--Ted

[ted]

One caveat: that code assumes that all connections are to the 0 or 1 ends of sections,
i.e. a child section is never attached to an internal location on its parent.

--Ted

[eacheon]

One caveat: that code assumes that all connections are to the 0 or 1 ends of sections,
i.e. a child section is never attached to an internal location on its parent.

--Ted

I was trying to add secnames beside the lines but have problem to add any text at a particular (x,y) position on a graph. It seems need the glyph class but glyph.label is not implemented yet.

Is there a way to add text annotations at perticular (x,y) position on a plot?

thanks,
eacheon

[ted]

The Graph class has a label() method, but the xy values are not "model coordinates"--
they are "relative position within the displayed window" i.e. they range from 0 to 1 where
0,0 and 1,1 are the LL and UR corners of the window itself, respectively. You could still
used it; just make up a pair of functions fx() and fy() that map model coords to relative
position.

[eacheon]

The Graph class has a label() method, but the xy values are not "model coordinates"--
they are "relative position within the displayed window" i.e. they range from 0 to 1 where
0,0 and 1,1 are the LL and UR corners of the window itself, respectively. You could still
used it; just make up a pair of functions fx() and fy() that map model coords to relative
position.

Thanks, I find if I issue a g.relative() or g.fixed() first and then the .label() method work with model coords...

[ted]

That's much better than what I suggested. Today I learned something new and useful--
thanks!

[Brad]

I run into a recursion depth issue using dendrogram.hoc on one of our morphologies ("section stack overflow" warning pointing to the line of add_children() which calls itself). I played around with the -NSTACK and -NFRAME options, but the error still occurs at the same point in the recursion.

Is there any way to verify that those command line options are successfully being passed and used?

Alternatively, is there another way to increase the stack size to alleviate the problem?

Outside of that, it seems I'll need to write a non-recursive version of add_children(). (It's a pity; your recursive version was an elegant solution by comparison.)

[ted]

Is there any way to verify that those command line options are successfully being passed and used?

Sure. Make a toy recursive function that, on every call, increments a variable and prints its
value. Note when it fails.

[Brad]

Sometimes, you look at something for 15 minutes and lose sight of the big picture. Good suggestion, Ted. The test I made is

Code: Select all

proc recur() {
	print $1+1
	recur($1+1)
}

recur(0)

Changing -NSTACK and -NFRAME gives

Code: Select all

-NSTACK	-NFRAME	# recursions
1000		100		99
1000		200		199
1000		300		299
1000		400		399
1000		500		499
1000		1000		499
1000		2000		499
2000		1000		999
2000		1500		999
10000		1500		1499
10000		5000		4999
10000		5001		4999
10002		5001		5000

It appears that, for this procedure, the number of allowed recursions is min(NFRAME-1,NSTACK/2-1).

However, when I look at the output of topology() for the morphology that I am attempting to use, there are only a total of 150 sections. Even with generous -NSTACK and -NFRAME settings, I still get the "nrniv: section stack overflow" and a "nrniv: Segmentation violation".

In the end, Dr. Hines solved the issue. In the add_children() procedure of dendrogram.hoc supplied by Ted, the whole FOR loop was perfromed with $o1.sr.child[ii] as the currenly-accessed section. This is uneccessary as it is only needed while creating the BranchRef object ("tobj"). It caused a problem because the recursive call of the function to itself was in that block. The lightly-modified procedure (using default -NFRAME and -NSTACK values), as it works for me, is

Code: Select all

// recursively add all children of the BranchRef argument
proc add_children() { local ii, x0, y0, dy  localobj tobj
	x0 = $2
	y0 = $&3
	dy = $4
  	if ($o1.sr.nchild > 0) {
		for ii = 0,$o1.sr.nchild-1 {
	    $o1.sr.child[ii] {tobj = new BranchRef()}
			tobj.setorigin(x0, y0)
			tobj.parbr = $o1  // so we can discover y coord of parent branch
			add_children(tobj, x0+tobj.sr.sec.L, &y0, dy)
			cell_brefs.append(tobj)
			cell_brefs.object(cell_brefs.count()-1).i = cell_brefs.count()-1
			if (ii < $o1.sr.nchild-1) {y0 += dy} // prepare for next branch
		}
	}
	$&3 = y0
}

[ted]

In the end, Dr. Hines solved the issue. In the add_children() procedure of dendrogram.hoc supplied by Ted, the whole FOR loop was perfromed with $o1.sr.child[ii] as the currenly-accessed section. This is uneccessary as it is only needed while creating the BranchRef object ("tobj"). It caused a problem because

the section stack is only 20 deep, which I probably read or heard sometime or other, but
then forgot entirely. The syntax used in the original version of add_children() was

Code: Select all

secname {
  statement(s)
}

which pushes secname onto the section stack before executing the statement(s) inside
the paired curly brackets. Thus each recursive call added yet another section to the
stack, and after there were 20 on the stack, the next call produced section stack
overflow. Neither NFRAME nor NSTACK does anything to the maximum depth of the
section stack, so the fix must be to revise the code as Brad indicates.

This revision has now been incorporated into the dendrogram.zip files (see my above
note from June 4, 2006 for the link).