Discussion:

Enzo is currently at somewhat of a crossroads, in that it will soon be used by a large portion of the scientific computing community for both scientific and benchmark computing, the number of core Enzo developers is growing, we have one current code version on which all future development will be based, and a number of new additions will soon be made to Enzo's physical and algorithmic functionality. As a result, we wish to decide on a development strategy for current and future Enzo development that attains the following goals:

1. allows for simplified integration of new physics modules
2. minimizes inefficiencies due to different code versions (playing
'catch up' to new versions)
3. allows for simplified merging of contributions from the multiple
Enzo developers
4. incorporates regular regression testing, to ensure that code
additions do not destroy Enzo functionality

We plan to address these in the manner outlined as follows:

1. Document the existing Enzo code infrastructure, including current
algorithms and program flow. This should build off of the
documentation template that Dave and Brian have sent out, and
should serve as the de-facto description of Enzo's capabilities,
usage, and structure. We all plan to help out with this phase, as
no single one of us understands all of Enzo, but our combined
knowledge should span the large majority of the code.

2. Set up regular regression testing. To do this, James will extend
the current build system using the approach that he developed for
the previous Enzo version. Additionally, Pascal has proposed to
develop one (or more) tests that will exercise Enzo's physical
functionality, which will be used as the example code(s) for
regression testing. John Hayes will also help out in this area.
Once these tests are in place, we will run some base tests and
save their output. Regression tests will then compare results
against these 'trusted' results. James has proposed to set up the
automated regression testing system in the same manner as what he
has previously done for MGMPI, in which regression test results
are automatically uploaded to a web page.

3. Compartmentalize Enzo based on functionality. Since much of the
code inside Enzo overlaps between different routines and serves
multiple purposes, development may be difficult for a large team,
as any changes by one author will almost certainly interfere with
changes by the others. Therefore, we plan to re-work much of the
'glue code' within Enzo so that different functional modules are
each accessed through clean interfaces, so that , for instance,
development on an I/O module does not affect functionality of
various physics modules. To this end, we plan to each look
through Enzo to consider where these clean interfaces should lie,
and how they should interact. We then plan to meet during the
first week of April to discuss this compartmentalization, and
decide on a plan of action from there.

4. Set up regularly-scheduled meetings between core Enzo developers.
We plan meed every two weeks or so to discuss what we are
currently working on and how best to interact on software
development. It will be at these meetings where we will determine
when and how to perform large-scale Enzo enhancements (e.g.
incorporation of MHD or radiation, etc.).

5. Use CVS regularly to both update personal code to current code
base, and commit contributions to the repository for regression
testing and use by others. This should serve to minimize parallel
development, in which multiple developers are working on the same
bugs and/or bug-fixes by one developer can be propagated to the
others and to scientific users.

6. Update the documentation regularly as new functionality and/or
algorithms are added to Enzo.