From gbr@NPD.UFPE.BR Fri Jun 26 09:01:07 1998 Received: from NPD1.NPD.UFPE.BR (npd1.npd.ufpe.br [150.161.6.1]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id JAA29714 Fri, 26 Jun 1998 09:00:47 -0400 (EDT) Received: from npd.ufpe.br (Hartree.DQF.UFPE.BR) by NPD.UFPE.BR (PMDF V5.1-4 #20469) with ESMTP id <01IYOSDM7VHS00242W@NPD.UFPE.BR> for CHEMISTRY@www.ccl.net; Fri, 26 Jun 1998 09:59:12 GMT-3 Date: Fri, 26 Jun 1998 09:55:03 -0300 From: Gerd Bruno Rocha Subject: MOTECC package To: CHEMISTRY@www.ccl.net Message-id: <35939A27.E2FF4BA5@npd.ufpe.br> MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Dear Netters, I would appreciate very much if you could inform me about the contacts to order or download the MOTECC package. Thank you very much, -- *********************************************************************** Universidade Federal de Pernambuco Centro de Ciencias Exatas e da Natureza Departamento de Quimica Fundamental http://www.dqf.ufpe.br Recife - PE - Brazil Gerd Bruno Rocha E-Mail : gbr@npd.ufpe.br : gerd@simas.dqf.ufpe.br DSc Student in Computational Chemistry *********************************************************************** From krys.radacki@ac.rwth-aachen.de Fri Jun 26 10:06:09 1998 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id KAA00695 Fri, 26 Jun 1998 10:06:08 -0400 (EDT) Received: from ac.rwth-aachen.de (pae102.ac.RWTH-Aachen.DE) by mail.rwth-aachen.de (PMDF V5.1-10 #30440) with ESMTP id <01IYP57VOY4S00017B@mail.rwth-aachen.de> for CHEMISTRY@www.ccl.net; Fri, 26 Jun 1998 16:07:12 +0200 Date: Fri, 26 Jun 1998 14:06:03 +0000 From: Krzysztof Radacki Subject: Rasmol under Linux Sender: root@mail.rwth-aachen.de To: CCL Message-id: <3593AACA.2A5519AD@ac.rwth-aachen.de> Organization: Inst.Inorg.Chem., RWTH Aachen, Germany MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.99 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Dear CCL'ers and Linux users, I tried to compile Rasmol for my X-windows and failed :( My X is configured for 16 bit color. Less looks bad, more I can't have due to amount of memory on my graphic card. In both cases when I compiled RASMOL with definition eigth- or thirtytwobit I became error 'No suitable display detected'. I tried also sixteenbit, but then I became some 'parse' and 'syntax' error. Question: Is there any easy way to compile rasmol for 16 bit X-server, or cofigure it to work with 8-bit color on 16-bit X? I should add that my knowledge of C is minimal. Krzys Radacki _________________________---------------------------------------------------- ------------------------- e-mail: Krys.Radacki@ac.RWTH-Aachen.DE --- ----------------------------------------------------------------------------- From mn1@helix.nih.gov Fri Jun 26 15:08:37 1998 Received: from helix.nih.gov (helix.nih.gov [128.231.2.3]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id PAA03862 Fri, 26 Jun 1998 15:08:37 -0400 (EDT) Received: (from mn1@localhost) by helix.nih.gov (8.8.5/8.8.5) id PAA04598; Fri, 26 Jun 1998 15:08:33 -0400 (EDT) Date: Fri, 26 Jun 1998 15:08:33 -0400 (EDT) From: "M. Nicklaus" Message-Id: <199806261908.PAA04598@helix.nih.gov> To: CHEMISTRY@www.ccl.net Subject: Re: Linux -malign-double? Cc: mn1@helix.nih.gov Hi, On Tue, 23 Jun 98 15:44:32, Dave Close wrote: > Recently I posted a LINUX makefile for installing G94 on a Pentium > running RedHat Linux. Milan Hodoscek wrote me to say that I had > omitted the -malign-double compiler option. In fact I recalled his > posting of this several months ago. When we tried it here there was > hardly any difference in runtime. Milan has written me again to say > this option could make a large difference in run time on a Pentium. > My question is does anyone know about this option? Is it now a default > setting so now it is not important? Or have I done something wrong? > To see what we used go to: > > http://physweb,etsu.edu/c_r_g94_linux.html In the G94 benchmark paper I've mentioned before (Milan Hodoscek is a co-author; in press in JCICS), we've analyzed the influence of various compiler options quite extensively. One of the most important ones-- --on Pentium based systems (only)--is indeed "-malign-double". In many runs, both for the small Gaussian test jobs and for a larger 'real-life' DFT job, G94 executables compiled with "-malign-double" were always faster than G94 compiled with the standard f2c makefile. However, the degree to which "-malign-double" sped up G94 varied greatly >from machine to machine (but was totally reproducible on each machine, at least under the benchmarking conditions of an empty machine). The speed increase ranged from virtually unnoticeable to about 40% for the test jobs, and more than 60% for the DFT jobs in some cases. For other programs, such as CHARMM, we've seen differences of up to 100%. Both Pentium Pro (P6) and Pentium II (PII) systems are affected by this. We don't know exactly what causes this very different behavior of individual machines. We think it's a subtle interplay of the placement of binaries in RAM coupled with details of the memory hardware architecture, chip sets etc. of the system (...not very explanatory, I know.) It's interesting to note in this context that the 300, 333, 350, and 400 MHz PII's are actually surprisingly different on a deep hardware level as far as cache and memory characterisrics are concerned. A good place to read up on this is http://www2.tomshardware.com/cpuslot1.html. We believe that "-malign-double" doesn't actually gain you anything, but rather cures a defect that makes your PII system work slower than it should. With "-malign-double", the timings got much more consistent with CPU and bus speeds than without. So, in your case, Dave, I'd say you may be one of the lucky ones whose system is already close to optimal even without this option. Still, we've never found it to hurt, so we now routinely compile with "-malign-double" on Pentium systems. Another factor affecting G94 speed on Pentiums may be noteworthy here. This is our--seemingly counterintuitive--finding that, in *all cases* we've tested, G94 jobs ran faster the *less* memory we gave them (via %Mem=...). This was the case, again, for both P6 and PII, and for all 7 test jobs as well as the DFT job (so please don't send me angry e-mails saying "But this doesn't work for my CBS-Q [or whatever] job!"). The curves are steepest in the beginning, i.e. for the smallest RAM amounts. The increase in CPU time when going from 8MB to 128MB for the DFT job ranged from 20% to 40%, again depending on the machine. Of course, you need to give the job at least the amount of memory it needs to run to completion. So if you're running a large frequency calculation, you'll only be able to use the much flatter part of the curve. We think this has to do with the very high CPU speed vs. the much lower memory access speeds (and bandwidths) on Pentium systems. A very large amount of very fast cache might help, but the cache sizes and/or speeds on Pentiums don't really make a dent in this problem with Gaussian 94. (We compared 256kB and 512kB cache P6's, and found clear, but small effects of 0%...5% speedup.) In effect, it seems that on modern Pentium systems, "direct" is actually more efficient than "in-core". Of course, if you force your job to go through more passes, or even to store integrals on disk by not giving it enough RAM, you'll lose all speed advantages. We found 8MB (1MW) to be the minimum amount of RAM to run any G94 job on P6 or PII systems. So it may be a useful strategy to try first with this amount, and if the job bombs, to go up from there in, say, 1MW steps. For one single-point calculation, this is will not usually be worthwhile, but for an optimization, and, even more so, a lengthy potential energy scan, this can save a lot of CPU time. Hope this is useful, Marc ------------------------------------------------------------------------ Marc C. Nicklaus National Institutes of Health E-mail: mn1@helix.nih.gov Bldg 37, Rm 5B29 Phone: (301) 402-3111 37 Convent Dr, MSC 4255 Fax: (301) 496-5839 BETHESDA, MD 20892-4255 USA http://rex.nci.nih.gov/RESEARCH/basic/medchem/mcnbio.htm Laboratory of Medicinal Chemistry, National Cancer Institute, & Center for Molecular Modeling, Ctr. for Information Technology, NIH ------------------------------------------------------------------------ From elewars@alchemy.chem.utoronto.ca Fri Jun 26 15:42:38 1998 Received: from alchemy.chem.utoronto.ca (alchemy.chem.utoronto.ca [142.150.224.224]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id PAA04386 Fri, 26 Jun 1998 15:42:37 -0400 (EDT) Received: (from elewars@localhost) by alchemy.chem.utoronto.ca (8.7.4/8.7.3) id PAA29818 for chemistry@www.ccl.net; Fri, 26 Jun 1998 15:42:37 -0400 (EDT) Date: Fri, 26 Jun 1998 15:42:37 -0400 (EDT) From: "E. Lewars" Message-Id: <199806261942.PAA29818@alchemy.chem.utoronto.ca> To: chemistry@www.ccl.net Subject: HELP--PROBLEM WITH CBS CALC Friday 1998 June 26 Hello, In trying to do several CBS-4 calculations with G94W I have found that the job fails at job step number 4 with the message (tail end of output): : : : Complete Basis Set (CBS) Extrapolation: M. R. Nyden and G. A. Petersson, JCP 75, 1843 (1981) G. A. Petersson and M. A. Al-Laham, JCP 94, 6081 (1991) G. A. Petersson, T. Tensfeldt, and J. A. Montgomery, JCP 94, 6091 (1991) J. A. Montgomery, J. W. Ochterski, and G. A. Petersson, JCP 101, 5900 (1994) LocMO: Using population method Warning from LocMO, DDelta( 3, 1)= .20896892E-07 LocMO: Using population method Eaa2: Convergence Problem in SVD <---- Pair 1 7 1 Ierr 2 Error termination via Lnk1e in C:\G94W\l803.exe. Job cpu time: 0 days 2 hours 9 minutes 23.0 seconds. File lengths (MBytes): RWF= 1082 Int= 0 D2E= 0 Chk= 2 Scr= 1 ----- The message says there was a convergence problem in the singular value decomposition (SVD). This happens with, for example, aniline (C6H5-NH2). This is a perfectly normal molecule and one should be able to do a CBS-4 job on it (the CBS-4 on C6H5-NH3+ worked fine). Could someone please suggest a way to overcome this problem? Thanks E. Lewars ======================= From dino@eik.bme.hu Fri Jun 26 16:58:23 1998 Received: from goliat.eik.bme.hu (root@goliat.eik.bme.hu [152.66.250.2]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id QAA05265 Fri, 26 Jun 1998 16:58:22 -0400 (EDT) Received: from localhost (dino@localhost [127.0.0.1]) by goliat.eik.bme.hu (8.8.8/8.8.8) with SMTP id WAA22537 for ; Fri, 26 Jun 1998 22:58:22 +0200 (MET DST) Date: Fri, 26 Jun 1998 22:58:21 +0200 (MET DST) From: SZIEBERTH Denes To: chemistry@www.ccl.net Subject: NORM(A) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear CCL -ers Could someone tell me the exact meaning of NORM(A) in a G94 CCSD(t) output file? Denes Szieberth dino@goliat.eik.bme.hu From mchalla@ice.lanl.gov Fri Jun 26 18:38:42 1998 Received: from ice.lanl.gov (ice.lanl.gov [128.165.22.6]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id SAA06157 Fri, 26 Jun 1998 18:38:41 -0400 (EDT) Received: from localhost (mchalla@localhost) by ice.lanl.gov (8.8.7/8.8.7) with SMTP id QAA02721 for ; Fri, 26 Jun 1998 16:36:45 -0600 Date: Fri, 26 Jun 1998 16:36:45 -0600 (MDT) From: Matt Challacombe T-12 To: CHEMISTRY@www.ccl.net Subject: Double Zeta STO basis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Netters, I am looking for refs/databases with DZ quality STO bases. I am most interested in the STO-NG form (Gaussian families of SP functions) but will be quite happy to find lists of exponents for the STOs. Thanks in advance for your help. Matt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Matt Challacombe Los Alamos National Laboratory http://www.t12.lanl.gov/~mchalla/ Theoretical Division email: mchalla@t12.lanl.gov Group T-12, Mail Stop B268 phone: (505) 665-5905 Los Alamos, New Mexico 87545 fax: (505) 665-3909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From calef1@llnl.gov Fri Jun 26 18:45:35 1998 Received: from popout.llnl.gov (popout.llnl.gov [128.115.18.67]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id SAA06267 Fri, 26 Jun 1998 18:45:35 -0400 (EDT) Received: from calefnt (calefsnt.llnl.gov [128.115.232.92]) by popout.llnl.gov (8.8.5/LLNL-3.0.2) with SMTP id PAA01404; Fri, 26 Jun 1998 15:45:36 -0700 (PDT) Message-Id: <3.0.3.32.19980626155129.00946490@popout.llnl.gov> X-Sender: e130450@popout.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 26 Jun 1998 15:51:29 -0700 To: chemistry@www.ccl.net From: Dan Calef Subject: October Western Regional ACS Meeting in SF Cc: fried1@llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear Colleagues, The Northern California Section of the American Chemical Society and the Society for Applied Spectroscopy is hosting the 34th Western Regional ACS Meeting in San Francisco on October 29th through the 31st. We have been asked to organize a session, or perhaps two, on computational chemistry. Readers of the list who are interested in presenting a paper at the conference are urged to submit a title, soon, and an abstract shortly thereafter. This can include, for example, molecular dynamics of materials, MD of biomaterials, computational chemistry in support of combinatorial chemistry, and new methods. At the meeting two years ago, we had so many papers we split it into two sessions. Graduate students and post-docs are encouraged to submit papers. This is an excellent opportunity to present your work to a wider audience. Dan Calef calef1@llnl.gov 925-422-7797 Mail Stop L-092 Larry Fried fried1@llnl.gov 925-422-7796 Lawrence Livermore National Laboratory P.O. Box 808 Livermore CA 94550 From mn1@helix.nih.gov Fri Jun 26 19:55:28 1998 Received: from helix.nih.gov (helix.nih.gov [128.231.2.3]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id TAA07034 Fri, 26 Jun 1998 19:55:27 -0400 (EDT) Received: (from mn1@localhost) by helix.nih.gov (8.8.5/8.8.5) id TAA23653; Fri, 26 Jun 1998 19:55:25 -0400 (EDT) Date: Fri, 26 Jun 1998 19:55:25 -0400 (EDT) From: "M. Nicklaus" Message-Id: <199806262355.TAA23653@helix.nih.gov> To: CHEMISTRY@www.ccl.net Subject: Is SGI O2/150 much faster than PII/233? Cc: stephane.humbel@univ-reims.fr, mn1@helix.nih.gov Hi, HUMBEL Stephane wrote: > Hi > SGI makes both R5000 and R10000 O2, mine is an R10000 150 MHz > regards > Stephane > PS > >hinv > 1 150 MHZ IP32 Processor > FPU: MIPS R10010 Floating Point Chip Revision: 0.0 > CPU: MIPS R10000 Processor Chip Revision: 2.5 > Data cache size: 32 Kbytes > Instruction cache size: 32 Kbytes > Secondary unified instruction/data cache size: 1 Mbyte on Processor 0 and > By the way I definitly agree with you about the fact that these small > tests jobs are not very representative of the everyday (intensive) use of > g94 (for IO), but they give some information. And I'd like to know how > compare the real Origin 200 (180Mhz?) you have with the other machines, > that could be informative at least for me. I ran the seven test jobs on the (real!) SGI Origin 200 (hinv output: FPU: MIPS R10010 Floating Point Chip Revision: 0.0 CPU: MIPS R10000 Processor Chip Revision: 2.6 1 180 MHZ IP27 Processor Main memory size: 128 Mbytes Instruction cache size: 32 Kbytes Data cache size: 32 Kbytes Secondary unified instruction/data cache size: 1 Mbyte ), running under IRIX 6.4. The aggregate time was 833.5 sec. For the individual jobs 1, 28, 94, 155, 194, 296, 302, the job cpu times were: 4.2 11.2 36.7 149.7 52.1 528.1 51.5 sec. Marc ------------------------------------------------------------------------ Marc C. Nicklaus National Institutes of Health E-mail: mn1@helix.nih.gov Bldg 37, Rm 5B29 Phone: (301) 402-3111 37 Convent Dr, MSC 4255 Fax: (301) 496-5839 BETHESDA, MD 20892-4255 USA http://rex.nci.nih.gov/RESEARCH/basic/medchem/mcnbio.htm Laboratory of Medicinal Chemistry, National Cancer Institute, & Center for Molecular Modeling, Ctr. for Information Technology, NIH ------------------------------------------------------------------------