From laaksone@convex.csc.fi Wed Dec 11 04:52:35 1991 Date: Wed, 11 Dec 1991 11:55:00 +0200 From: Leif Laaksonen To: chemistry@ccl.net, jkl@ccl.net Subject: Re: C vs Fortran summary Status: R I guess you have to hit me for this interesting but not too fruitful discussion about C and Fortran. It's strange that this subject still can make this much discussion! My intention was, however, to talk about applications. I guess quite many of us here on the network write now new code for the future needs in computational chemistry. A good question was/is: What are the needs? What should we demand from the software houses? What kind of tools/rules should we use now so next generation don't have to rewrite everything? Can we even manage to agree about some object classes for code in computational chemistry? I will not even mention the possibility of a common standard for file transfer between programs. Please feel free to let your imagination flow. -leif laaksonen From chemistry-request@ccl.net Wed Dec 11 05:25:05 1991 Date: Wed, 11 Dec 91 09:40 FWT From: "Peter de Vaal" To: Computational Chemistry List Subject: C and Fortran Status: R > In response to the original subject : I have just finished implementing the Fletcher - Powell algorithm for geometryoptimization in our ab initio package ASTERIX. Since I wanted to write the procedure together with a new user interface (such a thing which was called the input procedure in the past) and then let it control the execution of the quantum chemical modules (scf and gradient calculations) I wrote it in the language C and used the function fork() to execute the QC modules. > In contribution to the discussion C vs Fortran the following: Why choosing for one of the two? Just using the best language for the task to be performed is the most logical thing to do. In my program all input/output and data manipulation is written in C , while for the calculations use is made of the Fortran scientific library functions (sorry, I should call them subroutines). These subroutines interface well if you take care for the small differences (matrices inverted). Writing a user interface takes according to my experience less than a quarter of the time using C rather than Fortran. On the other hand, why waste time on rewriting matrix manipulation routines in C while highly efficient Fortran routines exist? Peter de Vaal , Lab. de Chimie Quantique Strasbourg, France From chemistry-request@ccl.net Wed Dec 11 08:33:25 1991 Date: Wed, 11 Dec 1991 08:18 EST From: "DOUGLAS A. SMITH" Subject: Re: Source and Contacts for MEDNMR, NMRGRAF -- Many Thanks To: YAMAMURA%CGF@Arizona.edu Status: R NMRGraf: Polygen/Molecular Simulations 796 North Pastoria Avenue Sunnyvale, CA 94086 voice 408-732-9090 fax 408-732-0831 Doug Smith University of Toledo From chemistry-request@ccl.net Wed Dec 11 08:53:25 1991 Date: Wed, 11 Dec 91 08:43:22 -0500 From: jle@world.std.com (Joe M Leonard) To: chemistry@ccl.net Subject: re: 20k workstations Status: R I guess a bit of marketing hype leaked through... I have seen several benchmarks that suggest that the performance of the latest class of workstations are similar in performance to an XMP, and provide a significant fraction (1/5th or more) of a YMP. Naturally, this dependes on the particular code - scalar stuff really favors the workstation while vector stuff plays to the Cray. The point to be considered, however, is the price/performance ratio (gee, I guess this is used to attack just about every salesman in existance...). \ Commodity chips are spreading everywhere - with SPARC's used in the latest Connection Machine... Joe Leonard jle@world.std.com From chemistry-request@ccl.net Wed Dec 11 10:18:02 1991 Date: Wed, 11 Dec 91 09:04:08 CST From: lwalsh@nemo.life.uiuc.edu (Laura L. Walsh) To: chemistry@ccl.net Subject: Annotation of PDB files Status: R I have available an annotated list of all of the Brookhaven PDB files. In it I list related files together and explain the differences between them. This is the same file that I recently made public in bionet.molbio.proteins. The file is approximately 1500 lines. If you would like to have a copy, send me a note and I will email it to you. It should also still be available from bionet.molbio.proteins. Laura Lynn Walsh (lwalsh@nemo.life.uiuc.edu) (217) 244-6764 Beckman Inst., Univ. of IL * 405 N. Mathews Ave. * Urbana, IL 61801, USA From chemistry-request@ccl.net Wed Dec 11 10:37:05 1991 Date: 11 Dec 91 10:25 LCL From: PA13808%UTKVM1.BITNET@OHSTVMA.ACS.OHIO-STATE.EDU To: CHEMISTRY@ccl.net Subject: BITNET mail follows Status: R VAX ULTRIX SOFTWARE I have free access to a VAX 9000 for several months and would like to h about codes which are available for this machine, I would prefer UNIX codes and am particularly interested in any ab initio codes which I could get to use. What about MOPAC 6? We have an older VMS version of MOPAC.There are people here who would be interested in a molecular mec hanics program. JOHN E. BLOOR(PA13808 AT UTKVM1.utk.edu.phn 615 974-3427) From chemistry-request@ccl.net Wed Dec 11 10:37:18 1991 Date: 11 Dec 91 15:17:42 GMT From: Siegfried.Schneider@rrze2.rrze.uni-erlangen.de To: CHEMISTRY@ccl.net Subject: F90 -> C Status: R Concerning the whole discussion Fortran vs. C it may sound ironic to hear about the first real FORTRAN 90 compiler. It is from NAG and converts the f90 source into C-code. Peter Gedeck From chemistry-request@ccl.net Wed Dec 11 12:39:37 1991 Date: Wed, 11 Dec 91 12:18 EST From: "Scott Le Grand" Subject: Re: F90 -> C To: Siegfried.Schneider@rrze2.rrze.uni-erlangen.de Status: R >Concerning the whole discussion Fortran vs. C it may sound ironic to hear >about the first real FORTRAN 90 compiler. It is from NAG and converts >the f90 source into C-code. > >Peter Gedeck > Now THAT'S FUNNY! I'm a C programmer myself and I created my own system from the ground up for my research because I couldn't stand how badly all of the pre-existing code is written. One also learns an awful lot about what one's programs are actually doing when one does this. I'd recommend that EVERYONE who seriously wishes to make a career in computational chemistry develop at least one serious and significant application from scratch during their career. My own arguments in favor of C are 1) Structures, 2) Modular Code, and 3) Boolean bit operators. The complex data type could EASILY be added to C. I don't know why it hasn't been done yet, really. Most of the other annoying features of C could easily be removed without affecting the rest of the language. I don't think the same can be said of FORTRAN. I programmed in FORTRAN IV and 77 for 8 years before making the switch to C. I am glad I have done so. My code is far more portable and readable now... Scott From chemistry-request@ccl.net Wed Dec 11 12:50:58 1991 Date: Wed, 11 Dec 91 18:38:16 +0100 From: Juerg Hutter To: chemistry@ccl.net Subject: G90 Symmetry Status: R Thanks to all who responded to my question. The accuracy of the cartesian coordinates were the problem. We finaly had success when we used NEWZMAT with the commandline '-ixyz -lsymm -symm' and changed one parameter in the resulting Z-matrix from 120.00000001 to 120.00000000. Juerg Hutter From jkl@ccl.net Wed Dec 11 13:50:01 1991 To: chemistry@ccl.net Subject: PDB coordinate file list Date: Wed, 11 Dec 91 13:49:53 EST From: jkl@ccl.net Status: RO Thanks to Laura Lynn Walsh, Beckman Institute, University of Illinois UC, we have another addition to the pdbdoc directory in pub/chemistry. This is a file which holds list of coordinate files in the PDB format (much better than the PDB Bulletin). As usual, you can get it by ftp or E-mail. It is circa 60kBytes. For ftp users: %ftp www.ccl.net (or ftp 128.146.36.48) Login: anonymous Password: Your_E-mail_address ftp> cd pub/chemistry/pdbdoc ftp> ascii ftp> pdb_file_list ftp> quit You can also get it by e-mail. Send a message: send ./pdbdoc/pdb_file_list from chemistry to OSCPOST@ccl.net or OSCPOST@OHSTPY.BITNET and the file will be automatically delivered to you. Thanks again to Dr. Walsh for this gift. Jan jkl@ccl.net From chemistry-request@ccl.net Wed Dec 11 14:18:15 1991 Date: Wed, 11 Dec 91 14:10:14 EST From: G. Ravishanker To: chemistry@ccl.net Subject: F90 -> C Status: R Hi I have seen a sudden increase in activity in this group related to Fortran vs C. It is indeed interesting and I thought I will voice my opinion on this too. I have been programming in both Fortran '77 and C for the past several years. I try to keep all my scientific code in Fortran and others, such as networking, input/output, parsing using lex and yacc in C. I personally feel that this kind of separation builds on the strengths of each language. Given that what we are trying to accomplish is a readable and modular code, it is hard to justify writing a piece of well readable scientific code in C. Since several of the users of that code are likely to be Fortran programmers, what is readable in C may not be well readable for a Fortran programmer. Regarding portability, I have found that several of the well written C programs are indeed system dependent, however small the system dependency may be. Same can be argued for Fortran too. One can always write Fortran programs with minimal system dependency. Fortran '77 gives enough flexibility to organize your program to look like a "structured program", if you wish to do that. You can write top-down programs, go-to less programs and all that. Someone needs to explain this to me clearly that structured programs are easier written in C than in Fortran '77. The only major disadvantage is you cannot have recursive subroutines in Fortran (some Unix machines even allow that), but how many have we all written in our lifetime! (factorial, Tower of Hanoi and Eight Queen problem....) What has gotten us much more than anything else in Fortran code (other than old spaghetti code) is the lack of bounds checking for arrays. Some of the old Fortran programs used this to their advantage in manipulating some scratch commons differently in different subroutines. But it stinks. You run an MD simulation and burn 5 hrs of Cray time only to see that your temperature in the common block got overwritten by the next to last member of the previous array in the common block. C of course would not allow you to do it (sometimes you can, in case of strings...) Though I do not have many things in support of C in the above paragraphs, I do a fair amount of code development in C, but I feel that it is more appropriate for doing things other than developing scientific code. Once you have put in all the strengths of C to develop a very good piece of code, you have lost a fair amount of your scientific users. Thanks for your attention. Ravi From chemistry-request@ccl.net Wed Dec 11 15:26:21 1991 Date: Wed, 11 Dec 91 12:11:14 -0800 From: ross@zeno.mmwb.ucsf.EDU (Bill Ross) To: chemistry@ccl.net Subject: recursion Status: R I was planning to stay out of the Fortran vs. C debate, but Ravi's mail brings up an aspect on which I can contribute actual data. > The only major disadvantage is you cannot have recursive > subroutines in Fortran (some Unix machines even allow that), but how many > have we all written in our lifetime! (factorial, Tower of Hanoi and Eight > Queen problem....) I am writing a new analysis routine for Amber. I started out in Fortran, biting the bullet e.g. by simulating data structures for linked lists of objects w/ mixed types of data in them, since I wanted to make sure that energy calcs were equal to the Fortran ones from Amber's major programs. However, I gave up on Fortran when I tried to implement nested set theoretic group specifications, since the recursive form is natural to me for any kind of parsing operations. I also expect to use recursion for coord set extraction criteria, e.g. allowing the user to dump a set from an md trajectory if torsion energy of group1 < 4.1 AND (rms deviation of group2 < .4 OR ...) I am also glad to be out from under the static memory allocation problem of Fortran. Hopefully the group working on numerical C issues can fix the array problems that inhibit compiler optimization. For the array addressing problem (you can't use array[i][j] like fortran's array(i,j) since [][] denotes an array of pointers to arrays) I tested the Numerical Recipes in C book's solution since I was skeptical that the fetching of the pointer to the secondary array would be as fast as the normal index computation array[i + j * size_i], and found the results to vary widely on different machines, and even to flip back & forth using successive optimization levels (this was just for a 2D array). I wound up following my prejudice and using [i + j * size_i]. > What has gotten us much more than anything else in Fortran code (other > than old spaghetti code) is the lack of bounds checking for arrays. Some > of the old Fortran programs used this to their advantage in manipulating > some scratch commons differently in different subroutines. But it stinks. > You run an MD simulation and burn 5 hrs of Cray time only to see that your > temperature in the common block got overwritten by the next to last member > of the previous array in the common block. C of course would not allow you > to do it (sometimes you can, in case of strings...) Actually, C pointers allow all sorts of serious mischief (in return for virtually unlimited flexibility in ways of treating data.) > Once > you have put in all the strengths of C to develop a very good piece of > code, you have lost a fair amount of your scientific users. (I hope not!) I don't see how users would care about the implementation language, tho users that want to modify would face a slight barrier. Hopefully these discussions will be convincing them that there are things worth having now beyond current Fortran. One more thing - the extra time it takes to figure out 1000 lines of spagetti code is probably more than the time it takes to learn enough C to understand the C equivalent, after which C is mostly gravy in this respect. Bill Ross From jkl@ccl.net Wed Dec 11 16:36:51 1991 Date: Wed, 11 Dec 91 16:36:45 -0500 From: jkl@ccl.net To: chemistry@ccl.net Subject: Re: F90 -> C Status: R Forwarding, forwarding... (jkl@ccl.net) ---------- Begin Forwarded Message ---------- >From rupley!root@cs.arizona.edu Wed Dec 11 15:34:10 1991 Date: Wed, 11 Dec 91 20:35:50 GMT From: rupley!root@cs.arizona.edu (Super-User) To: arizona!ccl.net!chemistry-request@cs.arizona.edu Subject: Re: F90 -> C Cc: rupley!local@cs.arizona.edu If you are writing small programs, say 1000 lines or less of source code, then probably it doesn't matter what language you use. Whatever is convenient for you or your environment. If you are part of a large project, say 10000 lines or more of source, then if you and your colleagues are using Fortran, you probably shouldn't be. Fortran doesn't support a high enough level of abstraction. I would be interested to see a comment from someone who (1) has been part of a large project (10000+ lines of source) written in Fortran, (2) has written both C (or C++, etc) and Fortran code, and (3) would use Fortran again for a large project. Except for a posting like the above, I would hope that this thread could end. John Rupley Biochemistry rupley@cs.arizona.edu ----------- End Forwarded Message ----------- From chemistry-request@ccl.net Wed Dec 11 16:46:35 1991 Date: 11 December 1991 15:30:09 CST From: "Bob Goldstein 6-6664" To: Subject: Status: R On the note of recursion, I have found exactly 2 cases where it was useful for me. 1) Multidimensional integration. I pass an external function to a 1-D integrator, and the function itself also calls the same 1-D integrator. Perfectly legit, but in fortran you would need 2 copies of the same 1-D integrator. 2) Sometimes I want to have nested do-loops, where the depth of nesting is determined at run time. With recursion, a function calls itself, incrementing a global variable until it determines a limit set at run-time. How would you do this in fortran? bobg From chemistry-request@ccl.net Wed Dec 11 17:15:36 1991 Date: Wed, 11 Dec 91 16:04:44 CST From: shepard@dirac.tcg.anl.gov (Ron Shepard) To: chemistry@ccl.net Subject: FORTRAN vs. C Status: R For programmers interested in converting existing FORTRAN programs to C, there is a book entitled "From Fortran to C" by J. F. Kerrigan ISBN 0-8306-7661-9, which contains some useful information. It is organized by Fortran keyword, and in each section gives a C replacement for the Fortran construct. I cannot really recommend the book as a reference for going the other way, (i.e. for C programmers learning about Fortran) because most of the Fortran examples are not particularly well written. For example, (1) most of the format statements have hollerith strings in them (instead of the conceptually simpler, consistent, use of '-delimited character strings), (2) variables in common blocks are initialized in data statements (in f77 such initializations must be localized in block data subprograms), (3) named common blocks appear inconsistently in save statements (in f77 if a block is saved anywhere, it must be saved everywhere), and (4) the examples use fortran specific intrinsic functions (a bad programming practice; generic intrinsics should always be used when possible to enhance portability). Another general shortcoming of the book, particularly for scientific programmers, is that all of the correspondences between Fortran and C data types are based on a 16-bit microcomputer point of view. For example, C types "double" and "long double" are both mapped to Fortran "double precision" which in turn is associated in the text with "real*8". (No mention is made of fortran "real*16" which is supported on many machines as 128-bit floating point.) However, I think on a Cray, a C "double" maps to "real", which is really equivalent to either of the fortran declarations "real*4" or "real*8", and C "long double" maps to "double precision", which is really equivalent to "real*16". Maybe someone with more C experience on a Cray can correct this if I'm wrong. There is also some confusion introduced in the book when C "char" is identified with Fortran "character". In fact, the C "char" data type is really an integer data type. A better correspondence would be C "char" with the result of the fortran intrinsic ichar() operating on a character*1 argument. Character variables in Fortran are really structured entities, with the components of the structure hidden from the programmer (until cross-language calls are needed, at which time the actual structure must be dealt with explicitly). This applies to fortran character values of any length, whereas in C long strings are associated with char arrays. As far as I know, this is the only book available that is devoted to bridging the Fortran to C language gap. -ron shepard p.s. I know that nonprogrammers on this bboard may be getting bored with this discussion, but as long as useful information is being exchanged, I'm reluctant to encourage its termination. Bear with us and you'll eventually benefit from the superior code that we write. (:-) From chemistry-request@ccl.net Wed Dec 11 17:29:51 1991 Date: Wed, 11 Dec 91 14:30:48 PST From: crc@iris12.biosym.com (Clifford Randall Cannon) To: chemistry@ccl.net Subject: At the risk of making a self-contradictory statement, Status: R *I* would like to see posters STOP TRYING TO CENSOR the content of this forum with "I hope this will end" and "Let's get back to [poster's favorite subject]". If NO ONE were interested in a subject, it would quickly die. If YOU are not interested, you can dispose of the posting in seconds. Part of the value (my opinion) of this reflector is the subjects that come across that may someday be useful--and I would not have thought of otherwise. So, while I defend your freedom to write "This subject doesn't interest me", I will encourage everyone, including you, to write about whatever interests THEM! From chemistry-request@ccl.net Wed Dec 11 22:55:28 1991 Date: Wed, 11 Dec 91 19:57:03 CST From: shepard@dirac.tcg.anl.gov (Ron Shepard) To: chemistry@ccl.net Subject: Initial Impressions of NAG f90 Status: R I have just finished with a Fortran 90 workshop here at Argonne which was presented by Walter Brainerd and Brian Smith, both associated with the ANSI X3J3 committee. Numerical Algorithms Group, Inc. (NAG) was one of the sponsors, and we used their compiler. This compiler has recently been reviewed in "The Fortran Journal", of which Walter Brainerd is a coeditor. I thought you might want to hear some brief comments on my initial experiences with the NAG f90 compiler. One thing that was not clear from my previous readings, which included "Fortran 90 Explained" by M. Metcalf and J. Reid and of various drafts from the X3J3 committee over the past 10 years or so, was the relation between modules and files. For example, it was clear that MODULE A could not reference MODULE B which in turn referenced MODULE A. However, the following situation is also not allowed, and this only became apparent with experimentation. Suppose you have FILE1 which consists of MODULE B and subroutine SUB1, the latter of which in turn uses MODULE A. Suppose you also have FILE2 which consists of MODULE A and subroutine SUB2, the latter of which uses MODULE B. FILE1: MODULE B FILE2: MODULE A ... ... END MODULE END MODULE SUBROUTINE SUB1 SUBROUTINE SUB2 USE A USE B ... ... END END Since the modules do not reference each other, infinite recursion is not implied. However, the f90 compiler cannot compile either file! The reason? The compiled version of MODULE A must be available before SUB1 is compiled, and the compiled version of MODULE B must be available before SUB2 is compiled. The solution to the delima is obvious, but such a situation might arise during the process of converting existing f77 code to use some f90 features. Fortran 90 programmers will undoubtedly need to become familiar with "make"-like utilities in order to guarantee the correct compilation order of large program systems. This type of compilation-order dependence is similar to the way some vendors have implemented "inlining" in existing f77 compilers. Pointers are included in f90, but not in the same manner as in C or as in various f77 extensions. In C and in f77 dialects, pointers are declared and manipulated like integer variables. In f90, pointers are declared, but they cannot be referenced directly like a variable. Instead, the pointer is automatically dereferenced, so any references to a pointer are really references to the data to which it points. However, this does not really seem to place any restrictions on pointer storage, since derived data types (equivalent to struct{} in C) can include pointers. In fact, a derived data type can consist only of a pointer, so an array of these objects is functionally equivalent to an array of pointers. A better way to think about f90 pointers, based on my limited experience, is to think of them as runtime equivalence statements. (Old time fortran programmer's ears perk up here, while C programmers shudder at the thought (:-) ). Optimization problems associated with pointers in other languages are avoided to some extent in f90 by restricting the data objects within the compilers scope to only those items which have been explicitly declared as pointer TARGETs. Time will tell, but I think this implementation of pointers is something that we can live with (:-). As has been mentioned before on this bboard, the NAG compiler produces C code. Consequently, it has the syntax advantages of f90, but the runtime performance handicaps of C. Some quick tests on some matrix operations indicated about a 4x penalty compared to f77 on a Sun. However, this must be put in perspective. NAG's purpose in developing the compiler is so that they can begin porting their (massive) subroutine library to f90. At this time they are more interested in getting the syntax right, and in producing correct final results, than in producing optimal object code. They will eventually rely on vendor-supplied f90 compilers to produce the machine-specific libraries in object form. Placing subroutines within modules resulted in a couple of unexpected surprises. First, since the routine's interface is defined within the module, you actually generate compile-time errors when you have the wrong number or types of arguments when the routine is referenced. This is analogous to a compile-time error you might get from a f77 compiler with an incorrect intrinsic function reference such as MAX(REAL,INT). The second surprise (to me) was that the routines within a module are visible only to subprograms that explicitly USE the module. Consequently, it is perfectly legit to have two completely different subprograms with the same name. If references to these occur in different subprograms, then there is no conflict about which routine is referenced in each case. If the references occur in the same routine, then at least one of them must be renamed locally to avoid conflicts (the USE statement allows this). With this encapsulation feature of modules, it seems that the "name space pollution" problems associated with the development of large program systems have been solved. However, a word of caution: Developers should take some time in designing modules in order to derive the full benefit from this feature -- the idea is to expose just enough, but not too much, of the module to the calling program. Another nice thing about f90 is that the concept of "generic" functions has now been extended to user-written subprograms. For the C programmers who might still be reading this, a generic function in f77 is one that produces different results depending on the types of its arguments. If S is REAL, D is DOUBLE PRECISION and Z is COMPLEX, then it is legal (in fact recommended in many cases) to use SQRT(S), SQRT(D), and SQRT(Z) instead of the "specific" function references SQRT(S), DSQRT(D), and CSQRT(Z). The function results are defined to be the same as the argument type in this case, but generally in f90 it is completely up to the programmer. One could define a generic dot product routine, GDOT(x,y), which returns an integer given integer arguments, a real result given real vector arguments, a double precision result given double precision arguments, and, perhaps just as importantly, which generates a compile-time error if the vector arguments don't match one of the allowed types. Of course, a programmer could still override the interface if he wanted to and pass in whatever he wanted - this is fortran after all (:-). Although REAL and DOUBLE PRECISION are still defined, there is now a general way of specifying precision that allows code to be portable between, e.g. a 32-bit workstation and a 64-bit Cray. There are two possible values returned from the SELECTED_REAL_KIND() intrinsic function in the NAG compiler: 1 for real*4 and 2 for real*8. Mixed-precision arithmetic is also supported in this same manner, with the old f77 rules suitably generalized. An interesting benefit of the f90 implementation is that if a compiler supports say 64-bit floating point arithmetic, it is now REQUIRED to support also (64-bit-real,64-bit-imaginary) COMPLEX arithmetic. This was not the case in f77, where it was legal to support 32-bit real and 64-bit double precision arithmetic, but only (32-bit-real,32-bit-imaginary) COMPLEX arithmetic. In fact, in f77 there was not even a portable way to support two different precisions of complex arithmetic. As an aside, it will be interesting to see if, for example, DEC decides to support both of its 64-bit floating point types in f90 in its VAX architecture. With f77, you could compile routines for one representation or the other, but you'd better not mix them. In f90, I believe that there is sufficient power to allow programmers to access both representations in the same subprogram. Finally, I guess I should say that since f90 contains f77 as a subset, there is nothing that can be done in f77 that cannot be done in f90. There are a few gotcha's involving conflicts between old external routines and new intrinsics, but these are very easily resolved with the addition of explicit EXTERNAL declarations. You don't even have to go in and rename the old routines. Now when someone says "that routine could be optimized in f77 but not in f90", you know it's probably not true. Time will tell if f90 is going to be a success, but I must say that it looks pretty good so far with this initial NAG f90 implementation. There are only a few things that I consider "missing", and I've been working around these for years in f77, so I know what to do about them and I'm not going to complain now. There is not another language that I would rather have to learn. Ask me in a couple of years and I may have a different story. Ron Shepard shepard@tcg.anl.gov