reggie@pdn.paradyne.com (George W. Leach) (09/18/90)
In article <1990Aug16.144551.11687@pdn.paradyne.com> I wrote: > Next week, I will begin teaching a FORTRAN Programming Course to >Engineering Students. This is the second time I will be teaching this >particular course. I wanted to tap into the expertise of this newsgroup >and obtain some example applications for which FORTRAN is being utilized >these days. > > > It has been about eight years since I last used FORTRAN in my day >to day work. At that time, FORTRAN was still a very popular language for >general applications. It seems as if C has taken that role over from >FORTRAN over the course of the last decade. It is my impression that >this has left FORTRAN to the domain of scientific and engineering applications >for which C is not suitable. > > > If you are working on or know of a unique application for which >FORTRAN is being utilized, I would appreciate it if you could e-mail me >a brief description. I want to use a few examples for the intro lecture >on FORTRAN as examples of its use in modern times. Below are the replies to this inquiry. Thanks to the following people for replying: Dwight Aplevich (dwight@watserv1.uwaterloo.ca) Leonore A. Findsen (FAX0357@uoft02.utoledo.edu) Jerry Berkman (jerry@violet.berkeley.edu) Scott Lamson (lamson@sierra.crd.ge.com) Doug Mink (mink@cfa.harvard.edu) Peter Montgomery (pmontgom@math.ucla.edu) Ralph Finch (rfinch@locke.water.ca.gov) Mike Peterson (system@alchemy.chem.utoronto.ca) William Clare Stewart (wcs@erebus.att.com) and one employee of a vendor who asked to remain anonymous. Thanks, George George W. Leach AT&T Paradyne reggie@paradyne.com Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA ____ ==> [ unzip here ] |____)-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8- Date: Fri, 17 Aug 90 23:35:13 EDT From: Dwight Aplevich <pdn!uunet!watserv1.uwaterloo.ca!dwight> Organization: University of Waterloo A computer scientist whose name I forget defined an engineer as "someone who does list processing in Fortran." For the development of a feedback control system design package I used Fortran because it is still the most portable language, and because many commercial companies are slow to adopt other languages. None of that is unusual, but in attempting to keep up to date it seemed desirable to use machine-produced tables to drive the input parser. Again nothing unusual if you use C and Unix: use lex and yacc, of course. But other parser-generators produce tables which can be automatically included in Fortran programs. The result can therefore be a skeleton compiler in Fortran. With such a beast one can concentrate on the numerical aspects of the program, which is what the language is good for. Including the input parser in Fortran also avoids the nasty problems of linking routines compiled from separate languages. It can be done, but not portably. ******************************************************************************** Date: Fri, 17 Aug 90 11:13 EST From: "Leonore A. Findsen" <pdn!uunet!uoft02.utoledo.edu!FAX0357> I doubt that this is unique, but I use FORTRAN exclusively for molecular dynamics calculations and semi-empirical molecular orbital calculations. My background is in computational chemistry, and most of the programs that I have used are in FORTRAN. Leonore -- ============================================================================= Leonore Findsen | College of Pharmacy | INTERNET: fax0357@uoft02.utoledo.edu system manager? | University of Toledo | BITNET: fax0357@uoft02 Asst. Professor | Toledo, OH 43606 | VOICE: (419) 537-2729 ============================================================================= Disclamer: This message is a figment of my imagination. ============================================================================= ******************************************************************************** Date: Sun, 9 Sep 90 12:17:15 PDT From: pdn!uunet!violet.berkeley.edu!jerry (Jerry Berkman) I wrote a large billing and resource management system for our Cray in Fortran. A similar system was originally written in C for our PDP/11's and VAXen. One hacker had attempted to port it to the Cray, but the port was real buggy. After looking at it a while, I decided I would never trust anything other than a total rewrite. So I replaced it by a system written in Fortran. It terms of size, the C system took about 15,000 lines of code, the Fortran system took 4,500 lines of code. The Fortran system is not a translation of the C system, it is a totally different implementaion. It uses entirely different data structures. It is written in a modular fashion. If one part fails, other parts still may be run. All advertised features work, and it is faster than the C system, for some commands, by a factor of 10. However, I am an anomaly. Most people working for computer centers use C for such packages. I prefer Fortran. Most of our Cray users use Fortran for their work. This month so far, (actually Sep. 4-Sep. 8) usage of compilers has been: unique command uses users cft77 1257 27 cf77 85 8 cft 111 8 scc 5 1 cc 81 2 pascal 0 0 as 0 0 cft77, cf77, and cft, all of which invoke Fortran compilers, were used by 27, 8, and 8 users respectively, which means somewhere between 27 and 53 unique users used Fortran. C was used by only 2 or 3 users, pascal by 0, assembler by 0. These stats exclude computer center staff who generally dislike Fortran. We have a lot of chemists, chemical engineers, mechanical engineers, etc., plus a few social scientists. I once checked the statistics at the San Diego Supercomputer Center, and Fortran dominance was even more pronounced there, except for staff which mainly used C. - Jerry Berkman, Cray Support, U.C. Berkeley, (415)642-4804 jerry@violet.berkeley.edu |h ******************************************************************************** Date: Thu, 16 Aug 90 17:25:39 From: THE MYSTERY REPLIER Fortran is still one of XXXXXXXXXX's best selling sw products. I am not at liberty to say how well, that is marketing's job ;> f77 is still the language of choice for a large number of ISV's, nearly all circuit simulation packages (spice type) are written in Fortran (discrete packages are written in LIPS, MAINSAIL and other lingos). Finite Element analysis packages are nearly all fortran, as are chemistry codes (gaussian for example). I'm given lots of talks about performance, etc. In many venues I ask "How many of your sites code in language foo" Where I've defined 30% or more of the total compute cycles to be significant use. Nearly all american crowds will not confess to PERSONALLY coding in Fortran, but a good 80-90% will confess that someone at their site does. Europe is a little less Fortran biased. But even Oxford burns lots of Fortran cycles. ******************************************************************************** Date: Fri, 17 Aug 90 11:06:16 EDT From: Scott Lamson <pdn!uunet!sierra.crd.ge.com!lamson> One interesting application I have developed in Fortran was a 3D analytic/numerical simulation of a superconducting generator. This was analyzed in cylindrical coordinates where the current distribution through the wire wrappings was approximated by a 2D Fourier series on the surface of a cylinder. Numeric intergation accounted for the radial distribution. The double integrals required to compute the Fourier coefficient representation of the current distribution were done analytically in Macsyma. The resulting expressions were translated into Fortran expressions and inserted into the Fortran application. Whenever changes were required, they were made to the Macsyma code, and the output expressions were recomputed in Macsyma, thus making Macsyma a higher level language, with Fortran taking the place of the "assembly" code produced by the compiler. Of course, the reality was a bit less elegant. Also, the TOOLPACK restructurer and declaration standardization tools were used to enhance readibility of the resulting code. scott Scott| ARPA: lamson@crd.ge.com Lamson| UUCP: uunet!crd.ge.com!lamson (518)387-5795| UUCP: uunet!sierra.crd.ge.com!lamson General Electric Corporate Research and Development ******************************************************************************** Date: Fri, 14 Sep 90 11:54:52 EDT From: pdn!uunet!das.harvard.edu!mink%cfa0 (Doug Mink) I use Fortran extensively in my astronomical work. The main project I am working on is the cross-correlation of spectra to get radial velocities of stars, for orbital and galactic structure problems, and galaxies, to figure out the radial distribution of matter in the universe. This project is a good example of how multiple languages are used. Preliminary processing of the data is done in C, the main processing is done in a language called SPP which is a Fortran preprocessor developed at Kitt Peak National Observatory as part of IRAF, their data reduction and analysis system, and most of the computational work is done in Fortran. Unix shell scripts and IRAF command language scripts tie everything together. Language choice is determined by programmer preference (I prefer Fortran, my colleague who wrote the reduction software prefers C), portability (IRAF software can be easily ported to many different computers and the system is written to handle much of the kind of work we do), and history (the computational subroutines have already been written and tested in Fortran). In my own work, I use Fortran software to predict occultations of stars by planets and their satellites. Over 15 years, I have built up a lot of mapping and astrometric software in Fortran. Originally written in IBM Fortran (on cards!) in the early 1970's, programs were ported to Data General Novas (cards -> cassettes -> hard disk and tape) in the late 1970's, an early 68000 Unix box in the early 1980's, Digital VAXen running Ultrix in the late 1980's, and now Suns and Decstations running Unix. With time the software has become more easily ported as system-dependent parts have been isolated or removed. Most of the code which directly interacts with terminals or files is in Fortran-callable C (translated from the original assembly language). Doug Mink Harvard-Smithsonian Center for Astrophysics Cambridge, Massachusetts Internet: mink@cfa.harvard.edu UUCP: {husc6,cmc12,mit-eddie}!harvard!cfa!mink BITNET: mink@cfa SPAN: cfa::mink Phone: (617)495-7408 ******************************************************************************** Date: Thu, 16 Aug 90 19:21:27 -0700 From: Peter Montgomery <pdn!uunet!math.ucla.edu!pmontgom> Organization: UCLA Mathematics Dept. My major application is a multiple precision arithmetic library which was originally in Fortran but is gradually begin converted to C (while keeping both sources around). Memory management is a pain in both languages. Fortran 90x has automatic arrays (variable size, allocated at subroutine entry) but many compilers do not yet support them and C has no corresponding construct (though gcc supports such declarations). Malloc can be used for variable-size declarations in C, but is expensive if the life span is short. Fortran has no such construct. Neither language has good primitive constructs for my application, such as the 64-bit product of two 32-bit integer operands. Since your students are engineers, give them an assignment involving complex arithmetic. For example, the program might read the coefficents of a 4-th degree real polynomial. Then have them enter some approximate complex estimates for the roots, and apply Newton's method from these starting values, printing out the first 10 or so iterates. Also give them some assignments involving multiple-dimensional arrays, esp. where the dimension is passed as a subroutine argument. Emphasize the large set of intrinsic functions available in Fortran. -- Peter L. Montgomery pmontgom@MATH.UCLA.EDU Department of Mathematics, UCLA, Los Angeles, CA 90024-1555 If I spent as much time on my dissertation as I do reading news, I'd graduate. ******************************************************************************** From: pdn!uunet!locke.water.ca.gov!rfinch (Ralph Finch) Date: Fri, 17 Aug 1990 09:14:42 PDT Organization: Calif. Dept. of Water Resources, Sac. We do mathematical modeling of the Sacramento-San Joaquin Delta, an estuary upstream of the San Francisco Bay. We use Fortran for most of our code; awk and shell scripts for the remainder. We are just about to try a distributed computing system whereby our code is split into pieces and run in parallel on different machines on the net. We also use an Army Corps of Engineers database system called the Data Storage System, written in Fortran (it would have been better to write that in C). It is specifically designed for time-series data. -- Ralph Finch 916-445-0088 rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch Any opinions expressed are my own; they do not represent the DWR ******************************************************************************** Date: Fri, 17 Aug 90 08:37:35 EDT From: System Admin (Mike Peterson) <pdn!uunet!alchemy.chem.utoronto.ca!system> Organization: University of Toronto Chemistry Department In Chemistry, there a several packages including GAUSSIAN 90, CADPAC, HONDO, MOPAC and MM2 that are used to determine the structure of molecules and their relative energies (and lots of other properties). These programs can be huge (>200000 lines of code for GAUSSIAN 90), and are >95% FORTRAN (mainly due to historical reasons probably, since most of these programs originated in the 70's, but there is no intention of rewriting them in C or anything else). Also, several high-end computer systems don't do all the optimizations in C that are done in FORTRAN, so you get better performance in FORTRAN (some of these computations can take many hours/days on a Cray). In our department, most people still use FORTRAN for most of their "home-grown" programs, mainly because FORTRAN has been the only language available on the scientific workstation / departmental computer systems until relatively recently, and it almost always performs better than C for such computations. In addition, some problems require data types that are a pain to emulate in C, like complex numbers and all the built-in functions that are available (csqrt, csin, etc.), not to mention some large libraries of FORTRAN routines: EISPACK, LINPACK, MINPACK, NAG. Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775 ******************************************************************************** Date: Mon, 20 Aug 90 17:42:24 EDT From: wcs@erebus.att.com (William Clare Stewart) Organization: AT&T Bell Labs I only know of four reasons you'd actually PREFER fortran over C: 1) COMPLEX numbers - C doesn't have them, and if the data you're working with needs them, it's much nicer to say X = Y * Z + J * OMEGA than x = cadd( cmul( y, z ) , cmul ( j, omega ) ); or whatever you have to do for exponentiation. Today I would solve this problem by using C++ or (yuk) Ada, both of which let you define your own data types. (Complex is one of the first that everyone does, so it's provided in the standard libraries.) 2) Existing commercial scientific software packages: It's nice to just BUY that Eigenvalue system rather than write it yourself and get the numerics right - - but presumably good packages are available, and you can call them from C as long as you're not trying to have THEM do I/O, so this reason no longer applies. 3) Existing locally-developed applications that do what you want, and are too annoying or poorly documented to rewrite - - for these you need to keep a Fortran guru around to maintain them, but unmaintainable code is a pain in any language - at some point it's cheaper to translate it or at least build walls around it and add any new stuff in separate C modules. 4) Your machine has a GREAT fortran compiler and a lousy C compiler - Not uncommon in the supercomputer world - Fortran is enough simpler that it's easy to write good vectorizing code for, while C's features (like pointers) sometimes mean that your compiler can't trust certain optimizations. In the rest of the world, C compilers are generally BETTER than fortran compilers, but the real win is usually the ability to write and maintain code better - if you can do a great C program in the same amount of work as a medium-quality fortran program, this will normally outweigh the compiler quality issues. Good luck; BIll --- # Bill Stewart 201-949-0705 erebus.att.com!wcs # AT&T Bell Labs 4M-312 Holmdel NJ 07733 Great!! We get to have a war to protect Exxon and King Fahd!! George W. Leach AT&T Paradyne reggie@paradyne.com Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (09/19/90)
I missed the original post, but feel a base urge to comment. I worked at the
Johns Hopkins Med. school as a system administrator of a dept. system for
a bunch of xray crystallographers. The ONLY language considered,
then, and for the most part now, was FORTRAN.
Besides the fact that it is what they always used
and it was what they knew, there were some other good reasons. There were
many packages in fortran, and fortran programs are, in general, extremely
portable. Fortran also, in general, has the best performance of any language.
When some people decided they would jump on the bandwagon and start using
C, they found a factor of 4 performance degradation for their application
and changed their minds (this is VAX VMS, VAXC vs. VAX Fortran).
While Unix is certainly becoming more prevalent, it is the unix bias of
C that makes it so non portable (I should say the 'standard' C library, the
language itself doesn't show all that much bias). Typical unix programs
are often a bear to port to other environments, due to the fact that C and
library encourage the programmer to be cute and use lots of neat unix specific
features. The C crowd (unix advocates or 'market research investment
bankers pretending they are computing authorities pushing the latest 'iron'
in the trade rags that runs unix because it was easier to pay at&t
than write something original') says that this is the 'standard'
library and all systems must implement it, but it's basically a one-to-one
mapping with the unix rtl and systems calls, and I'm not fooled. The systems
that do try to implement it (and I'm sure THEY have a hell of a time) end up
having to emulate unix, a mondo undertaking and a guaranteed performance
hit. I don't think people writing C programs in a unix environment 'get'
this ("huh? your not running unix? You're using a computer aren't you?
oh well i guess it's a MAC then?").
My experience has gradually come to make me loathe C. Yeah, sure,
fortran is a creaky old language and theres a lot of spaghetti code out
there and a lot of people writing good C programs (which brings up another
pet peeve: typing "nameofcprogram -crypticarg1crypticarg2..." on VMS !@&^%$!),
but when I write a program, I think I'll just use fortran (hell, I'll use
anything, just pleeeease not C, anything but !(@&@#%^# C). Then on the
other hand I could just bite the bullet and, gee, if I'm in a unix environment
it basically works, depending on what version of unix, and, yeah, I can just
grep the glob 'til I yacc, and, yeah they say this new unix box really has a
lot a MIPS, and, gosh, everyone else is and, oo i feel better now...
--
Tom O'Toole - ecf_stbo@jhuvms.bitnet - JHUVMS system programmer
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218
ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase