From chemistry-request@server.ccl.net Mon Apr 19 06:33:54 1999 Received: from www.ccl.net (www.ccl.net [192.148.249.5]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id GAA07913; Mon, 19 Apr 1999 06:33:54 -0400 Received: from ns.DKFZ-Heidelberg.DE (ns.dkfz-heidelberg.de [192.55.188.199]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id GAA04250 Mon, 19 Apr 1999 06:30:45 -0400 (EDT) Received: from dkfz1.inet.dkfz-heidelberg.de (dkfz1.inet.dkfz-heidelberg.de [193.174.51.93]) by ns.DKFZ-Heidelberg.DE (8.8.8/8.8.8/DKFZ-8.8.8) with ESMTP id MAA25926 for ; Mon, 19 Apr 1999 12:30:07 +0200 (MET DST) Received: from DKFZ1/SpoolDir by dkfz1.inet.dkfz-heidelberg.de (Mercury 1.31); 19 Apr 99 12:30:07 GMT+1 Received: from SpoolDir by DKFZ1 (Mercury 1.31); 19 Apr 99 12:29:48 GMT+1 Received: from DKFZ-Heidelberg.de by dkfz1.inet.dkfz-heidelberg.de (Mercury 1.31) with ESMTP; 19 Apr 99 12:29:44 GMT+1 Sender: tajkhors@ns.DKFZ-Heidelberg.DE Message-ID: <371B83B9.64EE387B@DKFZ-Heidelberg.de> Date: Mon, 19 Apr 1999 12:27:53 -0700 From: Emadeddin Tajkhorshid Organization: German Cancer Research Center X-Mailer: Mozilla 4.07C-SGI [en] (X11; I; IRIX 6.5 IP32) MIME-Version: 1.0 To: ccl CCL Subject: G94 & G98 DFT (Summary) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all Last week I sent a question regarding the (small) differences between the G94 and G98 programs with respect to the SCF energies and geometry optimization. Thanx to all who replied to my question. Here is the original question and a summary of the replies I got. ********************************************************************* Question: --------- I have experienced something using geometry optimization in G94 and G98 that I would like to check with you. I started from a G94-optimized set of coordinates for glycine. Using a DFT method (B3LYP/6-31G**), on the same platform (IBM/SP2) I started the same job in G94 and G98. These two jobs, while having the same optimization criteria (Default values) and the same starting geometries (and I suppose the same initial guess?) give different results. In one case the geometry is optimized and in the other case, the job does not meet the 'Maximum displacement' and 'RMS displacement' criteria after the first cycle. Examination of the energy also shows that we have different values after the first SCF. Although the differences in this case are not very large, I would like to know why they happen. If I am not mistaken there are some modifications with respect to the optimizer in G98, but I think in the case of this example, the difference is happening at the level of wavefunction. Did anybody else experience such differences at the wavefunction or geometry level? If so, how large are they? ---------------------------G94 job--------------------------------- First SCF: SCF Done: E(RB+HF-LYP) = -284.437033067 A.U. after 15 cycles Convg = .4529D-08 -V/T = 2.0089 S**2 = .0000 KE= 2.819396660737D+02 PE=-1.026794554909D+03 EE= 2.802029338205D+02 ::::: Item Value Threshold Converged? Maximum Force .000028 .000450 YES RMS Force .000009 .000300 YES Maximum Displacement .000293 .001800 YES RMS Displacement .000108 .001200 YES Predicted change in Energy=-1.479922D-08 ---------------------------G98 job --------------------------- First SCF: SCF Done: E(RB+HF-LYP) = -284.437035418 A.U. after 15 cycles Convg = .4595D-08 -V/T = 2.0089 S**2 = .0000 KE= 2.819396670445D+02 PE=-1.026794557138D+03 EE= 2.802029327275D+02 :::: Maximum Force .000028 .000450 YES RMS Force .000012 .000300 YES Maximum Displacement .004390 .001800 NO RMS Displacement .001377 .001200 NO Predicted change in Energy=-7.549560D-08 ****************************************************************** ... answers: ------------ Dear Emad, G94 and G98 DFT differ in at least two points. 1) The default weighing scheme for the numerical integration is now Stratmann/Scuseria. It was different in G94 (the Becke scheme ?). 2) The SCF cycles are now started with a superposition of states instead of the pure guess. This _might_ lead to differences, but does not seem to be the case in your calcs. Stefan ______________________________________________________________________ Dr. Stefan Fau Fachbereich Chemie, AK Frenking Philipps-Universität Marburg 35032 Marburg, Germany fau@chemie.uni-marburg.de ********************************************************************* Emad, There is a minor difference in energies, most likely due to the change in default numerical integration, G94 used Becke while G98 uses Strattman/Scuseria points and weights. The minor energy difference is consistent with this. Also the gradient summaries are identical which is consistent with having the wavefunction the same. The obvious difference is in the predicted displacment. G94 and G98 use different sets of redundant internals and start from an empirical valence hamiltonian. The variations here are likely what is causing the difference. I suspect that if you used Opt=CalcFC you would have much closer displacement predictions. -- Douglas J. Fox Director of Technical Support help@gaussian.com ********************************************************************* Hi, if I am not mistaken (which might well be the case) then G94 and G98 use different levels of integration grids for DFT calculations. This would perhaps explain the differences that you see. Please summarize! Best regards, Georg -- ============================================================== Dr. Georg Schreckenbach Tel: (USA)-505-667 7605 Theoretical Chemistry T-12 FAX: (USA)-505-665 3909 M.S. B268, Los Alamos National E-mail: schrecke@t12.lanl.gov Laboratory, Los Alamos, New Mexico, 87545, USA Internet: http://www.t12.lanl.gov/home/schrecke/ ***new location!*** ============================================================== ********************************************************************* Thanx again. -- Emad ********************************************************************* E. Tajkhorshid, Ph.D. German Cancer Research Center; DKFZ Tel: +49 6221 42 2340 Dept. Molecular Biophysics (H0200) FAX: +49 6221 42 2333 P.O.Box 101949 http://genome.dkfz-heidelberg.de/users/emad 69009 Heidelberg, Germany Email: E.Tajkhorshid@DKFZ-Heidelberg.de ********************************************************************* * "Science is talking to each other" * ********************************************************************* From chemistry-request@server.ccl.net Mon Apr 19 09:26:39 1999 Received: from dqo.fcq.unc.edu.ar (root@dqo.fcq.unc.edu.ar [200.16.18.55]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id JAA09894 for ; Mon, 19 Apr 1999 09:26:36 -0400 Received: from fer-net.fcq.unc.edu.ar (marcos@[200.16.18.99]) by dqo.fcq.unc.edu.ar (8.8.7/8.8.7) with SMTP id KAA19913 for ; Mon, 19 Apr 1999 10:25:50 -0300 From: Marcos Villarreal Organization: UNC, Dpto. Qca. Biol.-CIQUIBIC To: chemistry@ccl.net Date: Sun, 18 Apr 1999 22:19:39 -0400 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99041822205001.02259@fer-net.fcq.unc.edu.ar> Content-Transfer-Encoding: 8bit Hi all! I am looking for books dealing with the prediction of tridimensional structure of proteins from its sequence ( 1D -> 3D) Could please someone help me? Thanks in advance -- Lic. Marcos Villarreal Dpto Quimica Biologica Universidad Nacional de Cordoba Cordoba. Argentina From chemistry-request@server.ccl.net Mon Apr 19 17:10:43 1999 Received: from www.ccl.net (www.ccl.net [192.148.249.5]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id RAA15233; Mon, 19 Apr 1999 17:10:43 -0400 Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id RAA06578 Mon, 19 Apr 1999 17:07:31 -0400 (EDT) Received: from mail.rl.kodak.com (mail.rl.kodak.com [150.220.10.53]) by kodakr.kodak.com (8.9.1/8.9.1) with ESMTP id RAA02384 for ; Mon, 19 Apr 1999 17:07:01 -0400 (EDT) Received: from mozart.rl.kodak.com by mail.rl.kodak.com (8.8.3/1.1.10.5/17Jan97-0515PM) id RAA19991; Mon, 19 Apr 1999 17:30:29 -0400 (EDT) Received: from mozart.rl.kodak.com (berlioz [150.220.89.22]) by mozart.rl.kodak.com (980427.SGI.8.8.8/950213.SGI.AUTOCF) via ESMTP id RAA22041 for ; Mon, 19 Apr 1999 17:12:01 -0400 (EDT) Sender: giesen@kodak.com Message-ID: <371B9BE7.E796B3BB@mozart.rl.kodak.com> Date: Mon, 19 Apr 1999 17:11:03 -0400 From: David Giesen Organization: Eastman-Kodak X-Mailer: Mozilla 4.05C-SGI [en] (X11; U; IRIX64 6.5 IP25) MIME-Version: 1.0 To: CHEMISTRY@www.ccl.net Subject: Benchmarks and software Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I could not agree more with the idea that all software should be subject to a 'standard' benchmarking. A polite (since this list is moderated) pox on those vendors out there who make 'non-competition' a precondition to use of their software. I would like to add a second requirement of all commercial software if I may dream a little. All error messages produced from within the code (i.e. non-system errors) should be written in plain user language, not programmer debugging language. Soon the day will come when I refuse to spend $xx,xxx US$ to upgrade to a code which simply returns 'Error in subroutine xxx' or even more simply, 'y=a' (I would like to give more specific examples, but wouldn't you know, my license agreements prevent me from doing that). Another semi-polite pox on those guilty vendors. At risk of touching on a controversy which almost flared up several days ago, I'd like to point out that Jaguar does a nice job of printing useful error messages and has very responsive help staff. Dave I am not affiliated with Schrodinger, Inc. (Jaguar), nor are my comments reflective of the opinion of the Eastman Kodak Company. -- Dr. David J. Giesen Eastman Kodak Company giesen@kodak.com 2/83/RL MC 02216 (ph) 1-716-58(8-0480) Rochester, NY 14650 (fax)1-716-722-2327 From chemistry-request@server.ccl.net Tue Apr 20 17:07:04 1999 Received: from bioorganic.mechanisms.ucsb.edu. (gate-bioorganic.chem.ucsb.edu [128.111.114.116]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id RAA11673 for ; Tue, 20 Apr 1999 17:07:03 -0400 Received: (from rhonda@localhost) by bioorganic.mechanisms.ucsb.edu. (8.9.1a/8.9.1) id NAA18154 for chemistry@server.ccl.net; Tue, 20 Apr 1999 13:56:10 -0700 (PDT) Date: Tue, 20 Apr 1999 13:56:10 -0700 (PDT) From: Rhonda Torres Message-Id: <199904202056.NAA18154@bioorganic.mechanisms.ucsb.edu.> To: chemistry@server.ccl.net Subject: stability calculation references Hello, I am looking for references dealing with stability calculations in Gaussian. Specifically, references discussing criteria for neglecting differences in energies between stable and unstable results (less than ? kcal/mol). Can any one help? Thank you. Rhonda -------------------------------------------------------------------------- Rhonda A. Torres phone: (805) 893-7158 University of California fax: (805) 893-2229 Department of Chemistry email: rhonda@bioorganic.ucsb.edu Santa Barbara, CA 93106 -------------------------------------------------------------------------- From chemistry-request@server.ccl.net Tue Apr 20 20:28:23 1999 Received: from www.ccl.net (www.ccl.net [192.148.249.5]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id UAA13342; Tue, 20 Apr 1999 20:28:23 -0400 Received: from hermes.combichem.com (hermes.combichem.com [207.158.48.4]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id UAA16172 Tue, 20 Apr 1999 20:25:10 -0400 (EDT) Received: from combichem.com ([10.1.30.23]) by hermes.combichem.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-49457U200L100S0) with ESMTP id AAA310 for ; Tue, 20 Apr 1999 17:23:36 -0700 Message-ID: <371D19FC.96B93C68@combichem.com> Date: Tue, 20 Apr 1999 17:21:16 -0700 From: pgrootenhuis@combichem.com (Peter Grootenhuis) Reply-To: pgrootenhuis@combichem.com Organization: CombiChem X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: chemistry@www.ccl.net Subject: Summary Orally Available Compounds Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My question was: Can anybody point me to databases or lists or websites with data on oral bioavailability of compounds ? Also intestinal absorption, metabolic stability or toxicity data would be of interest. Summary of answers: (1) from Emilio Benfenati (e-mail: benfenati@irfmn.mnegri.it): A list of web sites, including some on toxicological data, is available at the site http://www.elet.polimi.it/AAAI-PT Most of them have been suggested by A. Richard, USEPA. In particular, there is the data base ECDIN, which includes data on a wide number of chemicals. (2) from Jens Sadowski (e-mail: sadowski@zhs4.zh.basf-ag.de): Lipinski at Pfizer proposed to use simply the subset of the World Drug Index (Derwent) that has got a USAN name assuming that these are the successful and thus implicitly bioavailable compounds..... (3) from Carlos Faerman (e-mail: cfaerman@scriptgen.com): I can suggest that you look at METABOLITE, a database that has different metabolic pathways and which also allows you to find possible metabolites for your lead molecule. METABOLITE is licensed by MDL. (4) from William Jorgensen (e-mail: bill@adrik.chem.yale.edu): The FDA gives dosage & administration info on all approved drugs: www.fda.gov Thanks everybody ! I am still interested in more info .... -- Dr. Peter D.J. Grootenhuis - Director Molecular Design CombiChem, Inc. - 9050 Camino Santa Fe - San Diego CA 92121 Tel: +1(619)530-0484 ext 168, Fax: +1(619)530-9998 pgrootenhuis@combichem.com - http://www.combichem.com From chemistry-request@server.ccl.net Wed Apr 21 09:36:37 1999 Received: from smb.chem.niu.edu (smb.chem.niu.edu [131.156.9.3]) by server.ccl.net (8.8.7/8.8.7) with SMTP id JAA21199 for ; Wed, 21 Apr 1999 09:36:37 -0400 Received: from smb by smb.chem.niu.edu via SMTP (940816.SGI.8.6.9/940406.SGI) for id IAA22882; Wed, 21 Apr 1999 08:30:27 -0500 Sender: smb@smb.chem.niu.edu Message-ID: <371DD2F2.41C6@smb.chem.niu.edu> Date: Wed, 21 Apr 1999 08:30:26 -0500 From: Steven Bachrach X-Mailer: Mozilla 3.01 (X11; I; IRIX 5.3 IP12) MIME-Version: 1.0 To: chemistry@ccl.net Subject: Re: CCL:Benchmarks and software References: <371B9BE7.E796B3BB@mozart.rl.kodak.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Giesen wrote: > > I could not agree more with the idea that all software should be subject > to a 'standard' benchmarking. A polite (since this list is moderated) > pox on those vendors out there who make 'non-competition' a precondition > to use of their software. > Dave makes a good point here but I think a strong word of caution is needed here. What would constitute a "standard" becnhmark for ab initio codes? When I installed G98 I did not run all of the test jobs provided since many of them cover types of calculations that I never run. What might be an important calculation for me might be of little interest to you. Furthermore, benchmarks of ab intio codes are very much dependent on the hardware and the compilers used. A particular code might have been tightly tuned for a specific machine and perform quite well, and then placed on a different machine the performance can degrade. This might even be found with different memory/disk configurations. Dave Feller has commented on many of these issues in the past - his becnhmark report is quite revealing and interesting in just how difficult it is to really 'benchmark' this type of program. Benchmarking MM codes is probably an even bigger poroblem - not only are you interested in speed, but the quality of the calculation is also in question. (Obviously all ab intio codes should provide the same energy for a HF/6-31G* calculation of methane, right?) I would imagine that vendors should be willing to provide the codes for local testing for a short period before making a purchase. If they don't, you should demand it or walk away - would you buy a car without a test drive? Steve -- Steven Bachrach Department of Chemistry and Biochemistry Northern Illinois University DeKalb, IL 60115 Phone: (815)753-6863 smb@smb.chem.niu.edu Fax: (815)753-4802 From chemistry-request@server.ccl.net Wed Apr 21 12:44:07 1999 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id MAA23491 for ; Wed, 21 Apr 1999 12:44:07 -0400 Received: from checfs2.UCSD.EDU (checfs2.ucsd.edu [132.239.73.6]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id JAA23461; Wed, 21 Apr 1999 09:40:47 -0700 (PDT) Received: by checfs2.UCSD.EDU (8.8.8+Sun/UCSDPSEUDO.4) id JAA06896 for ; Wed, 21 Apr 1999 09:40:43 -0700 (PDT) Date: Wed, 21 Apr 1999 09:40:43 -0700 (PDT) From: itsigeln@chem.ucsd.edu (Igor Tsigelny) Message-Id: <199904211640.JAA06896@checfs2.UCSD.EDU> To: arloa@dqo.fcq.unc.edu.ar, chemistry@ccl.net Subject: books In 1999 International University Line is publishing the book: Pharmacaphores Perception and Development for Drug Design. I am sure that they discuss that problem in this book. If you are interested I can let you know when the book will be lut of print. Regards Igor From chemistry-request@server.ccl.net Wed Apr 21 12:55:37 1999 Received: from www.ccl.net (www.ccl.net [192.148.249.5]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id MAA23734; Wed, 21 Apr 1999 12:55:34 -0400 Received: from schrodinger.com (root@thermidore.schrodinger.com [192.156.98.99]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id MAA26055 Wed, 21 Apr 1999 12:52:12 -0400 (EDT) Received: from sally.schrodinger.com (sally.schrodinger.com [206.231.140.227]) by schrodinger.com (8.8.5/8.8.5) with ESMTP id JAA07095 for ; Wed, 21 Apr 1999 09:54:19 -0700 Received: from localhost (shenkin@localhost) by sally.schrodinger.com (8.8.5/8.8.5) with ESMTP id MAA02210 for ; Wed, 21 Apr 1999 12:53:45 -0400 X-Authentication-Warning: sally.schrodinger.com: shenkin owned process doing -bs Date: Wed, 21 Apr 1999 12:53:45 -0400 (EDT) From: Peter Shenkin To: CHEMISTRY@www.ccl.net Subject: Re: CCL:Benchmarks and software In-Reply-To: <371B9BE7.E796B3BB@mozart.rl.kodak.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Warning: long, rambling and philosophical response follows. On Mon, 19 Apr 1999, David Giesen wrote: > I would like to add a second requirement of all commercial software if I > may dream a little. Where there's life, there's hope. :-) > All error messages produced from within the code > (i.e. non-system errors) should be written in plain user language, not > programmer debugging language. Soon the day will come when I refuse to > spend $xx,xxx US$ to upgrade to a code which simply returns 'Error in > subroutine xxx' or even more simply, 'y=a' (I would like to give more > specific examples, but wouldn't you know, my license agreements prevent > me from doing that). Another semi-polite pox on those guilty vendors. Hi, Dave, Though what you suggest is useful to strive for, I have found that even when one makes great efforts to do this, users often don't understand or believe the messages anyway. Ideally, one would like to tell the user "you did this wrong" (when s/he did :-) ), but a given exception deep in the code can often be caused by a variety of problems with the program input. After many years of trying to deal with this as a code developer, I've concluded that the most I can really hope for most of the time is to write error messages that are going to make enough sense to me that if a user reports them, it will be obvious enough to me what the problem is to allow me to respond quickly. Even this is terribly difficult. The messages you quote would not pass even this test, however. On the other hand, I have found that some users, when they see an error message, simply won't believe what they read. In MacroModel/BatchMin, if a forcefield does not have parameters for a particular system, we print out a line that says that parameters are missing for the following (stretches, bends, or whatever). The atoms in question are fully identified. One would think this is pretty clear. However, I get at least 20 queries a year from people asking me what this means. I always respond by saying "It means that the force field does not have parameters for certain stretches, bends, etc. in your molecule." Somehow, they understand this perfectly when I say it in email, even though the error message said exactly the same thing. Go figure. :-) Of course, there may be 200 users who *do* understand, and who don't have to call me, to the 20 who don't understand. At least I hope so. :-) Waxing philosophical for a moment, there are several mental models involved. One is the model of how any molecular mechanics program works: there are force-fields, interactions, energy terms; then there are minimization, conformational search, dynamics, etc. Not all users of these programs have this model in their heads. They may not have a good idea of what an interaction is, or even what a force-field is. Thus, my explanation may not even be in the language that the (naive) user understands. S/he just knows that "something failed." Another mental model involves the way a particular program does things -- how it chooses to carry out, say, conformational search. Even fewer users of a program will have this model in their heads. In fact, only the most experienced users will have it, and even then they will only have a partial picture. More and more, the same is true even of developers, especially for legacy codes, but I digress. For example, if a conformational search aborts with a message like, "You are trying to alter 10 degrees of freedom but only 9 were specified", that is very, very descriptive, but only if you have the right model in your head. In our program, it means that you requested that up to at 10 torsions or intermolecular translations/rotations be varied in a single step, but you only specified 9 variable torsions or intermolecular motions that can be varied at all. Only a sophisticated user of our particular program would be able to understand this. But at least I can understand it immediately and respond to the user giving a variety of possible causes. -P. -- ********* Peter S. Shenkin; Schrodinger, Inc.; (201)433-2014 x111 ********* *********** shenkin@schrodinger.com; http://www.schrodinger.com *********** From chemistry-request@server.ccl.net Wed Apr 21 15:02:11 1999 Received: from sp2.spcorp.com (sp2.spcorp.com [198.16.9.6]) by server.ccl.net (8.8.7/8.8.7) with SMTP id PAA24844 for ; Wed, 21 Apr 1999 15:02:11 -0400 Received: by sp2.spcorp.com id OAA13872 (InterLock SMTP Gateway 3.0 for chemistry@ccl.net); Wed, 21 Apr 1999 14:58:46 -0400 Message-Id: <199904211858.OAA13872@sp2.spcorp.com> Received: by sp2.spcorp.com (Internal Mail Agent-1); Wed, 21 Apr 1999 14:58:46 -0400 From: "MARTEN, BRYAN" To: "\"chemistry@ccl.net\" " Subject: RE: CCL:Benchmarks and software Date: Wed, 21 Apr 1999 14:54:00 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Steven Bachrach wrote: >(Obviously all ab intio codes should provide the same energy >for a HF/6-31G* calculation of methane, right?) I'm all for lots of relevant benchmarks but you might be surprised to know that the answer to your question is "it depends". It depends on how many sig figs you want in your HF/6-31G* calculation of methane. Few if any QM codes perform all 2e- integrals, for example. They avoid computing batches of them based on estimates of how large they are likely to be (small ones get skipped and the value of that cutoff is either hard-wired or user-defined with some default). Also, one program may default to iteratively converging an energy to 1.0E-5h while another defaults to 1.0E-10h (numbers made up for argument's sake). These are but two of several possible parameters which can be adjusted for a balance of speed and accuracy. For some computer experiments you need a tightly-converged ground-state wavefunction before moving on to a higher level calculation. For other experiments, you clearly don't. For people who want to compare to many decimal places, there will always be the additional issue of floating point round-off which will cause results to differ slightly from machine to machine and compiler to compiler for the same software program. So even this benchmark, which appears to be well defined, will need to be discussed to define the issues and produce benchmarks which are relevant to people's needs. Bryan Marten, PhD Schering-Plough Research Institute bryan.marten@spcorp.com From chemistry-request@server.ccl.net Wed Apr 21 17:12:52 1999 Received: from out5.ibm.net (out5.ibm.net [165.87.194.243]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id RAA26046 for ; Wed, 21 Apr 1999 17:12:52 -0400 From: jmmckel@ibm.net Received: from puccini (slip-32-100-232-228.ny.us.ibm.net [32.100.232.228]) by out5.ibm.net (8.8.5/8.6.9) with SMTP id VAA61482; Wed, 21 Apr 1999 21:09:26 GMT Message-ID: <371DF872.3422@ibm.net> Date: Wed, 21 Apr 1999 17:10:26 +0100 Reply-To: jmmckel@ibm.net X-Mailer: Mozilla 3.04 (WinNT; I) MIME-Version: 1.0 To: "MARTEN, BRYAN" CC: "\"chemistry@ccl.net\"" Subject: Re: CCL:Benchmarks and software References: <199904211858.OAA13872@sp2.spcorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MARTEN, BRYAN wrote: > > Steven Bachrach wrote: > > >(Obviously all ab intio codes should provide the same energy > >for a HF/6-31G* calculation of methane, right?) > > I'm all for lots of relevant benchmarks but you might be surprised to know > that > the answer to your question is "it depends". It depends on how many sig > figs > you want in your HF/6-31G* calculation of methane. > > Few if any QM codes perform all 2e- integrals, for example. They avoid > computing batches of them based on estimates of how large they are likely to > be > (small ones get skipped and the value of that cutoff is either hard-wired or > user-defined with some default). Also, one program may default to > iteratively > converging an energy to 1.0E-5h while another defaults to 1.0E-10h (numbers > made > up for argument's sake). These are but two of several possible parameters > which > can be adjusted for a balance of speed and accuracy. > > For some computer experiments you need a tightly-converged ground-state > wavefunction before moving on to a higher level calculation. For other > experiments, you clearly don't. > > For people who want to compare to many decimal places, there will always be > the > additional issue of floating point round-off which will cause results to > differ > slightly from machine to machine and compiler to compiler for the same > software > program. > > So even this benchmark, which appears to be well defined, will need to be > discussed to define the issues and produce benchmarks which are relevant to > people's needs. > > Bryan Marten, PhD > Schering-Plough Research Institute > bryan.marten@spcorp.com > -= This is automatically added to each message by mailing script =- > CHEMISTRY@ccl.net -- To Everybody | CHEMISTRY-REQUEST@ccl.net -- To Admins > MAILSERV@ccl.net -- HELP CHEMISTRY or HELP SEARCH > CHEMISTRY-SEARCH@ccl.net -- archive search | Gopher: gopher.ccl.net 70 > Ftp: ftp.ccl.net | WWW: http://www.ccl.net/chemistry/ | Jan: jkl@ccl.net So, from a practical, [industrial], point of view the question really becomes a mixture of machine speed, algorithms, what one wants to calculate, how many sig figures, how responsive the hardware and software vendors are to problems and questions, and how clever the user is... One is looking for an answer to a chemical problem... John McKelvey From chemistry-request@server.ccl.net Wed Apr 21 22:52:32 1999 Received: from mailbox.syr.edu (root@mailbox.syr.edu [128.230.18.5]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id WAA28857 for ; Wed, 21 Apr 1999 22:52:32 -0400 Received: from syr.edu (curie.syr.edu [128.230.187.116]) by mailbox.syr.edu (8.9.2/8.9.2) with ESMTP id WAA11528 for ; Wed, 21 Apr 1999 22:49:07 -0400 (EDT) Sender: desingh@mailbox.syr.edu Message-ID: <371E8F56.D128CEB8@syr.edu> Date: Wed, 21 Apr 1999 22:54:15 -0400 From: Deepak Singh Organization: Dept. of Chem & Biochem, Syracuse University X-Mailer: Mozilla 4.07C-SGI [en] (X11; I; IRIX64 6.5 IP30) MIME-Version: 1.0 To: Computational Chemistry List Subject: multi-processors and memory Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi folks This might be a little out of context but if someone could just point me in the right direction it would be great. I have a SGI OCTANE with 2 processors (and 1.5 GB of memory). I am not running any parallel applications and do not think runnign parallel versions would give me an advantage with just 2 processors, but is there any way I can assign a processor to e.g. a gamess run (which is where I need that capability the most)? Right now I have two charmm runs underway and one gamess run. While the overall operation of my computer is nto significantly affected, I do not like the CPU utilization which is currently ~75% each for the charmm runs and 21% for the GAMESS run (at least that is what gr_top reports). Any idea how I can make GAMESS utilize more of the CPU? Is this a problem in my GAMESS input file ( I am new to ab-inito stuff) or is there something I can do to teh computer? If someone can refer me to a good resource it would be great. Thanks Deepak. -- ********************************************************************** Deepak Singh Tel : (315)443 1739 (w) Graduate Student (315)472 9659 (h) Dept. of Chemistry & Biochemistry Fax : (315)443 4070 Syracuse University email : desingh@syr.edu 1-014 CST, Syracuse URL : http://web.syr.edu/~desingh NY 13244 "Violence is the last refuge of the incompetent." --- Salvor Hardin **********************************************************************