From chemistry-request@ccl.net Tue Dec 10 08:36:35 1991 Date: Tue, 10 Dec 1991 06:05 CDT From: Andy Holder Subject: FORTRAN vs. C To: CHEMISTRY@ccl.net Status: RO Sure C is more structured. So is Pascal (shudder). Sure C does somethings easier and better than FORTRAN. So does COBOL (goose- pimples). Perhaps a strength of FORTRAN is the lack of structure. On a less philosophical, but more religious note, FORTRAN is so much cooler than the other languages. Its the language of our youth. We leave our culture behind at the risk of losing our ident- ities and becoming lost wandering sheep in a multicultural world (Toungue firmly in cheek.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= DR. ANDREW HOLDER Department of Chemistry || BITNET Addr: AHOLDER@UMKCVAX1 University of Missouri - Kansas City || Internet Addr: aholder@vax1.umkc.edu Spencer Chemistry, Room 502 || Phone Number: (816) 235-2293 Kansas City, Missouri 64110 || FAX Number: (816) 235-1717 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From chemistry-request@ccl.net Tue Dec 10 10:05:30 1991 Date: Tue, 10 Dec 91 15:47:27 +0100 From: Juerg Hutter To: chemistry@ccl.net Subject: G90 symmetry Status: RO Dear Netters we have the following problem with GAUSSIAN 90. We want to make a force constant calculation of a molecule having 34 atoms in D3h Symmetry. We have the cartesian coordinates generated with an accuracy of 10**-9 Angstroms. Using these cartesian coordinates as input for GAUSSIAN 90 the program only finds CS Symmetry. The same problem occurs when we first generate a Z-matrix in internal coordinates. Does anybody have an idea how to solve this problem? Thanks a lot Juerg Hutter IPS, ETH Zurich hutter@ips.id.ethz.ch From chemistry-request@ccl.net Tue Dec 10 10:05:33 1991 Date: Tue, 10 Dec 91 09:47:23 -0500 From: jle@world.std.com (Joe M Leonard) To: chemistry@ccl.net Subject: QSAR programs Status: RO It seems that "contact Tripos" was the only answer to my earlier query to my posting regarding QSAR programs, although other mail I received indicated that Daylight (LogP) and BBN's Prophet are useful packages as well. Does this mean that the other commercial companies are (a) not doing a QSAR package, (b) not talking about a QSAR package yet or (c) the folks who know of codes other than those mentioned here are not reading the bboard or responding to posts...? I didn't receive any real information on contents of these packages - does this mean that the "traditional" descriptors are the only set in use (and so need not be mentioned)? I'd like to think that there's some new descriptors (electronic or structural) that have been developed and accepted over the last few years (other than CoMFA). Am I missing something? Joe Leonard jle@world.std.com From chemistry-request@ccl.net Tue Dec 10 11:08:49 1991 Date: Tue, 10 Dec 1991 15:42 GMT From: XRASIMMIE%cs8700.ucg.ie@OHSTVMA.ACS.OHIO-STATE.EDU Subject: more F90 vs C To: chemistry@ccl.net Status: RO Counihan's excellent ``Fortran 90'' Pitman 1991 isbn 0-273-03073-6 puts in perspective the F90 vs C argument On GOTO's he gives as examples GOTO 999 Bypass: IF (.FALSE.) THEN ........ ===> ......................... 999 CONTINUE END IF Bypass and 999 CONTINUE Jumpback: DO ............ ===> ............ GOTO 999 END DO Jumpback ------------------------------------------------- Dr. John M. Simmie Chemistry Department Roinn na Ceimice University College Col=iste na hOllscoile Galway Gaillimh Ireland Eire Fax: (+353)-91-25700 Fn:(+353)-91-24411x2451 ------------------------------------------------- From chemistry-request@ccl.net Tue Dec 10 11:10:06 1991 Date: Tue, 10 Dec 91 10:59:59 EST From: Joel M. Cohen To: chemistry@ccl.net Subject: structured programming Status: RO structured programming may be prettier to look at but how important is it really? goto statements are simply faster than calling subroutines, particularly in a conditional context. sometimes, fellas, the easiest way really is the easiest way. scientific code generally isn't written for computer buffs. it would be nice if, rather than ranting on about their superior abilities, these people were available to actually work with (gasp!) scientists who wished to streamline their code for computational (not reading) purposes. carry on, dr. joel cohen From chemistry-request@ccl.net Tue Dec 10 12:09:49 1991 Date: Tue, 10 Dec 91 17:00:41 GMT From: jnh@iris41.biosym.com (Jon Hurley) To: chemistry@ccl.net Subject: FORTRAN vs. C Status: RO OK, I normally steer away from these political issues, but I have had enough of these comments favoring FORTRAN. In all these messages about structured programming, people seem to be missing the point. Sure it is important that individual subroutines be written clearly, with indentation, meaningful variable names, straighforward control structures and suitable comments. But the crux of writting code that is extensible and easily maintable is modularity (i.e. using subroutines (or methods on objects or any other object oriented analog) that do a well defined thing and work on a known set of variables). FORTRAN does not have structures (although a few extensions have records). Since most reasonably complex (as scientific codes usually are) programs have dozens or hundreds of variables, the only way of passing the data into routines in FORTRAN is: 1) Use common blocks to keep global data. 2) Have subroutine calls with literally dozens or hundreds of arguments. The second approach is clearly infeasible and the former approach guarantees lack of modularity. For instance, let's say you want to modify a program to support two separate molecules instead of one. With FORTRAN global common block variables, you have no recourse but to rewrite the whole program; with C where you pass a pointer to a molecule structure into a routine, all you have to do is rewrite the calling routine. Yes FORTRAN is great for computational kernels. It has highly optimized compilers, and the form of the code strongly resembles the equations that it represents. But for data manipulation and extension of code based on pre-existing modules, and as I can attest the VAST majority of commercial computational code is just that, FORTRAN, without structures, is totally inadequate. Jon From jkl@ccl.net Tue Dec 10 13:38:32 1991 To: chemistry@ccl.net Subject: PDB format doc in LaTeX Date: Tue, 10 Dec 91 13:38:23 EST From: jkl@ccl.net Status: RO Here is your Holiday Season present (I am trying to be politically correct, after being a male-chauvinist-pig and a fascist, I do not want to be called a bigot): A machine readable PDB format description ========================================= Be aware that you have got what you paid for. There are obviously many mistakes in this file (I did not type it --- if I did, it would have even more typos). I would be thankful for your corrections (tell me where you see a typo and I will try to fix it when I am back - send these to jkl@ccl.net or JKL@OHSTPY.BITNET). This is a LaTeX/FrameMaker rendition of the PDB document entitled: Protein Data Bank Atomic Coordinate and Bibliographic Entry Format Description. To print it you need: 1. LaTeX 2. dvips 3. PostScript printer If you do not have 1 and 2 but you have 3, you can still grab the PostScript file (LARGE !!!). The following files are located in /pub/chemistry/pdbdoc directory: -rw-r--r-- 1 jkl 376132 Dec 10 12:11 pdbformat.ps (1) -rw-r--r-- 1 jkl 78083 Dec 10 12:11 pdbformat.tex (2) -rw-r--r-- 1 jkl 3888 Dec 10 13:05 pdbposting (3) -rw-r--r-- 1 jkl 25740 Dec 10 12:11 pg24a.eps (4) -rw-r--r-- 1 jkl 24922 Dec 10 12:11 pg24b.eps (5) -rw-r--r-- 1 jkl 25412 Dec 10 12:11 pg26.eps (6) -rw-r--r-- 1 jkl 23281 Dec 10 12:11 pg27.eps (7) -rw-r--r-- 1 jkl 24988 Dec 10 12:11 pg28.eps (8) -rw-r--r-- 1 jkl 23283 Dec 10 12:11 pg29.eps (9) -rw-r--r-- 1 jkl 24648 Dec 10 12:11 pg30.eps (10) -rw-r--r-- 1 jkl 23620 Dec 10 12:11 pg31.eps (11) -rw-r--r-- 1 jkl 24777 Dec 10 12:11 pg32.eps (12) -rw-r--r-- 1 jkl 2285 Dec 10 11:36 rotaten.sty (13) You can get them by ftp or by our e-mail distribution software. FTP: ==== Provided that you have ftp, do the following (I assume you run a UNIX) %mkdir pdbdoc %cd pdbdoc %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> mget * (then answer yes few times) ftp> quit E-MAIL: ======= Send the following message to OSCPOST@ccl.net or OSCPOST@OHSTPY.BITNET: send ./pdbdoc/pdbformat.ps from chemistry send ./pdbdoc/pdbformat.tex from chemistry send ./pdbdoc/pdbposting from chemistry send ./pdbdoc/pg24a.eps from chemistry send ./pdbdoc/pg24b.eps from chemistry send ./pdbdoc/pg26.eps from chemistry send ./pdbdoc/pg27.eps from chemistry send ./pdbdoc/pg28.eps from chemistry send ./pdbdoc/pg29.eps from chemistry send ./pdbdoc/pg31.eps from chemistry send ./pdbdoc/pg32.eps from chemistry send ./pdbdoc/rotaten.sty from chemistry The files will be forwareded to you automatically. You will have to save them and then edit out a top portion of these files before they can be used (header extends from the top of the file to the SECOND blank line - the one which follows: *** from oscpost, d-a-t-e t-i-m-e ***) Get the pdbformat.ps file only if your e-mail gateway allows files larger than 100kBytes - many gateways will not let you do it. ========================================================================= If you have LaTeX and dvips on your machine, do: 1. change to the directory with the files retrieved in the way described above. 2. latex pdbformat 3. latex pdbformat 4. dvips -o pdbformat.ps pdbformat.dvi 5. lpr -PYour_postscript_printer pdbformat.ps I assume you are using UNIX (to be exact, a UNIX with BSD extensions). If you do not, you probably know what to do. If you do not know, ask somebody (but not me, I do not know). If you do not have LaTeX, then you have only a need for pdbformat.ps file. You do not need the others. You just print this file on you PostSrript printer (e.g.: lpr -PYour_postscript_printer pdbformat.ps) If you do not have a PostScript printer, forget the whole thing. On the other hand, if you do not have LaTeX, you should. You might want to look into /pub/chemistry/tex and grab the file tex_for_sgi (it will not make you wiser, but will show you the light). Jan Labanowski Ohio Supercomputer Center jkl@ccl.net JKL@OHSTPY.BITNET From chemistry-request@ccl.net Tue Dec 10 16:49:49 1991 Date: Tue, 10 Dec 91 16:27:05 EST From: states@ncbi.nlm.nih.gov (David States) To: chemistry@ccl.net Subject: RE: Fortran vs. C - enough Status: RO IMHO we have clearly establish the fact that different languages have different uses and the religous nature of personal preferences in programming language. If this were a newsgroup I would simply add 'Fortran vs. C' to my kill file and be done with it. Unfortunately no such mechanism is available for E-mail lists (and they tie up more network resources to boot). I wonder if we might drop the subject and go on to other matters. David States From chemistry-request@ccl.net Tue Dec 10 19:44:16 1991 Date: Tue, 10 Dec 1991 17:37 MST From: YAMAMURA%CGF@Arizona.edu Subject: Source and Contacts for MEDNMR, NMRGRAF -- Many Thanks To: chemistry@ccl.net Status: RO Would be grateful to receive vendor name, address, telephone number for the following NMR related programs: MEDNMR NMRGRAF Please send your responses to: yamamura@cgf.chem.arizona.edu Thanks very much and Happy Holidays! Susan Yamamura From chemistry-request@ccl.net Tue Dec 10 20:11:56 1991 Date: Tue, 10 Dec 91 20:04:44 -0500 From: jle@world.std.com (Joe M Leonard) To: chemistry@ccl.net Subject: Attack of the killer workstations Status: RO Reviewing the recent discussion regarding C vs. Fortran and structured vs. spagetti coding, isn't it reasonable to consider the time of the programmer as more important that the code's runtime (within reason)? Given that approx. $20k workstations are comparable to Cray machines, isn't 10-ish% overhead more than worth the human time savings through better-thought- out programming (structured, modular, OO, etc.)? I hope the day's past for really needing to count cycles in loops - as one can wait for the next version of workstation xxx to gain appreciable speedups. Obviously, this isn't the case for mpp machines, for which the consensus is that one must rethink and/or reimplement algorithm's in order to use the hardware to advantage. Still, this might prove to be an example where clearer coding styles might turn out to be a win after all... Joe Leonard jle@world.std.com From chemistry-request@ccl.net Tue Dec 10 21:41:53 1991 Date: Tue, 10 Dec 91 21:20:49 -0500 From: fredvc@esvax.dnet.dupont.com To: %chem@ccl.net Subject: About those workstations.... Status: RO RE: Attack of the killer workstations From: Joe Leonard jle@world.std.com >>Reviewing the recent discussion regarding C vs. Fortran and structured vs. >>spagetti coding, isn't it reasonable to consider the time of the programmer >>as more important that the code's runtime (within reason)? Given that >>approx. $20k workstations are comparable to Cray machines, isn't 10-ish% >>overhead more than worth the human time savings through better-thought- >>out programming (structured, modular, OO, etc.)? I hope the day's past >>for really needing to count cycles in loops - as one can wait for the next >>version of workstation xxx to gain appreciable speedups. We have found it to be a mistake to depend upon workstation performance (MIPS/MFLOPS), per se. There is a lot that goes into getting good perform- ance out of a box besides processor speed. This becomes painfully clear as the problem gets large. Caching is commonly used in such systems, and this can quickly become a performance bottleneck. What you pay for in getting a CRAY is a balanced system in terms of cpu, memory access, and disk access speeds. >>Obviously, this isn't the case for mpp machines, for which the consensus is >>that one must rethink and/or reimplement algorithm's in order to use >>the hardware to advantage. Still, this might prove to be an example where >>clearer coding styles might turn out to be a win after all... Good code runs better than bad code on ANY machine. The "edge" tends to be bigger on a CRAY, but the edge is still there on a VAX, SUN, IBM 6000, etc. We recently optimized a program for the CRAY and found that the optimized version ran better on the ALL machines we tested. CRAY speed up: ~63x VAX speed up: ~17 IBM 6000 speed up: ~20 Mearly putting the original code on a box with a faster cpu would not give this kind of payback. There was nothing "pathological" about the program. It just needed some TLC!! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FREDERIC A. VAN-CATLEDGE Scientific Computing Division || Office: (302) 695-1187 Central Research & Development Dept. || FAX: (302) 695-9658 The Du Pont company || P. O. Box 80320 || Internet: fredvc@esvax.dnet.dupont.com Wiilmington DE 19880-0320 || ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From chemistry-request@ccl.net Tue Dec 10 22:00:04 1991 Date: Tue, 10 Dec 1991 21:52 EST From: Dale Southard Subject: modular vs spagetti code To: chemistry@ccl.net Status: RO Joe Leonard(jle@world.std.com) >Reviewing the recent discussion regarding C vs. Fortran and structured vs. >spagetti coding, isn't it reasonable to consider the time of the programmer >as more important that the code's runtime (within reason)? Given that >approx. $20k workstations are comparable to Cray machines, isn't 10-ish% >overhead more than worth the human time savings through better-thought- >out programming (structured, modular, OO, etc.)? I hope the day's past >for really needing to count cycles in loops - as one can wait for the next >version of workstation xxx to gain appreciable speedups. Excellent point. I just came across (and have now lost) some figures that compare the costs of various phases of programming/computer usage. The most expensive part of any computer was always the programmer. This explains and justifies the R&D in 4th Generation Languages which are always less efficient from a CPU/wall time prespective than comparable 2nd/3rd GLs. The same can be said of modular vs spagetti code (though modular usually easier to maintain AND runs much faster on vector/pp machines). Dale PS -- 20k workstation = Cray Y/MP ?? Surely you mean only in MIPS (Meaningless Indication of Processor Speed), not real-world throughput! Though if you don't I would like the address of the workstation company. From jkl@ccl.net Tue Dec 10 22:03:33 1991 To: chemistry@ccl.net Subject: C vs Fortran summary Date: Tue, 10 Dec 91 22:03:26 EST From: jkl@ccl.net Status: RO Thanks to Joe M Leonard we have a summary of the first wave of C versus Fortran discussion and comments which he got personally. Since some of us expressly wished to limit this discussion, I am not posting this long (though very interesting summary) but it is available for downloading at any time. ftp'ers can get it as: %ftp 128.146.36.48 (or ftp www.ccl.net) Login: anonymous Password: your e-mail address ftp> cd pub/chemistry ftp> get c_vs_fortran ftp> quit People not blessed with Internet can get it by e-mail. Send message: send c_vs_fortran from chemistry to OSCPOST@ccl.net or OSCPOST@OHSTPY.BITNET. Happy reading... Jan Labanowski Ohio Supercomputer Center (in case you forgot where this mail is coming from) jkl@ccl.net From chemistry-request@ccl.net Tue Dec 10 23:46:45 1991 Date: Tue, 10 Dec 91 20:17:35 PST From: d3f012@gator.pnl.gov Subject: Object-Oriented Electronic Structure Codes To: chemistry@ccl.net Status: RO I would like to hear from any individuals actively working on electronic structure codes in C++ (or any OO language). This could also include anyone who is seriously planning to do so in the near future. My intent is to establish a mailing list with others interested in exchanging ideas for defining and implementing libraries of quantum chemistry objects. Periodic summaries to the OSC mail list could be performed. Thanks Mark Thompson Molecular Science Research Center Battelle Pacific Northwest Laboratory d3f012@pnlg.pnl.gov 509-375-6734