From UDIM018%FRORS31.BITNET@phem3.acs.ohio-state.edu Sat Jul 10 11:18:19 1993 Date: Sat, 10 Jul 1993 15:18:19 -0400 (EDT) From: UDIM018%FRORS31.BITNET@phem3.acs.ohio-state.edu Subject: BAC-MP4 To: chemistry@ccl.net Message-Id: <01H0DHMB2QJM9H3CJL@phem3.acs.ohio-state.edu> E. M. EVLETH Dynamique des Interactions Moleculaires Universite Pierre et Marie Curie 4 Place Jussieu, Tour 22, Paris 75005 33-1-44-27-42-08 (work), 33 = France; 1 = Paris 33-1-45-48-67-20 (home) FAX 33-1-44-27-41-17 (lab);44-27-38-66(University) e-mail UDIM018 at FRORS31.BITNET Since the person currently responsible for and main developer of the BAC-MP4 program (Carl Melius, Sandia, Livermore Lab) nearly never reads or responds to e-mail and is now at the Gas Kinetics Meeting in Washington, I'll give a rundown on BAC-MP4 (BAC-MP4/6-31G**). Our recent article (JPC 97 pp 5040-5045 (1993)) gives a series of references on the method. BAC = bond additivity correction. The BAC program takes 6-31G** level calculations and using equations parameterized from known thermodynamic data gives estimates of heats of formation, entropy, free energes, kinetic rate constants for reactions. This work was supported for years on various military related contracts and has generated a theoretical data base containing about 2800 structures (extracted from a larger data base containing many tens of thousands of structures). The general precision of the method is 1-2 kcal/mole on heats of formation, which is superior to any semiempirical method especially since there is an estimate on the precision of each value generated even if unknown experimentally. Limitations: not parameterized for ions, the MP4SDTQ estimate leads to a molecule size limit (e.g. 120 CGTOS or above, this will depend on the computer used). It is based on single configuration RHF or UHF MO bases and not parameterized for MCSCF required structures. The program is not yet distributed and (in my view) needs "institutionalization", (no messing around with the code and training in its use). Second the BAC-code uses part of the Gaussian codes such that there may be a legal problem in distributing it. It also runs on Gaussian archival input and it would be natural for Gaussian to distribute it. However, up until recently (like one month ago) the code was not very transportable and testing is still going on. Since the BAC heats of formation are reasonably accurate they can be used along side the JANAF tables. As a external observer I would urge the US Department of Commerce-NBS to institutionalize BAC data bases (there are several), arrange for their expansion and development and secure its future. The basic principal of the BAC method is that the MP4 heats of formation can be corrected by errors in each bond, and these are additive. Roughly, MP4/6-31G** heats of formation are in error by from a few to maybe 10 kcal/mole per bond, i.e. if the molecule has 5 bonds, the error will be in the order of 30-50 kcals. The error per bond depends on the bond type (e.g. C-C) and is expontential with distance (the error in the CC bond in acetylene is larger than ethylene which is larger than ethane). Anybody can program their variant of the BAC method from the literature articles, but to reproduce exactly the literature results would be time consuming (see C. F, Melius, "Thermochemical Modeling I, application to Ignition and Combustion of Energetic Materials", published in "Chemistry and Physics of Energetic Materials", pp 21-49 S. N. Kluwer Academic Publishers, NY 1992). Although you might wish to contact Carl, but as friendly and as generous as he is, he never responds to personal mail or e-mail (well almost never). His is a human tornado and never slows down enough to respond except in personal face-to-face contact. It is just that, traveling in excess of the speed of light, either photons or electrons can catch him. From berkley@wubs.wustl.edu Sat Jul 10 16:25:04 1993 Date: Sat, 10 Jul 93 21:25:04 -0500 From: berkley@wubs.wustl.edu (Berkley Shands) Message-Id: <9307110225.AA02511@wubs.wustl.edu> To: chemistry@ccl.net Subject: Supportable Hardware SGI is supported as the defacto standard for graphics. Why should commercial vendors support platforms that "won't be around" for N years? If the major players will not support box "Q", who will buy it? Hmm... what choice does that leave me ? Who is driving this market? After owning every box but an "HP", (sun, sgi, ibm, dec alpha) I can see why the software vendors have settled on SGI. The operating system is mature, The hardware doesn't break on a regular basis, It has a proven track record, The software interfaces are well defined. The product line is not likely to get dropped in the near future. Well, I write software, and I look at these things too. I also support The sun (not solaris 2.1 :-), The VAX, The Dec alpha, the SGI, and as best as I can, the IBM RS6000. The Dec alpha has the uniprocessor "barn burner" tag today. Surely an SMP implementation of OSF/1 will be available. The kubota graphics on the 3000/5xx I used at the American Crystalographic symposia (may '93) made the reality engine look like second rate material. All at a significantly lower price. If you are looking for a platform, do not forget the 5 year cost of ownership rule. Sure you can buy it cheap, but what does hardware and software cost you each year. (Are you leasing that software? does the vendor charge 30% per year of LIST price for hardware support?) Look at the bottom line and be sure you understand which platforms you can afford. MIPS and DEC have the two of the 64 bit machines available now. Who will be here in five years? Gaze into the crystal ball or construct the Oracle at Delphi for an answer :-) A final question to ask is "Does the platform in question allow and support 3rd party devices? (Disks, tapes, cd's...) The answers you'll get will interest you. Berkley Shands Washington University Department of computer science