Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: Re: Trivial Fourier Transform Question
  • Next by Date: Re: Re: Re: Re: Re: typesetting fractions
  • Previous by thread: Re: Struggling with list element assignment in functions
  • Next by thread: RE: List arguments to functions - Use of Inner Command