(ed.). Gravitational waves (IOP, 2001)(422s).

390 Numerical relativitynumerics and computer science) and because of the geographical distribution ofthe people and computer resources involved in simulation and data analysis.The name Cactus comes from the design of a central core (or flesh) whichconnects to application modules (or thorns) through an extensible interface.Thorns can implement custom developed scientific or engineering applications,such as the Einstein solvers, or other applications such as computational fluiddynamics. Other thorns from a standard computational toolkit provide a range ofcapabilities, such as parallel I/O, data distribution, or checkpointing.Cactus runs on many architectures. Applications, developed on standardworkstations or laptops, can be seamlessly run on clusters or supercomputers.Parallelism and portability are achieved by hiding the driver layer and featuressuch as the I/O system and calling interface under a simple abstraction API. TheCactus API supports C/C++ and F77/F90 programming languages for the thorns.Thus, thorn programmers can work in the language they find most convenient,and are not required to master the latest and greatest computing paradigms. Thismakes it easier for scientists to turn existing codes into thorns which can thenmake use of the complete Cactus infrastructure, and in turn be used by otherthorns within Cactus.Cactus provides easy access to many cutting edge software technologies beingdeveloped in the academic research community, such as the Globus MetacomputingToolkit, HDF5 parallel file I/O, the PETSc scientific computing library,adaptive mesh refinement, web interfaces, and advanced visualization tools.So, how does a user use the code? A detailed user guide is available withthe code (see http://www.cactuscode.org), but in a nutshell, one specifies whichphysics modules, and which computational/parallelism modules, are desired in aconfiguration file, and makes the code on the desired architecture, which can beany one of a number of machines from SGI/Cray Origin or T3E, Dec Alpha, Linuxworkstations or clusters, NT clusters, and others. The make system automaticallydetects the architecture and configures the code appropriately. Control of runparameters is then provided through an input file. Additional modules can beselected from a large community-developed library, or new modules may bewritten and used in conjunction with the pre-developed modules.Our experiences with Cactus up to now suggest that these techniques areeffective. It allows a code of many tens of thousands of lines, but with acompact flesh that is possible to maintain despite the large number of peoplecontributing to it. The common code base has enhanced the collaborativeprocess, having important and beneficial effects on the flow of ideas betweenremote groups. This flexible, open code architecture allows, for example, arelativity expert to contribute to the code without knowing the details of, say,the computational layers (e.g., message passing or AMR libraries) or othercomponents (e.g., hydrodynamics). We encourage users from throughout therelativity and astrophysics communities to make use of this freely downloadablecode infrastructure and physics modules, either for their own use, or as acollaborative tool to work with other groups in the community.