Summary of Enzo code sprint
Summary
There were five primary goals for the code sprint, which are listed below, along with their current status.
- New version of Enzo with all bug fixes and some improvements. (lead: Rick). This is progressing quite well - we've taken Robert's most current stable version, put the new Makefile system into it along with new units-based functionality, and are busily rolling in bug fixes and improvements from various people (Greg, Dave, Rick, Stephen, and myself). The improvements are not complete yet, but I have high hopes that these will be done in the next couple of weeks.
- New Enzo website and documentation. (lead: Brian). The new website is available at Enzo1.5. It is not in its final resting place yet, but the outline is reasonably complete. The features of the Trac site (website, wiki, bug tracking, various Subversion repositories that allow us to separate public and development branches of Enzo) are all complete, and the primary issue at the moment is documentation. I have been populating the website with text, links, documentation, and so on, but there is still quite a bit of work to be done, particularly with respect to the parameter list and to the wiki that nominally contains information on getting started with Enzo.
- Enzo test suite (lcatest), as well as a web page and documentation. (lead: James). There is a website at http://lca.ucsd.edu/projects/lcatest, but it's relatively empty. James has been working on the site + documentation. I do not know the precise status of this, other than "in progress."
- yt (analysis/viz tool) release simultaneously with Enzo, as well as supporting website and documentation (lead: Matt Turk). The code is available via read-only svn, and a website with copious online documentation is available at http://yt.enzotools.org/. According to matt, yt is will be ready for public deployment within a week, but more is being done on the data-management side. Data-handling and plotting via scripting and GUI are now both fully-featured. In addition to this, Matt has registered the website enzotools.org, and anybody who is interested in sharing their scripts, tools, etc. with the world can contribute. Please contact Matt for more details.
- A draft email to the Enzo user list (and other potentially interested parties) introducing Enzo v1.5, the new website, and so on. This is currently on the wiki, here: EnzoAnnouncement?. Please feel free to correct any errors or to improve the letter, if you would like (you can access it as a wiki page). We will send this email out when the code is formally released to the public.
To-do
- Enzo v1.5: Specific to-do items are below:
- Greg: finish adding PPM flux fixes, combined primordial chemistry, and C++ version of the ZEUS hydro.
- Rick: parallel inline analysis tools
- Dave: minor bug fixes (and possibly something else?)
- Brian: isolated gravity, new test problems, improved tracer particle functionality, some changes to default parameter settings.
- Stephen: updated default values, updated or replaced analysis tools (enzo_anyl, enzohop).
- New enzo website/docs: The technical side is essentially done. The primary to-do item is to populate the wiki with documentation. This is in progress, and writing assignments have been handed out. Check the bug-tracking site (http://lca.ucsd.edu/projects/enzo/report/1) for your writing assignments. Currently, the following people have writing assignments: James, Brian, Dave, Rick, and Matt. More will be added soon; I will email people with specific requests.
- lcatest: James needs to complete the lcatest public release, website, and documentation. I would appreciate his comments on possible ETA.
- yt: Matthew is nearly done absorbing enzo_anyl into yt. enzohop (the 32/64 bit version from Stephen Skory) is also nearly 100% done. Both of these things need to be finished (ETA: next few days), and some more documentation needs to be written.
- Email to Enzo user list: nothing more to do, modulo any comments that people have on the announcement.
Code release date
I think it's important to have a discussion about the code release date. I would suggest that after we finish adding all of the fixes described above (in task #1), we declare a moratorium on any and all non-bugfix commits to the Subversion repository, for the period of approximately a month. This will give all of us some time to run our various test problems, including full-scale cosmology, turbulence, etc. simulations, and compare them to previous, trusted versions of the code. To this end, I will suggest that we have all of our changes committed to the CVS repository by June 27th (slightly less than four weeks from now), and we give ourselves through August 1st (five weeks from that date) to bang on the code and see what breaks. This is a somewhat longer time frame than we originally thought, but it also includes lead time required for more documentation, etc.
Does anybody have any thoughts on this?
--Brian
