From dmit@nmr1.ioc.ac.ru Thu Nov 21 03:39:11 1996 Received: from nmr-dmit.ioc.ac.ru for dmit@nmr1.ioc.ac.ru by www.ccl.net (8.8.2/950822.1) id DAA14327; Thu, 21 Nov 1996 03:30:40 -0500 (EST) Received: from nmr-dmit (dmit@localhost [127.0.0.1]) by nmr-dmit.ioc.ac.ru (8.6.12/8.6.9) with SMTP id LAA00790 for ; Thu, 21 Nov 1996 11:20:21 +0300 Sender: dmit@nmr-dmit.ioc.ac.ru Message-ID: <329410C4.4CD9AAEE@nmr1.ioc.ac.ru> Date: Thu, 21 Nov 1996 11:20:20 +0300 From: "Dmitry E. Dmitriev" Organization: IOCh RAS X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: CHEMISTRY@www.ccl.net Subject: Linux CACTVS problem - answer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear netters! Some days ago i posted a question about a problem with running of CACTVS package under Linux OS. Some respondents notice me that they has a same problem. I just received a reply from Dr. Wolf-D. Ihlenfeldt, author of CACTVS: >This means your dynamic C runtime library is outdated. Get a newer >release. >This is a known problem. I do not tested this yet. Dmitry -- ************************************************************************ * Dmitry E. Dmitriev * Moscow , Russia * * Local Network Administrator * Phone : (095) 135-9094 * * NMR Centre * Fax : (095) 135-5328 * * Russian Academy of Sciences * Email : dmit@nmr1.ioc.ac.ru * ************************************************************************ From yubofan@ms.fudan.edu.cn Thu Nov 21 06:39:09 1996 Received: from ns.fudan.edu.cn for yubofan@ms.fudan.edu.cn by www.ccl.net (8.8.2/950822.1) id FAA14878; Thu, 21 Nov 1996 05:41:36 -0500 (EST) Received: by ns.fudan.edu.cn (5.x/SMI-SVR4) id AA03392; Thu, 21 Nov 1996 17:37:31 -0800 >Received: by fudan.edu.cn (5.x/SMI-SVR4) id AA16364; Thu, 21 Nov 1996 18:27:55 +0800 Date: Thu, 21 Nov 1996 18:27:55 +0800 From: yubofan@ms.fudan.edu.cn (Fan Yubo) Message-Id: <9611211027.AA16364@fudan.edu.cn> To: chemistry@www.ccl.net Subject: A question about MINDO3 of Gauss 92. Content-Type: text Hi, I calculated a big molecule by MINDO3 of Gauss 92. But I couldn't know the unit and meaning of energy the program gave. For example, Energy= 0.660654941175 NIter= 18. Dipole moment= 0.250853 -0.144413 -0.042300 Leave Link 402 at Tue Jul 23 14:26:20 1996, MaxMem= 1500000 cpu: 190. (Enter Link 601) I am expecting to helps. Thanks a lot Yubo Fan From platon@serv.icerp.ro Thu Nov 21 06:57:55 1996 Received: from serv.icerp.ro for platon@serv.icerp.ro by www.ccl.net (8.8.2/950822.1) id GAA15096; Thu, 21 Nov 1996 06:24:14 -0500 (EST) Received: (from platon@localhost) by serv.icerp.ro (8.6.12/8.6.9) id NAA01182; Thu, 21 Nov 1996 13:24:51 +0200 Date: Thu, 21 Nov 1996 13:24:43 +0200 (EET) From: "Alexandru Platon-jr." To: chemistry@www.ccl.net Subject: CCL:Re:tar files Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-423558854-1616954753-848328681=:788" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---423558854-1616954753-848328681=:788 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Mon, 18 Nov 1996 16:51:22 +0200 (EET) From: Alexandru Platon-jr. To: Grant Handford Subject: Re: CCL:tar files >>>included "dos_tar.zip" in original message, not present here<<< Dear Grant, I saw on your message header that you are using Windows Eudora for e-mailing, so that I assumed that you are not very familiar with UNIX commands. There's an archived MS-DOS version of tar included in this message, as an attachment. The archive contains the files "readme", "tar.doc" and "tar.exe". This program is also available by ftp (login: anonymous, password: granthan@islandnet.com) at the address 'serv.icerp.ro', following the path: /pub/net/dos_tar.zip . Please, let me know if I could be of any more help. Good luck. > .. > started at using a computer for e-mail, Internet, etc. I need to know how > to convert compressed tar files into usable form. If you could help me it > .. -- Alexandru Platon-jr., ChemE INCERP - Ploiesti, RO | tel:+40-44-135111/int.196 | fax:+40-44-115732 e-mail: platon@serv.icerp.ro ---423558854-1616954753-848328681=:788-- From patrick@hartree1.rug.ac.be Thu Nov 21 09:39:18 1996 Received: from mserv.rug.ac.be for patrick@hartree1.rug.ac.be by www.ccl.net (8.8.2/950822.1) id JAA15896; Thu, 21 Nov 1996 09:24:07 -0500 (EST) Received: from hartree1.rug.ac.be by mserv.rug.ac.be with SMTP id AA28495 (5.67b/IDA-1.5 for ); Thu, 21 Nov 1996 15:24:05 +0100 Date: Thu, 21 Nov 1996 15:20:22 +0100 (NFT) From: Patrick Bultinck To: CCL Subject: GAMESS/TCGMSG/LINUX problems Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear, I am trying to get a Linux box to work in parallel with my IBM RS/6000 Workstations to test parallel GAMESS runs. TCGMSG comes with a very small test program, that says 'hello from Node X'. I had to put up a .rhosts file. I think it works since I can do rsh apple -me ls from the Linux machine, named Banana and get the results of ls. Apple is a SUN machine, banana is Linux. I can run the program from a SUN or IBM machine as kick-off place. So the small program gets the program started on Linux, and it returns sense results. In short typing 'parallel hello' on apple, causes the program to run on apple AND on banana. Hello from node 1 Hello from node 2 Hello from node 3 Hello from node 4 Hello from node 5 When I do the VERY same from the Linux machine (banana), going to the SUN or IBM machines, I get in big trouble. My .rhosts file on banana (and on apple the same) looks like : banana.rug.ac.be moi apple.rug.ac.be me The error I keep getting is : Creating: host=banana, user=moi, file=/moi/tcgmsg/ipcv4.0/hello.x, port=1193 Creating: host=apple, user=me, file=/staff/fwet/me/tcgmsg/ipcv4.0/hello.x, port=1195 10: RemoteCreate: in child after execv -1 (0xffffffff). system error message: No such file or directory Creating: host=banana, user=moi, file=/moi/tcgmsg/ipcv4.0/hello.x, port=1193 Creating: host=apple, user=me, file=/staff/fwet/me/tcgmsg/ipcv4.0/hello.x, port=1195 10: interrupt 0: interrupt The same .rhosts files exist on apple and banana, and the .p file instructing the machine where all files are, are also the same, except for the ordering on banana and apple. The files /moi/tcgmsg... and /staff/fwet... on the respective machines also exist, and are executable. When I go to banana, and instruct it to run 5 processes on banana alone, it also works fine ! When making the tcgmsg programs, and linking parallel stuff, I had to link to libipc on banana. From the faq's I learned that is part of libc (and ar t showed so for libc). Could someone help me a little on the way ? Patrick Bultinck QuantumChemistry Ghent, Belgium From berriz@chasma.harvard.edu Thu Nov 21 10:39:08 1996 Received: from chasma.harvard.edu for berriz@chasma.harvard.edu by www.ccl.net (8.8.2/950822.1) id KAA16404; Thu, 21 Nov 1996 10:14:01 -0500 (EST) Received: by chasma.harvard.edu (AIX 3.2/UCB 5.64/4.03) id AA20621; Thu, 21 Nov 1996 10:12:40 -0500 Date: Thu, 21 Nov 1996 10:12:40 -0500 From: berriz@chasma.harvard.edu (Gabriel Berriz) Message-Id: <9611211512.AA20621@chasma.harvard.edu> To: chemistry@www.ccl.net Subject: Summary: Parallelized SHAKE Dear netters: A few days ago I posted a request for information on published parallelized versions of the SHAKE algorithm. Here's a summary of responses: @ARTICLE{shake_par0, AUTHOR = {Stephen E. DeBolt and Peter A. Kollman}, TITLE = {{AMBERCUBE MD}, Parallelization of {AMBER}'s Molecular Dynamics Module for Distributed-Memory Hypercube Computers}, JOURNAL = {Journal of Computational Chemistry}, VOLUME = 14, NUMBER = 3, PAGES = {312-329}, YEAR = 1993 } @ARTICLE{shake_par1, AUTHOR = {W. Smith and D. Fincham}, TITLE = {The {E}wald Sum in Truncated Octahedral and Rhombic Dodecahedral Boundary Conditions}, JOURNAL = {Molecular Simulation}, VOLUME = 10, PAGES = {67}, YEAR = 1993 } @ARTICLE{shake_par2, AUTHOR = {W. Smith and T. R. Forester}, TITLE = {Parallel Macromolecular Simulations and the Replicated Data Strategy. II. The {RD-SHAKE} Algorithm}, JOURNAL = {Computer Physics Communications}, VOLUME = 79, PAGES = {63-77}, YEAR = 1994 } I have not been able to look at the reference by Smith and Fincham, but the other two go into parallelizations of SHAKE in detail. (I imagine there will be at least some overlap between the Smith and Fincham, and the Smith and Forester papers.) A related suggested alternative is to obtain the source code of the Smith/Forester software (DL_POLY), which is freely available upon signing a license agreement. For more details, consult: http://gserv1.dl.ac.uk/TCSC/Software/DL_POLY/main.html I want to thank all those who replied to my query. Gabriel Berriz berriz@chasma.harvard.edu Dept. of Chemistry and Chemical Biology Harvard University From berriz@chasma.harvard.edu Thu Nov 21 12:39:09 1996 Received: from chasma.harvard.edu for berriz@chasma.harvard.edu by www.ccl.net (8.8.2/950822.1) id MAA17040; Thu, 21 Nov 1996 12:06:05 -0500 (EST) Received: by chasma.harvard.edu (AIX 3.2/UCB 5.64/4.03) id AA14694; Thu, 21 Nov 1996 12:04:47 -0500 Date: Thu, 21 Nov 1996 12:04:47 -0500 From: berriz@chasma.harvard.edu (Gabriel Berriz) Message-Id: <9611211704.AA14694@chasma.harvard.edu> To: chemistry@www.ccl.net Subject: Summary:Rotational diffusion and quaternions A few weeks ago I posted a request for information on quaternion-based discussions of rotational difusion. Following is a summary of responses: @ARTICLE{quat00, AUTHOR = {R. M. Lynden-Bell and A. J. Stone}, TITLE = {Reorientational Correlation Functions, Quaternions and {W}igner Rotation Matrices}, JOURNAL = {Molecular Simulation}, VOLUME = 3, PAGES = 271-281, YEAR = 1989 } @ARTICLE{quat01, AUTHOR = {Gerald R. Kneller and Alfons Geiger}, TITLE = {A Method to Calculate the {g}-Coefficients of the Molecular Pair Correlation Function from Molecular Dynamics Simulations}, JOURNAL = {Molecular Simulation}, VOLUME = 3, PAGES = {283-300}, YEAR = 1989 } @ARTICLE{quat02, AUTHOR = {Gerald R. Kneller}, TITLE = {Quaternions as a Tool for the Analysis of Molecular Systems}, JOURNAL = {Journal de Chimie Physique}, VOLUME = 88, PAGES = {2709-2715}, YEAR = 1991 } @ARTICLE{quat03, AUTHOR = {Gerald R. Kneller and Volker Keiner and Meinhard Kneller and Matthias Schiller}, TITLE = {{\em n}{MOLDYN}: {A} Program for a Neutron Scattering Oriented Analysis of {M}olecular {D}ynamics Simulations}, JOURNAL = {Computer Physics Communications}, VOLUME = 91, PAGES = {191-214}, YEAR = 1995 } @ARTICLE{pawley:85b, AUTHOR = {G. S. Pawley and M. T. Dove}, TITLE = {Quaternion-based Reorientation Conditions for Molecular Dynamics Analyses}, JOURNAL = {Molecular Physics}, VOLUME = 55, NUMBER = 5, PAGES = {1147-1157}, YEAR = 1985 } @ARTICLE{pawley:81, AUTHOR = {G. S. Pawley}, TITLE = {Molecular Dynamics Simulation of the Plastic Phase; a Model for {SF}$_6$}, JOURNAL = {Molecular Physics}, VOLUME = 43, NUMBER = 6, PAGES = {1321-1330}, YEAR = 1981 } @ARTICLE{refson:87a, AUTHOR = {K. Refson and G. S. Pawley}, TITLE = {Molecular Dynamics Studies of the Condensed Phases of {\em n}-butane and their Transitions, {I} {T}echniques and Model Results}, JOURNAL = {Molecular Physics}, VOLUME = 61, NUMBER = 3, PAGES = {669-692}, YEAR = 1987 } @ARTICLE{refson:87b, AUTHOR = {K. Refson and G. S. Pawley}, TITLE = {Molecular Dynamics Studies of the Condensed Phases of {\em n}-butane and their Transitions, {II} {T}he Transition to the Plastic Phase}, JOURNAL = {Molecular Physics}, VOLUME = 61, NUMBER = 3, PAGES = {693-709}, YEAR = 1987 } The following reference gives a general overview on various modes of diffusion, including rotational diffusion, for arbitrarily shaped flexible molecules, though its analysis is not based on quaternions: @ARTICLE{goldstein93, AUTHOR = {Robert F. Goldstein}, TITLE = {Hydrodynamic Modes of Arbitrarily Shaped Flexible Molecules: {I}nfluences on Dynamic Light Scattering}, JOURNAL = {Biopolymers}, VOLUME = 33, PAGES = {409-436}, YEAR = 1993 } A general reference on quaternions, and their role in the analysis of physical problems is: @BOOK{quat04, AUTHOR = {Simon L. Altmann}, TITLE = {Rotations, Quaternions, and Double Groups}, PUBLISHER = {Clarendon Press/Oxford}, YEAR = 1986 } Of the papers I've had the chance to look at, I found the ones by G. R. Kneller to be particularly instructive and applicable to my query. Note also that the first two references given above are back-to-back papers, as are the two papers by Refson and Pawley. I want to thank all those who replied to my query, in particular, for the references above, to Robert Goldstein, Konrad Hinsen, Alain Kessi, and Keith Refson. (The typos, however, belong to me :-) ) Gabriel Berriz berriz@chasma.harvard.edu Dept. of Chemistry and Chemical Biology Harvard University From berriz@chasma.harvard.edu Thu Nov 21 14:39:11 1996 Received: from chasma.harvard.edu for berriz@chasma.harvard.edu by www.ccl.net (8.8.2/950822.1) id OAA17888; Thu, 21 Nov 1996 14:22:40 -0500 (EST) Received: by chasma.harvard.edu (AIX 3.2/UCB 5.64/4.03) id AA20812; Thu, 21 Nov 1996 14:20:43 -0500 Date: Thu, 21 Nov 1996 14:20:43 -0500 From: berriz@chasma.harvard.edu (Gabriel Berriz) Message-Id: <9611211920.AA20812@chasma.harvard.edu> To: chemistry@www.ccl.net Subject: Q: Scientific Fortran for C programmers Dear netters: What follows is a hodge-podge of questions surrounding scientific programming in general, and Fortran90, in particular. I apologize beforehand for their occasional vagueness. I'm hoping that despite it, they'll be "recognizable" to some CCL readers. More than detailed answers (which would be rather time-consuming to the brave responder), I'm interested in pointers to pertinent readings. I am experienced C programmer who's now taking his first steps in Fortran (Fortran90, to be precise). After a brief study of Fortran, I'm surprised at how much my idea of what a program is is shaped by the structure of C programs. This is so much so that I am having some difficulty grasping the overall structure of Fortran90 programs. For example, the whole business with "data blocks" seems bizarrely archaic to me. But this is a minor issue. More important is that I'm unclear on the usefulness of "modules." How is a module different from a file with a whole bunch of subroutines in it? How is modularization achie- ved with FORTRAN77? What was deficient about this approach that prompted the introduction of "modules" in Fortran90? Is there more to the rationale for modules than providing a finer control over variable scoping (which, I imagine, could be achieved with not much effort by a careful naming of variables)? I am interested in reading discussions on the structure of (medium to large) Fortran programs, particularly ones geared to C programmers. Two areas that I am particularly concerned about are (1) managing the proliferation of versions of my source code; (2) high performance, in- cluding parallelization. (Of course, neither of these topics is spe- cific to Fortran, though there may be features of Fortran90 that ger- mane to them.) Everything I've found on source code management seems to be geared to the writers of commercial software. I have found, however, that their concerns are different from those encountered in simulations-based research. (Perhaps this is why I have yet to find one writer/user of simulation programs who has managed to stick to RCS for more than a couple of weeks.) I.e., I am not worried about jug- gling a few, significantly different versions, some released, some geared for release, of my code. My situation is that I am constantly making small changes to my not-for-release code, as part of my simula- tion "experiments," which means that I'm dealing with, effectively, a large number of versions, many of which differ very slightly from each other. I keep notes on these changes (as comments on the code, or on my makefiles), but they don't seem adequate documentation. I suppose a sounder approach would be to save *all* versions of code ever used to generate data (which, incidentally, includes a non-trivial fraction of "dead-end" data), as well as notes on all the various source ver- sions that go into a given executable. Obviously, this strategy leads to a huge number of source files, and a wild efflorescence of file name extensions. Be that as it may, are there any resources (soft- ware, books, articles, &c.) helpful towards this sort of bookkeeping? As far as high-performance, I would like to learn about the effects of program structure on execution speed. For example, how expensive, re- lative to their alternatives, are subroutine calls and modules in For- tran90? Do COMMON variables slow down execution? Does one get faster code if one avoids COMMON variables, and instead defines subroutines with a long list of arguments? Again, I apologize for the chaotic appearance (and the length!) of the above query. I hope that a "core" set of concerns is detectable. I greatly appreciate your comments and suggestions. I'll summarize the responses. Gabriel Berriz berriz@chasma.harvard.edu Dept. of Chemistry and Chemical Biology Harvard University From Jeffrey.Nauss@UC.Edu Thu Nov 21 15:39:15 1996 Received: from jazz.san.uc.edu for Jeffrey.Nauss@UC.Edu by www.ccl.net (8.8.2/950822.1) id PAA18161; Thu, 21 Nov 1996 15:13:17 -0500 (EST) Received: from beryllium.crs.uc.edu by UCBEH.SAN.UC.EDU (PMDF V5.0-7 #15949) id <01IC3YVN106AAXBEZ6@UCBEH.SAN.UC.EDU> for chemistry@www.ccl.net; Thu, 21 Nov 1996 13:51:31 -0500 (EST) Received: by beryllium.crs.uc.edu (951211.SGI.8.6.12.PATCH1042/940406.SGI.AUTO) for chemistry@www.ccl.net id NAA08671; Thu, 21 Nov 1996 13:51:59 -0500 Date: Thu, 21 Nov 1996 13:51:57 -0500 From: Jeffrey.Nauss@UC.Edu (Jeffrey L. Nauss) Subject: Delphi reference To: chemistry@www.ccl.net Reply-to: Jeffrey.Nauss@UC.EDU Message-id: <9611211351.ZM8669@beryllium.crs.uc.edu> Organization: Dept. Chemistry, University of Cincinnati MIME-version: 1.0 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Zm-Priority: Low Quite sometime ago, I posted the following question: >From nauss Tue Oct 8 10:22:30 1996 > I am looking for the recommended reference for the program Delphi out > of Barry Honig's group. I have found five possibilities from the > Biosym/MSI manual for Delphi but which one is the *recommended* or > preferred reference? Here is the definitive reply from Kim Sharpe, one of the authors: First 'delphi' paper 1 ). Gilson, M., Sharp, K. A., Honig, B. (1988). "Calculating the Electrostatic Potential of Molecules in Solution: Method and Error Assessment". J. Comp. Chem. 9:327-335. Non-linear PB ref 2 ). Jayaram, B., Sharp, K. A., Honig, B. (1989). "The Electrostatic Potential of B-DNA". Biopolymers 28:975-93. Solvation energies 3 ). Sitkoff, D., Sharp, K., Honig, B. (1994). "Accurate calculation of hydration free energies using macroscopic solvent models". J. Phys. Chem. 98:1978-1988. Improved 'delphi (biosym's version) reference 1 ). Nicholls, A., Honig, B. (1991). "A rapid finite difference algorithm utilizing successive over-relaxation to solve the Poisson-Boltzmann equation". J. Comp. Chem. 12:435-445. Thanks, Kim, and to all else who responded. My apologies for not getting a summary out sooner. -- Jeff Nauss *********************************************************************** * UU UU Jeffrey L. Nauss, PhD * * UU UU Director, Molecular Modeling Services * * UU UU Department of Chemistry * * UU UU CCCCCCC University of Cincinnati * * UU UU CCCCCCCC Cincinnati, OH 45221-0172 * * UUUU CC * * CC Telephone: 513-556-0148 Fax: 513-556-9239 * * CC * * CCCCCCCC e-mail: Jeffrey.Nauss@UC.Edu * * CCCCCCC URL http://www.che.uc.edu/~nauss * *********************************************************************** From robert@pauli.utmb.edu Thu Nov 21 15:45:09 1996 Received: from nmr.utmb.edu for robert@pauli.utmb.edu by www.ccl.net (8.8.2/950822.1) id PAA18225; Thu, 21 Nov 1996 15:29:42 -0500 (EST) Received: from pauli.utmb.edu by nmr.utmb.edu via SMTP (931110.SGI/930416.SGI.AUTO) for CHEMISTRY@www.ccl.net id AA21098; Thu, 21 Nov 96 14:33:56 -0600 Received: (from robert@localhost) by pauli.utmb.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA03756 for CHEMISTRY@www.ccl.net; Thu, 21 Nov 1996 14:28:44 -0600 From: "Robert Fraczkiewicz" Message-Id: <9611211428.ZM3754@pauli.utmb.edu> Date: Thu, 21 Nov 1996 14:28:44 -0600 Return-Receipt-To: "Robert Fraczkiewicz" X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: CHEMISTRY@www.ccl.net Subject: F77 compiler on R10000 SGI Indigo2: buggy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Dear Netters, Below is a short FORTRAN code that I wrote solely for the purpose of testing the system subroutine DTIME in SGI IRIX 6.2. This subroutine returns the elapsed CPU time since the last call to DTIME. I have compiled it on SGI Indigo2 with R10000 processor using MIPSpro F77 compiler. I have used five different option sets listed below: 1) f77 silly.f -o silly (this produces 32-bit mips2 code by default) 2) f77 -O2 silly.f -o silly 3) f77 -64 silly.f -o silly (this produces 64-bit mips4 code) 4) f77 -64 -O2 silly.f -o silly 5) f77 -64 -O3 silly.f -o silly The unusual results I have obtained are shown in table below. Apart from the fact that the 64-bit executables produce slightly different result for x than their 32-bit counterparts, the CPU times in column 4) are larger by a factor of TEN in comparison to other columns! Normally, I would expect them to be in between 3) and 5). This abnormal result is reproducible for every SGI R10000 machine that we have here. It seems that options -64 and -O2 don't get along very well. Is there something I don't understand about MIPSpro F77 optimization options? Am I missing something? Or is there a bug in the compiler? Please, recompile this code on your R10000 (if you have it :-) to confirm or deny this observation. program silly implicit double precision (a-h,o-z) real tarray(2) x=0.d0 jmax=100 call dtime(tarray) do imax=8000,10000,100 do i=1,imax do j=1,jmax x=x+sqrt(float(i))*sin(float(j)) y=acos(x/(i*abs(x))) enddo enddo call dtime(tarray) print *,imax,tarray(1)+tarray(2) enddo print *,x,y stop end Results: ------------------------------------------------------------------------ | CPU times (s) reported by DTIME for different compiler options| imax ----------------------------------------------------------------- | 1) | 2) | 3) | 4) | 5) | ------------------------------------------------------------------------ 8000 | 0.8353710 | 0.6551640 | 0.6200770 | 6.131035 | 0.1884840 | 8100 | 0.8722960 | 0.6899580 | 0.6547980 | 6.208158 | 0.1924730 | 8200 | 0.8814020 | 0.6967919 | 0.6354470 | 6.280854 | 0.1928640 | 8300 | 0.8918310 | 0.6798510 | 0.6682850 | 6.354552 | 0.1953330 | 8400 | 0.9021270 | 0.7131230 | 0.6759790 | 6.454478 | 0.1976650 | 8500 | 0.9128000 | 0.7212590 | 0.6588350 | 6.503715 | 0.2249840 | 8600 | 0.9232100 | 0.7044880 | 0.6914790 | 6.604474 | 0.2023520 | 8700 | 0.9336550 | 0.7377620 | 0.6991270 | 6.682483 | 0.2047420 | 8800 | 0.9442470 | 0.7459780 | 0.7070640 | 6.732563 | 0.2070200 | 8900 | 0.9545040 | 0.7541710 | 0.6897570 | 6.828230 | 0.2343980 | 9000 | 0.9649110 | 0.7372350 | 0.7226390 | 6.902500 | 0.2117620 | 9100 | 0.9503450 | 0.7706130 | 0.7303350 | 6.977732 | 0.2140380 | 9200 | 0.9860920 | 0.7787640 | 0.7130180 | 7.052145 | 0.2164480 | 9300 | 0.9962510 | 0.7868320 | 0.7457520 | 7.127767 | 0.2188510 | 9400 | 1.006923 | 0.7699320 | 0.7534280 | 7.226908 | 0.2460940 | 9500 | 1.017477 | 0.8030970 | 0.7614270 | 7.281057 | 0.2234870 | 9600 | 1.052756 | 0.8112460 | 0.7440030 | 7.351462 | 0.2258430 | 9700 | 1.038267 | 0.8196840 | 0.7766720 | 7.452884 | 0.2281600 | 9800 | 1.048346 | 0.8278640 | 0.7845440 | 7.500894 | 0.2555520 | 9900 | 1.059044 | 0.8359420 | 0.7923810 | 7.600510 | 0.2328600 | 10000 | 1.069380 | 0.8191160 | 0.7999970 | 7.650619 | 0.2352500 | ------------------------------------------------------------------------ x | -1522838.034014487 | -1522834.807409876 | ------------------------------------------------------------------------ y | 1.570896326795063 | 1.570896326795063 | ------------------------------------------------------------------------ Best regards, Robert Fraczkiewicz University of Texas Meedical Branch Galveston, TX 77555 From robert@pauli.utmb.edu Thu Nov 21 15:48:21 1996 Received: from nmr.utmb.edu for robert@pauli.utmb.edu by www.ccl.net (8.8.2/950822.1) id PAA18225; Thu, 21 Nov 1996 15:29:42 -0500 (EST) Received: from pauli.utmb.edu by nmr.utmb.edu via SMTP (931110.SGI/930416.SGI.AUTO) for CHEMISTRY@www.ccl.net id AA21098; Thu, 21 Nov 96 14:33:56 -0600 Received: (from robert@localhost) by pauli.utmb.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA03756 for CHEMISTRY@www.ccl.net; Thu, 21 Nov 1996 14:28:44 -0600 From: "Robert Fraczkiewicz" Message-Id: <9611211428.ZM3754@pauli.utmb.edu> Date: Thu, 21 Nov 1996 14:28:44 -0600 Return-Receipt-To: "Robert Fraczkiewicz" X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: CHEMISTRY@www.ccl.net Subject: F77 compiler on R10000 SGI Indigo2: buggy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Dear Netters, Below is a short FORTRAN code that I wrote solely for the purpose of testing the system subroutine DTIME in SGI IRIX 6.2. This subroutine returns the elapsed CPU time since the last call to DTIME. I have compiled it on SGI Indigo2 with R10000 processor using MIPSpro F77 compiler. I have used five different option sets listed below: 1) f77 silly.f -o silly (this produces 32-bit mips2 code by default) 2) f77 -O2 silly.f -o silly 3) f77 -64 silly.f -o silly (this produces 64-bit mips4 code) 4) f77 -64 -O2 silly.f -o silly 5) f77 -64 -O3 silly.f -o silly The unusual results I have obtained are shown in table below. Apart from the fact that the 64-bit executables produce slightly different result for x than their 32-bit counterparts, the CPU times in column 4) are larger by a factor of TEN in comparison to other columns! Normally, I would expect them to be in between 3) and 5). This abnormal result is reproducible for every SGI R10000 machine that we have here. It seems that options -64 and -O2 don't get along very well. Is there something I don't understand about MIPSpro F77 optimization options? Am I missing something? Or is there a bug in the compiler? Please, recompile this code on your R10000 (if you have it :-) to confirm or deny this observation. program silly implicit double precision (a-h,o-z) real tarray(2) x=0.d0 jmax=100 call dtime(tarray) do imax=8000,10000,100 do i=1,imax do j=1,jmax x=x+sqrt(float(i))*sin(float(j)) y=acos(x/(i*abs(x))) enddo enddo call dtime(tarray) print *,imax,tarray(1)+tarray(2) enddo print *,x,y stop end Results: ------------------------------------------------------------------------ | CPU times (s) reported by DTIME for different compiler options| imax ----------------------------------------------------------------- | 1) | 2) | 3) | 4) | 5) | ------------------------------------------------------------------------ 8000 | 0.8353710 | 0.6551640 | 0.6200770 | 6.131035 | 0.1884840 | 8100 | 0.8722960 | 0.6899580 | 0.6547980 | 6.208158 | 0.1924730 | 8200 | 0.8814020 | 0.6967919 | 0.6354470 | 6.280854 | 0.1928640 | 8300 | 0.8918310 | 0.6798510 | 0.6682850 | 6.354552 | 0.1953330 | 8400 | 0.9021270 | 0.7131230 | 0.6759790 | 6.454478 | 0.1976650 | 8500 | 0.9128000 | 0.7212590 | 0.6588350 | 6.503715 | 0.2249840 | 8600 | 0.9232100 | 0.7044880 | 0.6914790 | 6.604474 | 0.2023520 | 8700 | 0.9336550 | 0.7377620 | 0.6991270 | 6.682483 | 0.2047420 | 8800 | 0.9442470 | 0.7459780 | 0.7070640 | 6.732563 | 0.2070200 | 8900 | 0.9545040 | 0.7541710 | 0.6897570 | 6.828230 | 0.2343980 | 9000 | 0.9649110 | 0.7372350 | 0.7226390 | 6.902500 | 0.2117620 | 9100 | 0.9503450 | 0.7706130 | 0.7303350 | 6.977732 | 0.2140380 | 9200 | 0.9860920 | 0.7787640 | 0.7130180 | 7.052145 | 0.2164480 | 9300 | 0.9962510 | 0.7868320 | 0.7457520 | 7.127767 | 0.2188510 | 9400 | 1.006923 | 0.7699320 | 0.7534280 | 7.226908 | 0.2460940 | 9500 | 1.017477 | 0.8030970 | 0.7614270 | 7.281057 | 0.2234870 | 9600 | 1.052756 | 0.8112460 | 0.7440030 | 7.351462 | 0.2258430 | 9700 | 1.038267 | 0.8196840 | 0.7766720 | 7.452884 | 0.2281600 | 9800 | 1.048346 | 0.8278640 | 0.7845440 | 7.500894 | 0.2555520 | 9900 | 1.059044 | 0.8359420 | 0.7923810 | 7.600510 | 0.2328600 | 10000 | 1.069380 | 0.8191160 | 0.7999970 | 7.650619 | 0.2352500 | ------------------------------------------------------------------------ x | -1522838.034014487 | -1522834.807409876 | ------------------------------------------------------------------------ y | 1.570896326795063 | 1.570896326795063 | ------------------------------------------------------------------------ Best regards, Robert Fraczkiewicz University of Texas Meedical Branch Galveston, TX 77555 From alper@moldyn.com Thu Nov 21 16:48:25 1996 Received: from photon.com for alper@moldyn.com by www.ccl.net (8.8.3/950822.1) id QAA18612; Thu, 21 Nov 1996 16:02:13 -0500 (EST) Received: from bart.moldyn.com ([172.16.2.14]) by gateway.photon.com with SMTP id <5890-2>; Thu, 21 Nov 1996 12:55:15 -0800 Received: by bart.moldyn.com (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA22017; Thu, 21 Nov 1996 16:06:02 -0500 From: alper@moldyn.com (Howard Alper) Message-Id: <199611212106.QAA22017@bart.moldyn.com> Subject: QM/MM and Multiple Time Scale MD To: CHEMISTRY@www.ccl.net Date: Thu, 21 Nov 1996 13:06:00 -0800 Cc: alper@bart.moldyn.com (Howard Alper) Reply-To: alper@bart.moldyn.com X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, A few days ago I posted to the list concerning the use of the combined QM/MM forcefield (I will summarize in a few days). But for now I have another, related, question. I could have sworn that I came across an article in which the Car-Parinello QM/MM method was being combined with multiple time scale integrators (RESPA, I assume). Does anyone know the reference for this article? It should be relatively recent (1996, I think.) Thanks in advance for any help. Howard -- Dr. Howard Alper Moldyn Inc. 955 Massachusetts Avenue Fifth Floor Cambridge, MA 02139-3180 617-354-3124 x19 email: alper@moldyn.com - helping molecules find happiness for over a 10th of a century. From case@scripps.edu Thu Nov 21 18:48:24 1996 Received: from scripps.edu for case@scripps.edu by www.ccl.net (8.8.3/950822.1) id RAA19188; Thu, 21 Nov 1996 17:58:22 -0500 (EST) Received: from dirac.scripps.edu by scripps.edu (5.61/1.34) id AA18396; Thu, 21 Nov 96 14:39:02 -0800 Received: by dirac.scripps (SMI-8.6/SMI-SVR4) id OAA04506; Thu, 21 Nov 1996 14:36:02 -0800 Date: Thu, 21 Nov 1996 14:36:02 -0800 From: case@scripps.edu (David Case) Message-Id: <199611212236.OAA04506@dirac.scripps> To: chemistry@www.ccl.net, berriz@chasma.harvard.edu Subject: Re: CCL:Q: Scientific Fortran for C programmers X-Sun-Charset: US-ASCII berriz@chasma.harvard.edu (Gabriel Berriz) wrote: > > example, the whole business with "data blocks" seems bizarrely archaic > to me. But this is a minor issue. More important is that I'm unclear > on the usefulness of "modules." How is a module different from a file > with a whole bunch of subroutines in it? How is modularization achie- > ved with FORTRAN77? What was deficient about this approach that > prompted the introduction of "modules" in Fortran90? Is there more to > the rationale for modules than providing a finer control over variable > scoping (which, I imagine, could be achieved with not much effort by a > careful naming of variables)? I am interested in reading discussions > on the structure of (medium to large) Fortran programs, particularly > ones geared to C programmers. Data blocks are often like structures in C. As I understand it, one of the principal driving forces in moving from Fortran77 to Fortran90 was to allow much tigher checking of the consistency of how data is used in different routines -- in the simplest cases, to type-check argument passing and other forms of inter-routine communication. It's a little like going from K&R to ANSI C. > ...requests ideas for version managament..... I use RCS for just what you describe. RCS does support branches, so you can have a set of optimizations that go to a dead-end, then start over from some previous point. If you copy the RCS ID to the output files, it's usually pretty easy to figure out which program gave which result. And yes, I do try to save more or less every version, but disk space is cheap, only the diffs are stored, and everything is in a single file. Don't overlook using aliases to turn version numbers into more meaningful version names. But I hope you will post a summary of the better ideas people send to you. > > As far as high-performance, I would like to learn about the effects of > program structure on execution speed. For example, how expensive, re- > lative to their alternatives, are subroutine calls and modules in For- > tran90? Do COMMON variables slow down execution? Does one get faster > code if one avoids COMMON variables, and instead defines subroutines > with a long list of arguments? Just the opposite (usually): people use COMMONs to avoid long argument lists, for speed considerations. In fact, COMMON blocks can be quite efficient if lack of memory is not a problem, since all of the address resolution is done at compile time. COMMON blocks are out of favor because it is difficult to impossible to cross check them for consistency. But carefully used, they can be a very intuitive way of organizing and encapsulating some forms of data structures. Most F90 texts will show you how to construct roughly equivalent ideas in Fortran90. I assume you are familiar with comp.lang.fortran. Lots of garbage goes there, but also some very good threads, and you could start one yourself.... ..dave case From robert@pauli.utmb.edu Thu Nov 21 19:48:24 1996 Received: from nmr.utmb.edu for robert@pauli.utmb.edu by www.ccl.net (8.8.3/950822.1) id TAA19551; Thu, 21 Nov 1996 19:41:20 -0500 (EST) Received: from pauli.utmb.edu by nmr.utmb.edu via SMTP (931110.SGI/930416.SGI.AUTO) for CHEMISTRY@www.ccl.net id AA21614; Thu, 21 Nov 96 18:45:37 -0600 Received: (from robert@localhost) by pauli.utmb.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA05444; Thu, 21 Nov 1996 18:40:23 -0600 From: "Robert Fraczkiewicz" Message-Id: <9611211840.ZM5442@pauli.utmb.edu> Date: Thu, 21 Nov 1996 18:40:23 -0600 In-Reply-To: "Omar G. Stradella" "Re: CCL:F77 compiler on R10000 SGI Indigo2: buggy?" (Nov 21, 7:04pm) References: <9611211428.ZM3754@pauli.utmb.edu> <9611211904.ZM19457@arkham.boston.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: CHEMISTRY@www.ccl.net, omar@boston.sgi.com Subject: Re: CCL:F77 compiler on R10000 SGI Indigo2: buggy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 21, 7:04pm, Omar G. Stradella wrote: > Subject: Re: CCL:F77 compiler on R10000 SGI Indigo2: buggy? > Hi Robert, > > That certainly doesn't look right. Did you run all the cases > standalone ?. You are printing user+sys times, try to print > both, are the sys times much higher than the user times ? All cases were run in the same conditions. And they are always reproducible. Below are the results with USER and SYSTEM times printed separately: 3) f77 -64 silly.f -o silly imax USER SYSTEM 8000 0.6193750 5.5300002E-04 8100 0.6530520 2.4150000E-03 8200 0.6353130 6.7899999E-04 8300 0.6679210 6.9600000E-04 8400 0.6755320 6.3899998E-04 8500 0.6583500 6.4099999E-04 8600 0.6910400 6.2499999E-04 8700 0.6987190 5.9399998E-04 (..............) 4) f77 -64 -O2 silly.f -o silly 8000 6.126564 4.4080000E-03 8100 6.200925 6.2020002E-03 8200 6.275659 4.4020000E-03 8300 6.359073 5.8579999E-03 8400 6.451895 4.6970001E-03 8500 6.503077 5.1230001E-03 8600 6.604784 5.6810002E-03 8700 6.678527 5.6050001E-03 (..............) 5) f77 -64 -O3 silly.f -o silly 8000 0.1880720 4.1099999E-04 8100 0.1910070 1.9430000E-03 8200 0.1929000 2.4500000E-04 8300 0.1953550 3.0600000E-04 8400 0.1976000 3.0900000E-04 8500 0.2249180 3.1199999E-04 8600 0.2022510 3.3700000E-04 8700 0.2045990 3.0900000E-04 (..............) As you see, results for -64 -O2 are proportionally ten-fold slower in both times :-( > I've just ran your program on a "quiet" Indigo2 R10000/195MHz > and this is what I got: > > -------------------------------------------- > imax | 3) | 4) | 5) | > -------------------------------------------- > 8000 | 0.6389320 | 0.4704070 | 0.3378320 > 8100 | 0.6739330 | 0.4792880 | 0.3438850 > 8200 | 0.6547930 | 0.5068420 | 0.3709340 (..............) >-- End of excerpt from Omar G. Stradella That certainly looks strange... Seems like the problem is specific only to our Indigo2's.. They all have been upgraded pretty recently to R10000/195MHz. And I have installed quite a number of software patches. Could it be a factor? Could other CCL readers reproduce these results? Robert Fraczkiewicz University of Texas Medical Branch Galveston, TX 77555 From omar@boston.sgi.com Thu Nov 21 19:50:36 1996 Received: from deliverator.sgi.com for omar@boston.sgi.com by www.ccl.net (8.8.3/950822.1) id TAA19444; Thu, 21 Nov 1996 19:04:48 -0500 (EST) Received: from sgibos.boston.sgi.com by deliverator.sgi.com via ESMTP (950413.SGI.8.6.12/951211.SGI.AUTO) id QAA14935; Thu, 21 Nov 1996 16:04:42 -0800 Received: from arkham.boston.sgi.com by sgibos.boston.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/940406.SGI) id TAA28791; Thu, 21 Nov 1996 19:04:29 -0500 Received: by arkham.boston.sgi.com (950413.SGI.8.6.12/951211.SGI) id TAA19459; Thu, 21 Nov 1996 19:04:20 -0500 From: "Omar G. Stradella" Message-Id: <9611211904.ZM19457@arkham.boston.sgi.com> Date: Thu, 21 Nov 1996 19:04:19 -0500 In-Reply-To: "Robert Fraczkiewicz" "CCL:F77 compiler on R10000 SGI Indigo2: buggy?" (Nov 21, 2:28pm) References: <9611211428.ZM3754@pauli.utmb.edu> Organization: Silicon Graphics, Inc. Reply-to: omar@boston.sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Robert Fraczkiewicz , CHEMISTRY@www.ccl.net Subject: Re: CCL:F77 compiler on R10000 SGI Indigo2: buggy? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Robert, That certainly doesn't look right. Did you run all the cases standalone ?. You are printing user+sys times, try to print both, are the sys times much higher than the user times ? I've just ran your program on a "quiet" Indigo2 R10000/195MHz and this is what I got: -------------------------------------------- imax | 3) | 4) | 5) | -------------------------------------------- 8000 | 0.6389320 | 0.4704070 | 0.3378320 8100 | 0.6739330 | 0.4792880 | 0.3438850 8200 | 0.6547930 | 0.5068420 | 0.3709340 8300 | 0.6877040 | 0.4876800 | 0.3502160 8400 | 0.6956780 | 0.5185640 | 0.3543930 8500 | 0.7036650 | 0.4994340 | 0.3836350 8600 | 0.6866900 | 0.5302930 | 0.3628220 8700 | 0.7196610 | 0.5362660 | 0.3671010 8800 | 0.7275980 | 0.5170740 | 0.3962870 8900 | 0.7105780 | 0.5479479 | 0.3754910 9000 | 0.7436190 | 0.5288640 | 0.4046990 9100 | 0.7515450 | 0.5597370 | 0.3839000 9200 | 0.7595540 | 0.5405610 | 0.3881170 9300 | 0.7425210 | 0.5715650 | 0.4173290 9400 | 0.7755310 | 0.5523360 | 0.3965220 9500 | 0.7834170 | 0.5831710 | 0.4257890 9600 | 0.7915200 | 0.5890040 | 0.4050190 9700 | 0.7995780 | 0.5699100 | 0.4092260 9800 | 0.7824590 | 0.6008570 | 0.4384830 9900 | 0.8153910 | 0.5817030 | 0.4176470 10000 | 0.8233650 | 0.6125400 | 0.4468400 As you said, -O2 should always be faster than -O0 (the default). -O3 is usually faster than -O2, but not always it depends on the code. Omar. On Nov 21, 2:28pm, Robert Fraczkiewicz wrote: > Subject: CCL:F77 compiler on R10000 SGI Indigo2: buggy? > Dear Netters, > > Below is a short FORTRAN code that I wrote solely for the purpose of > testing the system subroutine DTIME in SGI IRIX 6.2. This subroutine > returns the elapsed CPU time since the last call to DTIME. I have > compiled it on SGI Indigo2 with R10000 processor using MIPSpro F77 > compiler. I have used five different option sets listed below: > > 1) f77 silly.f -o silly (this produces 32-bit mips2 code by default) > 2) f77 -O2 silly.f -o silly > 3) f77 -64 silly.f -o silly (this produces 64-bit mips4 code) > 4) f77 -64 -O2 silly.f -o silly > 5) f77 -64 -O3 silly.f -o silly > > The unusual results I have obtained are shown in table below. Apart > from the fact that the 64-bit executables produce slightly different > result for x than their 32-bit counterparts, the CPU times in column > 4) are larger by a factor of TEN in comparison to other columns! > Normally, I would expect them to be in between 3) and 5). This abnormal > result is reproducible for every SGI R10000 machine that we have here. > It seems that options -64 and -O2 don't get along very well. Is there > something I don't understand about MIPSpro F77 optimization options? Am I > missing something? Or is there a bug in the compiler? > Please, recompile this code on your R10000 (if you have it :-) to confirm > or deny this observation. > > program silly > implicit double precision (a-h,o-z) > real tarray(2) > x=0.d0 > jmax=100 > call dtime(tarray) > do imax=8000,10000,100 > do i=1,imax > do j=1,jmax > x=x+sqrt(float(i))*sin(float(j)) > y=acos(x/(i*abs(x))) > enddo > enddo > call dtime(tarray) > print *,imax,tarray(1)+tarray(2) > enddo > print *,x,y > stop > end > > > Results: > ------------------------------------------------------------------------ > | CPU times (s) reported by DTIME for different compiler options| > imax ----------------------------------------------------------------- > | 1) | 2) | 3) | 4) | 5) | > ------------------------------------------------------------------------ > 8000 | 0.8353710 | 0.6551640 | 0.6200770 | 6.131035 | 0.1884840 | > 8100 | 0.8722960 | 0.6899580 | 0.6547980 | 6.208158 | 0.1924730 | > 8200 | 0.8814020 | 0.6967919 | 0.6354470 | 6.280854 | 0.1928640 | > 8300 | 0.8918310 | 0.6798510 | 0.6682850 | 6.354552 | 0.1953330 | > 8400 | 0.9021270 | 0.7131230 | 0.6759790 | 6.454478 | 0.1976650 | > 8500 | 0.9128000 | 0.7212590 | 0.6588350 | 6.503715 | 0.2249840 | > 8600 | 0.9232100 | 0.7044880 | 0.6914790 | 6.604474 | 0.2023520 | > 8700 | 0.9336550 | 0.7377620 | 0.6991270 | 6.682483 | 0.2047420 | > 8800 | 0.9442470 | 0.7459780 | 0.7070640 | 6.732563 | 0.2070200 | > 8900 | 0.9545040 | 0.7541710 | 0.6897570 | 6.828230 | 0.2343980 | > 9000 | 0.9649110 | 0.7372350 | 0.7226390 | 6.902500 | 0.2117620 | > 9100 | 0.9503450 | 0.7706130 | 0.7303350 | 6.977732 | 0.2140380 | > 9200 | 0.9860920 | 0.7787640 | 0.7130180 | 7.052145 | 0.2164480 | > 9300 | 0.9962510 | 0.7868320 | 0.7457520 | 7.127767 | 0.2188510 | > 9400 | 1.006923 | 0.7699320 | 0.7534280 | 7.226908 | 0.2460940 | > 9500 | 1.017477 | 0.8030970 | 0.7614270 | 7.281057 | 0.2234870 | > 9600 | 1.052756 | 0.8112460 | 0.7440030 | 7.351462 | 0.2258430 | > 9700 | 1.038267 | 0.8196840 | 0.7766720 | 7.452884 | 0.2281600 | > 9800 | 1.048346 | 0.8278640 | 0.7845440 | 7.500894 | 0.2555520 | > 9900 | 1.059044 | 0.8359420 | 0.7923810 | 7.600510 | 0.2328600 | > 10000 | 1.069380 | 0.8191160 | 0.7999970 | 7.650619 | 0.2352500 | > ------------------------------------------------------------------------ > x | -1522838.034014487 | -1522834.807409876 | > ------------------------------------------------------------------------ > y | 1.570896326795063 | 1.570896326795063 | > ------------------------------------------------------------------------ > > Best regards, > Robert Fraczkiewicz > University of Texas Meedical Branch > Galveston, TX 77555 > > > -------This is added Automatically by the Software-------- > -- Original Sender Envelope Address: robert@pauli.utmb.edu > -- Original Sender From: Address: robert@pauli.utmb.edu > CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: Coordinator > MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73 > Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > Web: http://www.ccl.net/chemistry.html >-- End of excerpt from Robert Fraczkiewicz -- +---------------------------------------------------------------------+ Omar G. Stradella, Ph.D. Supercomputing Applications Silicon Graphics, Inc. Computational Chemistry One Cabot Road, Hudson, MA 01749, USA N 42 22'41" W 71 33'45" E-mail: omar@boston.sgi.com Phone: +1-508-567-2258 FAX: +1-508-562-4755 http://www.sgi.com/ChemBio http://reality.sgi.com/omar +-------- Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn -------+