Re: [Moose-g3-devel] GENESIS 3 object and command priorities (Part 1)

[Upinder S. B. <bh...@nc...>]

Dear all,
   Dave's list makes a lot of sense.

Here I'll indicate
a) what I'm working on
b) what I'm likely to work on
c) how hard/easy it should be to implement desired objects.

I'll also add a few comments into Dave's list as I go along.

a) What I'm working on.
- Solver architecture. First solvers will be for biochemical kinetics.
- Moose preprocessor. This is the standalone program to convert the
high-level definition of a MOOSE class into grungy C++ code. It is alread=
y
much improved from the version in MOOSE 0.06. Once I figure out how to pu=
t
together another release, I'll upload it.
- Figuring out how to deal with Subversion, SourceForge, and the like.

b) What I'm likely to work on
- Interface for a partially implemented neuronal compartmental solver,
intended to replace the hsolver. Rajnish Ranjan did the initial pass on
this, but did not complete the Calcium handling stuff.
- Parallelization architecture.
- Occasional documentation, especially if prodded.

c) Comments on objects and how hard/easy it is to implement them.

> What is MOOSE HHgate?
Equivalent to the vdep_gate. The tabchannel is reimplemented a lot like
the old vdep_channel.

> -----------------------------------------------------------------------=
---
> High Priority
>
> asc_file
> closely elated objects that aren't high priority, but should be
> implemnented at the same time as asc_file: par_asc_file    res_asc_file
all should be easy

>
> Mg_block leakage    randomspike
Easy

> symcompartment
Medium

>
> voltage clamp circuitry: PID   RC    diffamp

Easy
> other commonly used device objects: efield
Hard

> pulsegen
Easy

>
> -----------------------------------------------------------------------=
---
> Medium Priority
>
> script_out tab2Dchannel   table2D    facsynchan    hebbsynchan
All moderately hard.

>
> Other device objects:
> autocorr    calculator   crosscorr      event_tofile    freq_monitor
> funcgen
> interspike  peristim     spikehistory   timetable
All easy

>
> File I/O objects - need to redo in context of NETCDF replacement:
> disk_in   disk_out    par_disk_out
Easy but may be messy, depending on replacement code.

>
> -----------------------------------------------------------------------=
---
> Low Priority   (Note that this does not necessarily mean "unimportant"
> or "unlikely to be implemented".   But, implemenation will probably wai=
t
> until someone needs them enough to volunteer to implement them, or
> other higher priority items are done first.)
>
> Leech library objects: SynE_object    SynG_object    SynS_object
Dunno.

>
> Kpores   Napores  (These are specialized markov channels that should
> be reimplemented in a more efficient and general manner.)
Should redo as proper Markovian channels with stochastic options. Hard.

>
> izcell
Dunno
>
> rarely used device objects:
> playback    sigmoid
Dunno

>
> Misc olflib objects:
> ddsyn    receptor    receptor2
Medium

>
> hh_channel (should be considered obsolete, but is widely used.  Impleme=
nt
> as a special case of tabchannel, or force users to change to tabchannel=
s?)
Subclass off tabchannel. Messy but not hard.

>
> tabgate vdep_channel vdep_gate (Widely used, although can generally be
>     replaced with tabchannel or tab2Dchannel.)
Actually the current tabchannel is implemented like this, so this should
be relatively easy.

>
> NOTE:  The concen and param libraries are not really low priority, but
> will take a lot of work.  Unless someone volunteers to implement these,
> they will have to wait until the other pieces of GENESIS 3 are in place=
.
>
> Concen library objects
> concpool    dif2buffer    difbuffer    fura2    ghk    difshell
> fixbuffer
> hillpump    mmpump        tabcurrent   taupump
Mostly easy.


>
> Parameter search objects
> paramtableBF    paramtableCG    paramtableGA    paramtableSA
> paramtableSS
> (paramtableSA is the most commonly used)
Dunno.

>
> -----------------------------------------------------------------------=
---
> "Not sure" - these may be implemented in MOOSE under different names,
> implemented implicitly without need for a class, or not needed, due
> to differences between MOOSE and GENESIS 2 -- Comments are requested!
>
> gsolve/hsolve - will these be handled transparently in MOOSE?
Very hard. I'm working on their API, and then volunteers should apply.

>
> text (Used only in kkit - breaks the separation between Xodus and
> non-Xodus objects)
Get rid of it.