From chemistry-request@ccl.net Sat Mar 6 05:20:46 2004 Received: from smtpsal.upv.es (marfik.cc.upv.es [158.42.249.16]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id i26AKijs020051 for >ccl.net>; Sat, 6 Mar 2004 05:20:45 -0500 Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by smtpsal.upv.es (8.12.10/8.12.10) with ESMTP id i26AMRm5019454; Sat, 6 Mar 2004 11:22:27 +0100 Received: from mx2.upv.es (mx2.cc.upv.es [158.42.249.55]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id i26AMR011620; Sat, 6 Mar 2004 11:22:27 +0100 (MET) Received: from chaba.itq.upv.es (chaba.itq.upv.es [158.42.92.184]) by mx2.upv.es (8.12.10/8.12.10) with SMTP id i26AMRcn021661; Sat, 6 Mar 2004 11:22:27 +0100 Date: Sat, 6 Mar 2004 11:07:56 +0100 (CET) From: "German I. Sastre Navarro" >itq.upv.es> Reply-To: german >itq.upv.es> To: Ru-Zhen Li >qmul.ac.uk> cc: CHEMISTRY<>ccl.net Subject: Re: CCL:analyse bond length distribution? In-Reply-To: <01aa01c4024d$09d751e0$402b258a@Ruzhen> Message-ID: >chaba.itq.upv.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=7.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on servernd.ccl.net Hi, > Does anyone know any free software that can analyse geometric properties of solids? such as length distribution, angle distribution etc? > > Thank you very much in advance! > Best regards, > Ru-Zhen Try zeoTsites. Although it's for covalent oxides, little modifications in the code may render it useful. It's free (for academics) software written in fortran. Have a look to what the code was writen for at: ZeoTsites: a code for topological and crystallographic tetrahedral sites analysis in zeolites and zeotypes G. Sastre, J.D. Gale Microporous and Mesoporous Materials, 2001, 43(1), 27-40 Regards German \|/ (o o) ------------------------------------------oOO-(_)-OOo---------------- German Sastre http://www.upv.es/~gsastre Instituto de Tecnologia Quimica e-mail: gsastre<>itq.upv.es Universidad Politecnica de Valencia Phone: +34-96-387-7803 Av. Los Naranjos s/n, 46022 Valencia (Spain) Fax: +34-96-387-7809 --------------------------------------------------------------------- oo0 0oo From chemistry-request@ccl.net Sat Mar 6 11:47:15 2004 Received: from front2.chartermi.net (front2.chartermi.net [24.213.60.124]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id i26GlDjs008508 for ; Sat, 6 Mar 2004 11:47:13 -0500 Received: from [24.236.135.230] (HELO mmserver) by front2.chartermi.net (CommuniGate Pro SMTP 4.0.6) with SMTP id 288497136 for chemistry.-at-.ccl.net; Sat, 06 Mar 2004 11:48:54 -0500 Message-ID: <003b01c4039a$e88c9230$0901a8c0@mmserver> From: "Jim Kress" To: References: <16062988.1078543778225.JavaMail.gaussian.-at-.mac.com> Subject: Re: CCL:RE:CCL:New website alert Date: Sat, 6 Mar 2004 11:48:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=2.6 required=7.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.61 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on servernd.ccl.net > Our rebuttal to this self-serving collection of misrepresentations, > half-truths, and outright lies can be found at: "The lady protesteth too much, methinks". With apologies to Shakespeare ... The treatment I have received from Gaussian, and the reason I no longer use Gaussian, is consistent with that described at the website in question. Mr. Frisch may resort to denial all he wishes, however many in the community will attest to the imperious, arrogant, high-handed treatment and poor support they have received from Gaussian. Jim ----- Original Message ----- From: "Gaussian Email" To: Cc: Sent: Friday, March 05, 2004 10:29 PM Subject: CCL:RE:CCL:New website alert > Anna Krylov writes: > > > > Dear Colleagues, > > > > Since many of you are employing electronic structure calculations in your > > research, you may find the following new website that highlights certain > > issues re: ab initio software to be of some interest to you: > > > > > > http://www.bannedbygaussian.org > > > > > > Our rebuttal to this self-serving collection of misrepresentations, > half-truths, and outright lies can be found at: > > http://www.gaussian.com/libel.htm > > Michael Frisch > Gaussian, Inc. > 340 Quinnipiac St., Bldg. 40 > Wallingford, CT 06492 USA > 203-284-2501 * Fax 203-284-2521 > frisch.-at-.gaussian.com > > > > -= This is automatically added to each message by the mailing script =- > To send e-mail to subscribers of CCL put the string CCL: on your Subject: line > and send your message to: CHEMISTRY.-at-.ccl.net > > Send your subscription/unsubscription requests to: CHEMISTRY-REQUEST.-at-.ccl.net > HOME Page: http://www.ccl.net | Jobs Page: http://www.ccl.net/jobs > > If your mail is bouncing from CCL.NET domain send it to the maintainer: > Jan Labanowski, jlabanow.-at-.nd.edu (read about it on CCL Home Page) > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > From chemistry-request@ccl.net Sat Mar 6 13:09:23 2004 Received: from puck.reed.edu (puck.reed.edu [134.10.2.8]) by server.ccl.net (8.12.8/8.12.8) with SMTP id i26I9Ljs014049 for ; Sat, 6 Mar 2004 13:09:22 -0500 Received: (qmail 6303 invoked from network); 6 Mar 2004 18:11:05 -0000 Received: from rosencrantz.reed.edu (134.10.2.31) by puck.reed.edu with SMTP; 6 Mar 2004 18:11:05 -0000 Message-id: <20531793.-at-.rosencrantz.reed.edu> Date: 06 Mar 2004 10:11:06 PST From: Alan.Shusterman.-at-.directory.reed.edu (Alan Shusterman) Subject: CCL:New website alert To: chemistry.-at-.ccl.net MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=7.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on servernd.ccl.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.ccl.net id i26I9Njs014053 >Joe Leonard wrote: >Since codes can't compete on results, they have to >compete on features, price or performance. There are a >number of codes which are available for little or no money, >so price presents a problem. Features tend to be well >published, and eventually end up in many programs. This >leaves performance, perhaps the single most important >information for hardware and software vendors - benchmark >performance. Joe has identified 3 important factors people *might* consider, but my experience suggests that only the first two factors are routinely considered and *performance* is usually ignored. I have given many workshops on computational chemistry over the last few years and spoken with many dozens of college chemistry teachers and researchers. Invariably, the workshop attendees always want to discuss possible software purchases with me ("what do you use?" is a common question). It turns out that they care a great deal about price (very important if you have to buy a program 20x to cover a lab) and features (but only important in a threshold sense). They never ask about performance. So it seems that Joe's big three decline in importance: threshold features > price >> performance. This might represent a lack of sophistication on their part, or just the opposite: we have learned over the past decade that performance (especially on a personal computer) is poorly defined. If someone is considering a purchase, I'd encourage them to also think about ease-of-use, customer support, documentation, reliability, and so on. Caveat emptor! -Alan ==== Alan Shusterman Department of Chemistry Reed College 3203 S.E. Woodstock Blvd. Portland, OR 97202-8199 503-517-7699 From chemistry-request@ccl.net Sat Mar 6 13:37:03 2004 Received: from jeeves.ccdc.cam.ac.uk (jeeves.ccdc.cam.ac.uk [131.111.113.44]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id i26Ib2js015823 for ; Sat, 6 Mar 2004 13:37:03 -0500 Received: from sun14.ccdc.cam.ac.uk ([131.111.113.48] helo=ccdc.cam.ac.uk) by jeeves.ccdc.cam.ac.uk with esmtp (Exim 3.35 #1 (CCDC Mailserver)) id 1AzghA-0005tX-00; Sat, 06 Mar 2004 18:38:44 +0000 Message-ID: <404A1AB4.1EB5B3DB~at~ccdc.cam.ac.uk> Date: Sat, 06 Mar 2004 18:38:44 +0000 From: Jacco van de Streek Organization: CCDC X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andras.Borosy~at~givaudan.com CC: chemistry~at~ccl.net Subject: Re: CCL:software evaluation / validation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CCDC-MailScanner: Not scanned: please contact syseng for details. X-CCDC-SpamCheck: X-Spam-Status: No, hits=0.0 required=7.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on servernd.ccl.net Andras.Borosy~at~givaudan.com wrote: > I agree with the first part, which is indeed a _VERY_ important point: > "The main criterion of scientific work is reproducibility." > However, my question about this would be: > How is it possible to reproduce scientific results obtained by commercial > _OR_ academic software which relies on _RANDOM_ methods ? Hi, I happen to work on a program that uses random numbers (to solve crystal structures from X-ray powder data) and I think that reproducibility is not an issue, at least not in the sense you are referring to. Because it is a random process, users of such programs would not run them just once, as the single outcome of a random event is meaningless. Instead, our program by default runs the simulated annealing run ten times (with different seeds for the random number generators). It is now the reproducibility (the statistical distribution of solutions) itself that should be reproducible. The fact that two different runs give two different results can actually be used to validate the random method and its solutions (within the limitations of the program, input data and input model). For example, if the ten runs give 8 identical solutions, with a figure of merit that is better than the other two runs, one can be fairly confident that the "global" minimum was found (within the limitations of the program, input data and input model). The two other runs are also interesting: are they two wildly different solutions with similar figures of merit that are significantly worse than the 8 better solutions? If the other two solutions are identical and have good figures of merit, is there a strong similarity between them and the eight better solutions? If less than five similar solutions were obtained (in ten runs), with siginificantly better figures of merit, this points to a problem with the search space, and more exhaustive runs should be run. If several wildly different solutions are found, with similar figures of merit, either there is a problem with the search space (the global minimum has not been found yet), or the model does not fit the data unambiguously (essentially an error in the input, be it the data or the model). Of course, in the publication all runs and their results (even if only in general terms) should be mentioned. Best wishes, -- Jacco van de Streek Research Scientist Cambridge Crystallographic Data Centre Cambridge, United Kingdom From chemistry-request@ccl.net Sat Mar 6 08:52:42 2004 Received: from eos.fwall.u-szeged.hu (eos.fwall.u-szeged.hu [160.114.120.248]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id i26Dqdjs031072 for ; Sat, 6 Mar 2004 08:52:40 -0500 Received: from localhost ([127.0.0.1] helo=eos.fwall.u-szeged.hu) by eos.fwall.u-szeged.hu with smtp (Exim 4.24) id 1AzcG0-0004EU-GY for chemistry~at~ccl.net; Sat, 06 Mar 2004 14:54:24 +0100 Received: from eos.fwall.u-szeged.hu ([127.0.0.1]) by eos.fwall.u-szeged.hu (SAVSMTP 3.0.0.44) with SMTP id M2004030614542407214 for ; Sat, 06 Mar 2004 14:54:24 +0100 Received: from mail.szote.u-szeged.hu ([160.114.96.63]) by eos.fwall.u-szeged.hu with esmtp (Exim 4.30) id 1AzcG0-0004EP-6R for chemistry~at~ccl.net; Sat, 06 Mar 2004 14:54:24 +0100 Received: from ovrisc.mdche.u-szeged.hu (IDENT:qmailr~at~ovrisc.mdche.u-szeged.hu [160.114.101.224]) by mail.szote.u-szeged.hu (8.9.3/8.8.7) with SMTP id OAA32699 for ; Sat, 6 Mar 2004 14:54:22 +0100 Received: (qmail 18488 invoked by uid 525); 6 Mar 2004 13:54:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Mar 2004 13:54:22 -0000 Date: Sat, 6 Mar 2004 14:54:22 +0100 (CET) From: "Dr. Csaba Hetenyi" To: Andras.Borosy~at~givaudan.com cc: chemistry~at~ccl.net, Computational Chemistry List Subject: Re: CCL:software evaluation / validation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SZTE-local: YES X-SZTE-AVcheck: YES X-Spam-Status: No, hits=0.0 required=7.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on servernd.ccl.net Hi, > Source code is not necessary for testing or validation. It is only > necessary if you want to modify, enhance, integrate, build onto an existing code > base. I mean, it is necessary for correct documentation. Obviously, a paper cannot include all (computational) details of a new program or methodology. The source code could serve as an "appendix" in this case. The users should have the right to check the details (source=appendix). > I agree with the first part, which is indeed a _VERY_ important point: > "The main criterion of scientific work is reproducibility." > However, my question about this would be: > How is it possible to reproduce scientific results obtained by commercial > _OR_ academic software which relies on _RANDOM_ methods ? > (e.g. GOLD, AutoDock, ICM-dock etc. employ random methods). Many of these methods are based on global search strategies including Monte Carlo, Genetic algorithm, etc. As these algorithms include random number generations, the test of these methods could be done statistically, i.e. you make several trials and check if you got acceptable results or not. (Statistical test is the ONLY possibility to check the reliability of such randomized methods.) --- As docking is a relatively "new" tool among other computational methods, there is a lot to be done in testing and improving the technique and also the search strategies. Despite its novelty and many simplifications included, this technique provide surprisingly good results in many cases. In my view, computational (modelling) work, like docking should be reproducible, otherwise we cannot expect experimental scientists to collaborate us and trust our results. In case of docking, e.g. the statistical reproducibility of structural fit (RMSD) is a precise test of the method. Best wishes, Csaba