Re: Struggling with list element assignment in functions

*To*: mathgroup at smc.vnet.net*Subject*: [mg45745] Re: Struggling with list element assignment in functions*From*: mt at 3planes.com (Michael Tobis)*Date*: Fri, 23 Jan 2004 03:15:29 -0500 (EST)*References*: <bu8gs2$ak5$1@smc.vnet.net> <buiv2s$qth$1@smc.vnet.net> <bulnjv$8c8$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

> Why reinvent the wheel ?? Well, I had hoped the wheel was already invented. The wheel I want is an implentation of a set of rules translating descriptions of PDEs to code, i.e., a FORTRAN or C representation, to insert into a larger, existing model. Please correct me if I am wrong, but NDSolve doesn't strike me as fitting that requirement. About a third of what we do in climatology is PDE's as normally understood; the remainder is ad hoc representation of boundary conditions and unresolved processes (cloud convection, radiative transfer). Regarding the conventional PDE part, going from a mathematical description to an executable involves a set of transformations each of which adds complexity to the model description, as well as tedium and opportunity for error in the effort. All these transformations (time differencing, space differencing, boundary conditions, domain decomposition for parallelization) are currently performed at great effort. The existing approach produces "model" code that is not just costly but also very opaque, and hence fails to serve some of the traditional cognitive purposes of a scientific model. What I'm after is a rapid development tool for the more Navier-Stokes-ish parts. The constraints which guide our numerical methods are quite definitely not the same as would be used in a general PDE solver. Performance is critical, as our calculations are enormous. Our accuracy requirements are very severe regarding conservation of passive tracer in ocean models, but quite lax in other ways. We are also interested, for efficiency reasons, in decomposing the problem into a vertically integrated part and a remainder. Finally, we are interested in decomposing the domain for parallelization, with careful attention to communication and bandwidth issues. What I'd like to see is a code generation tool: given formal descriptions of the PDE system, the geometry of the problem, the time differencing scheme, the space differencing scheme and the processor decomposition, to generate compilable parallel code. This would expand from order 100 lines of human-generated source code to order 10,000 lines of compilable code in C or FORTRAN. The 100 lines of human-generated code would serve as a comprehensible and reviewable model. Others have made efforts along these lines using templates in C++; the reports I have heard claim that in practice the problem with this approach is in the compile phase. The compilation of models generated with these products is reputedly time-consuming and unreliable. In any case, the efforts have been focussed on engineering problems which have substantially different performance goals than we do. My idea is to have a high-level model description language translated into a low-level high performance language like FORTRAN or C with MPI calls. Although this strikes me as a fairly obvious idea, so far I have not found anything of the sort already in existence. (Maybe it would be of little research utility outside geophysical fluid dynamics, though I think it would have a lot of didactic value in numerical methods courses.) What I'm considering here is the architecture of the translation mechanism. When I considered how to do this, it occurred to me that what I was talking about was a set of rules, so I thought about Mathematica. As described so far, the tool itself doesn't need to know very much mathematics, but once I had Mathematica in mind it occurred to me that the phase and stability analyses for these methods could be an almost free byproduct of the effort. Another approach I am considering is to use MathML and XSLT. Perhaps Mathematica's role will simply be as a MathML editor. I don't think it's realistic to build a complete climate model in Mathematica, and I'm not proposing to do that. -- mt -- Michael Tobis http://geosci.uchicago.edu/~tobis