about those three "spine" methods in hoc

Particularly useful chunks of hoc and/or NMODL code. May be pedestrian or stunningly brilliant, may make you gasp or bring tears to your eyes, but always makes you think "I wish I had written that; I'm sure going to steal it."
Post Reply
figoyouwei
Posts: 41
Joined: Sun Aug 08, 2010 11:09 am

about those three "spine" methods in hoc

Post by figoyouwei » Tue Jan 07, 2014 10:05 pm

Dear,

There are 3 spine methods default in hoc, getSpineArea(), setSpineArea() and spine3d() ?

For example, basically to get spine area, one may

spineArea
access spinehead
for (x) spineArea += area(x)
access spineneck
for (x) spineArea += area(x)

which is the conventional way to get spine area.

So my question is how or when do we use those 3 methods ? are there any example codes or published models that used them ?

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

Re: about those three "spine" methods in hoc

Post by ted » Tue Jan 07, 2014 11:41 pm

I can't recall seeing an instance in which anyone actually used any of those in a published model. Not sure they work properly, would stay away from them.

What they're about: these functions are meant to be used in conjunction with a rarely (if ever) used feature of pt3dadd (read the Programmer's Reference documentation of pt3dadd and note this statement
"The existence of a spine at this point is signaled by a negative value for d."
).

Why aren't these functions used?

For one thing, it turns out that they aren't particularly useful. Their theoretical utility is that they allow a model to contain an accurate representation of the contribution of spine areas to total area of each compartment of a multicompartmental model. However, modelers generally use other methods to take spine area into account (usually just assume a particular spine density per unit of dendritic length or area, and an average area per spine, then either distort the geometry of the dendrite to add the area without affecting DC electrotonic length OR multiply specific membrane capacitance and ion channel densities by a factor that represents the contribution of spines to surface area). For models in which spine function is actually an important issue, one must construct spines from sections (to represent the spine neck and head), and this does not use any of hoc's "spine-related" functions.

Actually using them presupposes that one has morphometric data in which
1. the actual location of attachment of each spine is noted
and
2. spine areas are adequately represented by a mean value

But it turns out that:
1. spine morphologies, hence areas, vary widely
2. the actual site of spine attachment is difficult if not impossible to discern under light microscopy.
3. lots of spines are missed because their images are too fuzzy to be distinguished from each other, and/or the dendritic shaft prevents them from being seen.
4. noting the existence of each spine that can be clearly seen is an extremely tedious task--the person who collects the morphometric data just gets tired and loses track of them. Consequently few morphometric data files contain any annotation regarding spine locations.

I will now stop beating this dead horse.

figoyouwei
Posts: 41
Joined: Sun Aug 08, 2010 11:09 am

Re: about those three "spine" methods in hoc

Post by figoyouwei » Thu Jan 09, 2014 12:15 pm

thank you for beating this.

Post Reply