My investigation has led me to several design strategies so far. I share these not only so I can organize my thoughts but also to see if anyone has suggestions on how to proceed.
Strategy #1: Insert Pyclaw
Pyclaw is a Clawpack Python wrapper designed by Kyle Mandli. I've already partially documented my attempts at incorporating this code into Sage in a Google Notebook which you can view here. The idea is to simply connect the Pyclaw code to Sage as a collection of additional Python modules.
Pros:
- Conceptually straightforward
- Python to Fortran interface is already done
Cons:
- Requires augmentation of high-level Pyclaw code
- Need to rework plotting routines to use Sage's plotting functionality
- Pyclaw is constantly changing
Strategy #2: Wrap the Core Fortran Code: Cython
Another approach is to create a Cython wrapper of the core Fortran code found in claw/clawpack. Then, the user can write Cython code that will interface with the library. However, since most of the Subroutines are stubs this would require some compiling against the library thus overriding the symbol table.
Pros:
- Fast.
- Allows the user to write the step1, src1, and other user-supplied Clawpack functions in Cython in addition to Fortran.
Cons:
- Recompiling routines might be a bit tricky, especially if the user is working in the Sage Notebook.
- Need to figure out a way to handle claw.data files.
- What happens when you Cython extern and then change the library contents / symbol table? Needs to be examined.
Clawpack and Sage are two different beasts and it'll be a challenge to harmoniously combine the two. However, like I said before, this will be a great way to introduce Sage to numerics.
1 comments:
A famous aphorism of David Wheeler goes: All problems in computer science can be solved by another level of indirection (wikipedia)
Seems that it would be possible to design a Pythonic interface to Clawpack to insulate user code from changes / extensions to the underlying libraries. If additional functionality were introduced, the interface could be extended and upward compatible. if clawpack changes, only the presentation layer implementation need change, not the user code
I didn't understand the bit about "overriding" the symbol table. I'd let C++ or Python do any overriding necessary and leave the symbol table to the linker... unless there's something really fancy going on which might be cause for concern. If the interfaces stay the same, recompilation shouldn't be necessary and dynamic libraries can do their magic.
Post a Comment