From chemistry-request@server.ccl.net Sat Dec 4 09:38:26 1999 Received: from web125.yahoomail.com (web125.yahoomail.com [205.180.60.193]) by server.ccl.net (8.8.7/8.8.7) with SMTP id JAA06281 for ; Sat, 4 Dec 1999 09:38:25 -0500 Received: (qmail 27504 invoked by uid 60001); 4 Dec 1999 13:30:32 -0000 Message-ID: <19991204133032.27503.qmail@web125.yahoomail.com> Received: from [206.148.0.189] by web125.yahoomail.com; Sat, 04 Dec 1999 05:30:32 PST Date: Sat, 4 Dec 1999 05:30:32 -0800 (PST) From: "Eric S. Ball" Subject: RO jobs on unsaturated organometallics To: chemistry@ccl.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Greetings, I'm having great difficulty getting convergence for my restricted open-shell DFT jobs on coordinatively unsaturated iron compounds. I'm using Jaguar for these (rob3lyp/lacvp**), and I've used G94/98 in the past, so suggestions pertaining to either package would help. In Jaguar I've used vshifts of 0.2 - 1.0; accuracy settings (iacc) of quick, medium, and ultrafine; As per hints in the manual I tried iacc=1 (ultrafine grids) with the lac3vp** basis (largest available) and etot simply oscillated. If anyone has successfully dealt with a similar situation with either Jaguar or G98, I'd love to start a little dialog. If/when I meet with success I'll edit down any conversations to the pertinent points and repost them. Thanks in advance, Eric Ball __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com From chemistry-request@server.ccl.net Mon Dec 6 04:05:35 1999 Received: from mail.anrb.ru ([62.76.11.150]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id EAA15525 for ; Mon, 6 Dec 1999 04:04:44 -0500 Received: from mail.anrb.ru (P150 [62.76.11.196]) by mail.anrb.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id YLJVY2ZX; Mon, 6 Dec 1999 13:51:46 +0500 Date: Mon, 6 Dec 1999 12:58:32 +0500 From: "Ilfir R. Ramazanov" X-Mailer: The Bat! (v1.036) S/N 0 Reply-To: "Ilfir R. Ramazanov" Organization: Institute of Petrochemistry and Catalysis,Ufa,Russia Priority: Normal Message-ID: <16540.991206@anrb.ru> To: chemistry@ccl.net Subject: Athlon or 2xPIII500E? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear CCLers! I'd like to know your opinion. What is better for GAMESS/G98W calculations - Athlon 600 or a two-processor system with PIII 500E. Are there any benchmarks? Best regards, Ilfir R. Ramazanov, Ph.D., Laboratory of Catalytic Synthesis Institute of Petrochemistry and Catalysis, pr. Oktyabrya, 141, Ufa, 450075, Russia. mailto:elf@anrb.ru Visit my homepage and find some QC software http://members.tripod.com/~ChemELF Visit our lab web page http://organomet.cjb.net 06.12.1999 12:51 From chemistry-request@server.ccl.net Mon Dec 6 04:18:14 1999 Received: from hydra.chem.rug.nl (hydra.chem.rug.nl [129.125.35.229]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id EAA15635 for ; Mon, 6 Dec 1999 04:18:14 -0500 Received: from [129.125.7.13] (theochem1.chem.rug.nl [129.125.7.13]) by hydra.chem.rug.nl (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA30598 for ; Mon, 6 Dec 1999 09:10:32 +0100 (MET) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: swart@hydra.chem.rug.nl Message-Id: In-Reply-To: Date: Mon, 6 Dec 1999 09:12:03 +0100 To: CHEMISTRY@ccl.net From: Marcel Swart Subject: Re: CCL:Comparative Linux quantum chemistry benchmark Dear Peter, a benchmark usually means checking DIFFERENT programs on ONE machine, or ONE program on DIFFERENT machines. This makes the benchmark meaningful. However, you are testing several programs on several machines, so you are actually performing several benchmarks. I summarize below the 3 benchmarks, from which you could say something. BTW, are the default grids the same for all programs ? Do they all use numerical integration, and if so, are the energies all the same, up to the same accuracy ? Is the numerical integration valid up to the same accuracy, etc. etc. ? Else, these times do not say anything more, than that you have had a nice time, the afternoon you were playing with these programs. Best wishes, Marcel. >On PIII-550 >------------------------------------------------------------------------- >reference-98 (6-31G*) > 1 CPU, 381 basis function 235 min/15 cycle = 940 sec/cycle >------------------------------------------------------------------------- >Jaguar v 3.5 rel 50: > 381 SCF basis functions: 64 min/11 SCF cycl. = 349 sec/cycle >------------------------------------------------------------------------- >DMOL 3.5 >1 CPU 358 SCF basis functions 49 min/18 SCF cycl. = 163 sec/cycle >------------------------------------------------------------------------- >Turbomole, RIDFT method, > 389 SCF basis functions 20 min/12 SCF cycles = 100 sec/cycle >------------------------- >Turbomole, DFT method >1 CPU, 1 PIII-550 (last cycle with large grid) (rel 5.1) > 102 min, 10 SCF cycles = 610 sec/cycle >------------------------------------------------------------------------- >On PII-450 >------------------------------------------------------------------------- >QCHEM ver 1.2: >standard grid, basis (381) 169 min/12 SCF = 844 sec/cycle >------------------------------------------------------------------------- >ON PII-400 >------------------------------------------------------------------------- >ADF-99 > 1 CPU: 389 SCF basis functions: > (127 min for 17 SCF cycles) = (448 sec/cycle) >------------------------------------------------------------------------- ========================================= drs. Marcel Swart Theoretical Chemistry (MSC) Molecular Dynamics (GBB) Rijksuniversiteit Groningen Chemistry Department Nijenborgh 4 9747 AG Groningen The Netherlands tel : +31 - (0)50 - 3634377 fax : +31 - (0)50 - 3634441 E-mail : m.swart@chem.rug.nl WWW: http://hydra.chem.rug.nl/~swart/ ========================================= From chemistry-request@server.ccl.net Mon Dec 6 04:11:12 1999 Received: from sun0.mpimf-heidelberg.mpg.de (sun0.mpimf-heidelberg.mpg.de [149.217.50.120]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id EAA15583 for ; Mon, 6 Dec 1999 04:11:11 -0500 Received: from [149.217.50.84] (mac40.mpimf-heidelberg.mpg.de [149.217.50.84]) by sun0.mpimf-heidelberg.mpg.de (8.9.1b+Sun/8.9.1) with ESMTP id IAA20253; Mon, 6 Dec 1999 08:58:40 +0100 (MET) X-Sender: vkitzing@sun0.MPImF-Heidelberg.mpg.de Message-Id: In-Reply-To: <3847E7FC.6EC00D10@iaf.uquebec.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 6 Dec 1999 09:09:38 +0100 To: "Jianhui Wu" , chemistry@ccl.net From: Eberhard von Kitzing Subject: Re: CCL:InsightII, PBC, counter ions Dear CCLler, At 16:55 Uhr +0100 03.12.1999, Jianhui Wu wrote: >I am trying to model ligand-protein interaction using discovery within >InsightII (version 97). I would like to solvate the system by PBC water >box. >The protein has –12 charge (ligand is neutral). Is it essential to add >the counter >ions in the system to neutralize the net charge before a PBC discovery >calculation (MM or MD) is performed? (Probably, yes) The Maxwell relaxation time (see introductions into semi conductor physics) is the time needed by the system to equilibrate. It is in the order of lDH^2/D where lDH is the Debye length and D the diffusion constant of the ions. Thus, to add salt in addition to the excess charge would improve the equilibration of your simulation. Test calculations done by others showed that such additional salt generally stabilizes the simulation. ========================================================== Eberhard von Kitzing Abteilung Zellphysiologie Max-Planck-Institut fuer Medizinische Forschung Jahnstr. 29 D 69120 Heidelberg Tel: +49 6221 486 467 Germany FAX: +49 6221 486 459 email: vkitzing@mpimf-heidelberg.mpg.de WWW: http://sunny.mpimf-heidelberg.mpg.de/people/vkitzing/ From chemistry-request@server.ccl.net Mon Dec 6 06:33:39 1999 Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id GAA16218 for ; Mon, 6 Dec 1999 06:33:38 -0500 Received: from moka.ccr.jussieu.fr (moka.ccr.jussieu.fr [134.157.1.23]) by shiva.jussieu.fr (8.9.3/jtpda-5.3.2) with ESMTP id LAA30393 for ; Mon, 6 Dec 1999 11:25:15 +0100 (CET) Received: from (geb@localhost) by moka.ccr.jussieu.fr (8.9.1a/jtpda-5.3.2) id LAA97680 ; Mon, 6 Dec 1999 11:25:15 +0100 From: geb@ccr.jussieu.fr (Gerard BOUREAU) Message-Id: <199912061025.LAA97680@moka.ccr.jussieu.fr> Subject: dual celeron To: chemistry@ccl.net Date: Mon, 6 Dec 1999 11:25:15 +0100 (NFT) Cc: geb@ccr.jussieu.fr (Gerard BOUREAU) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit dear ccl readers I summarize the informations concerning the dual celeron. The original question was: does anybody uses bp6 dual socket 370 motherboard with two 500 MHz celerons. price looks attractive. It should work under linux. informations: 1-David Groeten uses a 2x400 Celeron + 128 Mb +8Gb+Network+video card + redhat 6.0 It works fine for about 900 dollars 2-S.Janicki plans to use it. 3-Other people in France told me they have such a system. No problem. 4-At the present time, the new 500MHz celerons are not supported We have to use the 466 MHz only. (see the list http://www.bp6.comm/ (communicated by S.Janicki) as things are changing everyday) 5-There is a new how to on smp with a section devoted to celeron. see also the dual celeron myth at http://www.hardwarecentral.com/hardwarecentral/reports/7/2/3/ As a conclusion, it looks attractive. -- gerard boureau Laboratoire de chimie physique (UPMC-Paris 6) 11, rue Pierre et Marie Curie 75231 Paris cedex 5 e-mail geb@ccr.jussieu.fr tel 01 44 27 62 55 ou 01 44 27 66 27 fax 01 44 27 62 26 From chemistry-request@server.ccl.net Mon Dec 6 08:04:41 1999 Received: from rzusuntk.unizh.ch (rzumail2.unizh.ch [130.60.128.10]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id IAA17330 for ; Mon, 6 Dec 1999 08:04:38 -0500 Received: [from rzusgi.unizh.ch (chburger@rzusgif.unizh.ch [130.60.68.19]) by rzusuntk.unizh.ch (8.8.5/SMI-5.31) with ESMTP id MAA08236 for ; Mon, 6 Dec 1999 12:56:17 +0100 (MET)] From: "Dr. Peter Burger" Received: [(chburger@localhost) by rzusgi.unizh.ch (8.8.8/SMI-IRIX6.2/USAR_MAIL_V2) id MAA13781 for CHEMISTRY@ccl.net; Mon, 6 Dec 1999 12:56:16 +0100 (MET)] Message-Id: <199912061156.MAA13781@rzusgi.unizh.ch> Subject: Re: CCL:Comparative Linux quantum chemistry benchmark To: CHEMISTRY@ccl.net Date: Mon, 6 Dec 1999 12:56:16 +0100 (MET) X-Mailer: ELM [version 2.4 PL25 PGP2] Content-Type: text Dear Marcel, thanks for your E-mail and comments. > a benchmark usually means checking DIFFERENT programs on ONE machine, or > ONE program on DIFFERENT machines. This makes the benchmark meaningful. I agree, however, due to license restrictions, life is not always that simple in that I could not perform all the benchmarks on an identical machine. However, where it was possible, the benchmarks data displayed an excellent correlation with the clock frequency (slope of .99) in that that seems not to be too much of a concern if at all. > BTW, are the default grids the same for all programs ? Do they all use > numerical integration, and if so, are the energies all the same, up to the > same accuracy ? Is the numerical integration valid up to the same accuracy, > etc. etc. ? Energies are hard to compare since different basis sets _have_ to be used STO's for ADF, GTOs for most of them and numerical for Dmol.. The default grids were not always identical, some of them use modified grids, which cannot always be controlled by the user.. Essentially, it's better to see this comparison more as an applied benchmark for applied chemists using the default settings. Even more matters actually the number of cycles that are required with the same convergence criteria. This may vary from 10-28 cycles!!! and that the programs achieve convergence at all! which is definitely _not_ the case for transition metal complexes I am interested in. > > Else, these times do not say anything more, than that you have had a nice > > time, the afternoon you were playing with these programs. For me, it's actually more than _playing_ since time for completion matters to me. However, obviously there are more points to that including the quality of optimizers, SCF-convergence, flexibility of the programs, for instance to do an unrestricted/Cosmo/ECP run on open shell transition metal systems is not all that simple for a number of programs which I had to learn the hard way. So, the message is get the job done! For instance the ridft method in Turbomole is so fast in parallel runs (and still accurate) that you can treat even large systems fully quantum mechanically and have not resort to hybrid methods. Peter ------------------------------------------------------------- Peter Burger Anorg.-chem. Institut Universitaet Zuerich chburger@aci.unizh.ch From chemistry-request@server.ccl.net Mon Dec 6 11:39:11 1999 Received: from darkwing.uoregon.edu (darkwing.uoregon.edu [128.223.142.13]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id LAA18052 for ; Mon, 6 Dec 1999 11:39:10 -0500 Received: from localhost (genghis@localhost) by darkwing.uoregon.edu (8.9.3/8.9.3) with SMTP id HAA23397 for ; Mon, 6 Dec 1999 07:28:47 -0800 (PST) Date: Mon, 6 Dec 1999 07:28:47 -0800 (PST) From: "Dale A. Braden" To: cclpost Subject: Re: CCL:RO jobs on unsaturated organometallics In-Reply-To: <19991204133032.27503.qmail@web125.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Eric, The best thing to do is email Schrodinger at least one of your input files. In my case, they ran the job themselves until they figured out how to make it converge, and then emailed me the solution. They're interested in cases where their code fails. Otherwise, I'd suggest trying a *smaller* basis rather than the largest one, say lacvp. Sometimes a large basis provides too many degrees of freedom for a wfn that is a poor initial guess, but moving to a smaller basis helps the converger find a solution. Another choice is to use the OCBSE SCF-converence method. This worked for one of my problem cases. Good luck, Dale Dale Braden Department of Chemistry University of Oregon Eugene, OR 97403-1253 genghis@darkwing.uoregon.edu On Sat, 4 Dec 1999, Eric S. Ball wrote: > Greetings, > > I'm having great difficulty getting convergence for my > restricted open-shell DFT jobs on coordinatively unsaturated > iron compounds. I'm using Jaguar for these (rob3lyp/lacvp**), > and I've used G94/98 in the past, so suggestions pertaining to > either package would help. In Jaguar I've used vshifts of 0.2 - > 1.0; accuracy settings (iacc) of quick, medium, and ultrafine; > As per hints in the manual I tried iacc=1 (ultrafine grids) with > the lac3vp** basis (largest available) and etot simply > oscillated. > > If anyone has successfully dealt with a similar situation with > either Jaguar or G98, I'd love to start a little dialog. > If/when I meet with success I'll edit down any conversations to > the pertinent points and repost them. > > Thanks in advance, > Eric Ball > > > > > > __________________________________________________ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one place. > Yahoo! Shopping: http://shopping.yahoo.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 > > > > > From chemistry-request@server.ccl.net Mon Dec 6 13:08:29 1999 Received: from schrodinger.com (root@thermidore.schrodinger.com [192.156.98.99]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id NAA18828 for ; Mon, 6 Dec 1999 13:08:28 -0500 Received: from sandra.schrodinger.com (sandra.schrodinger.com [166.84.149.23]) by schrodinger.com (8.8.5/8.8.5) with ESMTP id JAA15480 for ; Mon, 6 Dec 1999 09:00:05 -0800 Received: from localhost (shenkin@localhost) by sandra.schrodinger.com (8.8.7/8.8.5) with ESMTP id MAA31954 for ; Mon, 6 Dec 1999 12:01:47 -0500 X-Authentication-Warning: sandra.schrodinger.com: shenkin owned process doing -bs Date: Mon, 6 Dec 1999 12:01:47 -0500 (EST) From: Peter Shenkin To: chemistry@ccl.net Subject: Re: CCL:Comparative Linux quantum chemistry benchmark In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Talking to the in-house experts, it does appear that there are some discrepancies between grids used in the different programs, and that these differences work to the detriment of the relative Jaguar performance cited. However, Peter's posting also led us to perform a few LINUX tuning experiments. These reveal that we can greatly improve our LINUX performance. This has not benefited in the past from the careful attention that we have given to performance on commercial UNIX platforms with the help of our vendor partners. LINUX is becoming a much more important platform to us; indeed, we will be supporting MacroModel as well as Jaguar under LINUX. Therefore, we will most certainly be addressing and improving Jaguar LINUX performance over the coming months. -P. -- ** Whether the playing field is level depends on the coordinate system. *** ********* Peter S. Shenkin; Schrodinger, Inc.; (201)433-2014 x111 ********* *********** shenkin@schrodinger.com; http://www.schrodinger.com *********** On Mon, 6 Dec 1999, Marcel Swart wrote: > Dear Peter, > > a benchmark usually means checking DIFFERENT programs on ONE machine, or > ONE program on DIFFERENT machines. This makes the benchmark meaningful. > > However, you are testing several programs on several machines, so you are > actually performing several benchmarks. I summarize below the 3 benchmarks, > >from which you could say something. > > BTW, are the default grids the same for all programs ? Do they all use > numerical integration, and if so, are the energies all the same, up to the > same accuracy ? Is the numerical integration valid up to the same accuracy, > etc. etc. ? > > Else, these times do not say anything more, than that you have had a nice > time, the afternoon you were playing with these programs. > > Best wishes, > > Marcel. > > > >On PIII-550 > >------------------------------------------------------------------------- > >reference-98 (6-31G*) > > 1 CPU, 381 basis function 235 min/15 cycle = 940 sec/cycle > >------------------------------------------------------------------------- > >Jaguar v 3.5 rel 50: > > 381 SCF basis functions: 64 min/11 SCF cycl. = 349 sec/cycle > >------------------------------------------------------------------------- > >DMOL 3.5 > >1 CPU 358 SCF basis functions 49 min/18 SCF cycl. = 163 sec/cycle > >------------------------------------------------------------------------- > >Turbomole, RIDFT method, > > 389 SCF basis functions 20 min/12 SCF cycles = 100 sec/cycle > >------------------------- > >Turbomole, DFT method > >1 CPU, 1 PIII-550 (last cycle with large grid) (rel 5.1) > > 102 min, 10 SCF cycles = 610 sec/cycle > >------------------------------------------------------------------------- > > >On PII-450 > >------------------------------------------------------------------------- > >QCHEM ver 1.2: > >standard grid, basis (381) 169 min/12 SCF = 844 sec/cycle > >------------------------------------------------------------------------- > > >ON PII-400 > >------------------------------------------------------------------------- > >ADF-99 > > 1 CPU: 389 SCF basis functions: > > (127 min for 17 SCF cycles) = (448 sec/cycle) > >------------------------------------------------------------------------- > ========================================= > drs. Marcel Swart > > Theoretical Chemistry (MSC) > Molecular Dynamics (GBB) > > Rijksuniversiteit Groningen > Chemistry Department > Nijenborgh 4 > 9747 AG Groningen > The Netherlands > > tel : +31 - (0)50 - 3634377 > fax : +31 - (0)50 - 3634441 > > E-mail : m.swart@chem.rug.nl > WWW: http://hydra.chem.rug.nl/~swart/ > ========================================= > > -= 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 > > > > > From chemistry-request@server.ccl.net Mon Dec 6 12:51:00 1999 Received: from ccshst09.cs.uoguelph.ca (ccshst09.cs.uoguelph.ca [131.104.96.18]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id MAA18708 for ; Mon, 6 Dec 1999 12:50:59 -0500 Received: from ccshst01 (wtian@ccshst01.cs.uoguelph.ca [131.104.96.81] (may be forged)) by ccshst09.cs.uoguelph.ca (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA03155 for ; Mon, 6 Dec 1999 11:42:36 -0500 (EST) Date: Mon, 6 Dec 1999 11:42:36 -0500 (EST) From: WeiQuan Tian X-Sender: wtian@ccshst01 To: chemistry@ccl.net Subject: Summary of Gaussian on Clusters Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The only responce from Dr. Fox at Gaussian Inc. Original Question: Does anyone know anygroup running Gaussian 98 or 94 on clusters (clusters of computer)? What are the operating system and hardware? Responce: (from Dr. Fox) Gaussian 98 is supported on clusters using the Linda software from SCA. Linda and G98 can utilize a variety of systems including Digital Unix, IBM AIX, Intel Linux, and SGI Irix. Please contact Gaussian, Inc. at info@gaussian.com and we can discuss details of licensing your site. ---- BTW, I am still interested in how about the performance of Gaussian with clusters (mainly Digital Unix, Intel Linux and SGI Irix), the optimistic number of nodes used (especially for Intel Linux and Digitals). I will resummarize the reponces if available. Wei Quan Tian From chemistry-request@server.ccl.net Mon Dec 6 12:58:32 1999 Received: from igor.wag.caltech.edu (igor.wag.caltech.edu [131.215.33.3]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id MAA18749 for ; Mon, 6 Dec 1999 12:58:32 -0500 Received: from wag.caltech.edu (octane2 [131.215.33.125]) by igor.wag.caltech.edu (8.9.3/8.9.3) with ESMTP id IAA13292; Mon, 6 Dec 1999 08:50:06 -0800 (PST) Sender: rpm@wag.caltech.edu Message-ID: <384BE93E.F19494F5@wag.caltech.edu> Date: Mon, 06 Dec 1999 08:50:06 -0800 From: "Richard P. Muller" X-Mailer: Mozilla 4.6 [en] (X11; U; IRIX64 6.4 IP30) X-Accept-Language: en MIME-Version: 1.0 To: "Eric S. Ball" , chemistry@ccl.net Subject: Re: CCL:RO jobs on unsaturated organometallics References: <19991204133032.27503.qmail@web125.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Eric S. Ball" wrote: > > Greetings, > > I'm having great difficulty getting convergence for my > restricted open-shell DFT jobs on coordinatively unsaturated > iron compounds. I'm using Jaguar for these (rob3lyp/lacvp**), > and I've used G94/98 in the past, so suggestions pertaining to > either package would help. In Jaguar I've used vshifts of 0.2 - > 1.0; accuracy settings (iacc) of quick, medium, and ultrafine; > As per hints in the manual I tried iacc=1 (ultrafine grids) with > the lac3vp** basis (largest available) and etot simply > oscillated. > > If anyone has successfully dealt with a similar situation with > either Jaguar or G98, I'd love to start a little dialog. > If/when I meet with success I'll edit down any conversations to > the pertinent points and repost them. > > Thanks in advance, > Eric Ball I can't speak for Gaussian, but this is a well-known problem in Jaguar for DFT with transition metals. Schrodinger is working on a solution, and I sent them some of our group's most catastrophic convergence cases to test it on. But, as I understand the situation, this fix won't be available for a while, so there are some things you can try. People in our group here (Caltech MSC) find setting iconv=4, dconv=1.0d-5, vshift=0.5, iacc=1 is a good workaround for these states, although this by no means makes the problem go away. GVB-DIIS convergence, the iconv=4 flag above, uses a slightly different convergence scheme, which may work better. I don't know why DFT convergence is so much harder than HF. I wrote the gvbdiis scheme as part of my graduate thesis, and if I had known how much harder DFT wave functions were, I would have focused on those wave functions instead of the HF and GVB wave functions. Another thing I try is to use a HF wave function as the initial guess. Again, this doesn't always work, which is something that I find amazing. I realize that the DFT and HF wave functions are different, but it surprises me that they are so different that the HF isn't always even a good initial guess. I think the reason that metals are so hard is that they have a large number of virtual orbitals very close in energy, and as the wave function converges the ordering of the orbitals changes, which throws off the convergence. I hope this is some help. I certainly empathize with your frustrations with these cases. Rick -- Richard P. Muller, Ph.D. rpm@wag.caltech.edu http://www.wag.caltech.edu/home/rpm From chemistry-request@server.ccl.net Mon Dec 6 14:51:07 1999 Received: from lrz.uni-muenchen.de (lsajca1-ar3-012-122.biz.dsl.gtei.net [4.3.12.122]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id OAA19491 for ; Mon, 6 Dec 1999 14:51:06 -0500 Received: (from eugene.leitl@localhost) by lrz.uni-muenchen.de (8.8.8/8.8.8) id LAA21898; Mon, 6 Dec 1999 11:38:58 -0800 From: Eugene Leitl MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14412.4306.173522.975372@lrz.uni-muenchen.de> Date: Mon, 6 Dec 1999 11:38:58 -0800 (PST) Subject: IBM unveils $100 million research initiative to build world's fastest supercomputer X-Mailer: VM 6.71 under 21.1 (patch 4) "Arches" XEmacs Lucid http://www.ibm.com/news/1999/12/06.phtml IBM unveils $100 million research initiative to build world's fastest supercomputer "Blue Gene" to tackle protein folding grand challenge On December 6, IBM announced a new $100 million exploratory research initiative to build a supercomputer 500 times more powerful than the world's fastest computers today. The new computer -- nicknamed "Blue Gene" by IBM researchers -- will be capable of more than one quadrillion operations per second (one petaflop). This level of performance will make Blue Gene 1,000 times more powerful than the Deep Blue machine that beat world chess champion Garry Kasparov in 1997, and about 2 million times more powerful than today's top desktop PCs. Blue Gene's massive computing power will initially be used to model the folding of human proteins, making this fundamental study of biology the company's first computing "grand challenge" since the Deep Blue experiment. Learning more about how proteins fold is expected to give medical researchers better understanding of diseases, as well as potential cures. "This is exactly what IBM Research does best -- continuously placing big, aggressive bets on technologies that change the future of computing," said Dr. Paul M. Horn, senior vice president of IBM Research. "In many ways, Deep Blue got a better job today -- if this computer unlocks the mystery of how proteins fold, it will be an important milestone in the future of medicine and healthcare." Experimental new architecture key to petaflop performance IBM Research believes a radical new approach to computer design and architecture will allow Blue Gene to achieve petaflop-scale performance in about five years -- one-third of the close to 15 years it would normally take following Moore's Law. The two fastest computers in the world today are part of the ASCI program run by the U.S. Department of Energy, and which were recently tested at about 2 teraflops -- two trillion operations per second each. "We think a tremendous gain in performance will be made possible by the first major revolution in how computers are built since the mid-1980s," said Dr. Ambuj Goyal, IBM Research's vice president of computer science. "We call this new approach to computer architecture SMASH, which stands for Simple, Many and Self-Healing." The SMASH architecture differs from existing approaches in three ways: It dramatically simplifies the number of instructions carried out by each processor, allowing them to work faster and with significantly lower power and chip surface requirements (the traditional approach is to add complex features to gain performance); It will facilitate a massively parallel system capable of more than 8 million simultaneous threads of computation (compared to the maximum of 5000 threads today); It will make the computer self-stabilizing and self-healing -- automatically able to overcome failures of individual processors and computing threads. Blue Gene will consist of more than one million processors, each capable of one billion operations per second (1 gigaflop). Thirty-two of these ultra-fast processors will be placed on a single chip (32 gigaflops). A compact two-foot by two-foot board containing 64 of these chips will be capable of 2 teraflops, making it as powerful as the 8000-square foot ASCI computers. Eight of these boards will be placed in 6-foot-high racks (16 teraflops), and the final machine (less than 2000 sq. ft.) will consist of 64 racks linked together to achieve the one petaflop performance. Protein folding holds key to understanding basics of life The scientific community considers protein folding one of the most significant "grand challenges" -- a fundamental problem in science or engineering that has broad economic and scientific impact and whose solution can be advanced only by applying high-performance computing technologies. Proteins control all cellular processes in the human body. Comprising strings of amino acids that are joined like links of a chain, a protein folds into a highly complex, three-dimensional shape that determines its function. Any change in shape dramatically alters the function of a protein, and even the slightest change in the folding process can turn a desirable protein into a disease. Better understanding of how proteins fold will give scientists and doctors better insight into diseases and ways to combat them. Pharmaceutical companies could design high-tech prescription drugs customized to the specific needs of individual people. And doctors could respond more rapidly to changes in bacteria and viruses that cause them to become drug-resistant. "Breakthroughs in computers and information technology are now creating new frontiers in biology," said Horn. "One day, you're going to be able to walk into a doctor's office and have a computer analyze a tissue sample, identify the pathogen that ails you, and then instantly prescribe a treatment best suited to your specific illness and individual genetic makeup." IBM Research About 50 scientists from IBM Research's Deep Computing Institute and Computational Biology Group will work on Blue Gene and the protein folding grand challenge. IBM Research is the world's largest research organization dedicated to information technology, with eight labs around the world, including Austin, Beijing, Delhi, Haifa, Tokyo, San Jose, Yorktown Heights (New York), and Zurich. From chemistry-request@server.ccl.net Mon Dec 6 15:27:12 1999 Received: from pgh.nauticom.net (www.nauticom.net [209.195.130.4]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA19759 for ; Mon, 6 Dec 1999 15:27:12 -0500 Received: from localhost (jkong1@localhost) by pgh.nauticom.net (8.8.7/8.8.7) with ESMTP id OAA19761 for ; Mon, 6 Dec 1999 14:16:07 -0500 (EST) Date: Mon, 6 Dec 1999 14:16:03 -0500 (EST) From: Jing Kong X-Sender: jkong1@pgh.nauticom.net To: chemistry@ccl.net Subject: Re: CCL:Comparative Linux quantum chemistry benchmark In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Netters, While we are at this, I would like to mention that the AO integral evaluations in DFT may vary too, in addition to grid for XC evaluation. As far as I know, the coulomb integrals have been evaluated as four-center integrals including fast-multiple for far field, three-center integrals with fitted auxillary basis set, and using numerical grid. Regards, Jing **** Jing Kong, Ph.D., Chief Scientist, Q-Chem Inc. On Mon, 6 Dec 1999, Peter Shenkin wrote: > Hi, > > Talking to the in-house experts, it does appear that there are > some discrepancies between grids used in the different programs, > and that these differences work to the detriment of the relative > Jaguar performance cited. > > However, Peter's posting also led us to perform a few LINUX tuning > experiments. These reveal that we can greatly improve our > LINUX performance. This has not benefited in the past from > the careful attention that we have given to performance on > commercial UNIX platforms with the help of our vendor partners. > > LINUX is becoming a much more important platform to us; indeed, > we will be supporting MacroModel as well as Jaguar under LINUX. > Therefore, we will most certainly be addressing and improving > Jaguar LINUX performance over the coming months. > > -P. > > -- > ** Whether the playing field is level depends on the coordinate system. *** > ********* Peter S. Shenkin; Schrodinger, Inc.; (201)433-2014 x111 ********* > *********** shenkin@schrodinger.com; http://www.schrodinger.com *********** > > On Mon, 6 Dec 1999, Marcel Swart wrote: > > > Dear Peter, > > > > a benchmark usually means checking DIFFERENT programs on ONE machine, or > > ONE program on DIFFERENT machines. This makes the benchmark meaningful. > > > > However, you are testing several programs on several machines, so you are > > actually performing several benchmarks. I summarize below the 3 benchmarks, > > >from which you could say something. > > > > BTW, are the default grids the same for all programs ? Do they all use > > numerical integration, and if so, are the energies all the same, up to the > > same accuracy ? Is the numerical integration valid up to the same accuracy, > > etc. etc. ? > > > > Else, these times do not say anything more, than that you have had a nice > > time, the afternoon you were playing with these programs. > > > > Best wishes, > > > > Marcel. > > > > > > >On PIII-550 > > >------------------------------------------------------------------------- > > >reference-98 (6-31G*) > > > 1 CPU, 381 basis function 235 min/15 cycle = 940 sec/cycle > > >------------------------------------------------------------------------- > > >Jaguar v 3.5 rel 50: > > > 381 SCF basis functions: 64 min/11 SCF cycl. = 349 sec/cycle > > >------------------------------------------------------------------------- > > >DMOL 3.5 > > >1 CPU 358 SCF basis functions 49 min/18 SCF cycl. = 163 sec/cycle > > >------------------------------------------------------------------------- > > >Turbomole, RIDFT method, > > > 389 SCF basis functions 20 min/12 SCF cycles = 100 sec/cycle > > >------------------------- > > >Turbomole, DFT method > > >1 CPU, 1 PIII-550 (last cycle with large grid) (rel 5.1) > > > 102 min, 10 SCF cycles = 610 sec/cycle > > >------------------------------------------------------------------------- > > > > >On PII-450 > > >------------------------------------------------------------------------- > > >QCHEM ver 1.2: > > >standard grid, basis (381) 169 min/12 SCF = 844 sec/cycle > > >------------------------------------------------------------------------- > > > > >ON PII-400 > > >------------------------------------------------------------------------- > > >ADF-99 > > > 1 CPU: 389 SCF basis functions: > > > (127 min for 17 SCF cycles) = (448 sec/cycle) > > >------------------------------------------------------------------------- > > ========================================= > > drs. Marcel Swart > > > > Theoretical Chemistry (MSC) > > Molecular Dynamics (GBB) > > > > Rijksuniversiteit Groningen > > Chemistry Department > > Nijenborgh 4 > > 9747 AG Groningen > > The Netherlands > > > > tel : +31 - (0)50 - 3634377 > > fax : +31 - (0)50 - 3634441 > > > > E-mail : m.swart@chem.rug.nl > > WWW: http://hydra.chem.rug.nl/~swart/ > > ========================================= > > > > > > > > > > > > > > > -= 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 > > > > > > From chemistry-request@server.ccl.net Mon Dec 6 15:40:13 1999 Received: from lion.studentergaarden.dk ([130.226.169.130]) by server.ccl.net (8.8.7/8.8.7) with SMTP id PAA19877 for ; Mon, 6 Dec 1999 15:40:12 -0500 Received: (qmail 25574 invoked from network); 6 Dec 1999 19:32:44 -0000 Received: from unknown (HELO studentergaarden.dk) (172.16.15.92) by nero.studentergaarden.dk with SMTP; 6 Dec 1999 19:32:44 -0000 Message-ID: <384C0E37.8DAEDD2C@studentergaarden.dk> Date: Mon, 06 Dec 1999 20:27:51 +0100 From: Kasper Planeta Jensen X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: chemistry@ccl.net Subject: Checkcoordinates Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am currently having some problems with the OPT(modred,CheckCoordinates) option in G98. I use both Geom(modredundant,connect) and Opt(modredundant) but the CheckCoordinates keyword, which ought to rebuild the connectivity matrix upon each optimisation step, does not seem to work. Does anybody know why? Love, Kasper From chemistry-request@server.ccl.net Mon Dec 6 16:57:01 1999 Received: from donkeykong.gpcc.itd.umich.edu (smtp@donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id QAA20334 for ; Mon, 6 Dec 1999 16:57:01 -0500 Received: from qix.gpcc.itd.umich.edu (smtp@qix.gpcc.itd.umich.edu [141.211.2.152]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id PAA27017 for ; Mon, 6 Dec 1999 15:48:34 -0500 (EST) Received: from localhost (brupalf@localhost) by qix.gpcc.itd.umich.edu (8.8.8/5.1-client) with ESMTP id PAA14136 for ; Mon, 6 Dec 1999 15:48:33 -0500 (EST) Precedence: first-class Date: Mon, 6 Dec 1999 15:48:32 -0500 (EST) From: Bruce Allan Palfey X-Sender: brupalf@qix.gpcc.itd.umich.edu To: chemistry@ccl.net Subject: hydrodynamic properties from structures? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the "old" days of biophysics, when 3-D structures were still fairly hard to come by, people would get very rough ideas of the shape of proteins from hydrodynamic experiments like analytical ultracentrifugation or viscosity measurements. I was wondering if things have now come full circle: Given a protein structure from crystallography or NMR, are there any programs that will calculate the frictional coefficient or shape parameters used in hydrodynamic analyses? Thanks in advance, Bruce Palfey Department of Biological Chemistry University of Michigan Ann Arbor, MI 48109-0606 From chemistry-request@server.ccl.net Mon Dec 6 15:57:09 1999 Received: from si.fi.ameslab.gov (si.fi.ameslab.gov [147.155.20.1]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id PAA20042 for ; Mon, 6 Dec 1999 15:57:09 -0500 Received: (from pradipta@localhost) by si.fi.ameslab.gov (AIX4.2/UCB 8.7/8.7) id NAA38178 for chemistry@ccl.net; Mon, 6 Dec 1999 13:50:51 -0600 (CST) From: Pradipta Bandyopadhyay Message-Id: <199912061950.NAA38178@si.fi.ameslab.gov> Subject: Free software for model problems! To: chemistry@ccl.net (CCL) Date: Mon, 6 Dec 1999 13:50:51 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Hi everyone, I am looking for a program which can solve the Schrodinger equation using basis set approach for simple potentials ( e.g. particle in a box having different potential energy regions i.e. more complicated than particle in a box). Basically it will use the variation theorem to form the Hamiltonian matrix and diagonalize ( I will supply the necessary integrals to form the H matrix) it. Basically it would be a prototype of any quantum chemistry program with different Hamiltonians. But, I will be needing the iterative procedure to solve my problem ( for the same reason as in the Hartree-Fock method). It is meant to be for educational purposes. Can anybody tell me whether I can get a free program for that? Thanks. Pradipta -- ***************************************** * Dr. Pradipta Bandyopadhyay * * AMES LAB * * Department of Chemistry * * Iowa State Unievrsity * * Ames, IA 50011 * * USA * * e-mail: pradipta@si.fi.ameslab.gov * * Phone : 515-294-4604 (Lab) * * : 515-232-8067 (Residence) * * Fax : 515-294-0105 * * URL: http://www.msg.ameslab.gov/ * * Group/pradipta/index.html * ***************************************** ------------------------------------------------------------------------------ The superfluous, that very necessary thing ... VOLTAIRE The secret of being a bore is to say everything. VOLTAIRE ------------------------------------------------------------------------------ From chemistry-request@server.ccl.net Mon Dec 6 17:27:00 1999 Received: from ccl.net (atlantis.ccl.net [192.148.249.4]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id RAA20616 for ; Mon, 6 Dec 1999 17:27:00 -0500 Received: from krakow.ccl.net (krakow.ccl.net [192.148.249.195]) by ccl.net (8.8.6/8.8.6/OSC 1.1) with ESMTP id QAA16140; Mon, 6 Dec 1999 16:18:31 -0500 (EST) Date: Mon, 6 Dec 1999 16:18:31 -0500 (EST) From: Jan Labanowski To: chemistry@ccl.net cc: Jan Labanowski Subject: US Funding opportunities alert service Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am in no way associated with this service, but found it useful (provided that you do a good job selecting the right keywords). Since the stereotype of the scientist undergoes dramatic changes in the last few decades, and modern scientists are evaluated more by their ability to secure funds for research rather than by their oldfashioned pursuits in quest of truth, this service can be very helpful (for those who feel offended, I say: "Yes, I know, if you are really good you will get money", and for those who agree, I'd say, take a few marketing courses, and maybe some advanced technical writing too...). It sends notices about US funding opportunities according to the keyword criteria entered on the Web site. Since it is free, you do not risk much, and if you want to stop it, you just choose that you want to receive information on research in basic science (just kidding...?). Jan jkl@ccl.net Jan K. Labanowski | phone: 614-292-9279, FAX: 614-292-7168 Ohio Supercomputer Center | Internet: jkl@ccl.net 1224 Kinnear Rd, | http://www.ccl.net/chemistry.html Columbus, OH 43212-1163 | http://www.ccl.net/ ======================================================================= Date: Mon, 6 Dec 1999 15:21:49 -0500 Message-Id: <199912062021.PAA15434@zappa.fie.com> To: jkl@ccl.net Subject: Referrals Must Register By Wednesday From: "ScienceWise Alert" Reply-To: "ScienceWise Alert" Dear Jan K Labanowski, As you know, ScienceWise Alert is currently in an "Open Period" and any colleague that you refer to the service will receive it free through May 2000. However, they must sign up no later than this Wednesday (Dec. 8th). So, if you haven't already done so, please take just a moment to forward the link below to your colleagues: http://www.usalert.com/freeservice4.asp Remember, we are NOT automatically charging at the end of this period, so the service truly is free during this time. After May 2000, subscribers wishing to continue the service will have to let us know by email. Thank you for your help and have a wonderful holiday season, Adam Waugh ScienceWise Alert http://www.sciencewise.com P.S. Please let us know anytime your email address changes. AW/bk:5206 =================================================================== From chemistry-request@server.ccl.net Mon Dec 6 22:45:43 1999 Received: from gwdu42.gwdg.de (root@gwdu42.gwdg.de [134.76.10.26]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id WAA21909 for ; Mon, 6 Dec 1999 22:45:43 -0500 Received: from gwdu20-eth.gwdg.de ([134.76.10.220] helo=gwdu20.gwdg.de ident=kmarkey) by gwdu42.gwdg.de with smtp (Exim 3.03 #2) id 11vAV7-0002iM-00 for CHEMISTRY@ccl.net; Tue, 07 Dec 1999 03:37:13 +0100 Received: from localhost by gwdu20.gwdg.de (5.65v4.0/1.1.10.5/11Feb98-0154PM) id AA30990; Tue, 7 Dec 1999 03:37:12 +0100 Date: Tue, 7 Dec 1999 03:37:11 +0100 (MEST) From: Kristan Markey To: CHEMISTRY@ccl.net Subject: Re: CCL:RO jobs on unsaturated organometallics In-Reply-To: <384BE93E.F19494F5@wag.caltech.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greetings, The convergence problem with transition metal clusters is something with which I have also had to deal. First off, Gaussian uses a Hueckel guess for its initial guess: not the best choice. Try converging a calculation with a small basis set and using the checkpoint file as an initial guess. Although this does not always work, especially when there are many virtuals close in energy, it is a good start. Secondly, restricted open shell wavefunctions and DFT don't mix. Indeed, when I was working on Ni clusters, I experienced the same Etot oscillations. I am not sure of the fundamental problems, but the wavefunction converges much better if it is unrestricted. The strict spin treatment is less important for DFT anyways. Cheers, kristan ============================================================================ Kristan Markey Schreiner Forschungsgruppe Tel: 0551 393290 Institut fuer Organische Chemie Tel: 0551 3399475 Tammannstr. 2 kmarkey@gwdg.de 37077 Goettigen http://www.gwdg.de/~kmarkey Germany It is easier to be a "patriot" than to render your own country its proper due; it is easier to be a "civic leader" than to make your community a better place to live in; it is easier to be a "humanitarian" than to treat your own family with loving understanding; for the smaller the focus of attention, the harder the task. -- Sydney J. Harris ===========================================================================