From chemistry-request@ccl.net Wed Jul 9 11:24:03 2003 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h69FO2qe019476 for ; Wed, 9 Jul 2003 11:24:03 -0400 Received: from cornell.edu ([128.84.183.113]) by postoffice.mail.cornell.edu (8.9.3p2/8.9.3) with ESMTP id LAA26345; Wed, 9 Jul 2003 11:23:49 -0400 (EDT) Date: Wed, 9 Jul 2003 11:23:49 -0400 Subject: Re: CCL:AutoDock and protein-protein interactions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: forum CCL To: Dominique Vlieghe From: Richard Gillilan In-Reply-To: <1057306539.12980.2.camel-.at.-dmbr032.fvms.ugent.be> Message-Id: <56D934AC-B221-11D7-9109-000393D59F68-.at.-cornell.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) > * a more specific question: > A way of circumventing a huge grid would be to use a smaller grid > (assuming that the interacting residues must be 'close' to the > receptor) > and setting the extnrg parameters to 0.0 kcal mol-1 (meaning that atoms > outside the grid would feel no field). Is this a correct assumption? > Would this speed up the calculations? > I've done a bit of work on hierarchical grids ... it can be done for linear interpolation, but higher order interpolations pose some problems. Once I started doing a lot of docking, I found that, for most proteins, grid size is not a problem if you work in the principle axis coordinate system (obtained by diagonalizing the inertial matrix). A cubic grid constructed using maximum extents + a buffer length along those axes will save a dramatic amount of space. Van der Waals grids die to zero much beyond 5A from the surface. Electrostatic protentials need to be larger. I go out 20A from the surface with my grid, then use the multipole approximation beyond that point to infinity. Total sum of grids (one electrostatic and 5 VDW in double precision) usually amount to only a couple hundred MB at 0.6A grid spacing. (for linear interpolation, one might want a finer grid). Single precision could work just fine if storage is a problem. One would have to put up with the cost of type conversion however. The grids do add up if you do a lot. I gridded the whole protein-protein docking benchmark of 58 structures (check out the ZDOCK web pages). It was quite a few GB. Richard Gillilan MacCHESS, Cornell ps, I just came back from the protein-protein docking meeting at Stonybrook a week ago. If there is interest, I suppose I could post a brief report. From chemistry-request@ccl.net Tue Jul 8 16:31:55 2003 Received: from mail.uh.edu (SanJacinto.Mail.UH.EDU [129.7.69.101]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h68KVsqe002267 for ; Tue, 8 Jul 2003 16:31:55 -0400 Received: from conversion-daemon by mail.uh.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) id <0HHQ003013OWWL{at}mail.uh.edu> for chemistry{at}ccl.net; Tue, 8 Jul 2003 15:31:44 -0500 (CDT) Received: from localhost (Colorado.Mail.UH.EDU [129.7.69.103]) by mail.uh.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0HHQ001EY3OVU9{at}mail.uh.edu> for chemistry{at}ccl.net; Tue, 08 Jul 2003 15:31:43 -0500 (CDT) Date: Tue, 08 Jul 2003 15:31:43 -0500 (CDT) From: Niharendu.Choudhury{at}mail.uh.edu Subject: averaging in CHARMM To: chemistry{at}ccl.net Message-id: <482398476.1057696303153.JavaMail.root@localhost> MIME-version: 1.0 X-Mailer: Sun(TM) Web Access 1.2 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi all, Thanks to all who replied me earlier, in particular, Rick Venable, Liisa laakkonen for their help/suggestion in hbuild. My present preblem is as follows: When I am starting a MD run(production stage ) in CHARMM after equilibration for calculating averages of various quantities, it is adding up the same from the previous equilibration stages, which I don't want. I want only averages from the present run, NOT from earlier runs(equilibration etc.) How can I achieve this? Bye Nihar From chemistry-request@ccl.net Sun Jul 6 23:24:25 2003 Received: from cornell.edu (cornell.edu [132.236.56.6]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h673OPqe011133 for ; Sun, 6 Jul 2003 23:24:25 -0400 Received: from connie.summerhill (syr-24-58-0-128.twcny.rr.com [24.58.0.128]) by cornell.edu (8.9.3p2/8.9.3) with ESMTP id XAA26694 for ; Sun, 6 Jul 2003 23:24:26 -0400 (EDT) Subject: Electric field and Gaussian From: Connie Chang To: chemistry{at}ccl.net In-Reply-To: <200307070322.XAA25914{at}cornell.edu> References: <200307070322.XAA25914{at}cornell.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jul 2003 23:24:25 -0400 Message-Id: <1057548265.7278.5.camel@connie> Mime-Version: 1.0 Hi CCLers-- I was wondering what can be done with electric fields in Gaussian. I've been told that Gaussian can't minimize the geometric coordinates of a molecule under an electric field. But what can it do? Will it give me how an electric field affects the electronic structure of a molecule? Can I perform a hessian calculation/find normal modes under an electric field? Thank you, Connie From chemistry-request@ccl.net Tue Jul 8 07:14:54 2003 Received: from alcides.host4u.net (alcides.host4u.net [216.71.64.98]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h68BErqe022761 for ; Tue, 8 Jul 2003 07:14:54 -0400 Received: from there (CPE0007954b9f8e-CM.cpe.net.cable.rogers.com [24.43.141.144]) by alcides.host4u.net (8.11.6/8.11.6) with SMTP id h68BEre18322 for ; Tue, 8 Jul 2003 06:14:53 -0500 Message-Id: <200307081114.h68BEre18322{at}alcides.host4u.net> Content-Type: text/plain; charset="iso-8859-1" From: Aniko Simon Organization: SimBioSys Inc. Subject: CCL: Announcing CAESA (Computer Assisted Estimation of Synthetic Accessibility) Date: Tue, 8 Jul 2003 03:11:55 -0400 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: CCL SimBioSys is pleased to announce the release of CAESA v2.4 CAESA stands for Computer Assisted Estimation of Synthetic Accessibility and it is a tool used to rank sets of molecules according to their ease of synthesis. This is especially helpful when used in conjunction with de novo design software. CAESA also assists the development of viable synthetic approaches by identifying suitable, readily available starting materials and retrosynthetic paths. CAESA uses the technology of expert systems to propose viable synthetic accessibility estimates and retrosynthetic routes. The program uses two sources of information that can be customized to provide estimations specific to the chemistry employed in the company: (1) a database of available starting materials and (2) a reaction knowledge-base. The presence of complexity-enhancing structural features (such as chiral centres or complex topological features) is detected in each target molecule. These features are used to assess the ease of synthesis of a compound. Conveniently, the client side of CAESA can be used via a web-browser on any operating system. The server side of the system can be installed either on Linux or SGI platform. For further information about CAESA, please visit our web site at http://www.simbiosys.ca/ or contact us at info{at}simbiosys.ca -- Aniko Simon Ph.D., aniko{at}simbiosys.ca, http://www.simbiosys.ca/ From chemistry-request@ccl.net Tue Jul 8 12:32:48 2003 Received: from cirse.saclay.cea.fr (cirse.saclay.cea.fr [132.166.192.127]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h68GWlqe030455 for ; Tue, 8 Jul 2003 12:32:48 -0400 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.saclay.cea.fr (8.12.9/CEAnet-Internet.1.0) with ESMTP id h68GWkFL021818 for ; Tue, 8 Jul 2003 18:32:46 +0200 (MEST) Received: from muguet.saclay.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Tue, 8 Jul 2003 18:28:39 +0200 Received: from petunia.bruyeres.cea.fr (petunia.bruyeres.cea.fr [132.165.64.1]) by muguet.saclay.cea.fr (8.12.9/CEAnet-Interne.1.0) with ESMTP id h68GVeKp017509 for ; Tue, 8 Jul 2003 18:31:40 +0200 (MEST) Received: from styx.bruyeres.cea.fr (styx-e76.bruyeres.cea.fr [132.165.76.3]) by petunia.bruyeres.cea.fr (8.9.3+Sun/jtpda-5.3.2) with ESMTP id SAA20604 for ; Tue, 8 Jul 2003 18:27:43 +0200 (MET DST) Received: by styx.bruyeres.cea.fr; id SAA03297; Tue, 8 Jul 2003 18:31:38 +0200 (MET DST) Message-Id: <200307081631.SAA03297*at*styx.bruyeres.cea.fr> Sender: mathieu*at*indre.ripault.cea.fr Date: Tue, 08 Jul 2003 17:59:58 +0200 From: Didier MATHIEU Organization: CEA X-Mailer: Mozilla 4.72 [fr] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: chemistry*at*ccl.net Subject: SUMMARY molecular mechanics parameters from ab initio calc Content-Type: multipart/alternative; boundary="------------829AC08FF4A058A831A832F5" --------------829AC08FF4A058A831A832F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Some weeks ago I asked about the best way to derive intramolecular force field parameters from ab initio data. I got some replies pointing to some references to the methology for deriving transferable force fields, i.e. based on atom types: Per-Ola Norrby and Peter Brandt, Coord. Chem. Rev. 2001, 212, 79-109. Per- Ola Norrby and Tommy Liljefors, J. Comput. Chem. 1998, 19, 1146-1166 Extensive examples are by Hagler et al (CFF) and Halgren (MMFF). I'm also been told about a commercial expensive program to make this kind of job: http://www.aeontechnology.com/ Two other replies, that exactly fit our needs, deal with the simpler problem, when one is interested in specific compounds and does not have to mind about transferability. J.M. Seminario, "Calculation of intramolecular force fields from second- derivative tensors", Int.J.Quant.Chem.: Quantum Chemistry Symposium 30, 1271-1277 (1996) Further work along those lines appears to have been carried out by Marcel Swart : IntraFF is currently within the submission phase for J.Comput.Chem.; when it is accepted, I will make it generally available. ====== Thanks to Jerome Baudray, Geoff Hutchinson, Per-Ola Norrby, Michele Lunelli, Marcel Swart, Teodorico Ramalho for their replies, advice or interest. -- Didier Mathieu CEA - Le Ripault BP 16 37260 Monts Didier.Mathieu*at*cea.fr Tel +33 02 47 34 41 85 Fax +33 02 47 34 51 42 --------------829AC08FF4A058A831A832F5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  Hello,

 Some weeks ago I asked about the best way to derive intramolecular force
 field parameters from ab initio data. I got some replies pointing to some
 references to the methology for deriving transferable force fields, i.e.
 based on atom types:
 Per-Ola Norrby and Peter Brandt, Coord. Chem. Rev. 2001, 212, 79-109.  Per-
 Ola Norrby and Tommy Liljefors, J. Comput. Chem. 1998, 19, 1146-1166
 Extensive examples are by Hagler et al (CFF) and Halgren (MMFF).  I'm also
 been told about a commercial expensive program to make this kind of job:
 http://www.aeontechnology.com/

 Two other replies, that exactly fit our needs, deal with the simpler
 problem, when one is interested in specific compounds and does not have to
 mind about transferability.
 J.M. Seminario, "Calculation of intramolecular force fields from second-
 derivative tensors",
 Int.J.Quant.Chem.: Quantum Chemistry Symposium 30, 1271-1277 (1996) Further
 work along those lines appears to have been carried out by Marcel Swart
 <swart*at*chem.vu.nl> : IntraFF is currently within the submission phase for
 J.Comput.Chem.; when it is accepted, I will make it generally available.

 ======
 Thanks to Jerome Baudray, Geoff Hutchinson, Per-Ola Norrby, Michele
 Lunelli, Marcel Swart, Teodorico Ramalho for their replies, advice or
 interest. 

-- 
Didier Mathieu
CEA - Le Ripault
BP 16
37260 Monts
Didier.Mathieu*at*cea.fr
Tel +33 02 47 34 41 85
Fax +33 02 47 34 51 42
  --------------829AC08FF4A058A831A832F5-- From chemistry-request@ccl.net Tue Jul 8 00:15:34 2003 Received: from mx4.ust.hk (mx4.ust.hk [143.89.13.26]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h684FWqe015239 for ; Tue, 8 Jul 2003 00:15:33 -0400 Received: from ust.hk (sqmail2.ust.hk [143.89.13.12]) by mx4.ust.hk (8.12.9/8.12.9) with SMTP id h684FSoT066579 for ; Tue, 8 Jul 2003 12:15:29 +0800 (HKT) Received: from 143.89.53.94 (SquirrelMail authenticated user chgy) by sqmail.ust.hk with HTTP; Tue, 8 Jul 2003 12:15:29 +0800 (HKT) Message-ID: <4860.143.89.53.94.1057637729.squirrel!at!sqmail.ust.hk> Date: Tue, 8 Jul 2003 12:15:29 +0800 (HKT) Subject: Problems on freqency calculations of PCM model in G03 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 Dear CCLers, I encounter a problem on l701 when I'm running the FREQ calculations of PCM model in G03. Would you kindly give some advices? Best Yi Gao Department of Chem HKUST, HK Input: %mem=200mb %chk=achc1.chk #p freq(noraman) rb3lyp/6-31g(d) scrf=(pcm,solvent=methanol) geom=allc heck Output: Hexadecapole moment (field-independent basis, Debye-Ang**3): XXXX= -1712.3039 YYYY= -1041.7383 ZZZZ= -346.5980 XXXY= -17.9298 XXXZ= -14.8633 YYYX= 58.6465 YYYZ= 75.0827 ZZZX= -18.0436 ZZZY= 35.9187 XXYY= -480.3303 XXZZ= -364.6161 YYZZ= -268.8508 XXYZ= 14.9374 YYXZ= 1.2719 ZZXY= 19.0798 N-N= 8.630549944201D+02 E-N=-3.152893967217D+03 KE= 6.067563047945D+02 Exact polarizability: 144.726 6.192 129.223 7.834 -2.048 140.577 Approx polarizability: 146.219 3.930 136.248 12.253 -7.650 176.150 No NMR shielding tensors so no spin-rotation constants. Leave Link 601 at Sun Jul 6 20:15:38 2003, MaxMem= 26214400 cpu: 1.2 (Enter /home/software/g03/l701.exe) Compute integral second derivatives. ... and contract with generalized density number 0. D1PCM: PCM CHGder 1st derivatives, ID1Alg=0 FixD1E=F DoIter=F I1PDM=0. D2PCM: PCM 2nd derivatives, FixD2E=F I1PDM=0. D2PCM-2 allocation failure: iend,mxcore= 27114695 26069026 Error termination via Lnk1e in /home/software/g03/l701.exe at Sun Jul 6 20:16:10 2003. Job cpu time: 0 days 3 hours 13 minutes 26.6 seconds. File lengths (MBytes): RWF= 264 Int= 0 D2E= 0 Chk= 8 Scr= 1 From chemistry-request@ccl.net Mon Jul 7 09:18:17 2003 Received: from webmail.mta.ca (rash.mta.ca [138.73.1.30]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h67DIHqe027666 for ; Mon, 7 Jul 2003 09:18:17 -0400 Received: from nobody by webmail.mta.ca with local (Exim 4.04) id 19ZVso-0006Kv-00 for chemistry(at)ccl.net; Mon, 07 Jul 2003 10:18:18 -0300 Received: from 138.73.24.166 ( [138.73.24.166]) as user kgdct(at)mailserv.mta.ca by webmail.mta.ca with HTTP; Mon, 7 Jul 2003 10:18:18 -0300 Message-ID: <1057583898.3f09731a35489(at)webmail.mta.ca> Date: Mon, 7 Jul 2003 10:18:18 -0300 From: kgdct(at)mta.ca To: chemistry(at)ccl.net Subject: Error #1 in AlGdDF message inquiry MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: 138.73.24.166 I was wondering if anyone has seen this error and if so if they knew how to solve the problem. I've encountered the same error a couple of times both on frequency calculation. Raff turned off since only 58.29% of shell-pairs survive. There are 69 degrees of freedom in the 1st order CPHF. 69 vectors were produced by pass 0. AX will form 35 AO Fock derivatives at one time. 69 vectors were produced by pass 1. 69 vectors were produced by pass 2. 66 vectors were produced by pass 3. 66 vectors were produced by pass 4. 63 vectors were produced by pass 5. Error #1 in AlGdDF. Error termination via Lnk1e in /var/local/g98/l1002.exe. Job cpu time: 0 days 2 hours 29 minutes 37.9 seconds. thanks so much -Katie Doucet Mount Allison University From chemistry-request@ccl.net Tue Jul 8 11:07:11 2003 Received: from mailgw1.technion.ac.il (mailgw1.technion.ac.il [132.68.238.34]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h68F7Aqe027939 for ; Tue, 8 Jul 2003 11:07:11 -0400 Received: by mailgw1.technion.ac.il (Postfix, from userid 60999) id 87595676FC; Tue, 8 Jul 2003 18:07:08 +0300 (IDT) Received: from techunix.technion.ac.il (techunix.technion.ac.il [132.68.1.28]) by mailgw1.technion.ac.il (Postfix) with ESMTP id DC327676F6 for ; Tue, 8 Jul 2003 18:07:07 +0300 (IDT) Received: from tx.technion.ac.il (mandrake.technion.ac.il [132.68.86.138]) by techunix.technion.ac.il (Postfix) with ESMTP id CA57721ECC for ; Tue, 8 Jul 2003 18:07:07 +0300 (IDT) Message-ID: <3F0AE023.10104~at~tx.technion.ac.il> Date: Tue, 08 Jul 2003 18:15:47 +0300 From: Irena Efremenko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en, ru, he MIME-Version: 1.0 To: ccl Subject: c8698 utility Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear CCLers, I want to use g94 checkpoint file for g98 calculations. Running c8698 utility I get the following message: Fixing /Label/ Fixing /B/, old MaxShl= 2500. ILSW is already fixed Fixing /Mol/, old MaxAtm= 1000. Fixing /LP2/, old MaxAtm= 1000. Fixing /SymInf/. Fixing /Info/. Fixing IOEDrv. chkchk utility can read it saying: Title: .... Route: ..... Atomic coordinates present. MO coefficients present. Internal force constants may be present. But g98 cannot use it: (Enter /usr/local/g98/l101.exe) --------------------------------------------------- Title --------------------------------------------------- Redundant internal coordinates taken from checkpoint file: myfile.chk Charge = 0 Multiplicity = 1 Operation on file out of range. FileIO: IOper= 2 IFilNo(1)= 20665 Len= 1632 IPos= 0 Q= 5390846208 dumping /fiocom/, unit = 1 NFiles = 14 SizExt = 524288 WInBlk = 1024 defal = T LstWrd = 709632 FType=2 FMxFil=10000 Does somebody here know what does it means and how to overcome it? Thanks, -- Dr. Irena Efremenko Wolfson Department of Chemical Engineering Technion - Israel Institute of Technology Haifa 32000, Israel Phone: 972-4-8293561 Fax: 972-4-8295672 From chemistry-request@ccl.net Mon Jul 7 17:15:49 2003 Received: from antigen.scripps.edu (relay1.scripps.edu [137.131.200.29]) by server.ccl.net (8.12.8/8.12.8) with SMTP id h67LFmqe009723 for ; Mon, 7 Jul 2003 17:15:48 -0400 Received: from relay1.scripps.edu(137.131.200.29) by antigen.scripps.edu via csmap id 10241; Mon, 07 Jul 2003 14:17:23 -0700 (PDT) Received: from antigen.scripps.edu (gamow [137.131.252.67]) by relay1.scripps.edu (8.11.7/TSRI-4.4.1r) with SMTP id h67LFlC17607 for ; Mon, 7 Jul 2003 14:15:47 -0700 (PDT) Received: from gamow.scripps.edu(137.131.252.67) by antigen.scripps.edu via csmap id 10234; Mon, 07 Jul 2003 14:17:21 -0700 (PDT) Received: from quine.scripps.edu (dhcp-252-215 [137.131.252.215]) by gamow.scripps.edu (8.9.2/TSRI-3.0.1) with SMTP id OAA134709 for ; Mon, 7 Jul 2003 14:15:47 -0700 (PDT) Received: by quine.scripps.edu (sSMTP sendmail emulation); Mon, 7 Jul 2003 14:15:47 -0700 Date: Mon, 7 Jul 2003 14:15:47 -0700 From: "David A. Case" To: chemistry..at..ccl.net Subject: New program available: PMEMD (Particle Mesh Ewald Molecular Dynamics) Message-ID: <20030707211547.GA2340..at..scripps.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i We are proud to announce the release of version 3.00 (the first version to be generally released) of PMEMD (Particle Mesh Ewald Molecular Dynamics). PMEMD is a new version of the Amber module "Sander", and has been written with the major goal of improving performance in Particle Mesh Ewald molecular dynamics simulations and minimizations. The code has been totally rewritten in Fortran 90, and is capable of running in either an Amber 6 or Amber 7 mode. Functionality is more complete in Amber 6 mode, with the Amber 7 mode designed mostly to do the same sorts of things that Amber 6 does, but with output that is comparable to Amber 7 Sander. The calculations done in PMEMD are intended to replicate either Sander 6 or Sander 7 calculations within the limits of roundoff errors. The calculations are just done more rapidly in less memory, and runs may be made efficiently on significantly larger numbers of processors. Performance improvement ratios on Linux clusters and IBM SP3/4 clusters are typically in the range of 1.9 to 3.6 fold relative to Sander 6 and 1.5 to 3.8 fold relative to Sander 7. Memory requirements are roughly cut in half. A large number of benchmarks are presented in the ReleaseNote file. PMEMD was developed by Dr. Robert Duke in Prof. Lee Pedersen's Lab at UNC-Chapel Hill, starting from the version of Sander in Amber 6. Funding support was provided by NIH grant HL-06350 (PPG) and NSF grant 2001-0759-02 (ITR/AP). When citing PMEMD (Particle Mesh Ewald Molecular Dynamics) in the literature, please use both the Amber Version 7 citation given in the Amber 7 manual, and the following citation: Robert E. Duke and Lee G. Pedersen (2003) PMEMD 3, University of North Carolina-Chapel Hill PMEMD is available without charge to users who have an existing license for Amber (version 6 or 7). For more information, and to download the code, please go to: http://amber.scripps.edu/pmemd-get.html ..Robert Duke (UNC-Chapel Hill) and David Case (The Scripps Research Institute) From chemistry-request@ccl.net Tue Jul 8 21:59:05 2003 Received: from web15213.mail.bjs.yahoo.com (web15213.mail.bjs.yahoo.com [202.3.77.143]) by server.ccl.net (8.12.8/8.12.8) with SMTP id h691x3qe006902 for ; Tue, 8 Jul 2003 21:59:04 -0400 Message-ID: <20030709015902.98426.qmail*at*web15213.mail.bjs.yahoo.com> Received: from [218.56.157.15] by web15213.mail.bjs.yahoo.com via HTTP; Wed, 09 Jul 2003 09:59:02 CST Date: Wed, 9 Jul 2003 09:59:02 +0800 (CST) From: =?gb2312?q?Jinsong=20Zhao?= Subject: CCL: About the alignment of CoMFA To: CCL MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Dear all, I have a series of structure similar chemicals. After I optimizate each compound with minimum energy, I found the alignment was poor (all the compounds were aligned to a maximum common structure). I am wondering if it's reasonable that I just minimize the subset of a chemical structure, i.e., I let the conformation of the common structure unchanged. I really appreciate any comments or suggestions! Best regards, Jinsong _________________________________________________________ Do You Yahoo!? 9zDZ5gSJSC;'74@,;x5w2i@-?*a!D; http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.tech.yahoo.com/zhuanti/laji/index.html From chemistry-request@ccl.net Tue Jul 8 12:02:26 2003 Received: from chem.udel.edu (chem.udel.edu [128.175.138.224]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h68G2Pqe029588 for >ccl.net>; Tue, 8 Jul 2003 12:02:25 -0400 Received: from localhost (pradyu@localhost) by chem.udel.edu (8.9.3/8.9.3) with ESMTP id MAA535355 for >ccl.net>; Tue, 8 Jul 2003 12:45:00 -0400 (EDT) Date: Tue, 8 Jul 2003 12:45:00 -0400 From: "Pradyumna S. Singh" >chem.udel.edu> To: chemistry<>ccl.net Subject: DFT and Charged Species In-Reply-To: <3F02ECDD.D642E01A<>trentu.ca> Message-ID: >chem.udel.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I was wondering if anyone has published on the accuracy of DFT for studying charged species like radical anions/cations or dianions/dications ? Any leads or references would be appreciated ! Thanks, Pradyumna From chemistry-request@ccl.net Wed Jul 9 06:37:47 2003 Received: from dove2.cf.ac.uk (dove2.cf.ac.uk [131.251.1.170]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h69Ablqe014112 for ; Wed, 9 Jul 2003 06:37:47 -0400 Received: from thor.cf.ac.uk ([131.251.0.1]) by dove2.cf.ac.uk with esmtp (Exim 4.05) id 19aCKT-0000Fz-00; Wed, 09 Jul 2003 11:37:41 +0100 Received: from localhost (sacjap@localhost) by thor.cf.ac.uk (8.8.8/8.6.12) with ESMTP id LAA05913; Wed, 9 Jul 2003 11:37:41 +0100 (BST) Date: Wed, 9 Jul 2003 11:37:40 +0100 (BST) From: Jamie Platts X-X-Sender: sacjap@thor To: chemistry^at^ccl.net, "" cc: "Waller, Mark -- Mark Waller" , Mark Waller Subject: Error with ONIOM/AMBER in G03 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi there - I'm having trouble getting an ONIOM job on a platinum complex to run in Gaussian03. Despite requesting AMBER for the outer region and LanL2DZ for the metal core, the job crashes because there is no VSTO-3G basis set for Pt (G98 just printed a warning and carried on). Does anyone know of a way to avoid this? More fundamentally, why does an AMBER calculation require an STO-3G basis anyway? Many thanks in advance, Jamie Error message from G03: ONIOM: restoring gridpoint 3 on chk file. ONIOM: generating point 3 -- low level on real system. Standard basis: VSTO-3G* (5D, 7F) IA out of range in STO. Error termination via Lnk1e in /usr/local/testsoft/g03/l301.exe ---------------------------------------------------------- Jamie Platts Dept. of Chemistry Phone: +44 (0) 2920 874950 Cardiff University Email: platts^at^cf.ac.uk P.O. Box 912 FAX: +44 (0) 2920 874030 Cardiff CF10 3TB www.cf.ac.uk/chemy From chemistry-request@ccl.net Mon Jul 7 03:11:10 2003 Received: from gems.uia.ac.be (hgems.uia.ac.be [143.169.254.10]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h677B9qe016681 for ; Mon, 7 Jul 2003 03:11:10 -0400 Received: from rnase (rnase.uia.ac.be [143.169.6.236]) by gems.uia.ac.be (8.12.9/8.12.3) with ESMTP id h677B7im005989; Mon, 7 Jul 2003 09:11:07 +0200 (MET DST) Content-Type: text/plain; charset="iso-8859-1" From: Ben Swerts Organization: University of Antwerp To: chemistry!at!ccl.net Subject: Re: CCL:Ewald in CHARMM Date: Mon, 7 Jul 2003 08:11:05 +0200 User-Agent: KMail/1.4.3 References: <482769665.1057357456126.JavaMail.root@localhost> In-Reply-To: <482769665.1057357456126.JavaMail.root@localhost> Cc: Niharendu.Choudhury!at!mail.uh.edu MIME-Version: 1.0 Message-Id: <200307070811.05870.ben.swerts!at!ua.ac.be> X-Spam-Flag: NO X-Spam-Status: Not checked, trusted sender X-Scanned-By: MIMEDefang 2.33 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.ccl.net id h677BAqe016682 Hi Niharendu, This message means CHARMM needs more memory and your architecture cannot provide more memory at runtime. You'll have to recompile CHARMM with a larger heap-size. Check out the file heap.fcm and change the parameter HEAPDM in the correct place for your architecture. Ben On Saturday 05 July 2003 00:24, you wrote: > Hi all, > I was initially running with following crystal keywords: > > Crystal Define Cubic 24.850 24.850 24.850 90.0 90.0 90.0 > Crystal Build noperations 0 > > and energy keywords : > > ENERGY ATOM ELEC EWALD KAPPA 0.21 KMAX 4 KSQMAX 27 - > CUTNB 10.0 CUTIM 10.0 CTOFNB 9.5 VDW SHIFT > > it was running fine. > > > Now I have changed the energy section to the following: > > ENERGY ATOM ELEC EWALD KAPPA 0.21 KMAX 4 KSQMAX 27 - > CUTNB 12.0 CUTIM 12.0 CTOFNB 10 VDW SHIFT > > and it is not running. (I have only changed cutnb and ctofnb, crystal > section being the same). > > FOR MORE DETAILS I am appending below the output error message: [snip] > > ***** LEVEL -4 WARNING FROM ***** > ***** CANNOT EXPAND HEAP ON THIS MACHINE > ****************************************** > BOMLEV ( 0) IS REACHED - TERMINATING. WRNLEV IS 5 > Execution terminated due to the detection of a fatal error. > [snip] From chemistry-request@ccl.net Mon Jul 7 13:33:58 2003 Received: from web15206.mail.bjs.yahoo.com (web15206.mail.bjs.yahoo.com [202.3.77.136]) by server.ccl.net (8.12.8/8.12.8) with SMTP id h67HXuqe004551 for ; Mon, 7 Jul 2003 13:33:57 -0400 Message-ID: <20030707173355.24104.qmail.-at-.web15206.mail.bjs.yahoo.com> Received: from [218.56.157.15] by web15206.mail.bjs.yahoo.com via HTTP; Tue, 08 Jul 2003 01:33:55 CST Date: Tue, 8 Jul 2003 01:33:55 +0800 (CST) From: =?gb2312?q?Jinsong=20Zhao?= Subject: CCL: Outlier of CoMFA Analysis To: CCL MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Dear all, I have met a question when I deal with the results of CoMFA analysis (3D-QSAR). In my data set, when certain compound was removed, the Q2 (r2 of LOO) was increased significantly. However, I cann't find the significant difference of structure between the removed compound and the rest ones, e.g., 3-Cl-C6H4OP(=O)(OMe)2 v.s. 4-Cl-C6H4OP(=O)(OMe)2. Therefore, I hope to get your knidly help. Anyone here could give me some hints or methods that could help me to figure out the outlier. Thanks in advance! By the way, is it necessary to align all the remainder molecules again after removing the outlier? It's something time-consuming. I really appreciate you for any comments, suggestions, and helps. Best regards, Jinsong _________________________________________________________ Do You Yahoo!? 9zDZ5gSJSC;'74@,;x5w2i@-?*a!D; http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.tech.yahoo.com/zhuanti/laji/index.html From chemistry-request@ccl.net Tue Jul 8 15:21:49 2003 Received: from altair.fccc.edu (altair.fccc.edu [131.249.12.217]) by server.ccl.net (8.12.8/8.12.8) with ESMTP id h68JLnqe001207 for ; Tue, 8 Jul 2003 15:21:49 -0400 Received: from fccc.edu by altair.fccc.edu (8.8.8/1.1.22.3/27Feb01-0452PM) id PAA0000018035; Tue, 8 Jul 2003 15:21:36 -0400 (EDT) Date: Tue, 8 Jul 2003 15:23:16 -0400 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: multipart/alternative; boundary=Apple-Mail-46--71898244 Subject: SCWRL3.0 for protein side-chain prediction From: "Roland L. Dunbrack" To: chemistry/at/ccl.net Message-Id: X-Mailer: Apple Mail (2.551) --Apple-Mail-46--71898244 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed SCWRL3.0, a program for predicting protein side-chain conformations for a given backbone, is now available. SCWRL3.0 uses a new algorithm based on graph theory that is much faster than previous versions of SCWRL, and faster than any other available programs for protein side-chain prediction. Some highlights: - very fast algorithm for side-chain prediction. A set of 180 test proteins comprising 34,342 side chains takes 404 seconds. - increased accuracy comparing to previous SCWRL versions with 82.6% correct chi1 and 73.7% correct chi1+2. - preserving residue numbering and chain IDs. Many programs renumber residues from 1 to N and strip chain IDs. - sequence replacement for comparative modeling and protein design - distributed as executable binaries for most popular operating systems (Linux, Windows, Mac OS X) - easy installation procedure - free academic/non-profit license - paper to appear in Protein Science, Sept. 2003 (preprint available on request) Visit http://dunbrack.fccc.edu/scwrl3 for more information and download options. Sincerely yours, Adrian Canutescu and Roland Dunbrack * Roland L. Dunbrack, Jr., Ph. D. * Member * Institute for Cancer Research * Fox Chase Cancer Center * 333 Cottman Avenue * Philadelphia PA 19111 * (215) 728-2434 * (215) 728-2412 (fax) * RL_Dunbrack/at/fccc.edu * http://dunbrack.fccc.edu (scientific research) * http://dunbrack.org/ (genealogy) --Apple-Mail-46--71898244 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII SCWRL3.0, a program for predicting protein side-chain conformations for a given backbone, is now available. SCWRL3.0 uses a new algorithm based on graph theory that is much faster than previous versions of SCWRL, and faster than any other available programs for protein side-chain prediction. Some highlights: - very fast algorithm for side-chain prediction. A set of 180 test proteins comprising 34,342 side chains takes 404 seconds. - increased accuracy comparing to previous SCWRL versions with 82.6% correct chi1 and 73.7% correct chi1+2. - preserving residue numbering and chain IDs. Many programs renumber residues from 1 to N and strip chain IDs. - sequence replacement for comparative modeling and protein design - distributed as executable binaries for most popular operating systems (Linux, Windows, Mac OS X) - easy installation procedure - free academic/non-profit license - paper to appear in Protein Science, Sept. 2003 (preprint available on request) Visit http://dunbrack.fccc.edu/scwrl3 for more information and download options. Sincerely yours, Adrian Canutescu and Roland Dunbrack * Roland L. Dunbrack, Jr., Ph. D. * Member * Institute for Cancer Research * Fox Chase Cancer Center * 333 Cottman Avenue * Philadelphia PA 19111 * (215) 728-2434 * (215) 728-2412 (fax) * RL_Dunbrack/at/fccc.edu * http://dunbrack.fccc.edu (scientific research) * http://dunbrack.org/ (genealogy) --Apple-Mail-46--71898244-- From chemistry-request@ccl.net Wed Jul 9 17:13:05 2003 Received: from antigen.scripps.edu (relay2.scripps.edu [137.131.200.30]) by server.ccl.net (8.12.8/8.12.8) with SMTP id h69LD4qe031374 for ; Wed, 9 Jul 2003 17:13:04 -0400 Received: from relay2.scripps.edu(137.131.200.30) by antigen.scripps.edu via csmap id 12051; Wed, 09 Jul 2003 14:14:44 -0700 (PDT) Received: from antigen.scripps.edu (renoir [137.131.252.25]) by relay2.scripps.edu (8.11.7/TSRI-4.4.1r) with SMTP id h69LD4801576; Wed, 9 Jul 2003 14:13:04 -0700 (PDT) Received: from renoir.scripps.edu(137.131.252.25) by antigen.scripps.edu via csmap id 12047; Wed, 09 Jul 2003 14:14:43 -0700 (PDT) Received: by renoir.scripps.edu (Postfix, from userid 1376) id EA279F6B; Wed, 9 Jul 2003 14:13:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by renoir.scripps.edu (Postfix) with ESMTP id DA46BA25; Wed, 9 Jul 2003 14:13:03 -0700 (PDT) Date: Wed, 9 Jul 2003 14:13:03 -0700 (PDT) From: Michael Crowley To: Ben Swerts Cc: chemistry:at:ccl.net, Subject: Re: CCL:Ewald in CHARMM In-Reply-To: <200307070811.05870.ben.swerts:at:ua.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Concerning the heap expand error message: You have increased the cutoff so most likely the message is not coming from ewald, but from the nonbond list generator. The list will be considerably bigger, and it is in HEAP memory. Normally, the heap will be reallocated during the run (on most machines) to accomodate the need. Your message says that heap cannot be increased on the machine. It is either because it cannot reallocate (there is no viable memalloc function) or that there is not enough memory on your machine to accomodate the need. Recompiling with a larger heap will help the first cause. The second cause will not be helped by recompiling. What architecture are you running on? Mike ----------------------------------------------------------------- Physical mail: Dr. Michael F. Crowley Department of Molecular Biology, TPC6 The Scripps Research Institute 10550 North Torrey Pines Road La Jolla, California 92037 Electronic mail: crowley:at:scripps.edu Telephone: 858/784-9290 Fax: 858/784-8688 ----------------------------------------------------------------- On Mon, 7 Jul 2003, Ben Swerts wrote: > Hi Niharendu, > > This message means CHARMM needs more memory and your architecture cannot > provide more memory at runtime. You'll have to recompile CHARMM with a larger > heap-size. Check out the file heap.fcm and change the parameter HEAPDM in the > correct place for your architecture. > > > Ben > > > On Saturday 05 July 2003 00:24, you wrote: > > Hi all, > > I was initially running with following crystal keywords: > > > > Crystal Define Cubic 24.850 24.850 24.850 90.0 90.0 90.0 > > Crystal Build noperations 0 > > > > and energy keywords : > > > > ENERGY ATOM ELEC EWALD KAPPA 0.21 KMAX 4 KSQMAX 27 - > > CUTNB 10.0 CUTIM 10.0 CTOFNB 9.5 VDW SHIFT > > > > it was running fine. > > > > > > Now I have changed the energy section to the following: > > > > ENERGY ATOM ELEC EWALD KAPPA 0.21 KMAX 4 KSQMAX 27 - > > CUTNB 12.0 CUTIM 12.0 CTOFNB 10 VDW SHIFT > > > > and it is not running. (I have only changed cutnb and ctofnb, crystal > > section being the same). > > > > FOR MORE DETAILS I am appending below the output error message: > [snip] > > > > ***** LEVEL -4 WARNING FROM ***** > > ***** CANNOT EXPAND HEAP ON THIS MACHINE > > ****************************************** > > BOMLEV ( 0) IS REACHED - TERMINATING. WRNLEV IS 5 > > Execution terminated due to the detection of a fatal error. > > > [snip] > > > > > -= This is automatically added to each message by 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) > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > >