From chemistry-request@ccl.net Fri Nov 28 02:41:51 2003 Received: from smtp2.ruc.dk (smtp2.ruc.dk [130.225.220.22]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hAS7fKNL028524 for ; Fri, 28 Nov 2003 02:41:20 -0500 Received: by smtp2.ruc.dk (Postfix, from userid 504) id 95AD818741F7; Fri, 28 Nov 2003 08:40:50 +0100 (CET) Received: from virgil.ruc.dk (virgil.ruc.dk [130.225.220.110]) by smtp2.ruc.dk (Postfix) with ESMTP id 47BE418741E6; Fri, 28 Nov 2003 08:40:47 +0100 (CET) Received: from VIRGIL/SpoolDir by virgil.ruc.dk (Mercury 1.47); 28 Nov 03 08:40:47 +0100 Received: from SpoolDir by VIRGIL (Mercury 1.47); 28 Nov 03 08:40:46 +0100 From: "Jens Spanget-Larsen" Organization: Roskilde Universitetscenter To: "David Danovich" Date: Fri, 28 Nov 2003 08:40:31 +0100 Subject: Re: CCL:g98 - dipole moment Reply-To: spanget_at_ruc.dk Cc: Chemistry_at_ccl.net Message-ID: <3FC70A07.32096.1493C87D@localhost> Priority: normal In-reply-to: <017a01c3b4e4$ac9a1c70$2a624084_at_ch.huji.ac.il> X-mailer: Pegasus Mail for Windows (v4.01) X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Report: X-Spam-Status: No, hits=-1.0 required=7.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: Dear David, the dipole moment printed in the last part of the output file is in atomic units: 1 a.u. = e a0 = elementary charge times Bohr radius: 1 Debye = 10^(-18) esu cm = 3.3356 10^(-30) C m = 0.3934 e a0 Yours, Jens >--< "David Danovich" > In the Gaussian output file there is information which related to > dipole moment > > Dipole moment (Debye): > X= 0.0000 Y= 0.0000 Z= -2.8469 Tot= 2.8469 > > > as well as some information in the end of output file > > Version=DEC-AXP-OSF/1-G98RevA.7\State=1-A1\HF=-113.8636997\RMSD=8.275 > e -05\Dipole=0.,0.,-1.1200326\PG=C02V [C2(C1O1),SGV(H2)]\\@ > > with some information about dipole. > > What this last dipole means? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JENS SPANGET-LARSEN Office: +45 4674 2710 Department of Chemistry Fax: +45 4674 3011 Roskilde University (RUC) Mobile: +45 2320 6246 P.O.Box 260 E-Mail: spanget_at_ruc.dk DK-4000 Roskilde, Denmark http://virgil.ruc.dk/~spanget =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From chemistry-request@ccl.net Thu Nov 27 12:52:38 2003 Received: from mailgate.tripos.com (mailgate.tripos.com [192.160.145.7]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hARHq6NL002001 for ; Thu, 27 Nov 2003 12:52:06 -0500 Message-ID: From: "Paul Hawkins" To: "Christoph Nimptsch" , Date: Thu, 27 Nov 2003 12:50:33 -0500 Subject: RE: Free software on CoMFA MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 In-Reply-To: <200311271400.19548.christoph.nimptsch{at}uni-tuebingen.de> Importance: Normal X-Spam-Status: No, hits=-0.4 required=7.0 tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,PRIORITY_NO_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hello all, As I noted in a response to the original question Tripos does indeed hold patents on the use of PLS and similar techniques to derive QSAR's based on grid-based fields around molecule sets. These patents are in force until 2007 and would prevent use of separate pieces of freeware that generate GRID-type maps and subsequently perform PLS on this data versus activity. So, to echo Christoph's caution do not use separate pieces of software to do this sort of task. If you wish to use the CoMFA approach then please contact your local Tripos sales representative. Paul Hawkins Applications Scientist Tripos Inc 1699 South Hanley Road St. Louis MO 63144 Ph: 617-899-4151 E-mail: phawkins{at}tripos.com www.tripos.com -----Original Message----- From: Computational Chemistry List [mailto:chemistry-request{at}ccl.net]On Behalf Of Christoph Nimptsch Sent: Thursday, November 27, 2003 8:00 AM To: chemistry{at}ccl.net Subject: CCL:Free software on ComFA Hello, as far as I know, Tripos has a patent for using GRID-maps (www.moldiscovery.com) with general PLS regression techniques. Am I right? So be careful not to violate this patent with free software. Christoph ------------------------------------------ Christoph Nimptsch Apotheker Pharmazeutisches Institut Arbeitskreis Prof. Kovar Universitdt T|bingen Auf der Morgenstelle 8 D-72076 Tuebingen Tel.: 07071 / 29 73047 Fax.: 07071 / 29 2470 mailto:christoph.nimptsch{at}uni-tuebingen.de ------------------------------------------ -= 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, jkl{at}ccl.net (read about it on CCL Home Page) -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From chemistry-request@ccl.net Fri Nov 28 07:39:54 2003 Received: from dedalus.lcc.ufmg.br (dedalus.lcc.ufmg.br [150.164.65.10]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hASCdINL004205 for ; Fri, 28 Nov 2003 07:39:23 -0500 Received: from dedalus.lcc.ufmg.br (loopback [127.0.0.1]) by dedalus.lcc.ufmg.br (8.12.8p1/8.12.8) with ESMTP id hASCdDnE032260; Fri, 28 Nov 2003 10:39:13 -0200 Received: from localhost (amolive@localhost) by dedalus.lcc.ufmg.br (8.12.8p1/8.12.8/Submit) with ESMTP id hASCdBqj034418; Fri, 28 Nov 2003 10:39:12 -0200 Date: Fri, 28 Nov 2003 10:39:11 -0200 (BDB) From: andre mauricio de oliveira X-X-Sender: amolive@dedalus To: Christoph Nimptsch cc: chemistry_at_ccl.net Subject: Re: CCL:Free software on ComFA In-Reply-To: <200311271400.19548.christoph.nimptsch_at_uni-tuebingen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=7.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Dear Dr Christoph, In fact, Tripos has been granted such rights to use GRID maps for CoMFA, but SOMFA uses a different methodology to define them (by the attribution of 1 or 0 tags to points located in or out the target's van der waals raddi on the grid, instead of absolute interaction energies employed in CoMFA. Results are somehow similar to CoMFA predictions. Best wishes. On Thu, 27 Nov 2003, Christoph Nimptsch wrote: > Hello, > > as far as I know, Tripos has a patent for using GRID-maps > (www.moldiscovery.com) with general PLS regression techniques. > > Am I right? > > So be careful not to violate this patent with free software. > > Christoph > > ------------------------------------------ > Christoph Nimptsch > Apotheker > Pharmazeutisches Institut > Arbeitskreis Prof. Kovar > Universitdt T|bingen > Auf der Morgenstelle 8 > D-72076 Tuebingen > Tel.: 07071 / 29 73047 > Fax.: 07071 / 29 2470 > mailto:christoph.nimptsch_at_uni-tuebingen.de > ------------------------------------------ > > > > > -= 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, jkl_at_ccl.net (read about it on CCL Home Page) > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Andre Mauricio de Oliveira VOICE +55-031-374-1325 +55-031-499-5765 FAX +55-031-499-5700 Laboratorio de QSAR e Modelagem Molecular Nucleo de Estudos em Quimica Medicinal (NEQUIM) NEQUIM's Homepage: http://www.qui.ufmg.br/~nequim Departamento de Quimica ICEx Federal University of Minas Gerais Av Antonio Carlos 6627 Pampulha ZIP CODE 31270-901 Belo Horizonte MG Brazil From chemistry-request@ccl.net Thu Nov 27 19:45:23 2003 Received: from ns1.scripps.edu (ns1.scripps.edu [192.42.82.59]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hAS0ipNL013981 for ; Thu, 27 Nov 2003 19:44:52 -0500 Received: from antigen.scripps.edu (antigen.scripps.edu [137.131.200.100]) by ns1.scripps.edu (8.11.7/TSRI-4.2rx) with SMTP id hAS0ipP12740 for ; Thu, 27 Nov 2003 16:44:51 -0800 (PST) Received: from relay2.scripps.edu(137.131.200.30) by antigen.scripps.edu via csmap id 2002; Thu, 27 Nov 2003 16:39:53 -0800 (PST) Received: from klee.scripps.edu (klee [137.131.252.148]) by relay2.scripps.edu (8.11.7/TSRI-4.4.1rAVB) with ESMTP id hAS0ipR26559 for ; Thu, 27 Nov 2003 16:44:51 -0800 (PST) Received: by klee.scripps.edu (Postfix, from userid 11465) id CD45C2E856; Thu, 27 Nov 2003 16:44:50 -0800 (PST) Date: Thu, 27 Nov 2003 16:44:50 -0800 From: Craig Shepherd To: chemistry_at_ccl.net Subject: disspative particle dynamics Message-ID: <20031128004450.GA8993_at_klee.scripps.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-2.5 required=7.0 tests=USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi CCLers, I'm looking for a software package to carry out dissipative particle dynamics (DPD). I'm sure there a quite a few out there. Does anyone have any recommendations? Many thanks, Craig Shepherd -- ____________________________________ Craig Shepherd, PhD The Scripps Research Institute 10550 North Torrey Pines Road, TPC-6 La Jolla, CA 92037 Tel: (858) 784-7308 email: shepherd_at_scripps.edu ____________________________________ From chemistry-request@ccl.net Fri Nov 28 11:23:20 2003 Received: from smtp4.dti.ne.jp (smtp4.dti.ne.jp [202.216.228.39]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hASGMlNL014028 for ; Fri, 28 Nov 2003 11:22:49 -0500 Received: from oemcomputer (PPP41.fukuoka-ip.dti.ne.jp [211.132.92.41]) by smtp4.dti.ne.jp (3.08s) with SMTP id hASGMhrL018249 for ; Sat, 29 Nov 2003 01:22:45 +0900 (JST) Message-ID: <006101c3b5ca$daf4bf80$295c84d3@oemcomputer> From: "Telkuni" To: References: <004701c3b2e1$b370b680$695c84d3@oemcomputer> Subject: Summary) CCL:"%mem" trouble of Gaussian Date: Sat, 29 Nov 2003 01:15:34 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.5 required=7.0 tests=REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hello, CCLers. I had sent a question of "%mem=xxx" on Gaussian98W a few days ago. ---------- Original Question ------------- >I've met curios phenomenon with G98W_ver.A7. However I modified the >PC's memory "%mem=128MB" to "%mem=512MB" on same calculation, >there was very little calc time difference between them(57min and 64 min!) > >If anyone met same phenomenon, please let me know. >All responses, I will appreciate. And I will summarize them. In general, each calculation type has each suitable memory size. If the memory is excess or insufficent on optimization, spreed-up is unexpectable(but for excited states calc and frequency calc). Here are replies that I have received. Thanks a lot! --- 1) from Lorant Janosi ---- Hi! I know what you mean. I noticed that gaussian tends to use up all physical memory given as parameter in the %Mem section. This may prolongue your time execution (like in your case) if the calculation does not require that much amount of memory. I would recommend a few test runs to see what would be the optimimum memory required. There is also a formula given by the manual for the memory requirement, but, honestely, I don't really trust it. But it's a good starting point for test runs. All the best, Lori. Lorant Janosi Department of Physics and Astronomy University of Missouri-Columbia email: lj8q5:at:mizzou.edu --- 2) from Matt Zwier ---- Telkuni, I ran a similar test several days ago. The impact of available memory depends strongly on the size of the job you're running. If you have enough RAM to store all AO integrals for SCF in 128MB, then 512MB will likely not run faster, if at all. If you can fit 90% of the AO integrals in 128MB, then you'll see a greater, but not amazing, speed gain when going up in RAM. If you can only fit 30% of your AO integrals in 128MB, you'll see a BIG speed increase when you get to 512MB. Matt Zwier Hope College --- 3) from Igor Avilov ---- Hello, Telkuni! You must always try to allocate as much memory as Gaussian needs, no more. If you will allocate much more memory than it needs, the calculation will slow down. I do not know why, but the fact is - it will slow down. In Linux (Unix) and Windows NT you can always see how much memory Gaussian is actually using. For geometry optimization you don't need much memory. On the contrary, for excited states calculation and frequency calculation you will need lots of memory. Its amount depends, of cause, on the size of your system. Best regards, Igor Avilov. --- 4) from Laurence Cuffe ---- I've not used g98W however my experience with g94 and g98 rev A7 and rev A11 would be similar to yours. In general once a calculation has adequate RAM adding more via a %mem directive rarely makes much difference and can (perversely) slow down a calculation where the operating system has to throw out other processes to get a large RAM image into memory. There are exceptions for instance if you can get an entire calculation into ram using a large %Mem and the directive scf=(incore,nosave) then the calculation can be scary fast! however this opportunity occurs rarely. On a related subject very occasionally calculations have failed with a "malloc" error indicating that they have not got sufficient ram. I have found that this error is often resolved by either increasing or decreasing the %Mem amount by a small amount, indicating that the program occasionally miscalculates the amount of memory available by a small amount and a small change in the memory allocation can fit it in. Hope this helps All the best Laurence cuffe --- 5) from Pierre Vitorge ---- I had similar problems. I run tests with different values for %mem, it seems there is an optimum %mem value to obtain the shortest CPU time, this optimum value is usually far from the maximum reasonable value (i.e the amount of physical memory minus 150to300Mb for the system). This probably depends (among other reasons) on the size of the exchange file memory, and whether this file is at the begining of the disk. I asked help to Gaussian, but did not get any answer. Pierre Vitorge CEA DEN Saclay DPC/SECR/LSRM & UMR 8587 (CEA-Universite d'Evry-CNRS) Bat.391 Pe.40a 91191 Gif sur Yvette cedex France tel.(+33) 169-08-32-65, secr.: (+33)169-08-32-50, fax:(+33)169-08-32-42 http://perso.club-internet.fr/vitorgen/pierre --- 6) from David Shobe ---- Telkuni, If the program cannot advantageously use the additional memory, then increasing %mem has no effect. However, if the additional memory allows Gaussian to store an array in memory that would otherwise have been stored on disk, increasing %mem will significantly shorten the time needed for the calculation. Also, some jobs may not be able to run at all if insufficient memory is allocated with %mem. Hope this helps, --David Shobe, Ph.D., M.L.S. S|d-Chemie, Inc. phone (502) 634-7409 fax (502) 634-7724 ---------------------------------------------------- Telkuni Tsuru telkuni:at:venus.dti.ne.jp From chemistry-request@ccl.net Fri Nov 28 11:37:07 2003 Received: from smtp4.dti.ne.jp (smtp4.dti.ne.jp [202.216.228.39]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hASGaZNL014622 for ; Fri, 28 Nov 2003 11:36:35 -0500 Received: from oemcomputer (PPP41.fukuoka-ip.dti.ne.jp [211.132.92.41]) by smtp4.dti.ne.jp (3.08s) with SMTP id hASGaVrL018719 for ; Sat, 29 Nov 2003 01:36:33 +0900 (JST) Message-ID: <009301c3b5cc$c8ade020$295c84d3@oemcomputer> From: "Telkuni" To: Subject: Complete Summary) CCL:"%mem" trouble of Gaussian Date: Sat, 29 Nov 2003 01:29:23 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=3.0 required=7.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hello, CCLers. The summary mail which I've sent a few minutes before was not complete version. Sorry! I had sent a question of "%mem=xxx" on Gaussian98W a few days ago. ---------- Original Question ------------- >I've met curios phenomenon with G98W_ver.A7. However I modified the >PC's memory "%mem=128MB" to "%mem=512MB" on same calculation, >there was very little calc time difference between them(57min and 64 min!) > >If anyone met same phenomenon, please let me know. >All responses, I will appreciate. And I will summarize them. In general, each calculation type has each suitable memory size. If the memory is excess or insufficent on optimization, spreed-up is unexpectable(but for excited states calc and frequency calc). Here are replies that I have received. Thanks a lot! --- 1) from Lorant Janosi ---- Hi! I know what you mean. I noticed that gaussian tends to use up all physical memory given as parameter in the %Mem section. This may prolongue your time execution (like in your case) if the calculation does not require that much amount of memory. I would recommend a few test runs to see what would be the optimimum memory required. There is also a formula given by the manual for the memory requirement, but, honestely, I don't really trust it. But it's a good starting point for test runs. All the best, Lori. Lorant Janosi Department of Physics and Astronomy University of Missouri-Columbia email: lj8q5:at:mizzou.edu --- 2) from Matt Zwier ---- Telkuni, I ran a similar test several days ago. The impact of available memory depends strongly on the size of the job you're running. If you have enough RAM to store all AO integrals for SCF in 128MB, then 512MB will likely not run faster, if at all. If you can fit 90% of the AO integrals in 128MB, then you'll see a greater, but not amazing, speed gain when going up in RAM. If you can only fit 30% of your AO integrals in 128MB, you'll see a BIG speed increase when you get to 512MB. Matt Zwier Hope College --- 3) from Igor Avilov ---- Hello, Telkuni! You must always try to allocate as much memory as Gaussian needs, no more. If you will allocate much more memory than it needs, the calculation will slow down. I do not know why, but the fact is - it will slow down. In Linux (Unix) and Windows NT you can always see how much memory Gaussian is actually using. For geometry optimization you don't need much memory. On the contrary, for excited states calculation and frequency calculation you will need lots of memory. Its amount depends, of cause, on the size of your system. Best regards, Igor Avilov. --- 4) from Laurence Cuffe ---- I've not used g98W however my experience with g94 and g98 rev A7 and rev A11 would be similar to yours. In general once a calculation has adequate RAM adding more via a %mem directive rarely makes much difference and can (perversely) slow down a calculation where the operating system has to throw out other processes to get a large RAM image into memory. There are exceptions for instance if you can get an entire calculation into ram using a large %Mem and the directive scf=(incore,nosave) then the calculation can be scary fast! however this opportunity occurs rarely. On a related subject very occasionally calculations have failed with a "malloc" error indicating that they have not got sufficient ram. I have found that this error is often resolved by either increasing or decreasing the %Mem amount by a small amount, indicating that the program occasionally miscalculates the amount of memory available by a small amount and a small change in the memory allocation can fit it in. Hope this helps All the best Laurence cuffe --- 5) from Pierre Vitorge ---- I had similar problems. I run tests with different values for %mem, it seems there is an optimum %mem value to obtain the shortest CPU time, this optimum value is usually far from the maximum reasonable value (i.e the amount of physical memory minus 150to300Mb for the system). This probably depends (among other reasons) on the size of the exchange file memory, and whether this file is at the begining of the disk. I asked help to Gaussian, but did not get any answer. Pierre Vitorge CEA DEN Saclay DPC/SECR/LSRM & UMR 8587 (CEA-Universite d'Evry-CNRS) Bat.391 Pe.40a 91191 Gif sur Yvette cedex France tel.(+33) 169-08-32-65, secr.: (+33)169-08-32-50, fax:(+33)169-08-32-42 http://perso.club-internet.fr/vitorgen/pierre --- 6) from David Shobe ---- Telkuni, If the program cannot advantageously use the additional memory, then increasing %mem has no effect. However, if the additional memory allows Gaussian to store an array in memory that would otherwise have been stored on disk, increasing %mem will significantly shorten the time needed for the calculation. Also, some jobs may not be able to run at all if insufficient memory is allocated with %mem. Hope this helps, --David Shobe, Ph.D., M.L.S. S|d-Chemie, Inc. phone (502) 634-7409 fax (502) 634-7724 --- 7) from Sigismondo Boschi ---- Hi, what kind of computation? In SCF memory is not used over a certain limit, and using more is just an overhead. For post-scf computations more memory makes a huge difference (in the sense of improving the performance). Regards, Sigismondo Boschi >>from Telkuni Hello, Dr.Boschi. Thank you for your reply. It is Opt --> Freq (# B3LYP/6-31G Opt Freq) calculation applying to hydrogen bonded two molecles. CPU times are about (Opt by 512MB)35min and (Opt by 128MB)39min, (both Freq)18 min. As you wrote, memory differnce doesn't act on SCF(opting, and freq?). --- 8) from Toomas Tamm ---- On Tue, Nov 25, 2003 at 03:55:44PM +0100, VITORGE Pierre 094605 wrote: > I had similar problems. I run tests with different values for %mem, it seems > there is an optimum %mem value to obtain the shortest CPU time, this optimum > value is usually far from the maximum reasonable value (i.e the amount of > physical memory minus 150to300Mb for the system). This probably depends > (among other reasons) on the size of the exchange file memory, and whether > this file is at the begining of the disk. I asked help to Gaussian, but did > not get any answer. There exists a hypothesis that with today's fast CPU's it is better to re-calculate some integrals in the CPU rather than store and read them > from memory. Integrals are accessed rather randomly and the CPU cannot cache them effectively. A cache miss can cost several tens of CPU cycles while the value is fetched from RAM. It may be faster to re-calculate a simple integral. Thus the calculation is faster if there is less memory available, since this forces the program to re-calculate integrals rather than store them. Can someone with intricate knowledge of modern CPUs and integral calculation algorithms tell if this is true? -- Toomas Tamm e-mail: tt-ccl:at:kky.ttu.ee Chair of Inorganic Chemistry voice: INT+372-620-2810 Tallinn Technical University fax: INT+372-620-2020 Ehitajate tee 5, EE-19086 Tallinn, Estonia http://www.kk.ttu.ee/toomas/ ---------------------------------------------------- Telkuni Tsuru telkuni:at:venus.dti.ne.jp From chemistry-request@ccl.net Fri Nov 28 06:12:51 2003 Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hASBCINL001638 for ; Fri, 28 Nov 2003 06:12:18 -0500 Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 659FA6C738; Fri, 28 Nov 2003 12:12:17 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 25FF65B644; Fri, 28 Nov 2003 12:12:17 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 06E165B5CE; Fri, 28 Nov 2003 12:12:17 +0100 (CET) Received: from imap.uni-wuerzburg.de (wrzx31.rz.uni-wuerzburg.de [132.187.3.31]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B97056C737; Fri, 28 Nov 2003 12:12:16 +0100 (CET) Received: from localhost (wrzx32.rz.uni-wuerzburg.de [132.187.3.32]) by imap.uni-wuerzburg.de (Postfix) with ESMTP id A56B154D; Fri, 28 Nov 2003 12:12:16 +0100 (CET) Received: from 132.187.70.199 ( [132.187.70.199]) as user phar072@132.187.3.41 by webmail.uni-wuerzburg.de with HTTP; Fri, 28 Nov 2003 12:12:16 +0100 Message-ID: <1070017936.3fc72d9096bdf:at:webmail.uni-wuerzburg.de> Date: Fri, 28 Nov 2003 12:12:16 +0100 From: Nikolaus Stiefl To: Christoph Nimptsch Cc: chemistry:at:ccl.net Subject: Re: CCL:Free software on ComFA References: <200311271400.19548.christoph.nimptsch:at:uni-tuebingen.de> In-Reply-To: <200311271400.19548.christoph.nimptsch:at:uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 132.187.70.199 X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) X-Spam-Status: No, hits=-2.3 required=7.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_IMP version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.ccl.net id hASBCpNL001648 Hi, I think Christoph is right in so far, that you are not allowed to combine GRID maps and PLS techniques in the same package. However, if you seperate the two (i.e. GRID and GOLPE) you shouldn't have any problems. Nevertheless you might want to check that with the people from moldiscovery. Nik Zitat von Christoph Nimptsch : > Hello, > > as far as I know, Tripos has a patent for using GRID-maps > (www.moldiscovery.com) with general PLS regression techniques. > > Am I right? > > So be careful not to violate this patent with free software. > > Christoph > > ------------------------------------------ > Christoph Nimptsch > Apotheker > Pharmazeutisches Institut > Arbeitskreis Prof. Kovar > Universitdt T|bingen > Auf der Morgenstelle 8 > D-72076 Tuebingen > Tel.: 07071 / 29 73047 > Fax.: 07071 / 29 2470 > mailto:christoph.nimptsch:at:uni-tuebingen.de > ------------------------------------------ > > > > > -= 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, jkl:at:ccl.net (read about it on CCL Home Page) > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > _____________________________ Nikolaus Stiefl Ph.D. student Chemometrics and Drug Design University Wuerzburg Dept. of Pharmacy Am Hubland D-97074 Wuerzburg Germany Phone: +49 - 931 8885473 From chemistry-request@ccl.net Thu Nov 27 22:06:47 2003 Received: from mx3.ust.hk (mx3.ust.hk [143.89.13.11]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hAS36ENL018136 for ; Thu, 27 Nov 2003 22:06:15 -0500 Received: from ust.hk (sqmail4.ust.hk [143.89.15.14]) by mx3.ust.hk (8.12.10/8.12.10) with SMTP id hAS3661p098178 for ; Fri, 28 Nov 2003 11:06:11 +0800 (HKT) Received: from 143.89.188.7 (SquirrelMail authenticated user chgy) by sqmail.ust.hk with HTTP; Fri, 28 Nov 2003 11:06:11 +0800 (HKT) Message-ID: <41707.143.89.188.7.1069988771.squirrel:at:sqmail.ust.hk> Date: Fri, 28 Nov 2003 11:06:11 +0800 (HKT) Subject: Could I compute ORD using Gaussian program? From: "GAO Yi" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=7.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Dear CClers, Would you kindly tell me whethter Gaussian program (98 or 03) compute the optical rotatory dispersion spectra directly? If yes, how should I do? I only know Gaussian03 can compute the CD spectra. Best Yi Gao Department of Chemistry, HKUST From chemistry-request@ccl.net Fri Nov 28 15:45:31 2003 Received: from smtp4.dti.ne.jp (smtp4.dti.ne.jp [202.216.228.39]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hASKixNL021681 for ; Fri, 28 Nov 2003 15:45:00 -0500 Received: from oemcomputer (PPP42.fukuoka-ip.dti.ne.jp [211.132.92.42]) by smtp4.dti.ne.jp (3.08s) with SMTP id hASKisrL023887 for ; Sat, 29 Nov 2003 05:44:58 +0900 (JST) Message-ID: <001c01c3b5ef$7b28f9c0$2a5c84d3@oemcomputer> From: "Telkuni" To: Subject: CCL: AMBER is MM or MD? Date: Sat, 29 Nov 2003 05:37:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=3.5 required=7.0 tests=RCVD_IN_OSIRUSOFT_COM,X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hello, CCLers. Although I think it is very basic knowledge, I want to know the truth. Some papers and books treat AMBER as Molecular Mechanic method describing with force fields and bonding parameters. But others treat AMBER as Molecular Dynamic method describing with potential functions. Does AMBER belong MM or MD? and or both of them? ...All responses, I will appreciate. And I will summarize them. Sincerely yours, ---------------------------------------------------- Telkuni Tsuru telkuni$at$venus.dti.ne.jp From chemistry-request@ccl.net Thu Nov 27 14:08:41 2003 Received: from denver065.server4free.de (leitl.org [217.172.178.65]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hARJ8ANL003842 for ; Thu, 27 Nov 2003 14:08:10 -0500 Received: by denver065.server4free.de (Postfix, from userid 500) id D68833A80DF; Thu, 27 Nov 2003 20:08:09 +0100 (CET) Date: Thu, 27 Nov 2003 20:08:09 +0100 From: Eugen Leitl To: Christoph Nimptsch Cc: chemistry)at(ccl.net Subject: Re: CCL:Free software on ComFA Message-ID: <20031127190809.GJ15515)at(leitl.org> References: <200311271400.19548.christoph.nimptsch)at(uni-tuebingen.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F4+N/OgRSdC8YnqX" Content-Disposition: inline In-Reply-To: <200311271400.19548.christoph.nimptsch)at(uni-tuebingen.de> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-6.2 required=7.0 tests=EMAIL_ATTRIBUTION,HTML_00_10,HTML_MESSAGE,IN_REP_TO, PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) --F4+N/OgRSdC8YnqX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 27, 2003 at 02:00:19PM +0100, Christoph Nimptsch wrote: > Hello, >=20 > as far as I know, Tripos has a patent for using GRID-maps=20 > (www.moldiscovery.com) with general PLS regression techniques. =20 There are no software patents approved in the EU. At least not yet. =20 > Am I right? >=20 > So be careful not to violate this patent with free software. I'm not sure the open source community should concern themselves=20 with IP issues. No validation nor research on prior art is done by the patent office attorneys, so as a direct consequence most patents are frivolous in nature, and their number is directly proportional to the financial resources of the claimant. Ditto enforcement: commercial entities win by virtue of larger resources. Witness latest SCO vs. GNU/Linux charade. It is certainly possible to release digitally signed code anonymously, should legal pressure become a real threat, so IP isn't really strictly enforcible anyway. Are there at all documented intellectual property issues with open source software in computational chemistry context?=20 =20 -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/xkuZdbAkQ4sp9r4RAiXlAJ9jXL0rMsCayENfWUerjITcgMsiXgCfVYXU ctElPS9o9gGIYB6HNWGII7U= =jVyZ -----END PGP SIGNATURE----- From chemistry-request@ccl.net Fri Nov 28 13:02:39 2003 Received: from lgdx04.lg.ehu.es (lgdx04.lg.ehu.es [158.227.1.36]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id hASI26NL018358 for ; Fri, 28 Nov 2003 13:02:07 -0500 Received: by lgdx04.lg.ehu.es id TAA0000017450; Fri, 28 Nov 2003 19:02:05 +0100 (MET) Message-ID: <008f01c3b5d9$bb808a80$222fe39e^at^lc.ehu.es> From: "Pablo Vitoria" To: "CCL" Subject: Summary: Gaussian03 Binary vs. Source Date: Fri, 28 Nov 2003 19:02:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01C3B5E2.1D2B01E0" 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.7 required=7.0 tests=HTML_40_50,HTML_MESSAGE,NO_EXPERIENCE version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) This is a multi-part message in MIME format. ------=_NextPart_000_008C_01C3B5E2.1D2B01E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, First, thanks a lot to Jos=E9 A. L=F3pez, Christoph van W=FCllen, = Salvador Blaya Escarre, Mathias Weigt and Jos=E9 A. L=F3pez for their = help and comments. The conclusion is: - It is possible to compile G03 with ifc. Quote: "It is not too = difficult to get it running with that compiler. If you have no = experience with editing Makefiles and so on, you might have a problem." - G03 rev. B.04 does not compile with the last version (5) of Portland = compiler, and this is supossed to be corrected in the next revision. So I will buy the source and give it a try. Pablo -------------------------------------------------------- Pablo Vitoria Garcia Dpto. Qu=EDmica Inorg=E1nica, Facultad de Ciencias Universidad del Pa=EDs Vasco (UPV/EHU) Aptdo. 644 48080 Bilbao (Bizkaia) Tfno. 94 6015992 Fax. 94 4648500 ------=_NextPart_000_008C_01C3B5E2.1D2B01E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
First, thanks a lot to Jos=E9 A. = L=F3pez, Christoph van=20 W=FCllen, Salvador Blaya Escarre, Mathias Weigt and Jos=E9 A. L=F3pez = for their help=20 and comments.
 
The conclusion is:
- It is possible to compile G03 with = ifc. Quote:=20 "It is not too difficult to get = it running=20 with that compiler. If you have no experience with editing Makefiles and = so on,=20 you might
have a problem."
 
- G03 rev. B.04 does not compile = with the=20 last version (5) of Portland compiler, and this is supossed to be = corrected in=20 the next revision.
 
So I will buy the source and give = it a=20 try.
 
Pablo
 
 
--------------------------------------------------------
Pabl= o Vitoria=20 Garcia
Dpto. Qu=EDmica Inorg=E1nica, Facultad de = Ciencias
Universidad del Pa=EDs=20 Vasco (UPV/EHU)
Aptdo. 644
48080 Bilbao (Bizkaia)
 
Tfno. 94 6015992
Fax. 94=20 4648500
------=_NextPart_000_008C_01C3B5E2.1D2B01E0--