From xiang@auriga.rose.brandeis.edu Thu Feb 10 00:21:07 1994 Received: from auriga.rose.brandeis.edu for xiang@auriga.rose.brandeis.edu by www.ccl.net (8.6.4/930601.1506) id AAA05321; Thu, 10 Feb 1994 00:07:18 -0500 Received: by auriga.rose.brandeis.edu (5.57/Ultrix3.0-C) id AA29435; Thu, 10 Feb 94 00:09:10 -0500 Date: Thu, 10 Feb 94 00:09:10 -0500 From: xiang@auriga.rose.brandeis.edu (Xiaoou Xiang) Message-Id: <9402100509.AA29435@auriga.rose.brandeis.edu> To: CHEMISTRY@ccl.net Subject: periodic BC in AMBER4.0 Hello, AMBER experts out there, I have a system of protein solvated in lipid bilayer with water caps. I would like to treat the protein as solute and lipid and water as solvent, and apply periodic boundary condition under constant pressure. Could anyone tell me how to do this in AMBER4.0? Any slight hint or suggestion would be of great help. Sincerely, Phil Xiang Brandeis University From gawboy@sodium.mps.ohio-state.edu Thu Feb 10 00:33:39 1994 Received: from silicon.mps.ohio-state.edu for gawboy@sodium.mps.ohio-state.edu by www.ccl.net (8.6.4/930601.1506) id AAA05317; Thu, 10 Feb 1994 00:03:25 -0500 Received: from localhost (gawboy@localhost) by silicon.mps.ohio-state.edu (8.6.4/8.6.4) id AAA03751 for CHEMISTRY@ccl.net; Thu, 10 Feb 1994 00:03:26 -0500 From: Galen Gawboy Message-Id: <199402100503.AAA03751@silicon.mps.ohio-state.edu> Subject: CCL:OOP in comp. chem To: CHEMISTRY@ccl.net Date: Wed, 9 Feb 1994 23:53:18 -0500 (EST) X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 3702 Netters, Like many others I find this topic quite fascinating and I just can't keep my big mouth shut. Before I voice my opinions I would just like to state that I believe that both viewpoints are equally valid depending on the specific area of computational chemistry you work in. My viewpoint is that of someone who runs large scale multireference electron correlation calculations. > Ferenc brought up this point. > >>> Third and most important: > >>> As you always have a lack of hardware resources, you > >>> need a compiler which optimizes efficiently. > >>> Often the raw speed of your calculation is the crucial point. > >>> FORTRAN compilers have quite a history and are very effective in > >>> "number crunching" and are essentially bug free. > >>> The advantage of C++ (or say FORTRAN 90) is that you can handle > >>> dynamic memory allocations, but this can slow down the program and > >>> prevent effective optimization. > > To which Quentin replied: > > This I really disagree with. Certainly I always wish my calculations > will go twice as fast but in reality I probably just have to wait > for next year's machines. In my opinion the big challenge facing us > at the moment is verification of correctness not optimization. If a > language change makes a program slower by a factor of two or three then > it is no big deal - that may set us back a year. > Well, if you run large jobs, speed IS critical. When you submit a proposal to a super computer center, one of the issues which you must address is that your codes will make efficient use of the center's resources. On these machines, you can oftentimes only count on getting access to ONE cpu. So for a machine like this, you want the fastest time on a single CPU which you can manage. Suppose my application code runs at 235 MFLOPS on a single cray CPU. If it only ran at 78 or 156 MFLOPS it could cost me getting my grant for time approved. If I was paying cash for the time, I would rather have 235 MFLOPS performance than 156 MFLOPS anyday, so as to get more results/dollar. Also most ab-initio packages do not rely on compiler optimization, these packages are hand tuned for each machine on which they are going to be run on. This tuning is usually done in the number crunching library routines. > > But if we could introduce > a better and more robust design that would benefit us for the lifetime > of the program (which has been ~25years for codes like GAUSSIAN). Here we run into a the harsh realities of the real world. To re-design and re-implement the major ab-initio packages would optimistically take 8-10 years. What is the probablility of getting funding for such an effort? What would be the probability of getting this effort funded if the end product was going to be 2-3 times slower than what already exists? What is more likely is that the large codes will evolve. For example some ab-initio packages are begining to use C routines to implement byte addresable rather than word addressable arrays. Also many parralelization efforts on these codes use C library routines to handle the message passing/load balancing on parralel machines. > If > we want to go faster by orders of magnitude then only better algorithms > and/or faster hardware can do it for us; not compiler optimizations. But > most importantly we need the right answer not the fastest answer. > I agree whole-heartedly with this. But what will happen will most likely be evolution rather than revolution. As I have pointed out above, the evolution is already happening. -Regards galen From seibel@phmms0.mms.smithkline.com Thu Feb 10 01:21:08 1994 Received: from phinet.smithkline.com for seibel@phmms0.mms.smithkline.com by www.ccl.net (8.6.4/930601.1506) id AAA05372; Thu, 10 Feb 1994 00:22:24 -0500 Received: by phinet.smithkline.com (5.57/ULTRIX-az-040392); id AA19079; Thu, 10 Feb 94 00:19:40 -0500 Received: by phmms0.mms.smithkline.com (931110.SGI/931108.SGI.ANONFTP) for @phinet.smithkline.com:CHEMISTRY@ccl.net id AA19083; Thu, 10 Feb 94 00:21:53 -0500 Date: Thu, 10 Feb 94 00:21:53 -0500 From: seibel@phmms0.mms.smithkline.com (George Seibel) Message-Id: <9402100521.AA19083@phmms0.mms.smithkline.com> To: CHEMISTRY@ccl.net Subject: Re: OOP Jerry Perlstein writes: >Paul Townsend replies: >> I find this point mildly hilarious ! Just yesterday I came across an Amber >> example where user in question had to increase an array parameter in order >> to perform a calculation. Time to edit and recompile was minutes. >> Increased execution time vs dynamic allocation (C etc ...) was probably a >> second at most. Fair trade ? I think not. >> >I agree with Dan Severances reply to this. I do Monte Carlo simulations >than often run 7 days or more on an RS6000. I have written code for this >both in C and FORTRAN for this machine and frankly I must tell you that >C is a poor second when it comes to number crunching speed. While I prefer >C as a language, the overwhelming need for fast turnaround time requires >that I stick to FORTRAN. I don't see this changing anytime soon. I would >be interested to know if anyone else has done comparisons. I'm afraid Paul Townsend was right. At least mostly right. Dan's interpretation of Paul's statement was that dynamic allocation slowed the program significantly, like one second out of ten. In a program like Amber, you could do the allocation one time, and that would be that. Never again would you need to allocate. How long does one malloc() take? Some number of miliseconds, not a second on any machine I'm aware of. If your code is brain damaged, and does a malloc/free pair inside of an inner loop, then yes, you will slow down. But that's not the fault of malloc, it's the fault of the programmer who doesn't design well. As for the speed of C relative to FORTRAN, my experience on SGI and Sun machines is that there is not a significant difference when both languages are used correctly. I've done the comparison. Fast loops in C look an awful lot like fast loops in FORTRAN. You can write slow code in either language, too. George Seibel seibelgl@sb.com From gl@coil.mdy.univie.ac.at Thu Feb 10 03:21:12 1994 Received: from coil.mdy.univie.ac.at for gl@coil.mdy.univie.ac.at by www.ccl.net (8.6.4/930601.1506) id CAA05987; Thu, 10 Feb 1994 02:41:25 -0500 Received: by coil.mdy.univie.ac.at (930416.SGI/930416.SGI) for CHEMISTRY@ccl.net id AA08287; Thu, 10 Feb 94 08:40:46 +0100 From: "Gerald Loeffler" Message-Id: <9402100840.ZM8285@coil.mdy.univie.ac.at> Date: Thu, 10 Feb 1994 08:40:44 +0100 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: CHEMISTRY@ccl.net Subject: OOP in Comp. Chemistry Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Good morning net-chemists! Just a few sentences in reply to your discussion of computer languages in comp. chemistry: When will theoretical scientists wake up and realize that programming is a major part of their skill! Would any experimental scientist ever dare to neglect state-of-the-art equipment? So face it: FORTRAN IS DEAD (for at least half a decade), JUST USE C++ !!! C++ is not perfect, but it's as close to a comfortable, high-performance programming language as you can get today. And be sure that further development proceeds from C++ and not from FORTRAN (or do you really consider FORTRAN90 a development?) Those handful of theorists that are programming a CM5 or a C90 and need every nanosecond of CPU-cycle to finish their computations in 2.5 rather then 3 years may really need those extra-bit of performance FORTRAN gives them. You may flame me! But the others should compare the sum of maintenance time and run-time of FORTRAN and C++ software! Don't mix up your laziness in switching to a new programming-paradigm with the need for high performance! Sorry for the emotions, Gerald -- Gerald Loeffler : gl@coil.mdy.univie.ac.at Theoretical Biochemistry Group, Department of Theoretical Chemistry University of Vienna Institut fuer Theoretische Chemie und Strahlenchemie der Universitaet Wien Arbeitsschwerpunkt Theoretische Biochemie Waehringerstrasse 17/Parterre A-1090 Wien, Austria From Leif.Laaksonen@pobox.csc.fi Thu Feb 10 04:21:16 1994 Received: from pobox.csc.fi for Leif.Laaksonen@pobox.csc.fi by www.ccl.net (8.6.4/930601.1506) id DAA06517; Thu, 10 Feb 1994 03:56:57 -0500 Received: from [128.214.46.163] (laaksone.csc.fi) by pobox.csc.fi with SMTP id AA01336 (5.65c8+/IDA-1.4.4 for ); Thu, 10 Feb 1994 10:56:43 +0200 Date: Thu, 10 Feb 1994 10:56:43 +0200 Message-Id: <199402100856.AA01336@pobox.csc.fi> X-Sender: laaksone@finsun.csc.fi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Gerald Loeffler" From: Leif.Laaksonen@csc.fi Subject: Re: CCL:OOP in Comp. Chemistry Cc: chemistry@ccl.net This discussion about OOP in chemistry is going the wrong way again. We have discussed too many times already about which program language is superior or which is dead or anything else in that direction. As far as I can understand we will be programming in any language available, efficiently or not. The thing I was interested in was the PRODUCT. Should we be producing programs in a more modular (object) basis which would make it easier to reuse and maintain the code or not? Instead of producing n-number of programs doing MCSCF or MP2 should we now produce plug in modules? Would it be absolutely impossible to agree about a common interface standard between modules (or even programs)? Perhaps this is already too late because everything has a price tag on it now. Today when we all have to be producing income in one or an other way. Does anybody know if there is a collaborative effort to restructure computational chemistry code into a more object based approach? The other thing which surprises me a bit is the lack of interest in tools like WWW, Mosaic and Gopher. I think the biochemistry (no I'm not a biochemist) community has done a good job here. Just imagine that we computational chemists could download force field parameters, basis sets, structures and so on as the biochemists can download and search sequence data and structures now. My 0.02 Finn mark (which is worth terrible little). -leif laaksonen ------------------------------------------------------------------- Leif Laaksonen | Center for Scientific Computing | Phone: 358 0 4572378 P.O. Box 405 | Telefax: 358 0 4572302 FIN-02101 Espoo | Voice Mail: 358 486257407 FINLAND | Mail: Leif.Laaksonen@csc.fi -------------URL: http://www.csc.fi/faces/leif.html---------------- New opinions are always suspected, and usually opposed, without any other reason but because they are not already common. John Locke ------------------------------------------------------------------- From kras@ncc.free.net Thu Feb 10 04:29:19 1994 Received: from unic.uni-c.dk for kras@ncc.free.net by www.ccl.net (8.6.4/930601.1506) id EAA06578; Thu, 10 Feb 1994 04:04:15 -0500 Received: from ncc.free.net by unic.uni-c.dk (5.65c+/1.34) id AA23138; Thu, 10 Feb 1994 10:03:57 +0100 Received: from [193.124.3.23] (nmr2.ioh.free.net) by ncc.free.net with SMTP id AA12954 (5.65c8/EM.01/IDA-1.4.4 for chemistry@ccl.net); Thu, 10 Feb 1994 08:44:00 GMT From: "Anatoly Krasavin" Date: Sun, 9 Jan 94 12:40:08 +0300 Message-Id: <45609.kras@ncc.free.net> X-Popmail-Charset: IBM 8-Bit To: chemistry@ccl.net Subject: Re: OOP All languages are practically equal! X-Russian: Cyrillic On Thu, 10 Feb 94 00:21:53 -0500, George Seibel wrote: >Jerry Perlstein writes: > >I'm afraid Paul Townsend was right. At least mostly right. Dan's >interpretation of Paul's statement was that dynamic allocation slowed >the program significantly, like one second out of ten. In a program >like Amber, you could do the allocation one time, and that would be that. >Never again would you need to allocate. How long does one malloc() take? >Some number of miliseconds, not a second on any machine I'm aware of. >If your code is brain damaged, and does a malloc/free pair inside of an >inner loop, then yes, you will slow down. But that's not the fault of >malloc, it's the fault of the programmer who doesn't design well. > >As for the speed of C relative to FORTRAN, my experience on SGI and Sun >machines is that there is not a significant difference when both languages >are used correctly. I've done the comparison. Fast loops in C look >an awful lot like fast loops in FORTRAN. You can write slow code in >either language, too. > >George Seibel >seibelgl@sb.com I think there are no way dynamic memory allocation can slow down your program, because compiler works with both fixed and dynamically-allocated modules in the same way. Yes, if you write programs according to stupid Program Examples and allocate every float-point number in array, that it will be. But if you allocate only big modules (the whole matrix for example) then it works well. What about benchmarks and compilers... Well, last versions of Fortran, C, Pascal, etc work with numbers equally. All the remarks about "my program in Fortran works 30 percent quicker" show only that you haven't write optimal code. Anyway, if you like speed, then use build-in assembler to go through all bottle-necks. It is worth to spend a lot of time (10-100 times at least!) to receive really optimal code (2-3 times) without any Fortran optimizers. > > >---Administrivia: This message is automatically appended by the mail exploder: >CHEMISTRY@ccl.net -- everyone | CHEMISTRY-REQUEST@ccl.net -- coordinator >MAILSERV@ccl.net: HELP CHEMISTRY | Gopher: www.ccl.net (port 70 or 73) >Anon. ftp www.ccl.net | CHEMISTRY-SEARCH@ccl.net -- archive search -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Anatoly O. Krasavin chief programmer NMR group N.D.Zelinsky Institute of Organic Chemistry Leninsky pr, 47 117913, Moscow B-334 Russia Fax (7-095) 135 53 28 Tel (7-095) 135 90 94 e-mail -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From kneth@kiku.dk Thu Feb 10 05:21:33 1994 Received: from krypton for kneth@kiku.dk by www.ccl.net (8.6.4/930601.1506) id EAA06848; Thu, 10 Feb 1994 04:58:02 -0500 Received: from osc.kiku.dk by krypton.kiku.dk with smtp (smail3.1.28.1) id m0pUY9i-0001GFC; Thu, 10 Feb 94 10:57 MET Message-Id: Received: by osc.kiku.dk (15.11/15.6) id AA03912; Thu, 10 Feb 94 10:57:31 -0100 Subject: Chemical Compilers To: chemistry@ccl.net (Computational Chem.) Date: Thu, 10 Feb 94 10:57:29 MET From: Kenneth Geisshirt Mailer: Elm [revision: 64.9] Hi Netters! I am writting on my M.S. thesis at the moment. During my graduate studies, I have been working on a chemical compiler, i.e. a program which can translate a set of chemical reactions into a simulation program. I would like to compare my program with other programs, and therefore I ask if anybody knows of such programs. I am interested in references to papers and/or source code (so I can try the program). Thank you in advance. +----------------------------------------------------------+ | Kenneth Geisshirt (kneth@osc.kiku.dk) - graduate student | | Dept. of Theoretical Chemistry, University of Copenhagen | +----------------------------------------------------------+ | Experiment with a chemist | +----------------------------------------------------------+ From kneth@kiku.dk Thu Feb 10 06:21:22 1994 Received: from krypton for kneth@kiku.dk by www.ccl.net (8.6.4/930601.1506) id FAA07342; Thu, 10 Feb 1994 05:57:31 -0500 Received: from osc.kiku.dk by krypton.kiku.dk with smtp (smail3.1.28.1) id m0pUZ5P-0001FAC; Thu, 10 Feb 94 11:57 MET Message-Id: Received: by osc.kiku.dk (15.11/15.6) id AA04498; Thu, 10 Feb 94 11:57:08 -0100 Subject: Chemical Compiler To: CHEMISTRY@ccl.net Date: Thu, 10 Feb 94 11:57:06 MET From: Kenneth Geisshirt Mailer: Elm [revision: 64.9] Hi Netter! I am looking for "chemical compilers" i.e. programs which can translate a set of chemical reaction into a simulation program. I am interested in both source code and references to papers. +----------------------------------------------------------+ | Kenneth Geisshirt (kneth@osc.kiku.dk) - graduate student | | Dept. of Theoretical Chemistry, University of Copenhagen | +----------------------------------------------------------+ | Experiment with a chemist | +----------------------------------------------------------+ From h.rzepa@ic.ac.uk Thu Feb 10 06:24:05 1994 Received: from punch.ic.ac.uk for h.rzepa@ic.ac.uk by www.ccl.net (8.6.4/930601.1506) id FAA07333; Thu, 10 Feb 1994 05:54:43 -0500 Received: from sg1.cc.ic.ac.uk by punch.ic.ac.uk with SMTP (PP) id <01951-0@punch.ic.ac.uk>; Thu, 10 Feb 1994 10:51:10 +0000 Received: from rzepa.ch by cscmgb.cc.ic.ac.uk (920330.SGI/4.0) id AA16567; Thu, 10 Feb 94 10:53:45 GMT Date: Thu, 10 Feb 94 10:53:45 GMT Message-Id: <9402101053.AA16567@cscmgb.cc.ic.ac.uk> X-Sender: rzepa@sg1.cc.ic.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: chemistry@ccl.net From: h.rzepa@ic.ac.uk (Henry Rzepa) (Henry Rzepa) Subject: Re: CCL:Re: CCL:OOP in Comp. Chemistry Leif Laaksonen writes >The thing I was interested in was the PRODUCT. Should we be producing >programs in a more modular (object) basis which would make it easier >to reuse and maintain the code or not? Instead of producing n-number >of programs doing MCSCF or MP2 should we now produce plug in modules? >Would it be absolutely impossible to agree about a common interface >standard between modules (or even programs)? Our effort was in modular Explorer (see http://argon.ch.ic.ac.uk/jmg/CRG.html) Clearly, the thing could be extended to number crunching calculations! >The other thing which surprises me a bit is the lack of interest in >tools like WWW, Mosaic and Gopher. I think the biochemistry (no I'm >not a biochemist) community has done a good job here. Lack of interest? See the http ref above!! I agree however. There are only a handful of www and gopher servers dedicated to chemistry in the world. I PREDICT that by the end of 1994, there will be >100 such www servers in chemistry. Anyone give me any odds? Henry Rzepa From moshe_o@vnet.IBM.COM Thu Feb 10 10:22:24 1994 Received: from vnet.IBM.COM for moshe_o@vnet.IBM.COM by www.ccl.net (8.6.4/930601.1506) id JAA08829; Thu, 10 Feb 1994 09:47:36 -0500 Message-Id: <199402101447.JAA08829@www.ccl.net> Received: from HAIFASC3 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1864; Thu, 10 Feb 94 09:46:23 EST Date: Thu, 10 Feb 94 16:34:26 IDT From: "Moshe Olshansky" To: chemistry@ccl.net Subject: FORTRAN versus C I saw a posting telling that on RS6000 Fortran performs much better for heavy numerical applications than C. Personally I always preferred Fortran, but not because of it's performance. Here in Haifa we have a group working on improving the compilers for RS6000 (both Fortran and C), so I asked them about this issue. Their response was that if one tries hard and writes a C program in a very special (machine dependent) manner, it may perform quite well. However, for programs written in a more or less standard language Fortran should indeed have a better performance than C, and this is due not to the compiler but to the languages themselves. Therefore, it is very likely that Fortran will maintain a performance advantage over C for a long time. Moshe Olshansky IBM Israel Science & Technology Haifa, Israel From FS300627@Sol.YorkU.CA Thu Feb 10 10:32:24 1994 Received: from Sol.YorkU.CA for FS300627@Sol.YorkU.CA by www.ccl.net (8.6.4/930601.1506) id KAA09068; Thu, 10 Feb 1994 10:08:22 -0500 From: Received: from Sol.YorkU.CA by Sol.YorkU.CA (PMDF #12410) id <01H8PT8LQN8W90S4KC@Sol.YorkU.CA>; Thu, 10 Feb 1994 10:06 EDT Date: Thu, 10 Feb 1994 10:06 EDT Subject: MDL problems? To: chemistry@ccl.net Message-id: <01H8PT8LQN8W90S4KC@Sol.YorkU.CA> X-Envelope-to: chemistry@ccl.net X-VMS-To: IN%"chemistry@ccl.net" Hi there, I am interested in obtaining the ISIS/DRAW & ISIS/BASE package.However, a couple of days ago someone told me that the company that supports this package (MDL) is in serious problems. Does anyone know more about this? Thanks. ************************************************************************** ** Patrick van der Valk | It is a capital mistake to theorize * ** BioMimic | before one has data. Insensibly one * ** | begins to twist facts to suit theories * ** e-mail:FS300627@Sol.YorkU.Ca | instead of theories to suit facts. * ** Phone: (416) 739-0783 | * ** Fax: (416) 650-3558 | -Sherlock Holmes- * ************************************************************************** From figuei@lutece.rutgers.edu Thu Feb 10 11:21:47 1994 Received: from lutece.rutgers.edu for figuei@lutece.rutgers.edu by www.ccl.net (8.6.4/930601.1506) id LAA10202; Thu, 10 Feb 1994 11:06:32 -0500 Received: by lutece.rutgers.edu (931110.SGI/920502.SGI.ANONFTP) for CHEMISTRY@ccl.net id AA29736; Thu, 10 Feb 94 11:05:52 -0500 Date: Thu, 10 Feb 94 11:05:52 -0500 From: figuei@lutece.rutgers.edu (Francisco Figueirido) Message-Id: <9402101605.AA29736@lutece.rutgers.edu> To: lsaw00@risque.chem.rochester.edu Cc: CHEMISTRY@ccl.net, dan@omega.chem.yale.edu In-Reply-To: <9402092048.AA13533@risque.chem.rochester.edu> (lsaw00@risque.chem.rochester.edu) Subject: Re: CCL:Re: CCL:CCL:OOP Reply-To: figuei@lutece.rutgers.edu I have seen many comments on the "religious" issue of whether FORTRAN is better than C or viceversa. It seems to me that the discussion is misdirected. I must, at the start, say that I have strong bowel movements whenever somebody mentions FORTRAN, so my comments below are also biased. It is well known that FORTRAN code that deals with linear arrays is easier to optimize than code written in C or C++ due to pointer aliasing in these latter languages. It is also well known that most numeric codes spent most of their time in simple computations (if I am mistaken I will appreciate corrections). I would NEVER write a user interface or script interpreter in FORTRAN, but I would seriously consider writing short routines that perform most of the numerical work in FORTRAN (unless the C/C++ compiler allows me to optimize the code, for example, with #pragma directives, to the same extent as the FORTRAN compiler). I routinely write code that interfaces pieces in C, C++ and FORTRAN on several machines (all UNIX compatible) and have found no problems (at least as long as character strings are not passed around). There is no need, in my view, to write a program all in ONE language. The best design would exploit each language's strengths and work to avoid its defficiencies. An important strength of C++ (maybe of any OOPL) is that it allows the programmer to present a SIMPLE and NATURAL interface that encapsulates all or most of the messy implementation details. This makes it much better than C, and infinitely better than FORTRAN; but it can also lead to inefficient code unless the design has been thoroughly thought out. From ryszard@MSI.COM Thu Feb 10 12:21:54 1994 Received: from schizoid.msi.com for ryszard@MSI.COM by www.ccl.net (8.6.4/930601.1506) id LAA10473; Thu, 10 Feb 1994 11:23:32 -0500 Received: from hogan.MSI.COM by schizoid.msi.com (4.1/SMI-4.1) id AA22622; Thu, 10 Feb 94 11:23:00 EST Received: by hogan.MSI.COM (AIX 3.2/UCB 5.64/4.03) id AA14863; Thu, 10 Feb 1994 11:22:58 -0500 Date: Thu, 10 Feb 1994 11:22:58 -0500 From: ryszard@MSI.COM (Ryszard Czerminski X 285) Message-Id: <9402101622.AA14863@hogan.MSI.COM> To: chemistry@ccl.net Subject: FORTRAN versus C Moshe Olshansky wrote: [...] However, for programs written in a more or less standard language Fortran should indeed have a better performance than C, and this is due not to the compiler but to the languages themselves. [...] This is really hard to understand for me (maybe somebody would enlighten me in this matter). After all when you write a program (in any language) you basically write a plain TEXT. Compiler converts it (eventually) into strings of bits which hardware can understand, so every programs when finally presented to the hardware looks more or less similarly boring 01110010010010101000000100... 101000101010001000100001010... etc and this is COMPILER job to make these bits string perform properly with given hardware. Ryszard Czerminski, Molecular Simulations, Inc. From srp@ZGI.COM Thu Feb 10 12:25:47 1994 Received: from m5.ZGI.COM for srp@ZGI.COM by www.ccl.net (8.6.4/930601.1506) id LAA10967; Thu, 10 Feb 1994 11:58:03 -0500 Received: from zgi.com (stella.ZGI.COM) by m5.ZGI.COM (4.1/SMI-4.1) id AA00244; Thu, 10 Feb 94 08:56:59 PST Received: from blaster.zgi.com by zgi.com (4.1/SMI-4.1) id AA26115; Thu, 10 Feb 94 08:56:59 PST Received: from localhost by blaster.zgi.com (8.6.4/920502.SGI) id IAA10523; Thu, 10 Feb 1994 08:56:58 -0800 Date: Thu, 10 Feb 1994 08:56:58 -0800 From: srp@ZGI.COM (Scott Presnell) Message-Id: <199402101656.IAA10523@blaster.zgi.com> To: "Moshe Olshansky" Subject: Re: CCL:FORTRAN versus C Cc: chemistry@ccl.net Moshe Olshansky writes: >Personally I always preferred Fortran, but not because of it's performance. >Here in Haifa we have a group working on improving the compilers for RS6000 >(both Fortran and C), so I asked them about this issue. Their response was >that if one tries hard and writes a C program in a very special (machine >dependent) manner, it may perform quite well. However, for programs >written in a more or less standard language Fortran should indeed have >a better performance than C, and this is due not to the compiler but >to the languages themselves. Therefore, it is very likely that Fortran >will maintain a performance advantage over C for a long time. (I wasn't going to jump into this, but...) Even when spoken from a compiler group, I really don't see how this is possible. I don't write compilers, but most compilers for Fortran and C I'm familiar with generate assembler code (virtual or not) from their backend, independent of the language that enters on the frontend. Hence these high level languages are funneled through a common representation. I grant you that compiler technology may be at different levels of development for different languages, but it seems to me that in the end, you are limited by: A) The ability of the compilers to translate and optimize the high level language into assembler. B) The constraints of the assembler available for the processor under question. There are indeed differences between Fortran and C specs (such as call by reference vs. call by value), but I'm not aware of differences that would allow for "better performance" given the above constraints... Can you give us some more detail on what your compiler friends are referring to? - Scott Presnell (srp@zgi.com) From mam@xenon.chem.ucla.edu Thu Feb 10 13:21:26 1994 Received: from xenon.chem.ucla.edu for mam@xenon.chem.ucla.edu by www.ccl.net (8.6.4/930601.1506) id MAA11297; Thu, 10 Feb 1994 12:28:53 -0500 Received: by xenon.chem.ucla.edu (4.1/SMI-4.1) id AA23859; Thu, 10 Feb 94 09:30:55 PST Date: Thu, 10 Feb 94 09:30:55 PST From: mam@xenon.chem.ucla.edu (McAllister Michael) Message-Id: <9402101730.AA23859@xenon.chem.ucla.edu> To: chemistry@ccl.net Subject: thermochem in gaussian I have a very simple question -- I hope someone has an equally simple answer!! Is there a reasonably straight forward way to get calculated enthalpies from a gaussian frequency job?? I noticed the freq job prints some information about 'thermal energies' -- are these related to enthalpies?? I do know the equations for converting internal energies (HFscf) to enthalpies -- but i don't know where this info is in the gaussian output. Any help would be greatly appreciated. Mike McAllister From shepard@dirac.tcg.anl.gov Thu Feb 10 14:21:32 1994 Received: from dirac.tcg.anl.gov for shepard@dirac.tcg.anl.gov by www.ccl.net (8.6.4/930601.1506) id NAA12335; Thu, 10 Feb 1994 13:28:19 -0500 Received: by dirac.tcg.anl.gov (4.1/SMI-4.1) id AA11578; Thu, 10 Feb 94 12:28:18 CST Date: Thu, 10 Feb 94 12:28:18 CST From: shepard@dirac.tcg.anl.gov (Ron Shepard) Message-Id: <9402101828.AA11578@dirac.tcg.anl.gov> To: chemistry@ccl.net Subject: Re: CCL:FORTRAN versus C Cc: shepard@tcg.anl.gov Scott Presnell (srp@zgi.com) writes: >There are indeed differences between Fortran and C specs (such as call by >reference vs. call by value), but I'm not aware of differences that would >allow for "better performance" given the above constraints... Can you give >us some more detail on what your compiler friends are referring to? These are well known issues, and this chemistry mail exploader is not the best place to discuss them. Although fortran and C are quite similar in many respects, there are some important semantic differences. One of the biggest that relates to performance is aliasing of variables. The C model is basically (with a few exceptions) that any two pointers can point anywhere in memory; this prevents the compiler from making assumptions about prefetching items into registers, setting up tight pipelined loops, etc. In fortran, there are not explicit pointers, only implicit pointers to dummy arguments. But fortran does not allow dummy arguments that are modified to be aliased. This allows the fortran compiler to perform optimizations that a C compiler cannot. On the other hand, compact C code can exploit such aliases to do clever things. Consequently, both languages have evolved into incompatible "local minima" of sorts, where each has an advantage in different situations. It is unlikely that fortran will change to adopt a "wild pointer" semantics, and it is unlikely that C will tame its pointers (there was a failed effort to do so during the ANSI standardization process). $.02 -Ron Shepard From rs0thp@RohmHaas.Com Thu Feb 10 14:25:16 1994 Received: from monte.br.RohmHaas.Com for rs0thp@RohmHaas.Com by www.ccl.net (8.6.4/930601.1506) id NAA12463; Thu, 10 Feb 1994 13:38:17 -0500 Received: by monte.br.RohmHaas.Com (AIX 3.2/UCB 5.64/4.03) id AA14244; Thu, 10 Feb 1994 13:37:33 -0500 From: rs0thp@RohmHaas.Com (Dr. Tom Pierce) Message-Id: <9402101837.AA14244@monte.br.RohmHaas.Com> Subject: Re: CCL:FORTRAN versus C To: chemistry@ccl.net Date: Thu, 10 Feb 1994 13:37:33 +22305350 (EST) In-Reply-To: <9402101622.AA14863@hogan.MSI.COM> from "Ryszard Czerminski X 285" at Feb 10, 94 11:22:58 am X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2170 Previously, Ryszard Czerminski X 285 wrote: > > Moshe Olshansky wrote: > [...] > However, for programs > written in a more or less standard language Fortran should indeed have > a better performance than C, and this is due not to the compiler but > to the languages themselves. > [...] > > This is really hard to understand for me (maybe somebody would enlighten me > in this matter). > After all when you write a program (in any language) you basically > write a plain TEXT. Compiler converts it (eventually) into strings > of bits which hardware can understand, so every programs when finally > presented to the hardware looks more or less similarly boring > > 01110010010010101000000100... > 101000101010001000100001010... etc > > and this is COMPILER job to make these bits string perform > properly with given hardware. Ok - My vote on the religious war is that I like both C and FORTRAN. My productivity toos are in C (mail, Mosaic, etc), my computations in FORTRAN. Now as to the differences, C language allows one to easily write logical constructions that are complex and may have multiple outputs. This makes optimizing C much harder than optimizing Fortran. Fortran is quite rigid in the logical segments that one writes. A friend of mine, once summarized it in this way. That he wanted to write C code, but he wanted his customers to write in FORTRAN because it simplified his job. Basically if the language is simple and does not allow logical complexity, then compilers can do a very effective job optimizing the machine code. If the program has lots of different kinds of logical segments, then one cannot anticipate the outcomes and prepare for them, or sometimes even predict what part of the program would need to be loaded next.. I think that FORTRAN will be the language of computational science for a long time. caveat - unless the MIMD parallel machines *change* the requirements for speed optimizations to something like I/O or nearest CPU/Instruction.... -- Sincerely, Thomas Pierce - THPierce@RohmHaas.Com - Computational Chemist "These opinions are those of the writer and not the Rohm and Haas Company." From ravishan@swan.wcc.wesleyan.edu Thu Feb 10 14:27:52 1994 Received: from swan.wcc.wesleyan.edu for ravishan@swan.wcc.wesleyan.edu by www.ccl.net (8.6.4/930601.1506) id NAA12650; Thu, 10 Feb 1994 13:58:13 -0500 Received: by swan.wcc.wesleyan.edu (AIX 3.2/UCB 5.64/4.03) id AA14372; Thu, 10 Feb 1994 13:55:51 -0500 Date: Thu, 10 Feb 1994 13:55:51 -0500 Message-Id: <9402101855.AA14372@swan.wcc.wesleyan.edu> From: "G. Ravishanker" To: chemistry@ccl.net In-Reply-To: <199402101656.IAA10523@blaster.zgi.com> (srp@ZGI.COM) Subject: Re: CCL:Re: CCL:FORTRAN versus C Hi I could not resist throwing my two cents. We have several instances where the MD code that we use, called WESDYN, has been subjected to the Fortran vs C issue. That is, the non-bonded interaction routines have been written in both languages and the wall-clock and CPU times were compared. It has always turned out that Fortran beats C on several hardware platforms. However, as many people have pointed out, the comparison has several if's and but's. If one spends an awful lot of time tweaking the C-code to optimize it, rather than simply running f2c type of conversion programs, it is likely that the C version can be made to perform better. The view we take is simple: 1. The number-crunching portion of the program works faster in Fortran for us, so stick with it. It is because we understand how to make things perform better under Fortran from our prior experience. It is also not hard to write Fortran '77 programs that are readable and structured (not as structured as some hard-core computer scientists may like), properly indented and all that. (emacs19 is an excellent tool for this... Oh Oh, now I created a monster-- Which is the better editor vi or emacs?) 2. The code development in some ways is driven by who is your user. I cannot expect to develop a C program and give it to the group if most of them are Fortran-wise. 3. Front-ends, such as windows for inputting the data, or display outputs are easily and elegantly programmed in C++ and most of the "number crunchers" are simply not interested in getting involved at that level of programming. So, do that portion of code in the most convenient language of choice. Ravi **************************************************************************** * Ganesan Ravishanker Ph: (203) 344-8544 Ext. 3110 * * Coordinator of Scientific Computing, Fax:(203) 344-7960 * * Adjunct Associate Professor(Dept. of Chem.) * * Wesleyan University e-mail:ravishan@swan.wcc.wesleyan.edu * * Middletown, CT 06457. * **************************************************************************** From cmao771@charon.chpc.utexas.edu Thu Feb 10 14:29:25 1994 Received: from hermes.chpc.utexas.edu for cmao771@charon.chpc.utexas.edu by www.ccl.net (8.6.4/930601.1506) id NAA12258; Thu, 10 Feb 1994 13:27:27 -0500 Received: from charon.chpc.utexas.edu by hermes.chpc.utexas.edu (5.64/SMI-3.2) id AA19542; Thu, 10 Feb 94 12:27:18 -0600 Received: by charon.chpc.utexas.edu (5.61/SMI-3.2) id AA15229; Thu, 10 Feb 94 12:27:17 -0600 From: cmao771@charon.chpc.utexas.edu (Bersuker) Message-Id: <9402101827.AA15229@charon.chpc.utexas.edu> Subject: MM with transition metal cpds To: chemistry@ccl.net (Computational Chemistry List) Date: Thu, 10 Feb 94 12:27:16 CST Cc: cmao771@hermes.chpc.utexas.edu (Bersuker) X-Mailer: ELM [version 2.3 PL11] In reply to many inquiries I present my Abstract to the 15th Austin Symposium on Molecular Structure(Austin, March 21-23, 1994) I am open to cooperation on this and related topics. PRINCIPLES OF MOLECULAR MODELING FOR TRANSITION METAL SYSTEMS The well known methods of molecular mechanics (MM) useful for modeling organic compounds are, in general, invalid for transition metal compounds including organometallics. The success of the MM methods in application to organic compounds is due mainly to the electron homogeneity produced by similar snpm (mostly 2sn2pm) atoms. Because of their d electron participation, transition metals introduce strong heterogeneity into the system which makes the idea of force fields with constant parameters inapplicable. The most important effects of this heterogeneity are: nontransferability, ligand excitation, and electron-coformational effects [1]. Nontransferability of the metal-ligand bond parameters is caused by the three-dimensional delocalization of the bonding density due to the participation of d electrons. This results in the strong dependence of any given M-L1 bond on the other bonds M-L2, M-L3, etc., formed by the same atom M. It means that, in general, there are no constant characteristics of the M-L bonds to be used in the force field of the MM methods. Ligand excitation is due to the orbital charge transfer from the ligand to the metal and subsequent back donation of electron density from the metal to the excited states of the ligand. The partially excited ligands cannot be accurately modeled in terms of force field parameters or molecular orbital indices derived for the ground state. The electron-conformational effects in organometallics are changes in the conformation of the organic environment due to charge rearrangements in the metal center. These effects can be of great significance within biological systems but are not addressed by standard MM methods. We suggest a method of modeling organometallic and other transition metal compounds which takes into account all three of the effects described above. In this method, the electronic structure calculation and geometry optimization are performed on molecular fragments (including self-consistent inter-fragmentary interactions). The main fragment (I) consists of the metal and its near-neighbor environment; the remaining organic groups comprise the secondary fragments (II). The method includes vibronic coupling effects for fragment I and modified MM for fragments II. The results are used to introduce a special index of atomic reactivity in orbital-controlled interactions and then to describe the molecular system in terms of a 3-dimensional matrix which contains information about the electronic structure and geometry of one or more conformations. Comparison of a series of molecular systems described in this fashion with their corresponding activities allows one to determine both the electronic parameters and conformation required for favorable interaction with a receptor site (e.g., to determine the pharmacophore within a series of bioactive compounds). 1. I.B.Bersuker, Electronic Structure and Properties of Transition Metal Compounds. Introduction to the Theory, in press. -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Isaac B. Bersuker | E-mail: Dept. of Chemistry | cmao771@charon.chpc.utexas.edu B Univeristy of Texas at Austin | Vox: (512) 471-4671 Austin, TX 78712 | Fax: (512) 471-8696 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From burkhart@goodyear.com Thu Feb 10 15:21:27 1994 Received: from goodyear.com for burkhart@goodyear.com by www.ccl.net (8.6.4/930601.1506) id OAA13571; Thu, 10 Feb 1994 14:58:22 -0500 Received: from rdsrv2 (rdsrv2.goodyear.com) by goodyear.com (4.1/SMI-4.1) id AA24246; Thu, 10 Feb 94 14:58:17 EST Received: from rds325 by rdsrv2 (4.1/SMI-4.1) id AA09114; Thu, 10 Feb 94 14:58:16 EST Received: by rds325 (920330.SGI/920502.SGI.AUTO) for @rdsrv2:mam@xenon.chem.ucla.edu id AA00735; Thu, 10 Feb 94 14:57:45 -0500 Date: Thu, 10 Feb 94 14:57:45 -0500 From: burkhart@goodyear.com (Craig W. Burkhart) Message-Id: <9402101957.AA00735@rds325> To: mam@xenon.chem.ucla.edu (McAllister Michael) Subject: Re: CCL:thermochem in gaussian Cc: chemistry@ccl.net If you look at Hehre, Radom, von Schleyer & Pople ("Ab Initio Molecular Orbital Theory"), you will find on pgs. 251-60 a full explanation of the entities involved in computing enthalpy, entropy, and by implication, free energies. I don't have G9X, but I would expect the common components to be there... -------------------------------------------------------------------------- Craig W. Burkhart, Ph.D. Senior Research Chemist E-mail: cburkhart@goodyear.com The Goodyear Tire & Rubber Co. Fone: 216.796.3163 Research Center Fax: 216.796.3304 142 Goodyear Boulevard Akron, OH 44305 -------------------------------------------------------------------------- For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled - Feynman -------------------------------------------------------------------------- From sheridan@merck.com Thu Feb 10 16:21:21 1994 Received: from merck.com for sheridan@merck.com by www.ccl.net (8.6.4/930601.1506) id PAA14092; Thu, 10 Feb 1994 15:37:18 -0500 From: Message-Id: <199402102037.PAA14092@www.ccl.net> Received: by igw.merck.com with rsmtp; Thu, 10 Feb 1994 15:40:09 EST Date: Thu, 10 Feb 1994 15:26:18 -0500 (EST) To: chemistry@ccl.net Subject: ACS symposium -- similarity Listed below is the program for the "Chemical Similarity and Superposition" session at the ACS in Denver. The session will be held on the morning of Monday March 14 at the Marriott 8:30 A. Lipkus. "Ordering chemical structures for database browsing." 9:00 J.M. Barnard "Choice of structural descriptors for similarity measurement." 9:30 R. Upton "Use of pharmacophore identification with 3D databases." 10:00 C. Burt "3D molecular similarity calculations in the design of bioactive compounds." 10:30 M. Miller "SQ: a program for producing rapid molecular superpositions." 11:00 D.P. Yee "A measure of protein structural similarity: how tightly are proteins clustered into families." 11:30 R. Nussinov "Surface description, biomolecular recognition (docking), and sequence-order independent substructural motifs in proteins." Details are in the Feb. 7 C&E News pg. 66. From heather@rassilon.chem.yale.edu Thu Feb 10 17:21:23 1994 Received: from rassilon.chem.yale.edu for heather@rassilon.chem.yale.edu by www.ccl.net (8.6.4/930601.1506) id QAA14545; Thu, 10 Feb 1994 16:30:20 -0500 Received: by rassilon.chem.yale.edu; Thu, 10 Feb 94 16:25:50 EST Date: Thu, 10 Feb 94 16:25:50 EST From: Heather Carlson Message-Id: <9402102125.AA06772@rassilon.chem.yale.edu> To: chemistry@ccl.net Subject: religious debate Question to fuel the flames... I understand it is very difficult to read someone else's C code. In a group like ours, we use programs that we have been developing over many years and even more grad students. Is it possible to have C code that could be used as efficiently? (note use here applies to people having to update code with new modules) You could require some standard be used within the group, but will this really stand up over several years & people writing subroutines in their own style anyway? Opinions? Does anyone have code in development (with several people on the project) that is in C? As far as the efficiency debate... don't y'all think that each group has explored their options & already knows what's best for their individual needs? "Don't judge a man until you've walked a mile in his shoes!" Thanks... heather From noy@tci002.uibk.ac.at Thu Feb 10 17:25:56 1994 Received: from uibk.ac.at for noy@tci002.uibk.ac.at by www.ccl.net (8.6.4/930601.1506) id QAA14536; Thu, 10 Feb 1994 16:28:06 -0500 Received: from tci002.uibk.ac.at by uibk.ac.at with SMTP id AA09192 (5.65c/IDA-1.4.4 for ); Thu, 10 Feb 1994 22:28:02 +0100 Received: by tci002.uibk.ac.at (AIX 3.2/UCB 5.64/CFIBK-2e.AIX) id AA39068; Thu, 10 Feb 1994 22:28:00 +0100 From: noy@tci002.uibk.ac.at (Teerakiat Kerdcharoen) Message-Id: <9402102128.AA39068@tci002.uibk.ac.at> Subject: Re: FORTRAN versus C To: chemistry@ccl.net Date: Thu, 10 Feb 1994 22:28:00 +0100 (NFT) In-Reply-To: <9402101837.AA14244@monte.br.RohmHaas.Com> from "Dr. Tom Pierce" at Feb 10, 94 01:37:33 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1349 : : Ok - My vote on the religious war is that I like both C and FORTRAN. :My productivity toos are in C (mail, Mosaic, etc), my computations in FORTRAN. : Hi, I absolutely agree with you on this point. In comparison with C, FORTRAN is easier to port to various machines. The language is simple and easy to understand and plentiful of mathematic functions. Anyway, there are some weak points that make the program written in FORTRAN lacking of Generality. FORTRAN does not support dynamical memory allocations and for this reason I come to love C finally. It takes less time to code in FORTRAN than in C. But after that, most FORTRANers have to re-compile again when they want to run programs using different parameters or configurations. In this case, C users just change their inputs or do at the Unix prompt. Molecular Dynamics program is one of the examples. : I think that FORTRAN will be the language of computational science for : a long time. caveat - unless the MIMD parallel machines *change* the : requirements for speed optimizations to something like I/O or nearest : CPU/Instruction.... : I have to agree with you again on this point. Many langauges are going to die, COBOL, BASIC, PASCAL, RPG but not FORTRAN. It would be nice if you could extend this point more. sincerely, Teerakiat From sheridan@merck.com Thu Feb 10 18:22:40 1994 Received: from merck.com for sheridan@merck.com by www.ccl.net (8.6.4/930601.1506) id RAA15368; Thu, 10 Feb 1994 17:57:08 -0500 From: Message-Id: <199402102257.RAA15368@www.ccl.net> Received: by igw.merck.com with rsmtp; Thu, 10 Feb 1994 18:00:41 EST Date: Thu, 10 Feb 1994 17:54:39 -0500 (EST) To: chemistry@ccl.net Subject: ACS meeting in San Diego Sorry folks, I do mean San Diego, not Denver!! To repeat: Listed below is the program for the "Chemical Similarity and Superposition" session at the ACS in San Diego. The session will be held on the morning of Monday March 14 at the Marriott 8:30 A. Lipkus. "Ordering chemical structures for database browsing." 9:00 J.M. Barnard "Choice of structural descriptors for similarity measurement." 9:30 R. Upton "Use of pharmacophore identification with 3D databases." 10:00 C. Burt "3D molecular similarity calculations in the design of bioactive compounds." 10:30 M. Miller "SQ: a program for producing rapid molecular superpositions." 11:00 D.P. Yee "A measure of protein structural similarity: how tightly are proteins clustered into families." 11:30 R. Nussinov "Surface description, biomolecular recognition (docking), and sequence-order independent substructural motifs in proteins." Details are in the Feb. 7 C&E News pg. 66. From kb7@unix.york.ac.uk Thu Feb 10 18:31:35 1994 Received: from leeman.york.ac.uk for kb7@unix.york.ac.uk by www.ccl.net (8.6.4/930601.1506) id RAA15334; Thu, 10 Feb 1994 17:53:18 -0500 Received: from tower.york.ac.uk by leeman.york.ac.uk with SMTP (PP) id <17208-0@leeman.york.ac.uk>; Thu, 10 Feb 1994 22:52:15 +0000 Received: by tower.york.ac.uk (920330.SGI/920502.SGI) for @leeman.york.ac.uk:CHEMISTRY@ccl.net id AA03903; Thu, 10 Feb 94 22:55:15 GMT Date: Thu, 10 Feb 1994 22:37:58 +0000 (GMT) From: K Bryson Subject: psi88 running from g92 checkpoint files. To: CHEMISTRY@ccl.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I wish to run psi88 MO plotting software from g92. Now the chk2psi.f code provided with psi88 will read g90 checkpoint files. Unfortunately I believe that Gaussian Inc. have increased the sizes of common data arrays going from G90->G92 which will mean that I have to change various common blocks in the chk2psi.f code to get it to read g92 checkpoint files or else it will scramble the ordering of the data. I thought I would inquire whether anyone else has already accomplished this task and has a g92 version of the psi88 code before I start re-coding it myself ( As the current topic seems to be reusable code ... ). Thanks, Kevin. ----------~~~~~~------~~~~~~~~~~---------------~~~~~----------~~~~~-- K.Bryson email: kb7@tower.york.ac.uk Biophysics Group Tel : +44 904 430000 Extn. 2236 Physics Department Fax : +44 904 432214 University of York Heslington "Molecular modelling of DNA and its YORK, UK interaction with small molecules." YO1 5DD -------------------~~~~~-------------~~~~--------~~~~--------~~~~~--- From dan@omega.chem.yale.edu Thu Feb 10 19:21:35 1994 Received: from omega.chem.yale.edu for dan@omega.chem.yale.edu by www.ccl.net (8.6.4/930601.1506) id TAA16449; Thu, 10 Feb 1994 19:16:57 -0500 Received: by omega.chem.yale.edu; Thu, 10 Feb 94 19:16:45 -0500 From: Dan Severance Message-Id: <9402110016.AA17385@omega.chem.yale.edu> Subject: CCL:psi88 running from g92 checkpoint files. (fwd) To: chemistry@ccl.net Date: Thu, 10 Feb 94 19:16:44 EST Organization: Laboratory for Computational Chemistry X-Mailer: ELM [version 2.3 PL11] Hi Netters, > I wish to run psi88 MO plotting software from g92. > Now the chk2psi.f code provided with psi88 will read g90 > checkpoint files. I have uploaded the program chk2psi92.f to www.ccl.net It has been modified to read G92 checkpoint files. checkpoint files... Dan Severance From wolpert@neon.chem.utk.edu Thu Feb 10 21:21:24 1994 Received: from neon.chem.utk.edu for wolpert@neon.chem.utk.edu by www.ccl.net (8.6.4/930601.1506) id VAA17681; Thu, 10 Feb 1994 21:09:00 -0500 Received: by neon.chem.utk.edu (4.0/1.34) id AA25216; Thu, 10 Feb 94 21:09:17 EST Date: Thu, 10 Feb 94 21:09:17 EST From: wolpert@neon.chem.utk.edu (Edward Wolpert) Message-Id: <9402110209.AA25216@neon.chem.utk.edu> To: chemistry@ccl.net, heather@rassilon.chem.yale.edu Subject: Re: CCL:religious debate Heather asked the question: "Is C code good for group projects?" (Basically) The answer is: Maybe. Much of what is written for computers currently is in C or C++. Yet banks still use Cobol, and Fortran is popular with chemistist. To be honest, those aren't that readable... you have to train yourself to understand what is going on. In C, you can write some really bone-head statements. C++ restricts you somewhat, but if you wanted, you stil can write unreadable code. In a good programming group, the programmers would try to write easy to read code, no matter what the lang. C has alot of good points, but the most important for comp chem is the ability to increase the speed of the program manually. IMHO, it's hard to really optimize fortran code, and the compilers out there can't do it as well as someone can opt C code. If someone wanted to try to re-write HONDO in C, I believe it would run faster. Now the real question: Who wants to try that? This debate will not end until someone does just that. Period. When you can compare real applications that are as intensive as HONDO, then well have facts about the best programming lang, not just emotions. Of course, then we could always try APL for HONDO, perhaps that's faster? Nahhh... Virtually, Edward Wolpert --------------------------- wolpert@utk.edu | System Administrator wolpert@osti.slip.utk.edu | Systems Programmer pa153568@utkvm1.utk.edu | Graduate Chemistry Student --------------------------- I'm sorry, but Godot isn't here today. Perhaps if you came back tomorrow... From cuf@aol.com Thu Feb 10 23:21:25 1994 Received: from mailgate.prod.aol.net for cuf@aol.com by www.ccl.net (8.6.4/930601.1506) id XAA18901; Thu, 10 Feb 1994 23:10:36 -0500 From: Received: by mailgate.prod.aol.net (1.37.109.4/16.2) id AA24086; Thu, 10 Feb 94 23:15:28 -0500 X-Mailer: America Online Mailer Sender: "cuf" Message-Id: <9402102216.tn52942@aol.com> To: chemistry@ccl.net Date: Thu, 10 Feb 94 22:16:30 EST Subject: Computer & health The Computer User Family (CUF) is concerned about the health problem associated with computers. Video Display Terminals, emit UV and ELF radiation and may cause cancer, immune system irregularities, miscarriages and eye fatigue. Computer noise from fans, disk and CD drives is also becoming a source of anxiety, stress and general discomfort . We usually don't realize how loud our computers are: 50dB and more. These problems should be dealt with and add-ons should be provided for present computers to avoid putting us at risks. Some safe screens and quiet power supplies are coming out but they are marginal and prices are prohibitive. Meanwhile the general guidelines for the users are: 1. Position yourself approximately 22 inches to 28 inches (arm's length) from the screen and four feet from the sides and rear of other terminals. 2. Eliminate sources of glare and lower light levels in the room. Don't sit facing a bright window. If necessary, use screen hoods, glare shields over the screen or wear anti-UV/anti-glare glasses. 3. Put a noise absorbing mat under your computer. Pull your computer away from the wall or any hard surface that reflects noise and vibration back to you. 4. Rest occasionally during periods of intense concentration. Closing your eyes helps. 5. Turn off the VDT when not in use.