[Moose-g3-devel] Comments on GENESIS 3 object priorities

[Dave B. <db...@do...>]

Here is a summary of some comments on the object prioities that I
received directly from other developers.

>From Avrama Blackwell:

The only low priority objects I use are the mmpump.  But I use this with my
chemesis objects, so I won't need it until I re-implement all of chemesis.
Once I'm doing that, mmpump is really easy compared to other objects such
as diffusion.

Besides, I don't plan on re-implementing everything from Chemesis.  I won't
re-implement the Chemesis enzyme or reaction, since that is already in
Moose.  I will probably implement the GHK channel (with important
differences to the genesis GHK), the calcium release objects (with a much
more efficient markov formulation), diffusion (probably as a self-contained
reaction-diffusion object), a sodium-calcium exchanger and I'll throw in
the mmpump.

-----
>From Hugo Cornelis :

The symcompartment can be given a low priority for the following reasons :

- it gives higher accuracy only for cells with compartments of the
   same length (which are unlikely to exist)
- it mixes up the model with how to simulate the model.
- it is easy, for the first transitional versions of moose, to alias
   symcompartment to compartment.

The script_out object can easily be emulated by adding PROCESS actions
to a neutral element.  It is better to have this in a script level
library than in C++ code (more easy to maintain, also nice as an
example).

> gsolve/hsolve - will these be handled transparently in MOOSE?

I will reimplement hsolve in a Moose context, based on an extended
hsolve version of Genesis2.2.  Neurospaces will be used as frontend.
I will do a careful analysis next week of what exactly needs to be
done and will, after discussion with Mike Edwards, report to you and
Jim.

Another suggestion : the monotone project -- unrelated to the CNS
world -- discusses things like these on a mailing list and places
reports on a wiki (e.g. an example todo is in
http://www.venge.net/monotone/wiki/ThingsStatusShouldShow).

Comment by Dave Beeman:

I still consider the symcompartment a high priority, but would like to
hear the opinions of others.  The choice of whether to use symmetric or
asymmetric compartments is part of the model, and not part of the
implementation, as the results will depend on the choice.  The Traub
model uses symmetric compartments, and the results are different when
asymmetric compartments are used.  Most NEURON models that I've seen use
symmetric compartments, and it would look bad to implement them with
asymmetric compartments and not be able to get the same results.  It
might be possible to mimic symcompartments with compartments by hacking
the cell parameter file to split up the compartments in a different way
and messing with the Ra values of the compartments adjacent to the
soma.  I considered doing this with the Traub mode back when the
symcompartment wasn't hsolvable, but it was so ugly that I gave up.
For very large models with many compartments, the differences will be
less, but the choice of how to split up the Ra of a large diameter
soma would still have an effect.

Dave