Re: [Moose-g3-devel] [Neuroml-technology] generic simulator interface (from "neuroml-api status")

[Hugo C. <hug...@gm...>]

Note : posted to genesis-dev and neuroml mailing lists.  Comments below.

On 10/2/06, Mike Schachter <mik...@gm...> wrote:
>  >[Josef]
>
> >Moose (the new back end for genesis) is supposed to be heading in the
> direction
> >of exposing it's API through swig. IMO, Moose is still at a pre-alpha
> stage.
> >It's been very difficult to convince powers that it's difficult, if not
> >impossible, to create a swig interface to what's there. There needs to be
> some
> >core re-architecting to avoid exposing all the plumbing when all you really
> >want is a glass of water from the tap ;-) Instead of focusing on just C++,
> I
>  >think it would make more sense to decide what you want to expose and
> expose it
> >using swig. Then users have a lot more language choices for interacting
> with it.
>

As explained on the genesis-dev mail list some time ago, moose suffers
from mixing up several data layers in the software architecture.  The
core of the problem for running simulations in computational
neuroscience is, I think, that there is no one-to-one mapping between
biological concepts and mathematical equations.  As a consequence of
this, moose forces biological quantities, physics quantities,
numerical quantities and algorithmic quantities to live in the same
big space.  Interfacing to this big space is a nice software
engineering problem, and is not just a matter of data bindings or
script bindings, exactly what you say.  The moose framework partitions
the space with Genesis2 style functional objects such that simulations
can be run, but it does not separate out quantities living in
different domains.  So indeed, I am fully convinced that interfacing
to moose is cumbersome.  On the other hand, it is fair to add that
moose addresses a number of scheduling problems in a nice way.

Josef, It would help the whole community if you could write an outline
or summary of what you think the problem is.  Also, I do not
understand exactly what you mean if you say that moose should be a
library.  If you mean that moose should be split up in different
functional components, then I agree.  If not, I would be interested to
hear what you really mean.

I have just coded a new numerical solver for compartmental models.  It
is called heccer.  It is as fast as hsolve (Genesis2), clean
implementation, and puts a lot of emphasis on interfacing.  It is
currently driven by a scheduler written in perl, but it is
straightforward to link heccer to matlab or neurospaces fi.
Neurospaces is addressing the domain problems outlined above.  The
three tools, heccer, neurospaces and the ssp scheduler, have been
developed separately and their code is nicely isolated.  Heccer as
well as neurospaces are different functional components and come as
separate link libraries, so you can use them in different ways :
isolated for testing, model validation and visualization
(neurospaces), connecting to databases (neurospaces), instantiating
large simulations from binary data (heccer, ssp).  Or, of course using
all together, for network simulations.  Neurospaces and heccer are
core components of Genesis 3 and have been designed based on the
Genesis 3 functional decomposition I recently posted on the
genesis-dev mailing list.

If you are interested in heccer, check the Neurospaces website
(www.neurospaces.org), I will post releases there in a week or two -
three.


Hugo


-- 
                    Hugo Cornelis Ph.D.

                  Research Imaging Center
   University of Texas Health Science Center at San Antonio
                    7703 Floyd Curl Drive
                 San Antonio, TX  78284-6240

                    Phone: 210 567 8112
                      Fax: 210 567 8152