Clawpack - Code Jam #1

The Clawpack 5.0 project has officially started. Yesterday, Kyle and I built the foundations of the project. Although there isn't much to look at yet, you can keep up to date on the current state of the code using Subversion. Just do the following:

$ svn checkout http://kingkong.amath.washington.edu/svn/clawpack

Since the code will have a very high flux over the summer, make sure to update often:

$ cd
$ svn update

About a month ago, Randy, Kyle, and I outlined Clawpack's new design. We aimed to accomplish several things:

• greater use of Python in installation, experimental setup, and data IO,
• updated source code organization to match that of common software projects,
• library packaging of core Fortran code,
• use of advanced f2py features. (Available by the end of the summer courtesy of the Cython team.)
  

For more information on our proposed plans for Clawpack 5.0 please visit this site. It presents a more robust outline of the software. Yesterday, we further discussed programming and design strategies for the new version of Clawpack. In particular, one of the fundamental questions we need to address is How much should Python be involved in the core Clawpack computations? This is a good question to ask since it not only impacts the way in which a user interacts with the product but more importantly it can affect the performance; this being a priority since Clawpack is intended to be used for research and, possibly, massively parallel environments. The above questions immediately shows its face in the primary subroutine in the core library, claw1. (For the moment let's just focus on the one-dimensional setting.) Among many operations, the main loop in the subroutine calls several functions:

claw1: main loop
    b4step     - user-supplied pre-step setup
    src1       - sub-solver if using Strang splitting
    step1      - perform a "step"
        rp1    - the algorithm's Riemnan solver
    src1       - another Strang splitting step
    src1       - sub-solver if using Godunov splititng

Our question, in this situation, then becomes "Does the Python interface simply wrap claw1 or does it dive into that subroutine and execute the main loop itself, calling the subroutines listed above?" The short answer is that for now we'll simply wrap claw1. However, our plan is to experiment and eventually run some performance analyses. Adding Cython to the mix expands the possibilities at hand for software design. We also look forward to the additions to f2py and Cython-Fortran integration that are currently being implemented by the Cython developers and funded by Google Summer of Code. I encourage you to check out Cython for yourself and see what they have planned for the summer.

As for my work on this project, I'm currently "library-atizing" the core, Fortran-based Clawpack code. It's current configuration requires the user to compile against the full source producing a "new Clawpack program" for each set of parameters you feed it. Hopefully having the code in library form will not only make it easier to use but also boost the relevance and importance of having Python serve as the means of operation. I suspect this sub-project to be a helpful one in exposing me to more of the core Clawpack code and familiarizing myself with gfortran's advanced compilation and linking features.