www.neuron.yale.edu

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

Thanks
Yoav

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

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

ted wrote: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

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.

ted wrote: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...

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

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.)

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.

Sometimes, you look at something for 15 minutes and lose sight of the big picture. Good suggestion, Ted. The test I made is
Changing -NSTACK and -NFRAME gives
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

Brad wrote: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 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).