From owner-chemistry@ccl.net Wed Oct 8 01:45:00 2008 From: "Sengen Sun sengensun+*+yahoo.com" To: CCL Subject: CCL: Why Bader's theory represents the future of theoretical chemistry? Message-Id: <-37865-081008013709-17022-jN5yi7GMLmUaGx/NN8xBYQ(0)server.ccl.net> X-Original-From: Sengen Sun Content-Type: text/plain; charset=us-ascii Date: Tue, 7 Oct 2008 22:30:18 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: Sengen Sun [sengensun(-)yahoo.com] Thanks to five people who responded to my last post (3 private and 2 public). Three of them agreed with me, and two don't. To me, Bader's theory is conceptually superior to Pople's and Kohn's. I am very disappointed that Dr. Nicholls judges a good theory based on its current popularity. (It is accidentally ironic!) As pointed out by Dirac, the major task in Quantum mechanics is to solve the Schrodinger equation, or is about mathematics. Pople and Kohn have just done that in different ways - techniques (in my best knowledge)! I have no doubt that Pople and Kohn well deserved the Nobel Prize. They created wonderful mathematical tools to solve some aspects (but not all) of chemical puzzles. But they just created tools! In DFT, the key sentence related to physics is that electron density (ED) decides everything. Unfortunately, ED is simply a mathematical tool and does not have an absolute meaning in DFT. Although some physical principles are referenced (used) quite often in order to solve, ED - the cause of chemical phenomena is not the major concern in DFT, but other observable properties such as geometries, energies, etc.. DFT abandons its original conceptual statement in the end of the mathematical processes. Bader's focus has been the cause of natural puzzles - ED. He and his group of people have proved that there is absolute ED in the nature that is computational accessible and experimentally provable by x-rays crystallography. If there is computationally accessible ED today, there will be computationally accessible ED tomorrow, and 100 years later, and 1000 years later, and 10000 years later, and.....! Until this world ends! Will DFT or LCAO still be there by then? I am not sure! This is an authentic example of theoretical revolution of chemistry about solving natural puzzles as Kuhn discussed. Who else did the same? Pople? Kohn? Hoffmann? Fukui? I don't know. > Dr. Anthony Nicholls: "The comments by Sengun Sun reflect one > of the main criticisms of Kuhn's work at the time it was first > published. It was easy to see the shift in Newton-Einstein or > Classical-Quantum as paradigm shifts but since these only happen > every fifty years or so, what use is it?" Are you asking "What use is it?"? Please forgive me for being straightforward. But do you think this a good opportunity to make some money (commercial opportunity?), or to make decoration symbolizing that the main stream community has reached a new level of civilization? > > Dr. Anthony Nicholls: "If Sun had attended any of the Kuhn >> Symposia he would have heard my introduction wherein I give many >> examples of such and in particular champion the "Kuhn-lite" >> description by the great British geneticist J. B. S. Haldane (J. >> Genetics #58, 1963, p 464): >> Four stages of acceptance of a scientific theory: > i) It is worthless nonsense. > ii) This is an interesting, but perverse, point of view. > iii) It is true, but quite unimportant. > iv) I always said so. > Every time I have given this introduction I have seen heads nod in > rueful acknowledgement because most of us who have had original ideas > have experienced just this process." Therefore, you think you are the problem-solver by recruiting "experts" and "judges". I would say that you should be awarded a nobel prize more than Bader. Best regards, From owner-chemistry@ccl.net Wed Oct 8 04:23:01 2008 From: "Shunichi Ozawa s.ozawa],[infocom.co.jp" To: CCL Subject: CCL: New version: JChem Extensions for KNIME: Message-Id: <-37866-081008040120-22502-LK//S3dymCmbGoThZKchsw###server.ccl.net> X-Original-From: "Shunichi Ozawa" Date: Wed, 8 Oct 2008 04:01:16 -0400 Sent to CCL by: "Shunichi Ozawa" [s.ozawa-*-infocom.co.jp] Infocom launches JChemExtensions ver 1.3.5 Infocom is pleased to announce a new release of JChem Extensions 1.3.5, which allows researchers to deal with chemical structure data using ChemAxons software tools such as Marvin, JChem, Standardizer, on the KNIME open source workflow platform. This version supports ChemAxon's JChem ver 5.1.2 and includes new fifteen nodes. New added nodes mainly support some ChemAxon's plugins besides "Markush enumeration node" which can generate a whole or a subset of the library of a generic Markush structure in patent claims. So far,INFOCOM had offered the limitation version for academic customer. Now they can use all of "JChem Extensions" free of charge. Evaluation and more information: http://www.infocom.co.jp/bio/develop/jchemextension_en.html [New features in version 1.3.5] New nodes: - Charge - Orbital Electronegativity - Polarizability - Geometry - Molecular Surface Area - Polar Surface Area - Topology Analysis - H Bond Donor/Acceptor - Huckel Analysis - Refractivity - Markush Enumeration - BCUT - ChemicalFingerprint - Fragmentrer - MultipleMolImporter Evaluation and more information: http://www.infocom.co.jp/bio/develop/jchemextension_en.html =================================================== Shunichi OZAWA (s.ozawa*|*infocom.co.jp) Chem & Bio Informatics Department INFOCOM CORPORATION Tokyo Head Office;2-34-17, Jingumae, Shibuya-ku, Tokyo, 150-0001, Japan From owner-chemistry@ccl.net Wed Oct 8 04:54:01 2008 From: "Jerome Kieffer jerome.Kieffer^terre-adelie.org" To: CCL Subject: CCL:G: G03 on Barcelona's Message-Id: <-37867-081008031938-18549-9KfvJ6fVAKbtShgOSzGcbw|*|server.ccl.net> X-Original-From: Jerome Kieffer Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 8 Oct 2008 08:17:46 +0200 Mime-Version: 1.0 Sent to CCL by: Jerome Kieffer [jerome.Kieffer[*]terre-adelie.org] On Sat, 4 Oct 2008 16:39:26 -0400 "Gennady L Gutsev gennady.gutsev_+_famu.edu" wrote: > we have installed a cluster of 50 Barcelona's but Gaussian jobs=20 > are not running. If I submit, say, 10 jobs, 5 die in a few seconds, > 2 in a few minutes, 3 in hours to several days. > Have anybody experienced similar problems? I wonder what could be > wrong: or processors themselves, either G03 is not well adapted to > the Barcelona platform, either the problem with the system support?=20 Hi, the Barcelona is NOT compatible with Gaussian http://www.gaussian.com/g03_plat.htm --=20 J=E9r=F4me KIEFFER : http://www.terre-adelie.org =C0 v=E9lo, prendre une rue =E0 contre-sens est moins dangeureux que prendre un boulevard dans le sens l=E9gal. =C0 qui la faute ? From owner-chemistry@ccl.net Wed Oct 8 09:00:01 2008 From: "Gustavo Seabra gustavo.seabra*gmail.com" To: CCL Subject: CCL:G: G03 on Barcelona's Message-Id: <-37868-081008085312-20595-vVbHBel6tzNtxpHD/CYtqA~!~server.ccl.net> X-Original-From: "Gustavo Seabra" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 8 Oct 2008 08:52:55 -0400 MIME-Version: 1.0 Sent to CCL by: "Gustavo Seabra" [gustavo.seabra[A]gmail.com] On Wed, Oct 8, 2008 at 2:17 AM, Jerome Kieffer wrote: > "Gennady L Gutsev wrote: >> we have installed a cluster of 50 Barcelona's but Gaussian jobs >> are not running. If I submit, say, 10 jobs, 5 die in a few seconds, >> 2 in a few minutes, 3 in hours to several days. >> Have anybody experienced similar problems? I wonder what could be >> wrong: or processors themselves, either G03 is not well adapted to >> the Barcelona platform, either the problem with the system support? > > Hi, the Barcelona is NOT compatible with Gaussian > http://www.gaussian.com/g03_plat.htm That's *not* what the webpage you indicated says. It's just not /supported/, just as they do not support installation on Mac OS X 10.5 Leopard. But that does /not/ mean it can't be compiled there, given you have the source code and the compilers. Granted, it may take some extra time to make Gaussian work smoothly there, but that's probably more a matter of compiler/interconnect than of gaussian vx Barcelona itself. Best regards, -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA From owner-chemistry@ccl.net Wed Oct 8 09:35:01 2008 From: "Jones de Andrade johannesrs%x%gmail.com" To: CCL Subject: CCL:G: G03 on Barcelona's Message-Id: <-37869-081008091715-29896-rzrP7fV738CrcikYzZXUPg%server.ccl.net> X-Original-From: "Jones de Andrade" Content-Type: multipart/alternative; boundary="----=_Part_75695_982809.1223471819264" Date: Wed, 8 Oct 2008 10:16:59 -0300 MIME-Version: 1.0 Sent to CCL by: "Jones de Andrade" [johannesrs]^[gmail.com] ------=_Part_75695_982809.1223471819264 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Better say: B2 Barcellonas are not compatible with G03. Kill your suplier i= f they sold you B2s instead of B3s. On Wed, Oct 8, 2008 at 3:17 AM, Jerome Kieffer jerome.Kieffer^ terre-adelie.org wrote: > > Sent to CCL by: Jerome Kieffer [jerome.Kieffer[*]terre-adelie.org] > On Sat, 4 Oct 2008 16:39:26 -0400 > "Gennady L Gutsev gennady.gutsev_+_famu.edu" > wrote: > > > we have installed a cluster of 50 Barcelona's but Gaussian jobs > > are not running. If I submit, say, 10 jobs, 5 die in a few seconds, > > 2 in a few minutes, 3 in hours to several days. > > Have anybody experienced similar problems? I wonder what could be > > wrong: or processors themselves, either G03 is not well adapted to > > the Barcelona platform, either the problem with the system support? > > Hi, the Barcelona is NOT compatible with Gaussian > http://www.gaussian.com/g03_plat.htm > > -- > J=E9r=F4me KIEFFER : http://www.terre-adelie.org > =C0 v=E9lo, prendre une rue =E0 contre-sens est moins dangeureux > que prendre un boulevard dans le sens l=E9gal. =C0 qui la faute ? > > > > - This is automatically added to each message by the mailing script -> > > ------=_Part_75695_982809.1223471819264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Better say: B2 Barcellonas are not compatible with G03. Ki= ll your suplier if they sold you B2s instead of B3s.

On Wed, Oct 8, 2008 at 3:17 AM, Jerome Kieffer jerome.Kieffer^<= a href=3D"http://terre-adelie.org">terre-adelie.org &= lt;owner-chemistry[]ccl.net&g= t; wrote:

Sent to CCL by: Jerome Kieffer [jerome.Kieffer[*]terre-adelie.org]
On Sat, 4 Oct 2008 16:39:26 -0400
"Gennady L Gutsev gennady.gutsev_+_famu.edu" <owner-chemistry+*+ccl.net>
wrote:

> we have installed a cluster of 50 Barcelona's but Gaussian jobs > are not running. If I submit, say, 10 jobs, 5 die in a few seconds, > 2 in a few minutes, 3 in hours to several days.
>    Have anybody experienced similar problems? I wonder what = could be
> wrong: or processors themselves, either G03 is not well adapted to
> the Barcelona platform, either the problem with the system support?
Hi, the Barcelona is NOT compatible with Gaussian
http://w= ww.gaussian.com/g03_plat.htm

--
J=E9r=F4me KIEFFER  : http://www.terre-adelie.org
=C0 v=E9lo, prendre une rue =E0 contre-sens est moins dangeureux
que prendre un boulevard dans le sens l=E9gal. =C0 qui la faute ?



- This is automatically added to each message by the mailing script -
E-mail to subscribers: CHEMISTRY[]ccl.n= et or use:
     http://www.ccl.net/cgi-bin/ccl/send_ccl_message=

E-mail to administrators: CHEM= ISTRY-REQUEST[]ccl.net or use
     http://www.ccl.net/cgi-bin/ccl/send_ccl_message=

Subscribe/Unsubscribe:
     http://www.ccl.net/chemistry/sub_unsub.shtml

Before posting, check wait time at: http://www.ccl.net

Job: http://www.ccl.n= et/jobs
Conferences: http://server.ccl.net/chemistry/announcements/co= nferences/

Search Messages: htt= p://www.ccl.net/htdig  (login: ccl, Password: search)
     http://www.ccl.net/spammers.txt

RTFI: http://www.ccl.net/chemistry/aboutccl/instructions/



------=_Part_75695_982809.1223471819264-- From owner-chemistry@ccl.net Wed Oct 8 11:13:01 2008 From: "Veronique LEGRAND vflegrand:free.fr" To: CCL Subject: CCL:G: check the total number of molecular orbital Message-Id: <-37870-081008110236-23882-fekAZwaXftnFw1X2fksoHQ%x%server.ccl.net> X-Original-From: "Veronique LEGRAND" Date: Wed, 8 Oct 2008 11:02:32 -0400 Sent to CCL by: "Veronique LEGRAND" [vflegrand*_*free.fr] First, I want thank you for your opinion on my problem, I feel less desesperate. Maybe I omitted certain details in the last message. I know that MP2 needs the density=current keywords, but when I used this syntax to my NBO calculation, I hadn't the analysis of Perturbation Theory part in the output. And I really need it to explain the electron tranfer occuring in my molecule. So I was obliged to choose a less optimum solution, it's to say omitted this keyword. If you have an other one, I take it. About the other point: the number of orbitals. I checked it again. And I realised thanks to you, that gaussian gives the same number of Molecular orbitals in both case. The difference is in the file .wfn, where in a case there are 127 and in the other 330. It's unbelievable. So I just run these 2 files one more time, and I tried one another. If I see something knew, or if it's like now I will tell you. Sincerely yours. Veronique > "Ol Ga eurisco1[]pochta.ru" wrote: > > Sent to CCL by: "Ol Ga" [eurisco1*o*pochta.ru] > Dear Legrand Vronique, > > > I think that your two input sections are not correct. If you really want to do NBO analysis for MP2 you need to type DENSITY=CURRENT or DENSITY=ALL in the script, e.g. > #p UMP2/6-31G** GFPrint GFinput DENSITY=CURRENT Scf=VeryTight Output=WFN > # Punch=Archive iop(5/14=2) Maxdisk=500000000 Pop=(Full,NBO) Test > > You will get in .out > > ******************************Gaussian NBO Version > > Analyzing the MP2 density > *********** > > Or you should use > > #p UMP2/6-31G** GFPrint GFinput DENSITY=ALL Scf=VeryTight Output=WFN > # Punch=Archive iop(5/14=2) Maxdisk=500000000 Pop=(Full,NBO) Test > > In .out-file you will get both analysis of SCF and MP2 densities, i.e. > > You will get two sections of NBO analysis > > ******************************Gaussian NBO Version 3.1 > > Analyzing the SCF density > > ******************************Gaussian NBO Version 3.1 > > Analyzing the MP2 density > > --------------- > I really dont understand why you see different numbers of orbitals (127 MO vs. 330). Obviously, scf(VeryTight) has not any influence for this type of calculations. I tried your two inputs I didnt see any difference in the number of orbitals. > > Sincerely, > > Ol Ga > > > > Sent to CCL by: "V ronique LEGRAND" [vflegrand- -free.fr] > > Hello everybody, > > > I'm a french student in PHD, and I have a problem between 2 results > > of Gaussian calculation. To be clear : > > -First : I realised an NBO calculation and the generation of a WFN file with the syntax : > > #p UMP2/6-31G** GFPrint GFinput Scf=VeryTight Output=WFN Punch=Archive iop(5/14=2) > > Maxdisk=500000000 Pop=(Full,NBO) Test > > > In this case I can't use density=current as it should be with MP2, > > otherwise I have not all the NBO description in the output (?). > > > -So in a second time, to have the real energy of my molecule in MP2 I used: > > #p UMP2/6-31G** density=current GFPrint GFinput Output=WFN Punch=Archive iop(5/14=2) > > Maxdisk=500000000 Test > > There are no more NBO or scf calculation. > > > When I compared the results of these 2 steps, I was very surprised > > to find 127 molecular orbitals in the first (NBO...) and 330 in the second. > > > > I don't know why it's so different, I used the same basis set, and > > method. Which one tell the truth !! > > > Thank you so much for any explanation (please be sure), and help on this problem. > > > LEGRAND Vronique at vflegrand:+:free.fr > > From owner-chemistry@ccl.net Wed Oct 8 11:51:00 2008 From: "Patrik Rydberg pry]=[farma.ku.dk" To: CCL Subject: CCL:G: G03 on Barcelona's Message-Id: <-37871-081008111809-27993-qpCFFO4+pPwQSr7c/eeRQg---server.ccl.net> X-Original-From: "Patrik Rydberg" Content-Language: sv Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 Oct 2008 16:19:40 +0200 MIME-Version: 1.0 Sent to CCL by: "Patrik Rydberg" [pry##farma.ku.dk] An the webpage also specifies "B2 Barcelona", which means Barcelona cpus with B2 stepping, a version of the cpu which had some problems and which = as far as I know is not even for sale any more.=20 If you have Barcelona cpus with B2 stepping you should probably take a careful look at the known issues of this cpu version so that it does not affect other software you are using. However, from experience I know that the same problems you have can = occur on Barcelonas with B3 stepping. Gaussian suggests using the latest version = of G03, revision E.01. I am waiting for it to be delivered right now. When testing I got rev. C.02 working but not rev. D.01 Best regards,=20 Patrik Rydberg -------------------------------------------------------------------------= - Patrik Rydberg, Post-doc, Ph.D. Biostructural Research Group Department of Medicinal Chemistry Faculty of Pharmaceutical=A0 Sciences University of Copenhagen DK-2200 Copenhagen http://www.farma.ku.dk/index.php/Patrik-Rydberg/5304/0/ > -----Original Message----- > From: owner-chemistry\a/ccl.net [mailto:owner-chemistry\a/ccl.net] > Sent: den 8 oktober 2008 14:53 > To: Rydberg, Patrik > Subject: CCL:G: G03 on Barcelona's >=20 >=20 > Sent to CCL by: "Gustavo Seabra" [gustavo.seabra[A]gmail.com] > On Wed, Oct 8, 2008 at 2:17 AM, Jerome Kieffer wrote: > > "Gennady L Gutsev wrote: > >> we have installed a cluster of 50 Barcelona's but Gaussian jobs > >> are not running. If I submit, say, 10 jobs, 5 die in a few seconds, > >> 2 in a few minutes, 3 in hours to several days. > >> Have anybody experienced similar problems? I wonder what could = be > >> wrong: or processors themselves, either G03 is not well adapted to > >> the Barcelona platform, either the problem with the system support? > > > > Hi, the Barcelona is NOT compatible with Gaussian > > http://www.gaussian.com/g03_plat.htm >=20 > That's *not* what the webpage you indicated says. It's just not > /supported/, just as they do not support installation on Mac OS X 10.5 > Leopard. But that does /not/ mean it can't be compiled there, given > you have the source code and the compilers. Granted, it may take some > extra time to make Gaussian work smoothly there, but that's probably > more a matter of compiler/interconnect than of gaussian vx Barcelona > itself. >=20 > Best regards, > -- > Gustavo Seabra > Postdoctoral Associate > Quantum Theory Project - University of Florida > Gainesville - Florida - USA >=20 >=20 >=20 > -=3D This is automatically added to each message by the mailing script = =3D- > To recover the email address of the author of the message, please > change>=20>=20>=20>=20>=20> Conferences: = http://server.ccl.net/chemistry/announcements/conferences/ >=20 > Search Messages: http://www.ccl.net/htdig (login: ccl, Password: > search) >=20>=20 From owner-chemistry@ccl.net Wed Oct 8 12:48:01 2008 From: "Jim Kress ccl_nospam],[kressworks.com" To: CCL Subject: CCL: Why Bader's theory represents the future of theoretical chemistry? Message-Id: <-37872-081008104440-21309-guIQ21pWCzveboQljYID1A=server.ccl.net> X-Original-From: "Jim Kress" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Date: Wed, 8 Oct 2008 09:51:34 -0400 MIME-Version: 1.0 Sent to CCL by: "Jim Kress" [ccl_nospam- -kressworks.com] > Kohn's. I am very disappointed that Dr. Nicholls judges a > good theory based on its current popularity. (It is > accidentally ironic!) Oh my gosh! The world really is flat, the starts are just points in the sky, and the universe revolves around us. At least it was in the 15th century when that was the most popular theory - at least until Nicolaus Copernicus proved it to be wrong. That's the scary thing about justification of theories by popularity. The lemming approach is usually wrong. Just look at the so called "global warming" theory as a modern example. Its adherents steadfastly maintain it is correct because it is popular with a so called "consensus" of scientists. Facts, not popularity must be the determining factor in science. Jim > -----Original Message----- > From: owner-chemistry:ccl.net [mailto:owner-chemistry:ccl.net] > Sent: Wednesday, October 08, 2008 1:30 AM > To: Kress, Jim > Subject: CCL: Why Bader's theory represents the future of > theoretical chemistry? > > > Sent to CCL by: Sengen Sun [sengensun(-)yahoo.com] Thanks to > five people who responded to my last post (3 private and 2 > public). Three of them agreed with me, and two don't. > > To me, Bader's theory is conceptually superior to Pople's and > Kohn's. I am very disappointed that Dr. Nicholls judges a > good theory based on its current popularity. (It is > accidentally ironic!) > > As pointed out by Dirac, the major task in Quantum mechanics > is to solve the Schrodinger equation, or is about mathematics. > Pople and Kohn have just done that in different ways - > techniques (in my best knowledge)! I have no doubt that Pople > and Kohn well deserved the Nobel Prize. They created > wonderful mathematical tools to solve some aspects (but not > all) of chemical puzzles. > But they just created tools! > > In DFT, the key sentence related to physics is that electron > density (ED) decides everything. Unfortunately, ED is simply > a mathematical tool and does not have an absolute meaning in DFT. > Although some physical principles are referenced (used) quite > often in order to solve, ED - the cause of chemical phenomena > is not the major concern in DFT, but other observable > properties such as geometries, energies, etc.. DFT abandons > its original conceptual statement in the end of the > mathematical processes. > > Bader's focus has been the cause of natural puzzles - ED. He > and his group of people have proved that there is absolute ED > in the nature that is computational accessible and > experimentally provable by x-rays crystallography. If there > is computationally accessible ED today, there will be > computationally accessible ED tomorrow, and 100 years later, > and 1000 years later, and 10000 years later, and.....! Until > this world ends! Will DFT or LCAO still be there by then? I > am not sure! This is an authentic example of theoretical > revolution of chemistry about solving natural puzzles as Kuhn > discussed. Who else did the same? Pople? > Kohn? Hoffmann? Fukui? I don't know. > > > Dr. Anthony Nicholls: "The comments by Sengun Sun reflect > one of the > > main criticisms of Kuhn's work at the time it was first > published. It > > was easy to see the shift in Newton-Einstein or > Classical-Quantum as > > paradigm shifts but since these only happen every fifty > years or so, > > what use is it?" > > Are you asking "What use is it?"? Please forgive me for being > straightforward. But do you think this a good opportunity to > make some money (commercial opportunity?), or to make > decoration symbolizing that the main stream community has > reached a new level of civilization? > > > > Dr. Anthony Nicholls: "If Sun had attended any of the Kuhn > >> Symposia he would have heard my introduction wherein I give many > >> examples of such and in particular champion the "Kuhn-lite" > >> description by the great British geneticist J. B. S. Haldane (J. > >> Genetics #58, 1963, p 464): > >> Four stages of acceptance of a scientific theory: > > i) It is worthless nonsense. > > ii) This is an interesting, but perverse, point of view. > > iii) It is true, but quite unimportant. > > iv) I always said so. > > Every time I have given this introduction I have seen heads nod in > > rueful acknowledgement because most of us who have had > original ideas > > have experienced just this process." > > Therefore, you think you are the problem-solver by recruiting > "experts" > and "judges". I would say that you should be awarded a nobel > prize more than Bader. > > > Best regards, > > > > -= This is automatically added to each message by the mailing > script =- To recover the email address of the author of the > message, please change the strange characters on the top line > to the : sign. You can also look up the X-Original-From: line > in the mail header.> Conferences: > http://server.ccl.net/chemistry/announcements/conferences/ > > Search Messages: http://www.ccl.net/htdig (login: ccl, > Password: search)> > From owner-chemistry@ccl.net Wed Oct 8 14:32:01 2008 From: "Jean-Christophe Poully poully::galilee.univ-paris13.fr" To: CCL Subject: CCL: Biomolecular simulation - free to access Message-Id: <-37873-081008130830-5660-S8+5NbUqhf9V3dkSdoioOQ*_*server.ccl.net> X-Original-From: Jean-Christophe Poully Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; format=flowed Date: Wed, 08 Oct 2008 18:29:24 +0200 Mime-Version: 1.0 Sent to CCL by: Jean-Christophe Poully [poully^^^galilee.univ-paris13.fr] Dear Mr Holt, I am very interested in QM/MM computational=20 methods and I would like to read the article=20 dealing with polarization but it does not seem to=20 be free to access... Could you tell me how to get=20 this article please? Thank you very much! Best regards, JC Poully At 12:17 07/10/2008, you wrote: >Sent to CCL by: "Tim Holt" [tim.holt^^^royalsociety.org] >'Biomolecular simulation' is a special theme issue of Journal of the Royal >Society Interface. Organised by Adrian Mulholland, it consists of nine= peer- >reviewed articles all of which are free to access via the journal's= homepage >at: > >http://publishing.royalsociety.org/interface > >The issue contains: > >Introduction: Biomolecular simulation > >Biomolecular simulation and modelling: status, progress and prospects > >Destabilisation of DNA duplexes by oxidative damage at guanine: >implications for lesion recognition and repair > >Dynamics of conserved waters in human HSP 90: implications for drug design > >Analysis of polarization in QM/MM modelling of biologically >relevant hydrogen bonds > >Theoretical site-directed mutagenesis: Asp168Ala mutant >of lactate dehydrogenase > >The enzyme aromatic amine dehydrogenase induces a substrate conformation >crucial for a promoting vibration that significantly reduces the effective >potential energy barrier to proton transfer > >Mapping protein electron transfer pathways with QM/MM methods > >DNA and lipid bilayers: self assembly and insertion > > >Dr Tim Holt > >tim.holt() royalsociety.org > >The Royal Society >6-9 Carlton House Terrace >London >SW1Y 5AG > > > >-=3D This is automatically added to each message by the mailing script =3D-Jean-Christophe Poully Doctorant dans l'=E9quipe AMIBES Laboratoire de Physique des Lasers Institut Galil=E9e 99, avenue JB Cl=E9ment 93430 VILLETANEUSE Bureau B002 0149403853=20 From owner-chemistry@ccl.net Wed Oct 8 16:12:00 2008 From: "Mikolaj Feliks mikolaj.feliks**pwr.wroc.pl" To: CCL Subject: CCL:G: G03 on Barcelona's Message-Id: <-37874-081008124528-23750-ZizFqZ3Ok+6bTy2GfJrhzQ*server.ccl.net> X-Original-From: Mikolaj Feliks Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 8 Oct 2008 18:06:15 +0200 MIME-Version: 1.0 Sent to CCL by: Mikolaj Feliks [mikolaj.feliks:+:pwr.wroc.pl] How is it possible that B3 revision of Barcelona is compatible with Gaussian, whereas B2 is not? B2 and B3 are the same microarchitecture, the only difference between these two is a TLB bug fixed in B3. To learn more about a TLB bug, please see: http://en.wikipedia.org/wiki/AMD_Phenom#TLB_errata I am not very familiar with Barcellonas, but for desktop Phenom B2 processors there are various software patches and workarounds that disable the TLB. I can't see the reason why not to run Gaussian on B2 Barcellonas. Regards, mfx On Wed, Oct 08, 2008 at 10:16:59AM -0300, Jones de Andrade johannesrs%x%gmail.com wrote: > Better say: B2 Barcellonas are not compatible with G03. Kill your suplier if > they sold you B2s instead of B3s. > > On Wed, Oct 8, 2008 at 3:17 AM, Jerome Kieffer jerome.Kieffer^ > terre-adelie.org wrote: > > > > > Sent to CCL by: Jerome Kieffer [jerome.Kieffer[*]terre-adelie.org] > > On Sat, 4 Oct 2008 16:39:26 -0400 > > "Gennady L Gutsev gennady.gutsev_+_famu.edu" > > wrote: > > > > > we have installed a cluster of 50 Barcelona's but Gaussian jobs > > > are not running. If I submit, say, 10 jobs, 5 die in a few seconds, > > > 2 in a few minutes, 3 in hours to several days. > > > Have anybody experienced similar problems? I wonder what could be > > > wrong: or processors themselves, either G03 is not well adapted to > > > the Barcelona platform, either the problem with the system support? > > > > Hi, the Barcelona is NOT compatible with Gaussian > > http://www.gaussian.com/g03_plat.htm > > > > -- > > Jérôme KIEFFER : http://www.terre-adelie.org > > ? vélo, prendre une rue ? contre-sens est moins dangeureux > > que prendre un boulevard dans le sens légal. ? qui la faute ? > > > > > > > > - This is automatically added to each message by the mailing script -> > > > > -- -\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- Mikolaj Feliks Molecular Modeling & Quantum Chemistry Group Institute of Physical & Theoretical Chemistry Wroclaw University of Technology, Poland http://ichfit.ch.pwr.wroc.pl/?q=user/81 -\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- From owner-chemistry@ccl.net Wed Oct 8 16:47:00 2008 From: "Ol Ga eurisco1+*+pochta.ru" To: CCL Subject: CCL:G: Re2:check the total number of molecular orbital Message-Id: <-37875-081008161228-22760-0vQ6yv7Ss0c1s1uTl02vTQ#,#server.ccl.net> X-Original-From: "Ol Ga" Date: Wed, 8 Oct 2008 16:12:25 -0400 Sent to CCL by: "Ol Ga" [eurisco1-#-pochta.ru] Dear Veronique LEGRAND, I understood your _two_ problems after additional comments. About your first point: As it is noted on the native site of NBO programs in section FAQ http://www.chem.wisc.edu/~nbo5/faq.htm Q10. I tried to go to a higher-level MP2 or CASSCF treatment, but suddenly there were no NBO orbital energies and no table of 2nd-order perturbative energies? What's wrong? NBO evaluates "orbital energies" and 2nd-order stabilization energies only when there is a well-defined 1-electron effective Hamiltonian operator (e.g., Fock or Kohn-Sham operator). Such an operator is unavailable for correlated descriptions, except those of DFT type You can see it is methodological problem (not only a problem of NBO 3.1 and NBO 5). Obviously, if you want to use correlated methods with NBO you have only one choice it is DFT. About your second point: As it is noted on the native site of AIM (and .wfn) http://www.chemistry.mcmaster.ca/aimpac/notes/aimweb.txt Density=current is vital when running correlated jobs. Otherwise the SCF (HF) density is used for popultion analysis, and more importantly, in the wavefunction file. If all the orbital populations in your wavefunction file are 2.00 you can be sure you have a Hartree-Fock wfn. If all the orbitals have energy=0.0 you have a natural orbital description. For HF densities this is fine, but the individual MOs are meaningless - try again without density=current And additional comments from me : In the .wfnfile are printed orbitals which have non-zero occupation numbers. If you use the route section _without_ DENSITY=CURRENT #p UMP2(full)/6-31G** GFPrint GFinput Scf=VeryTight Output=WFN Punch=Archive iop(5/14=2) # Maxdisk=500000000 Pop=(Full,NBO) Test 0, 2 are occupation numbers of RHF orbitals and 0, 1 are occupation numbers of UHF orbitals. You will get a list _alpha_orbital_1, , _alpha_orbital_n (it is highest occupied _alpha_orbital) and list _beta_ orbital_(M+1) where M is number of atomic orbitals in your case in .wfnfile. Please, note an unusual sequence in the numbered list (n<(M+1)) . If you use the route section _with_ DENSITY=CURRENT #p MP2(full)/6-31G** GFPrint density=current GFinput Scf=VeryTight Output=WFN Punch=Archive iop(5/14=2) # Maxdisk=500000000 Pop=(Full,NBO) Test You will get a list of _all_ orbitals in .wfn because NBO analysis will be performed and _all_ orbitals have non-zero occupation numbers. So, you will get different numbers of orbitals in two cases. I wish you good luck. Sincerely, Ol Ga > Sent to CCL by: "Veronique LEGRAND" [vflegrand*_*free.fr] > First, I want thank you for your opinion on my problem, I feel less desesperate. > Maybe I omitted certain details in the last message. I know that > MP2 needs the density=current keywords, but when I used this syntax > to my NBO calculation, I hadn't the analysis of Perturbation Theory > part in the output. And I really need it to explain the electron > tranfer occuring in my molecule. So I was obliged to choose a less > optimum solution, it's to say omitted this keyword. If you have an other one, I take it. > About the other point: the number of orbitals. I checked it again. > And I realised thanks to you, that gaussian gives the same number of > Molecular orbitals in both case. The difference is in the file .wfn, > where in a case there are 127 and in the other 330. > It's unbelievable. So I just run these 2 files one more time, and I tried one another. > If I see something knew, or if it's like now I will tell you. > Sincerely yours. > Veronique >> "Ol Ga eurisco1[]pochta.ru" wrote: >> >> Sent to CCL by: "Ol Ga" [eurisco1*o*pochta.ru] >> Dear Legrand Vronique, >> >> I think that your two input sections are not correct. If you really want to do NBO analysis for MP2 you need to type DENSITY=CURRENT or DENSITY=ALL in the script, e.g. >> #p UMP2/6-31G** GFPrint GFinput DENSITY=CURRENT Scf=VeryTight Output=WFN >> # Punch=Archive iop(5/14=2) Maxdisk=500000000 Pop=(Full,NBO) Test >> >> You will get in .out >> >> ******************************Gaussian NBO Version >> >> Analyzing the MP2 density >> *********** >> >> Or you should use >> >> #p UMP2/6-31G** GFPrint GFinput DENSITY=ALL Scf=VeryTight Output=WFN >> # Punch=Archive iop(5/14=2) Maxdisk=500000000 Pop=(Full,NBO) Test >> >> In .out-file you will get both analysis of SCF and MP2 densities, i.e. >> >> You will get two sections of NBO analysis >> >> ******************************Gaussian NBO Version 3.1 >> >> Analyzing the SCF density >> >> ******************************Gaussian NBO Version 3.1 >> >> Analyzing the MP2 density >> >> --------------- >> I really dont understand why you see different numbers of orbitals (127 MO vs. 330). Obviously, scf(VeryTight) has not any influence for this type of calculations. I tried your two inputs I didnt see any difference in the number of orbitals. >> >> Sincerely, >> >> Ol Ga >> >> >> > Sent to CCL by: "V ronique LEGRAND" [vflegrand- -free.fr] >> > Hello everybody, >> >> > I'm a french student in PHD, and I have a problem between 2 results >> > of Gaussian calculation. To be clear : >> > -First : I realised an NBO calculation and the generation of a WFN file with the syntax : >> > #p UMP2/6-31G** GFPrint GFinput Scf=VeryTight Output=WFN Punch=Archive iop(5/14=2) >> > Maxdisk=500000000 Pop=(Full,NBO) Test >> >> > In this case I can't use density=current as it should be with MP2, >> > otherwise I have not all the NBO description in the output (?). >> >> > -So in a second time, to have the real energy of my molecule in MP2 I used: >> > #p UMP2/6-31G** density=current GFPrint GFinput Output=WFN Punch=Archive iop(5/14=2) >> > Maxdisk=500000000 Test >> > There are no more NBO or scf calculation. >> >> > When I compared the results of these 2 steps, I was very surprised >> > to find 127 molecular orbitals in the first (NBO...) and 330 in the second. >> >> >> > I don't know why it's so different, I used the same basis set, and >> > method. Which one tell the truth !! >> > LEGRAND Vronique at vflegrand:+:free.fr >> >> From owner-chemistry@ccl.net Wed Oct 8 19:17:01 2008 From: "Jones de Andrade johannesrs\a/gmail.com" To: CCL Subject: CCL:G: G03 on Barcelona's Message-Id: <-37876-081008191501-7555-cOBquQuQpXRLm9QpGhPTDQ,server.ccl.net> X-Original-From: "Jones de Andrade" Content-Type: multipart/alternative; boundary="----=_Part_84043_4999109.1223507687164" Date: Wed, 8 Oct 2008 20:14:47 -0300 MIME-Version: 1.0 Sent to CCL by: "Jones de Andrade" [johannesrs,gmail.com] ------=_Part_84043_4999109.1223507687164 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Well, given the fact that G03 also doesn't work on phenoms B2 but seems to work on B3s, it's possibly exactly the bastard TLB bug that somehow affects G03. On Wed, Oct 8, 2008 at 1:06 PM, Mikolaj Feliks mikolaj.feliks**pwr.wroc.pl = < owner-chemistry^^ccl.net> wrote: > > Sent to CCL by: Mikolaj Feliks [mikolaj.feliks:+:pwr.wroc.pl] > > How is it possible that B3 revision of Barcelona is compatible with > Gaussian, whereas B2 is not? B2 and B3 are the same > microarchitecture, the only difference between these two is > a TLB bug fixed in B3. > > To learn more about a TLB bug, please see: > http://en.wikipedia.org/wiki/AMD_Phenom#TLB_errata > > I am not very familiar with Barcellonas, but for desktop Phenom B2 > processors there are various software patches and workarounds that > disable the TLB. I can't see the reason why not to run Gaussian on B2 > Barcellonas. > > > Regards, mfx > > > On Wed, Oct 08, 2008 at 10:16:59AM -0300, Jones de Andrade johannesrs%x% > gmail.com wrote: > > Better say: B2 Barcellonas are not compatible with G03. Kill your supli= er > if > > they sold you B2s instead of B3s. > > > > On Wed, Oct 8, 2008 at 3:17 AM, Jerome Kieffer jerome.Kieffer^ > > terre-adelie.org wrote: > > > > > > > > Sent to CCL by: Jerome Kieffer [jerome.Kieffer[*]terre-adelie.org] > > > On Sat, 4 Oct 2008 16:39:26 -0400 > > > "Gennady L Gutsev gennady.gutsev_+_famu.edu" ccl.net> > > > wrote: > > > > > > > we have installed a cluster of 50 Barcelona's but Gaussian jobs > > > > are not running. If I submit, say, 10 jobs, 5 die in a few seconds, > > > > 2 in a few minutes, 3 in hours to several days. > > > > Have anybody experienced similar problems? I wonder what could b= e > > > > wrong: or processors themselves, either G03 is not well adapted to > > > > the Barcelona platform, either the problem with the system support? > > > > > > Hi, the Barcelona is NOT compatible with Gaussian > > > http://www.gaussian.com/g03_plat.htm > > > > > > -- > > > J=E9r=F4me KIEFFER : http://www.terre-adelie.org > > > ? v=E9lo, prendre une rue ? contre-sens est moins dangeureux > > > que prendre un boulevard dans le sens l=E9gal. ? qui la faute ? > > > > > > > > > > > > - This is automatically added to each message by the mailing script -= > > > > > > > > > -- > > -\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- > Mikolaj Feliks > > Molecular Modeling & Quantum Chemistry Group > Institute of Physical & Theoretical Chemistry > Wroclaw University of Technology, Poland > > http://ichfit.ch.pwr.wroc.pl/?q=3Duser/81 > -\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- > > > > -=3D This is automatically added to each message by the mailing script = =3D-> > > ------=_Part_84043_4999109.1223507687164 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Well, given the fact that G03 also doesn't work on phe= noms B2 but seems to work on B3s, it's possibly exactly the bastard TLB= bug that somehow affects G03.

On Wed, Oc= t 8, 2008 at 1:06 PM, Mikolaj Feliks mikolaj.feliks**pwr.wroc.pl <owner-chemistry^^ccl.net> wrote:

Sent to CCL by: Mikolaj Feliks [mikolaj.feliks:+:pwr.wroc.pl]

 How is it possible that B3 revision of Barcelona is compatible with Gaussian, whereas B2 is not? B2 and B3 are the same
microarchitecture, the only difference between these two is
a TLB bug fixed in B3.

 To learn more about a TLB bug, please see:
http://en.wikipedia.org/wiki/AMD_Phenom#TLB_errata

 I am not very familiar with Barcellonas, but for desktop Phenom B2 processors there are various software patches and workarounds that
disable the TLB. I can't see the reason why not to run Gaussian on B2 Barcellonas.


 Regards, mfx


On Wed, Oct 08, 2008 at 10:16:59AM -0300, Jones de Andrade johannesrs%x%gmail.com wrote:
> Better say: B2 Barcellonas are not compatible with G03. Kill your supl= ier if
> they sold you B2s instead of B3s.
>
> On Wed, Oct 8, 2008 at 3:17 AM, Jerome Kieffer jerome.Kieffer^
> terre-adelie.org= <owner-chemistry * ccl= .net> wrote:
>
> >
> > Sent to CCL by: Jerome Kieffer [jerome.Kieffer[*]terre-adelie.org]
> > On Sat, 4 Oct 2008 16:39:26 -0400
> > "Gennady L Gutsev gennady.gutsev_+_famu.edu" <owner-chemistry+*+ccl.net>
> > wrote:
> >
> > > we have installed a cluster of 50 Barcelona's but Gaussi= an jobs
> > > are not running. If I submit, say, 10 jobs, 5 die in a few s= econds,
> > > 2 in a few minutes, 3 in hours to several days.
> > >    Have anybody experienced similar problems? I wo= nder what could be
> > > wrong: or processors themselves, either G03 is not well adap= ted to
> > > the Barcelona platform, either the problem with the system s= upport?
> >
> > Hi, the Barcelona is NOT compatible with Gaussian
> > http://www.gaussian.com/g03_plat.htm
> >
> > --
> > J=E9r=F4me KIEFFER  : http://www.terre-adelie.org
> > ? v=E9lo, prendre une rue ? contre-sens est moins dangeureux
> > que prendre un boulevard dans le sens l=E9gal. ? qui la fau= te ?
> >
> >
> >
> > - This is automatically added to each message by the mailing scri= pt ->
> >
> >

--

-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
  Mikolaj Feliks

 Molecular Modeling & Quantum Chemistry Group
 Institute of Physical & Theoretical Chemistry
   Wroclaw University of Technology, Poland

 http://ichfit.ch.pwr.wroc.pl/?q=3Duser/81
-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-



-=3D This is automatically added to each message by the mailing script =3D-=
To recover the email address of the a= uthor of the message, please change
E-mail to subscribers: CHEMISTRY^^ccl.n= et or use:
     http://www.ccl.net/cgi-bin/ccl/send_ccl_message=

E-mail to administrators: CHEM= ISTRY-REQUEST^^ccl.net or use
     http://www.ccl.net/cgi-bin/ccl/send_ccl_message=

Subscribe/Unsubscribe:
     http://www.ccl.net/chemistry/sub_unsub.shtml

Before posting, check wait time at: http://www.ccl.net

Job: http://www.ccl.n= et/jobs
Conferences: http://server.ccl.net/chemistry/announcements/co= nferences/

Search Messages: htt= p://www.ccl.net/htdig  (login: ccl, Password: search)
     http://www.ccl.net/spammers.txt

RTFI: http://www.ccl.net/chemistry/aboutccl/instructions/



------=_Part_84043_4999109.1223507687164-- From owner-chemistry@ccl.net Wed Oct 8 20:44:00 2008 From: "Kadir Diri kadir::visual1.chem.pitt.edu" To: CCL Subject: CCL: Gordon Research Conference and Graduate Seminar on Molecular Energy Transfer: Second announcement Message-Id: <-37877-081008204221-7836-nrUZlgP0Ja1ajWeUVJqFVA|a|server.ccl.net> X-Original-From: Kadir Diri Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Date: Wed, 08 Oct 2008 17:42:06 -0700 MIME-version: 1.0 Sent to CCL by: Kadir Diri [kadir[]visual1.chem.pitt.edu] Dear Colleagues, This might be of interest to many of you. I apologize if it was posted before by someone else. Regards, kadir ---------- Forwarded message ---------- Date: Thu, 02 Oct 2008 19:54:37 -0700 (PDT) > From: Anna Krylov To: MOLECULAR-DYNAMICS-NEWS-request%a%JISCMAIL.AC.UK Cc: Anna Krylov Subject: Gordon Research Conference and Graduate Seminar on Molecular Energy Transfer: Second announcement Apologies for crossposting. Dear Colleagues, This is the second announcement of the upcoming Gordon Research Conference on Molecular Energy Transfer (http://www-rcf.usc.edu/~krylov/grcomet2009), to be held at the Four Points Sheraton Harbortown, in Ventura California, January 18-22, 2009. In keeping with the tradition of this meeting, which alternates between the MET Gordon Conference in the US and the COMET meeting in Europe, we are organizing sessions to cover all areas of molecular energy transfer: * Chemical reactivity and reaction dynamics. * Ionized and electronically excited species. * Clusters, interfaces and the condensed phases. * Photochemistry, spectroscopy, and imaging. * Non-adiabatic, spin-forbidden, and vibronic ET. Confirmed Speakers: Confirmed Session Chairs: Millard Alexander Ara Apkarian Joel Bowman Mark Johnson Steve Bradforth Ken Jordan Piero Casavecchia Marsha Lester Robert Continetti Carl Lineberger Bob Field Anne McCoy George Flynn David Perry Benny Gerber Scott Reid Wei Kong Alec Wodtke Kevin Lehmann Kopin Liu David Nesbitt Hanna Reisler Andrei Sanov George Schatz Reinhard Schinke David Sherrill Albert Stolow Arthur Suits Arthur Utz Curt Wittig David Yarkony The conference will be preceded by a graduate and post-doctoral research seminar (GRS), a 2-day satellite meeting on January 17-18 for young people only, to amplify their participation in this Gordon conference. The GRS, first initiated at the 2005 meeting in Buellton, CA, has proven to be a great success. Professors Daniel Neumark and Alexander Benderskii have agreed to be Faculty Mentors for the GRS meeting which will be co-chaired by Anton Zadorozhny and Sarandis Marinakis. The full program, location information, history of the meeting, application instructions, and other details are available on the conference website: http://www-rcf.usc.edu/~krylov/grcomet2009/ Limited travel support for graduate students is available. Students are strongly encouraged to apply as early as possible. Note that participation in the GRS requires separate application! We are grateful to the following organizations for their financial support: Department of Energy, Office of Basic Energy Sciences Del Mar Photonics Q-Chem PCCP We are looking forward for the exciting meeting and hope to see you in Ventura! Sincerely, H. Floyd Davis Professor of Chemistry Cornell University http://www.chem.cornell.edu/hfd1 Anna I. Krylov Professor of Chemistry University of Southern California http://www-rcf.usc.edu/~krylov From owner-chemistry@ccl.net Wed Oct 8 21:19:01 2008 From: "Wenli Zou zorkzou,,gmail.com" To: CCL Subject: CCL:G: serious BUGs in Gaussian03's O3LYP and IOP Message-Id: <-37878-081008164435-9154-TCbATQXp7LPsZYB7ZF7MUg:-:server.ccl.net> X-Original-From: "Wenli Zou" Date: Wed, 8 Oct 2008 16:44:31 -0400 Sent to CCL by: "Wenli Zou" [zorkzou++gmail.com] Recently I performed O3LYP(LDA=VWN5)/cc-pVTZ test calculations for F- by using several quantum chemistry softwares. The energies are listed below. -99.698059008 PC-GAMESS -99.698055077 NWChem (*) -99.698015916 ORCA -99.811519454 Gaussian03 -100.262303658 PQS (*) O3LYP can be defined in NWChem by dft XC vwn_5 0.19 lyp 0.81 Hfexch 0.1161 slater 0.9262 OPTX 0.8133 end For OPTX functional, however, there is a bug in the source code $NWCHEM_TOP/src/nwdft/input_dft/xc_inp.F. To correct it, go to the line "xfac(2)=1.05151d0" (at about Line 288, depending on the version), replace it by "if (abs(xfac(2)).lt.1.d-4) xfac(2)=1.05151d0", and recompile it. We can see that the energies of Gaussian03 and PQS are very different from the others, which means their O3LYPs are WRONG! I noticed that some other research groups have also found the problem of Gaussian03's O3LYP. For example, see Phys. Chem. Chem. Phys., 2004, 6, 673 - 676, Tests of second-generation and third-generation density functionals for thermochemical kinetics Yan Zhao, Jingzhi Pu, Benjamin J. Lynch and Donald G. Truhlar In the paper, they could not reproduce the standard O3LYP values by using Gaussian03. Yet, according to the above tests, their final PQS-O3LYP results are also questionable. There is a temporary way to correct this BUG. In the Route Section, the parameters of the correlation functionals must be specified explicitly by IOP(3/77=0813309262), i.e., # cc-pvtz IOp(3/74=-24) IOP(3/77=0813309262) or (for Gaussian 03.c.01 and higher) # o3lyp/cc-pvtz IOP(3/77=0813309262) Then a correct energy of -99.6980592818 a.u. can be obtained. It implies that either the original parameters of Slater and/or OPTX functionals are not right, or the right parameters are changed somewhere by error. Its highly recommended to check the source code of Gaussian03, if someone has it. Whatever the case may be, the published O3LYP results by Gaussian03 are not reliable. For opt+freq computation, there is still another problem. If we define # o3lyp/cc-pvtz IOP(3/77=0813309262) opt freq we'll find that the keyword IOP(3/77=0813309262) can not be passed to the frequency calculation, so the O3LYP energy (as well as the properties) in the second step is still not right. This may be a BUG about IOP. To avoid it, the geometry optimization and frequency calculations must be performed separately, either in two jobs, or in a multi-step job. I asked some friends to help me do the tests by using several revisions of Gaussian03. For Gaussian03 b.x and c.x (and probably a.x), this correction is effective. But for Gaussian03 d.x (and probably e.x), the energies with and without IOP(3/77=0813309262) are still not right. It seems there is a new BUG in the IOP keyword since Gaussian03 d.x. B.T.W. The Gaussian03 calculations were performed on the PC-Cluster in Dept. Chem., Peking Univ. It is site licensed.