From chemistry-request %-% at %-% www.ccl.net Mon Oct 19 21:36:39 1998 Received: from risky3.thchem.siu.edu (risky3.thchem.siu.edu [131.230.89.13]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id VAA28396 Mon, 19 Oct 1998 21:36:38 -0400 (EDT) Received: from localhost (tapas $#at#$ localhost) by risky3.thchem.siu.edu (AIX4.2/UCB 8.7/8.7) with SMTP id UAA33066 for ; Mon, 19 Oct 1998 20:40:33 -0500 (CDT) Date: Mon, 19 Oct 1998 20:40:33 -0500 (CDT) From: Tapas Kar To: "Comp. Chem. List" Subject: Summary: CPU-MEM-RWF relation from G94 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > To check the effect of %MEM on G94 jobs, i did 4 CCSD(T) freq > calculations using same input file but different %MEM=32, 64, 128 and > 150MB. No other application prog. was running during these four jobs. > > The result is: > %MEM CPU RWF(MB) MaxMem (from output) > 32mb 55m 35.2s 45 4194304 > 64mb 57m 11.8s 77 8388608 > 128mb 59m 37.5s 141 16777216 > 150mb 1h 0m 25.5s 163 19660800 > > It looks odd. Expert's comment please. > Tapas > PS: I am using RS/6000 Model 590 and AIX4.2 > Total 256mb memory and 13(2+2+9)gb hard disk. > **************************************************************************** AIX uses the spare RAM memory as the disk cache. Thus when you allocate memory to G94 with the %MEM directive you are also actually reducing the disk cache, slowing iour I/O. If your job is disk-intensive ( like CC ) it is reasonably possible to observe behaviors like the one you experience just my 0.02$ Ivan -- Dr. Ivan Rossi - Computational Chemistry Consultant e-mail: ivan#* at *#lipid.biocomp.unibo.it phone: (+39)-051-456177 ****************************************************************************** Though not an expert, I may have some relevant observations to share. You point out something odd about the Gaussian programs, namely the less-than-intuitive relationship between the amount of memory allocated and the ressources used. We have recently run a series of tests on a variety of machines to examine these relationships, but I'm afraid that in the end we were only confused, abeit on a higher level. We concentrated our efforts on time-consuming jobs, which in our line of work means MP2/4 and QCISD(T) calculations (G2 and CBS-Q methods). The results are somewhat dependent upon the size of the system and upon the hardware employed. For a relatively small open-shell system (a C3H7N radical cation) we found that the UMP2/6-311+G(3df,2p) step of a G2(MP2) calculation on a single node of an IBM SP2 cluster would use within reason the same amount of cpu time, regardless of whether the job was allowed to use (%Mem) 4MW, 16MW, or 64MW of memory. The reported maximum size of the read-write file in the three runs was 700MB, 365MB, and 633MB; in two runs using 10MW and 100MW we observed that the read-write file was almost three times bigger in the 100MW run than in the 10MW run (900MB vs 350MB). The QCISD(T)/6-311G(d,p) step ran 30% faster when 64MW were available (for the C3H7N+. system, the memory required for AO integral storage is 25MW); the time used for the triples was the same, regardless of the %Mem setting. (see below). Doing CBS-Q calculations on an SGI Origin200 for a C3H7O cation, we found that the execution times would vary only little with the amount of memory allocated (8MW, 16MW, 32MW, 48MW). The memory required for in-memory allocated (1.33GB, 1.39GB, 1.51GB, 1.64GB). QCISD(T)/6-31G(d) calculations (Origin200) for a somewhat bigger system (a C4H12N cation) indicated that the QCISD step would benefit from increased memory (test runs with 8MW, 16MW, 32MW, 48MW; in-memory storage of AO integrals requiring 25MW), but that, strangely enough, the triples calculations would actually slow down. To examine this further we did QCISD(T)/6-31G(d) calculations for C5H14N cations on an SGI Origin200, on a single node of an IBM SP2 cluster, and on a Fujitsu VX1. In all three instances we observed that the cpu-time for the triples calculations would INCREASE quite a bit with increased memory (data points: SGI 246 min (10MW), 321 min (60MW); IBM 97 min (16MW), 209 min (80MW); the memory required for AO integral storage was 51MW; similar results on the Fujitsu machine). These slow-downs were on all three machines to some extent off-set by a more rapid execution of the QCISD step with increased memory. Also here we observed that increased memory would be accompanied by an increase in the size of the read-write file. Since doing these calculations I have been told that also other people have observed that the cpu-time used by the Gaussian programs for highly correlated calculations can show an inverse dependence on the amount of memory allocated. I don't know if these things have changed in Gaussian98. Hope this helps. Steen -- Steen Hammerum steen*- at -*kiku.dk Department of Chemistry (+45) 35 32 02 08 University of Copenhagen, Denmark fax: (+45) 35 32 02 12 **************************************************************************** -------------------------------------------- Tapas Kar, Ph. D Asst. Scientist/Asst. Professor (Adjunct) Forestry Bldg 118 Department of Chemistry Southern Illinois University at Carbondale Illinois 62901-4409 Fax: (618) 453 6408 Tel: (618) 453 6433(Lab) 6485(Office) --------------------------------------------