Tue 28 Jun 2005 03:49:01 PM UTC, comment #3:
Hi, Paolo. Thanks for your comments and suggestions. Balancing generality of computation, straighforwardness of user interface, and simplicity in implementation has probably been the trickiest issue in developing Channelflow. I'm not sure how well Channelflow will generalize beyond spectral approximation of Fourier x Chebyshev x Fourier expansions, or degenerate cases of those. The Flowfield class, which is pretty central to everything Channelflow does, is hardwired for Fourier x Chebyshev x Fourier expansions. One could write a similar class for another form of expansion without too much trouble, or one could write a general framework for building such expansions out of elements. My guess if that the latter approach would require years of deep thought and hard work, if done in C++.
Before Channelflow, I worked on a general-geometry, general-representation PDE approximation C++ code, which collapsed under the weight of its own generality. So I decided to err in the direction of specifity towards my problem domain for Channelflow.
I'm also not sure about integration of Channelflow with other packages, particularly ones like ATLAS that make heavy use of sophisticated template constructions. I'm looking into interfacing Channelflow with Python, in order to make Channelflow scriptable and to provide graphics and GUI capabilities. I don't yet have a complete grasp of the issues involved, but it looks like this will be simpler if I keep the template usage low and self-contained, and the object reference/copy model simlpe as well.
On the other hand, I appreciate your interest in working with/on Channelflow, and I don't want to turn you away by rulign anything out. You might have to bear with me while I come to understand your issues.
Other people I'm talking to about Channelflow are mostly interested in parallelization and multithreading.
So with that in mind, responses to your specific comments:
(1) I'd like to hold off on migrating from my home-grown Array to the STL class until I understand the Python integration issues more completely. The Array class is written and it works, so there's no pressure to get rid of it besides cleanliness (which I agree with but it's an aesthetic consideration!).
(2) The linear algebra in core Channelflow code is very simple (banded tridiags) and complete, so I don't see a pressing need for deep integration between Channelflow and GMM++. However, it could be very useful for users to be able to combine the two packages. I wonder if there are any name-space collisions. (Making Channelflow name-space friendly is something I haven't gotten around to yet.)
I've been combining Channelflow and Octave linear algebra libraries in my research codes, but I've found that binary Octave packages (RPMs) always have missing function definitions and I've been forced to tinker with the source packages to make it work. It's tricky, and so I haven't supported this combination to other users. I wonder if GMM++ integration would be easier.
(5) I want to keep the object memory-management model as simple as possible, for the sake of future Python integration and because my experience with reference-counting smart-pointers code was painful and bitter.
(6) I'm planning to rename ChebyCoeff to ChebyExpan or ChebyExpansion. I plan to implement a number of your suggestions for it, like building in a quick-and-dirty FFT, and moving the gridpts function to a member function. But I'm not inclined to generalize it beyond finite-domain Chebyshev expansions, because it won't pay off for my problem domain, and it seesm it would it would complicate the code significantly.
Can you implement infinte-domain expansions as a separate class? Would this satisfy your needs? If not, how would you integrate them, and at what cost?
(7) Doxygen would be great. I've concentrated on thea Latex manual since it's good for mathemtical expressions. But Doxygen would be good for a programmer's reference manual.
ok, thanks again for your thoughts!
John
|