From GENESIS to MOOSE: A User's Guide.

1. Introduction

Who should read this guide:
User's and developers of GENESIS who are upgrading to MOOSE.

Who does not need to read this guide:
People coming into MOOSE from scratch.

MOOSE is the rewritten core code for GENESIS. It has tried to remain true to what I see as the core philosophy of GENESIS model development. Further, it seeks to be backward compatible to a very large extent. The extent is partially determined by our time, by user needs, and by the fact that there really are better ways to do things in MOOSE than in GENESIS. The idea is to make it simple enough to take existing big models, hopefully do rather minimal fixing up to get it to work in MOOSE, and then proceed secure in the knowledge that you have a more modern and powerful basis for your next 20 years of modeling.

1.1. Why MOOSE?

MOOSE is a next generation simulator with backward compatibility with GENESIS. GENESIS did many things right, which is why I and many other people still use it. MOOSE was written to keep those good things, and do the rest better too. GENESIS also accumulated cruft over 20 years. Many of these random hacks and inelegant tricks in its code were my own doing, so mea culpa. But somewhere in there are also a lot of good ideas and practical experience of what a comprehensive simulator needs.

Also, many of the uglier hacks are seeds of good ideas.

1.2. Status

This is a continuing process. As of the beta release of January 2008, this is where things stand from a user's viewpoint:

• Script language interface works but lacks a few commands.
• Many models of kinetic simulations can be read in from kkit dump files
• Nine different numerical methods available for kkit models through solvers.
• Cellreader works for simple models
  
• Many regression tests of a range of models that run identically on MOOSE and GENESIS
  
• Most kinetic and simple biophysics objects implemented.
  
• No graphics
• Rudimentary TTY
• Parallel stuff under heavy development
• Ported to Mac, many flavors of Linux, Solaris. Windows compilation in progress.

1.3. Differences and similarities

Doctor to patient: "Perhaps it would save time if I told you what was right with you".

So let's start with similarities.

• Script language
• Concept of objects doing computations, linked up using messages
• Object hierarchy

Differences:

Despite these differences, most of the same commands work and do equivalent things. The changes are sufficiently flexible that you can do all of what you used to, plus more.

1.4. Architectures

MOOSE works on 32 and 64 bit Linux, and on Macs. A port to Windows is under way. These are all native compilations, not using Cygwin.

1.5. Scripting

SLI is implemented by simply grabbing the old GENESIS script code and getting it to work in C++ (not trivial!). There are still angularities where it interfaces with the shell and TTY, and of course not all the commands are implemented. But the basic functionality is identical, because the code is. Python has been implemented through SWIG through the efforts of Subhasis Ray. We feel that Python is likely to be the future scripting language for MOOSE, and in due course the GENESIS script interpreter will become an optional add-on.

1.6. Solvers

Solvers were a key part of GENESIS's ability to do things fast. The main GENESIS solver was the hsolve for neuronal models. Later a Gsolve was added for certain kinds of kinetic simulations. Solvers were ad-hoc, bolted on constructions. In MOOSE solvers interface much more cleanly with the objects, and are designed to be completely unobtrusive. The interface with objects is much better defined, and is entirely the programmer's headache. As a user you should be able to interact with the object (say a cell model) just as if it were being solved in the old-fashioned explicit integration mode. Solvers still turn objects into zombies, but these are much better facsimiles of the real thing.

1.7. Synapses

In GENESIS, synapses were done using active messages. The MOOSE concept of messages actually looks a lot more like active messages than the regular GENESIS messages. So synapses work very well, much faster, and more economically. It is also easier to access values of individual synapses - it is like a simple array lookup.

2. Converting old scripts

The main limiting factor at the time of writing (January 2008) is that only a small subset of the original GENESIS objects, and none of the graphical objects, have been reimplemented. You will also find that there are many commands that remain to be implemented, and often some of the command options are missing. We'll work on these according to how people give us feedback.

3. Kinetic modelling

The simdump schema has been reimplemented in MOOSE, along with the basic kinetic classes of molecule, reaction and enzyme. So kinetic modelling can be attempted with a fair chance of success.  A few models use channels, and other things which MOOSE does not yet have.

4. Single-neuron modeling

The bare minimum of the asymmetric compartment, and the HH-type channels have been reimplemented. The Traub models work. The cellreader works at its most basic level, but fancier channels involving calcium are not yet handled. A lot of work has gone into making MOOSE read the old channel setup files and one of the main regression tests (moose_channels.g) illustrates how far we have gone with this. The Hsolver is partly there and is set up automatically when you use readcell.

5. Network Modelling

Many of the network commands (createmap, region_connect and so on) have been implemented but not all of their options. Try and see. 

6. Using on SMP and parallel machines

There is a compilation option to use MPI for synaptic connections, for the adventurous. MPI-based messaging is working at a raw level, and we have a global namespace for objects over the entire simulation over many nodes. Things are not yet set up for user-level runs, but that should come soon. A bit later we will implement Multithreading (which will benefit from SMP) as part of the internal calculations of the solvers. Later still we will have dynamic multithreading for all messages.