The Cactus Framework and Toolkit: Design andApplicationsTom Goodale1, Gabrielle Allen1, Gerd Lanfermann1, Joan Mass´o2, ThomasRadke1, Edward Seidel1, and John Shalf31Max-Planck-Institut f¨ur Gravitationsphysik, Albert-Einstein-Institut,Am M ¨uhlenberg 1, 14476 Golm, Germany{goodale, allen, lanfer, tradke, eseidel}@aei.mpg.de2Departament de F´ısica, Universitat de les Illes BalearsE-07071 Palma de Mallorca, [email protected] Berkeley National Laboratory,Berkeley, [email protected]. We describ e Cactus, a framework for building a variety ofcomputing applications in science and engineering, including astrophysics,relativity and chemical engineering. We first motivate by example theneed for such frameworks to support multi-platform, high performanceapplications across diverse communities. We then describe the design ofthe latest release of Cactus (Version 4.0) a complete rewrite of earlierversions, which enables highly modular, multi-language, parallel appli-cations to be developed by single researchers and large collaborationsalike. Making extensive use of abstractions, we detail how we are ableto provide the latest advances in computational science, such as inter-changeable parallel data distribution and high performance IO layers,while hiding most details of the underlying computational libraries fromthe application developer. We survey how Cactus 4.0 is being used byvarious application communities, and describe how it will also enablethese applications to run on the computational Grids of the near future.1 Application Frameworks in Scientific ComputingVirtually all areas of science and engineering, as well as an increasing number ofother fields, are turning to computational science to provide crucial tools to fur-ther their disciplines. The increasing power of computers offers unprecedentedability to solve complex equations, simulate natural and man-made complexprocesses, and visualise data, as well as providing novel possibilities such as newforms of art and entertainment. As computational power advances rapidly, com-putational tools, libraries, and computing paradigms themselves also advance.In such an environment, even experienced computational scientists and engi-neers can easily find themselves falling behind the pace of change, while theyredesign and rework their codes to support the next computer architecture. This2 Tom Goodale et al.rapid pace of change makes the introduction of computational tools even moredifficult in non-traditional areas, e.g., social arts and sciences, where they maypotentially have the most dramatic impact.On top of this rapidly changing background of computation, research andengineering communities find themselves more and more dependent on eachother as they struggle to pull together expertise from diverse disciplines to solveproblems of increasing complexity, e.g., simulating a supernova or the Earth’sclimate. This creates a newfound need for collaborative computational science,where different groups and communities are able to co-develop code and tools,share or interchange modules and expertise, with the confidence that everythingwill work. As these multidisciplinary communities develop ever more complexapplications, with potentially hundreds or thousands of modules and parame-ters, the potential for introducing e rrors, or for incorrectly using modules orsetting parameters, also increases. Hence a software architecture that supports awide range of automated consistency checking and multi-architecture verificationbecomes essential infrastructure to support these efforts.Application developers and users also need to exploit the latest computa-tional technologies without being exposed to the raw details of their implemen-tation. This is not only because of the time needed to learn new technologies,or because their primary interest is in what the application itself can do, andnot how it does it, but also because these technologies change rapidly; e.g. timeinvested in learning one technology for message passing is largely wasted when adeveloper has to learn the next. What the developer really needs is an abstractedview of the operations needed for data distribution, message passing, parallelIO, scheduling, or operations on the Grid [1] (see se ction 16.5), and not theparticular implementation, e.g., a particular flavour of MPI, PVM, or some fu-ture replacement. The abstract concept of passing data between processors doesnot change over time, even though a specific library to do it will. A properlydesigned application framework with suitable abstractions could allow new oralternate technologies, providing similar operations, to be swapped in under theapplication itself. There is a great need for developing future-proof applications,that will run transparently on today’s laptops as well as tomorrow’s Grid.At the same time, many application developers, while recognising the need forsuch frameworks, are reluctant to use “black box”, sealed packages over whichthey have little control, and into which they cannot peer. Not only do someapplication developers actually want to see (perhaps some) details of differentlayers of the framework, in some cases they would like to be able to extend themto add functionality needed for their particular application. Such transparency isnearly impossible to provide through closed or proprietary frameworks w ithoutresorting to excessively complex plug-in SDKs. For this reason, freely available,open source tools are preferred by many communities (see, for example, Linux!).Source code is available for all to see, to improve, and to extend; these improve-ments propagate throughout the communities that share open source tools.The idea of open source tools, once accepted by one segment of a community,tends to be contagious. Seeing the benefits, application developers making useCactus Framework 3of such open tools are often inclined to make their own modules freely availableas well, not only in the computational science areas, but also for modules spe-cific to research disciplines. In the computational science disciplines, modularcomponents that carry out specific tasks are increasingly able to inter-operate.Developing application components for, or in, one framework makes it easier touse them with another framework. This is a particular goal of the “CommonComponent Architecture” [2], for example. As another example, we describebelow application modules developed for numerical