cammerdl@camme.UUCP (R. De Langhe CAMME project) (08/17/90)
Hello world ! On our site, lots of scientists are developping modeling programs to simulate all kinds of hydrodynamical systems like oil-slick evolution, wave-height predictions, etc. The problem for these guys, as for all scientists using computers I guess, is that they are stuck to that little bit of programming languages they know : FORTRAN. Creating code that runs under every input data, produces results, or even results that might be correct, takes several weeks per tiny peace of code. I was thinking that the biggest problem for them is : converting their (often genious) algebra-solutions for a given model, into some programming language like FORTRAN they're not used to 'speak'. Would it not be much more easy and efficient if these scientists could use an algebra-like programming language, in which they can easily recognize errors, or proof correctness of an algorithm, etc. and let some kind of a source-code generator parse their expressions into C (or FORTRAN) ? The resulting program would even be quite efficient, because the problems they study involve often many thousands of matrix-elements to compute (on a supercomputer). Therefore I'd like to ask for opinions about this problem, and if someone has developped or has under development such algebra-syntax parser/code generator. The machines we are working which all run under UNIX bsd 4.2 and have (vectorising) C and FORTRAN compilers. Please email your opinions and suggestions to me. Thanks ! Rob
doleh@math-cs.kent.edu (Yaser K. Doleh) (08/18/90)
Code generating has been an active research area at Kent State for quit sometime. GENTRAN (FORTRAN code generator) and GENCRAY (parallel CRAY FORTRAN generator) are two packages that do what you are looking for. For more information contact Dr. Paul S. Wang (pwang@cs.kent.edu) and/or Sanjiva Weerawarana (saw@cs.purdue.edu) --------------------------------------------------- Yaser Doleh <doleh@math-cs.kent.edu> Department Of Mathematics & Computer Science Kent State University Kent - OH 44242
steve@hubcap.clemson.edu ("Steve" Stevenson) (08/18/90)
When I was at Bell Labs, we did something for the biophysics department. Dan Warner (numerical analysis) modified his stiff ODE solver. I wrote a compiler which had stoichiometric equations for its input. The output was Fortran. That was 10 years ago---it's still in use by Truman Brown at Fox Chase Cancer Center at U. of Penn. We considered it a real prototype. BTW-we used Lisp interpreter to process the intermediate code. Really flexible system. =============================================================================== Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906 -- =============================================================================== Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (08/18/90)
>>>>> On 17 Aug 90 10:27:00 GMT, cammerdl@camme.UUCP (R. De Langhe CAMME project) said:
R.> On our site, lots of scientists are developping modeling programs to
R.> simulate all kinds of hydrodynamical systems like oil-slick evolution,
R.> wave-height predictions, etc.
R.> Would it not be much more easy and efficient if these scientists could
R.> use an algebra-like programming language, in which they can easily recognize
R.> errors, or proof correctness of an algorithm, etc. and let some kind of a
R.> source-code generator parse their expressions into C (or FORTRAN) ?
This is certainly one of the weakest areas in the field of "scientific
programming".
I found a very interesting article in the Journal of Computational
Physics in 1966 describing a package written in Algol which wrote 3D
plasma dynamics programs in Algol. Since this work was done in
1964-1965, it is a bit shocking that in 25 years such techniques have
made such negligible intrusion into the day-to-day activities of
scientific programmers.
One package that I do know of is ELLPACK, a system for generating
FORTRAN programs for solving elliptic partial differential equations.
I believe that Purdue University has the copyright, and that they are
working on an elliptic PDE expert system based on it.
The introduction of higher-level/object-oriented languages will
presumably make the construction of many programs easier, since a
collection of "building blocks" can be constructed to take care of a
lot of the coding detail. Ken Wilson's group (then) at Cornell was
using C++ for such a project. I heard that Wilson left Cornell, but I
don't know where he went, or if the "Gibb's Project" followed him.
--
John D. McCalpin mccalpin@perelandra.cms.udel.edu
Assistant Professor mccalpin@vax1.udel.edu
College of Marine Studies, U. Del. J.MCCALPIN/OMNETabennett@athena.mit.edu (Andrew Bennett) (08/18/90)
As I understand it, programs such as Mathematica and Maple try to run directly off of the algebra equations. Both are available for Crays. Mathematica is *way* too costly, but Maple is pretty reasonable. Never having used either, though, I don't know if they're worth the effort. Are they? If not, what's wrong with them? Too limited somehow? Too slow? -Drew
usenet@nlm.nih.gov (usenet news poster) (08/18/90)
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) ("jdm>") writes:
in response to cammerdl@camme.UUCP (rdl De Langhe CAMME project) ("rdl>")
rdl> Would it not be much more easy and efficient if these scientists could
rdl> use an algebra-like programming language, in which they can easily
rdl> recognize errors, or proof correctness of an algorithm, etc. and let some
rdl> kind of a source-code generator parse their expressions into C
rdl> (or FORTRAN) ?
jdm> This is certainly one of the weakest areas in the field of "scientific
jdm> programming".
jdm>
jdm> I found a very interesting article in the Journal of Computational
jdm> Physics in 1966 describing a package written in Algol which wrote 3D
jdm> plasma dynamics programs in Algol. Since this work was done in
jdm> 1964-1965, it is a bit shocking that in 25 years such techniques have
jdm> made such negligible intrusion into the day-to-day activities of
jdm> scientific programmers.
Generation of standard Fortran or C code to evaluate an algebraic expression
has been a standard feature of symbolic algebra programs such as MACSYMA
for at least 15 years. Mathmatica supports similar functionality.
I have never seen it used much. Anyone care to speculate on why this is?
jdm> The introduction of higher-level/object-oriented languages will
jdm> presumably make the construction of many programs easier, since a
jdm> collection of "building blocks" can be constructed to take care of a
jdm> lot of the coding detail. Ken Wilson's group (then) at Cornell was
jdm> using C++ for such a project. I heard that Wilson left Cornell, but I
jdm> don't know where he went, or if the "Gibb's Project" followed him.
I have heard alot of enthusiasm for object oriented programming, but
it seems like you can create incompatible objects almost as easily as
non-shareable libraries. I hope I am wrong.
jdm> John D. McCalpin mccalpin@perelandra.cms.udel.edu
David Stateskhb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (08/18/90)
...1964-1965, it is a bit shocking that in 25 years such techniques have
...made such negligible intrusion into the day-to-day activities of
Humm, well there are some that use tools ;>
LLNL folks wrote BASIS.
Mohler et al. have derivatives of MATHLIB, see MathWorks
someone or another wrote GAUSS (pc only ?)
MathSoft's MathStation seems very sexy (write WYSIWG text, it
computes, or generates fortran code)
Universal Technical Systems, TK Solver Plus
Some interesting things can be done with GPSS too.
Not to sound commerical or anything, but all these goodies are listed
in the Sun Catalyst Guide (2000 application programs, and related
goodies).
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (08/18/90)
In article <1990Aug17.214800.16650@athena.mit.edu> abennett@athena.mit.edu (Andrew Bennett) writes:
As I understand it, programs such as Mathematica and Maple try to
run directly off of the algebra equations. Both are available for
Crays.
Mathematica is *way* too costly, but Maple is pretty reasonable.
Never having used either, though, I don't know if they're worth the
effort. Are they? If not, what's wrong with them? Too limited
somehow? Too slow?
-Drew
Both are symbolic packages; not necessarily wonderful for numerical
approximations. I defer to those that have run the codes (like the
folks at NCSA) but I don't recall Mathematica on the Cray being a
speed demon, one article suggested that for solving a large gravity
model it was only 4x a Sun (not that Suns are slow ;> but one expects
more from a Cray).
MathStation _sounds_ like a super package. However, I am not currently
involved in the kinds of projects for which it is suited. I look
forward to a NetReview ;>
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043hamm@austoto.sps.mot.com (Steve Hamm) (08/21/90)
-----On 17 Aug 90 22:16:48 GMT, usenet@nlm.nih.gov (David States) said:
David> Generation of standard Fortran or C code to evaluate an
David> algebraic expression has been a standard feature of symbolic
David> algebra programs such as MACSYMA for at least 15 years.
David> Mathmatica supports similar functionality. I have never seen
David> it used much. Anyone care to speculate on why this is?
Because they generate extremely inefficient code (at least Mathematica
does-- I have very little experience with Macsyma). For instance, I
periodically use Mathematica to generate partial derivatives. I then
output expressions in some human readable format and edit them
extensively to turn them into semi-efficent C code.
Part of the problem is that Mathematica's expression simplification
function doesn't work very well at all. And for generating code, some
techniques should be used, such as common subexpression elimination,
to turn a single algebraic expression into more than one line of code.
Another part of the problem is I dislike the coding style that
Mathematica outputs. The code requires use of a set of C macros
(supplied), but would make that section of code's style different from
anything else in our program, which is a distinct code maintenance
disadvantage.
Were I using FORTRAN, I'd be much better served by an automatic code
differentiation package, such as NETLIB's JAKEF.
--
Steve Hamm ----------- Motorola Inc. Semiconductor Sector CAD
3501 Ed Bluestein Blvd., MD-M2, Austin TX 78762
Ph: (512) 928-6612 Internet: hamm@austoto.sps.mot.com
UUCP: ...cs.utexas.edu!oakhill!austoto!hammpainter@lll-crg.llnl.gov (Jeff Painter) (08/25/90)
In article <1116@camme.UUCP> cammerdl@camme.UUCP () writes: >On our site, lots of scientists are developping modeling programs to >simulate all kinds of hydrodynamical systems like oil-slick evolution, >wave-height predictions, etc. >The problem for these guys, as for all scientists using computers I guess, >is that they are stuck to that little bit of programming languages they >know : FORTRAN. Creating code that runs under every input data, produces >results, or even results that might be correct, takes several weeks per >tiny peace of code. >I was thinking that the biggest problem for them is : converting their >(often genious) algebra-solutions for a given model, into some >programming language like FORTRAN they're not used to 'speak'. > >Therefore I'd like to ask for opinions about this problem, and if someone >has developped or has under development such algebra-syntax parser/code >generator. Most symbolic algebra programs have some sort of primitive Fortran generator; i.e. they can generate one line (plus continuation lines) of unoptimized Fortran from a scalar expression. It's easy to do that much; after all, Fortran was originally designed for that. Many people have gone a lot further than that. Grant Cook, I, and others are involved in one such effort. For details see Grant Cook's paper "ALPAL, a Program to Generate Physics Simulation Codes from Natural Descriptions", in the first issue of International Journal of Modern Physics C. The references should help track down some of the other efforts in this area. ALPAL is built on Macsyma, and Grant Cook substantially improved Macsyma code generation capability to support it. A few of these extensions are available with the DOE-Macsyma version of Macsyma, from the National Energy Software Center in Argonne, Illinois 60439, USA. There are not any advanced codes in this area which exploit the power of large symbolic algebra programs and which I could recommend as being freely available, general-purpose, and fully engineered beyond the research level. Jeffrey F. Painter painter@lll-crg.llnl.gov L-316, Lawrence Livermore Laboratory 415-422-0675, FTS 532-0675 Livermore CA 94550 USA 415-423-7613, FTS 543-7613