From my naive, uninformed perspective the core Clawpack library is meant to be directly edited to solve a problem of your choice. Well, that's not entirely true. The primary function, claw1, initializes some parameters such as the number of equations to solve, the number of waves to propagate, etc. Then --- and this is where I was a little bit lost --- claw1ez calls a sequence of user-defined Fortran subroutines in the main loop: (for the 1d solver)
- bc1 --- extend the data to the "virtual cells" outside the computed region to account for boundary conditions
- b4step1 --- set time-dependent aux arrays or perform other computational tasks that need to be done at each step in the iteration process
- step1 --- take one time step, updating the solution. This called rp1, a user-defined Riemann solver
- rp1 --- a user-defined Riemann solver routine executed at each step of the iterative process
- setprob --- a user-defined function that sets problem parameters or reads in data for initialization of the claw1 routine.
This structure completely changes my approach on creating a Sage wrapper. I can't simply compile the contents of claw/clawpack/ into a dynamic library and wrap that in Cython --- the meat of the code is completely empty!
Fortunately, Kyle Mandli has created a pure Python version of Clawpack in addition to a Python interface for the "hands-on" Fortran-based solver. So, for now I'll start by picking the easy-to-reach fruit and implement that pure Python functionality into Sage. His code already contains routines for solving common kinds of hyperbolic differential equations. That will be my starting point.
After that, my goal will be to figure out a way so that users can supply their own solver routines and methods just like the core Clawpack code intends. It would be really cool if a user could write a Fortran subroutine in a Sage Notbook cell and then somehow compile that into the base functionality. I have a strong feeling that this in entirely possible.
I'm such a noob!

1 comments:
Why can't you develop an interface which is subclassed by user code? It could be a cython interface object and/or, if you get fancy and the performance doesn't kill ya, you could invoke python objects the user has implemented, again by subclassing a clawpack provided superclass. Cython probably does all the work for you in both cases although "where's main?" is always the key with Framework design.
Post a Comment