From enzo@sissy.crs4.it Thu May 6 11:30:09 1993 Date: Thu, 6 May 1993 09:30:09 +0200 From: enzo@crs4.it (Vincenzo Martorana) Message-Id: <9305060730.AA10364@sissy.crs4.it> To: CHEMISTRY@ccl.net Subject: Re: DFT program for IBM RS/6000? At CRS4 (Center for Research, Development and Superior Studies of Sardinia), we are developing and collecting a package of programs in Computational Chemistry (MOTECC). In the next version of MOTECC (93) there will be a DFT implementation using Gaussian Basis Set running on the IBM Risc6k. For further information please contact: Prof. Enrico Clementi or Dr. Gina Corongiu CRS4, PO BOX 488, 09100 Cagliari Italy Fax -39-70-2796 400 e-mail:gina@crs4.it Vincenzo Martorana CRS4, Italy e-mail: enzo@crs4.it tel: -39-70-2796-402 From hommes@organik.uni-erlangen.de Thu May 6 05:17:05 1993 From: Nico van Eikema Hommes Message-Id: <9305060844.AA03313@derioc1.organik.uni-erlangen.de> Subject: Re: NFS and G92 To: wiedeman@uci.edu (Lyle Wiedeman), chemistry@ccl.net Date: Thu, 6 May 93 10:44:49 METDST Hi all! Several people seem to struggle with problems like the following: > > We, too experience mysterious file-access crashes when trying to use > an NFS file system for scratch files. We have G92 on a Convex, > writing to an NFS mounted disk on an SGI Indigo system. > What they want to do is using an NFS mounted disk as scratch space for a Gaussian 92 calculation. There are no mysteries involved here at all. The point is that G92 tries to do things like file-locking. These are not available with every NFS. A crash is then pretty unavoidable. But let's consider what kind of files these are: HUGE binary scratch files, that may grow as large as a few gigabytes. And not only do they become that large, the program does actually read all that stuff occasionally. The effect on the poor ethernet is easily imagined. Everything is blocked, other NFS connections time out, jobs die because of this time-out, people get annoyed and feel urged to send mails to the mail-exploder, etc. The point is that all files belonging to the job should reside on the machine on which the job is running (the output file can go to an NFS partition if you insist on doing that). That way, the heavy I/O load is kept away from the net, file access is MUCH faster, performance increases, jobs finish in less time, users are happy, and so on. See it this way: it's not a bug, it's a sign that the G92 program is just a bit smarter than the users. :-) Happy computing! Nico van Eikema Hommes -- +=====================================+================================+ | Dr. N.J.R. van Eikema Hommes | hommes@organik.uni-erlangen.de | | Institut fuer Organische Chemie I | Tel. : 49/0 - 9131 - 85 - 4096 | | Henkestr. 42, W-8520 Erlangen, FRG | Fax : - 9132 | +=====================================+================================+ From UDIM018@FRORS31.bitnet Mon May 6 07:10:00 1993 Message-Id: <199305061022.AA03944@oscsunb.ccl.net> Date: 06 May 93 11:10:00 EDT From: Subject: ESP Charges To: chemistry@ccl.net E. M. EVLETH Dynamique des Interactions Moleculaires Universite Pierre et Marie Curie 4 Place Jussieu, Tour 22, Paris 75005 33-1-44-27-42-08 (work), 33 = France; 1 = Paris 33-1-45-48-67-20 (home) FAX 33-1-44-27-41-17 (lab);44-27-38-66(University) e-mail UDIM018 at FRORS31.BITNET There are several papers which show that there are linear relationships between ESP ab initio charges (at a particular basis set level) and semiempirical values using various parameterizations (for instance: Ferenczy et al. J Comp Chem 11, 159 (1990). There is a problem with scaling for CHARGED species, the total charge after scaling is not correct. One current problem is that fitted charges are not transportable for the same group type (like a -CH2- in pentane might not have the same charge in hexane). Secondly, the charges change on simple conformational change (see Urban and Famini's article which cites what had been published previously, J Comp. Chem. 14,353 (1993)). Mulliken and Natural atomic populations may be invariant with conformation but NOT fitted charges. These "problem" areas are is currently being examined by several groups, papers by Chipot et al will or have appeared in JPC or JACS on some of these problems. One of the conceptual traps in atomic centered charge modeling is attributing chemical significance to the generated charges. Beware. Second, fitted charges may not accurately regenerate the fields used to generate them (see. Colonna et al. J Comp. Chem. 13 1234 (1992) for other more accurate models). What solutions are available for generating conformationally invariant charges is an area of current research in various groups. It is an area, however, for one to keep one largest salt grains available. From DSMITH@uoft02.utoledo.edu Thu May 6 06:27:08 1993 Date: Thu, 06 May 1993 11:27:08 -0500 (EST) From: "DR. DOUGLAS A. SMITH, UNIVERSITY OF TOLEDO" Subject: Re: NFS and G92 To: hommes@organik.uni-erlangen.de Message-Id: <01GXUQERW11E0079TI@UOFT02.UTOLEDO.EDU> Sure, we would all like to have gigabytes of scratch on each machine for large files, but we must live with what we have - which is usually less than optimum. So, excuse the bandwidth overload, but if it is a choice between running a job using NFS or not doing the research, I opt for the former. Doug Douglas A. Smith Assistant Professor of Chemistry The University of Toledo Toledo, OH 43606-3390 voice 419-537-2116 fax 419-537-4033 email dsmith@uoft02.utoledo.edu From h.rzepa@ic.ac.uk Thu May 6 17:51:18 1993 Message-Id: <9305061651.AA05812@cscmgb.cc.ic.ac.uk> Date: Thu, 6 May 1993 17:51:18 +0000 To: CHEMISTRY@ccl.net From: h.rzepa@ic.ac.uk (Henry Rzepa) (Henry Rzepa) Subject: Re: NFS and G92 >What they want to do is using an NFS mounted disk as scratch space for a >Gaussian 92 calculation. There are no mysteries involved here at all. The >point is that G92 tries to do things like file-locking. These are not >available with every NFS. A crash is then pretty unavoidable. >But let's consider what kind of files these are: HUGE binary scratch files, >that may grow as large as a few gigabytes. And not only do they become that >large, the program does actually read all that stuff occasionally. The >effect on the poor ethernet is easily imagined. >The point is that all files belonging to the job should reside on the machine >on which the job is running (the output file can go to an NFS partition if >you insist on doing that). That way, the heavy I/O load is kept away from >the net, file access is MUCH faster, performance increases, jobs finish in >less time, users are happy, and so on. > >See it this way: it's not a bug, it's a sign that the G92 program is just >a bit smarter than the users. :-) Well, but consider our setup. We have a file server with lots of disks, and a compute engine with less. The big difference is that the two are connected using FDDI. OK, so that is still not ideal, but I defy anyone to thrash FDDI even with fast wide SCSI-2 disks (Seagate Elite in our case). Yet we cannot run large G92 jobs on our compute server because of the above problem! PS, I notice the ADF program also uses absolutely amazing amounts of scratch disk space!! Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; rzepa@ic.ac.uk via Eudora 1.3.1, Tel:+44 71 225 8339, Fax:+44 71 589 3869. From nobody@Kodak.COM Thu May 6 13:25:51 1993 Date: Thu, 6 May 93 13:22:21 EDT From: nobody@Kodak.COM (Adi Treasurywala) Message-Id: <9305061722.AA05567@bcc9.kodak.com> To: chemistry@ccl.net The promised summary for the list. I have tried to edit so that the highlights are preserved . Adi. ORIGINAL MESSAGE: > Hi, > I was wondering if someone out there has a collection of refs > that document success in designing small molecule ligands from > pharmacophores that have been developed from peptide ligands. > The discussion comes up reasonably frequently and I would like > to have FACTS. Clearly the efforts of Marshall et al comes to > mind but I was wondering if there were any others. Please note > its PEPTIDE based pharmacophores that I am specifically > interested in not small molecule-based pharmacophores. I will > be happy to summarize for the net if there is a substantial > response. If your communication is to be kept private or > annonymous please indicate that. > > Thanks RESPONSES: ======================================================================= > From sgi.com!biocad!beethoven.biocad.com!john@bcc7.kodak.com Thu Apr 29 13:13:36 1993 > Date: Thu, 29 Apr 93 09:46:20 -0700 > From: sgi.com!biocad!beethoven.biocad.com!john@bcc7.kodak.com (John Van Drie) > To: adit@kodakr.kodak.com > Subject: Pharmacophores from peptides > Content-Length: 2939 > > I see that you have two requests: > > 1. documented success with developing p-phores from peptide ligands > > 2. designing small mol ligands from those p-phores > > To my knowledge, no one has reported in the literature such a success. > If you find out anything, please let me know. > > Regarding published success on (1), I'm aware of various attempts > at automated p-phore development, but NOT using peptides: > > Mayer, Motoc, & Marshall, JCAMD, vol 1, 1985 > > ACE inhibitors, NOT their peptide origins, but the nanomolar-inhibitors > discovered by Merck, Squibb, etc. > > I can't find the exact ref., but it was a Dutch group, > I believe op den Kelder was the lead author, using beta-2 antagonists > > Smellie & Crippen, ~1991, clique-detection algorithm, my > recollection is again it was small molecules > > Bolis, DiPace, Fabrocini, JCAMD, vol 5, pp 617-628 (1991). > Thermolysin inhibitors, fairly peptide-like. Not enough > detail in this publication to allow anyone to reproduce their results. > > A paper appeared recently in JMB, one of the authors was Ghose, > describing an automated p-phore generation procedure. Once again, > the test case was non-peptidic, as I recall. > > DISCO, Bures, deLazzer & Martin, JCAMD in press. Mark Bures talked > about this at last year's spring ACS - examples again are non-peptidic, > and requires at least one known bioactive conformation. Yvonne will > send you a preprint if you ask. ... > Regarding published success on (2), I know of nothing published. > > At BioCAD, we've been pursuing both of these problems aggressively, > but nothing has been published yet. I'm currently preparing a talk for > the next ACS about applications of our methods to thrombin inhibition, > using peptide-like inhibitors, addressing both (1) and (2). A poster > on the method is planned for the QSAR Gordon Conference this summer. > If you'd like some details on that ahead of time, please let me know. > > I hope this helps. Please keep me informed of your success in > answering your questions. > > - John Van Drie > john@biocad.com > 415/903-3914 > p.p.s. I've omitted the Golender reference, which Biosym has > recently commercialized. > > Also, you might be interested in some of the publications cited > in Blaney & Dixon, Ann Rep in Med Chem, vol 26, pp 281-285 (1991). > > - John ============================================================================= > From sgi.com!biocad!beethoven.biocad.com!john@bcc7.kodak.com Thu Apr 29 14:44:01 1993 > Date: Thu, 29 Apr 93 11:15:05 -0700 > From: sgi.com!biocad!beethoven.biocad.com!john@bcc7.kodak.com (John Van Drie) > To: adit@kodakr.kodak.com > Subject: further thoughts... > Content-Length: 1143 > > Incidentally, if one looks in the literature for successful > reports of starting with peptides and discovering small molecule > drugs, you'll generally see the following types of reports: > > - (e.g. Merck w/ CCK) found rigid molecule in broth in 1986, > was used as lead > > - (e.g. SKB w/ RGD) tried various ways of cyclizing, found > one way that worked, and used that as the basis for small mol. > development > > - (e.g. Abbott w/ ANF, recently in JMedChem) sheer hard work. > I asked the leader of this project, Tom Von Geldern, why > they reported absolutely NO modelling studies in their final > report, when the modellers had in fact been quite active in > studying that. He replied that the energy surface of the peptides > 'looked like the Great Plains', and that modelling had not proven > helpful. > > The report of the Merck work you'll find in an Ann. Rep. of Med. Chem. > from around that time, and the Smith-Kline work you'll find in > JMC in the late '80's w/ an author Bondinell somewhere in the author list. > > I presumed (maybe wrongly) that you were looking for _rational_ desgin > from peptides. > > - John Van Drie ===================================================================== > From raman@bioc01.uthscsa.edu Thu Apr 29 17:28:49 1993 > From: raman@bioc01.uthscsa.edu (C.S.RAMAN) > Subject: Peptide - Pharmacophores! > To: adit@kodakr.kodak.com > Date: Thu, 29 Apr 1993 16:31:22 -0500 (CDT) > Cc: chemistry@ccl.net > X-Mailer: ELM [version 2.4 PL3] > Content-Type> : > text> > Content-Length: 1425 > > Other than the continuing work of Marshal, there were two important > papers in the field of Peptido-mimetics as pharmacophores and they are" > > 1. Simon,R.J. et al., [1992] Proc. Natl. Acad. Sci. USA 89, 9367-9371 > "Peptoids: A modular approach to drug discovery" > > 2. Fincham,C.I. et al., [1992] J. Med. Chem. 35,1472-1484 " Amide bond > replacements Incorporated into CCK-B selective 'Dipeptoids' " > THIS ARTICLE HAS AN EXCELLENT INTRODUCTION WITH REFERENCES TO RELATED > WORK. > > Also, see: > > Kerr, J.M. et al., [1993] J.Am. Chem.Soc. 115, 2529-2531 "Encoded > combinatorial Pptide Libraries Containing Non-natural Amino acids" > > > Hope this helps! > =================================================================== > From swolfe@sfu.ca Thu Apr 29 19:52:35 1993 > From: swolfe@sfu.ca > Subject: no subject (file transmission) > To: adit@kodakr.kodak.com > Date: Thu, 29 Apr 93 16:54:48 PDT > X-Mailer: ELM [version 2.3 PL11] > Content-Length: 155 > > Dear Adi: > > On your recent pharmacophores quest, have you seen Can J. Chem. 66, 2751 > (1988) and Heterocycles 28, 639 (1989). > > Best wishes, > > Saul Wolfe ======================================================================= > > From mitchell@bdrc.bd.com Fri Apr 30 10:13:26 1993 > From: mitchell@bdrc.bd.com > Subject: Pharmacophores From Peptides > To: > Date: Fri, 30 Apr 93 09:07:00 PDT > Encoding: 13 TEXT > X-Mailer: Network Courier V2.1b > Content-Length: 304 > > > > Adi- > > I haven't looked at this stuff for a while, but the folks at Agouron > have been > doing peptide/drug work for years. Probably Arnie Hagler would be one > of the authors on most of these papers. > Mike Mitchell > mitchell@bdrc.bd.com > > =================================================================== I guess that this is a fairly young field with many opportunities. If there are other refs or if there are some more specific refs from the "honchos" whose names were mentioned I would love to get them. Thanks to all who replied and thanks in advance to any others who may help. Adi M Treasurywala,Sterling Winthrop Inc,1250 South Collegeville Road, PO Box 5000, Collegeville, PA 19426-0900,Voice (215)983-6610 FAX (215)983-5559, INTERNET adit@kodak.com From madura@hobbes.chem.uh.edu Thu May 6 09:43:55 1993 Date: Thu, 6 May 93 14:43:55 -0500 From: madura@hobbes.chem.uh.edu (Jeffry Madura) Message-Id: <9305061943.AA08058@hobbes.chem.uh.edu> To: chemistry@ccl.net Subject: looking for the program messcad... Sometime ago I found a program called messcad. I have been working with it a little and would like to contact the author to find out if there is an updated version of the program. The version of the program I have does not have the authors name or location. If someone knows where it is located please let me know. Regards, jeffry Dr. Jeffry D. Madura University of South Alabama Department of Chemistry Chem. Bldg. Room 223 Mobile, AL 36688 e-mail madura@moe.chem.usouthal.edu phone (205) 460-7430 FAX (205) 460-7928 From ryan%phmms0.mms.smithkline.com@smithkline.com Thu May 6 11:44:16 1993 Date: Thu, 6 May 93 15:44:16 -0400 From: ryan%phmms0.mms.smithkline.com@phinet.smithkline.com (Dominic Ryan) Message-Id: <9305061944.AA25088@phmms0.mms.smithkline.com> To: chemistry@ccl.net Subject: NFS and G92 I may have missed something, but it seems to me that if you only have NFS mountable scratch space you are going to be much better off doing a directscf calculation than paying the price in i/o time. I have never done an explicit timing test but i/o to the disk controller on the backplane has got to be *way* faster than i/o across ethernet. If you are doing directscf then the remaining files (checkpoint and rwf) are not that big and should be tolerable. M. Dominic Ryan SmithKline Beecham Pharmaceuticals (215)-270-6529 internet: ryan%phmms0.mms@smithkline.com From DSOUTH@uoft02.utoledo.edu Thu May 6 13:42:38 1993 Date: Thu, 06 May 1993 18:42:38 -0500 (EST) From: DSOUTH@uoft02.utoledo.edu Subject: NFS and G92 To: chemistry@ccl.net Message-Id: <01GXV4PQR8DI007J29@UOFT02.UTOLEDO.EDU> From: IN%"hommes@organik.uni-erlangen.de" "Nico van Eikema Hommes" 6-MAY-1993 08:47:13.61 >What they want to do is using an NFS mounted disk as scratch space for a >Gaussian 92 calculation. stuff deleted There are no mysteries involved here at all. The point is that G92 tries to do things like file-locking. These are not available with every NFS. A crash is then pretty unavoidable. But let's consider what kind of files these are: HUGE binary scratch files, that may grow as large as a few gigabytes. And not only do they become that large, the program does actually read all that stuff occasionally. The effect on the poor ethernet is easily imagined. Everything is blocked, other NFS connections time out, jobs die because of this time-out, people get annoyed and feel urged to send mails to the mail-exploder, etc. >The point is that all files belonging to the job should reside on the machine >on which the job is running Not. The whole reason behind NFS is resource sharing (making 10 workstations into one big one). Why do you thing there is so much work on standards like FIDDI and HIPPI? Faster e-mail delivery? >That way, the heavy I/O load is kept away from >the net, file access is MUCH faster, performance increases, jobs finish in >less time, users are happy, and so on. Running fewer basis functions faster isn't an acceptable solution for everyone. Users are happier when their computers are chugging away on a job, not crashing. By above arguement, we should all disable virtual memory -- it slows the computer down and makes the I/O subsystem work overtime! Fortunately, those of us in the real world have found that a limited amount of virtual memory can be used AND that it allows the machines to do things that would otherwise be out of reach (financially or otherwise). One CANNOT have too much memory or too much disk space. Most of us are willing to take slower memory and/or slower disk space because having that extra meg or gig is the difference bewteen doing research and not doing research. >See it this way: it's not a bug, it's a sign that the G92 program is just >a bit smarter than the users. :-) Not. NFS is a STANDARD way to share disk resources. G92's failure to support it is NOT a feature. -- Dale Southard dsouth@uoft02.utoledo.edu From hogue@canada.den.mmc.com Thu May 6 11:47:50 1993 Date: Thu, 6 May 93 17:47:50 MDT From: hogue@canada.den.mmc.com (Pat Hogue 1-2183) Message-Id: <9305062347.AA00494@canada.den.mmc.com> To: Chemistry@ccl.net Subject: Net charges As a graduate student I feel the liberty to ask what may turn out to be a pretty dumb question but here goes: Pacansky* published net charges for perfluorodimethyl ether that are quite a bit larger than those computed by AM1, as shown below. atom Gaussian AM1 O1 -.799 -.3663 C1 1.507 .5643 C2 1.507 .5643 F1 -.366 -.1065 F2 -.366 -.1375 F3 -.376 -.1371 F4 -.366 -.1065 F5 -.376 -.1374 F6 -.366 -.1372 I canot find the dipole moment data for this molecule with which to try to check which is closer to reality. Can anyone offer an opinion or data? Pat Hogue *JACS 113 (1991) 329-343.