From hinsen@lmspc1.ibs.fr Wed Jul 23 09:13:06 1997 Received: from ibs.ibs.fr for hinsen@lmspc1.ibs.fr by www.ccl.net (8.8.3/950822.1) id JAA18809; Wed, 23 Jul 1997 09:04:21 -0400 (EDT) Received: from lmspc1.ibs.fr (hinsen@lmspc1.ibs.fr [192.134.36.141]) by ibs.ibs.fr (8.6.12/8.6.12) with ESMTP id PAA05382; Wed, 23 Jul 1997 15:05:31 +0200 Received: (from hinsen@localhost) by lmspc1.ibs.fr (8.8.5/8.8.5) id PAA32729; Wed, 23 Jul 1997 15:04:11 +0200 Date: Wed, 23 Jul 1997 15:04:11 +0200 Message-Id: <199707231304.PAA32729@lmspc1.ibs.fr> From: Konrad Hinsen To: dalke@ks.uiuc.edu CC: chemistry@www.ccl.net In-reply-to: <199707220012.TAA11576@bilbao.ks.uiuc.edu> (message from Andrew Dalke on Mon, 21 Jul 1997 19:12:32 -0500) Subject: Re: CCL:Re: CCL:Object-oriented means for computational chemistry programming > In a non-commercial sense I think most application domains have > their own set of tools, and it will be very hard to convince > mathematicians to give up MatLab/Mathematics and astronomers to > give up AIPS/AIPS++ and statisticians give up S-Plus and ... True. So maybe such activities should be more specific to one domain. But I think the basic idea makes sense: since scientists are not able to develop non-trivial high-quality code of their own, due to lack of time and technical knowledge, then some institution should take care of that task and assemble a team of the right experts. > If the code is implemented "correctly" there is no reason to do > this. When was the last time you needed to upgrade ftp, or > telnet, or bc, or yacc? I use libpdb from the CGL to read PDB files That's something else; the programs don't change because the requirements don't change. I was thinking of programs that are changed continuously to incorporate new methods. After a while the result is an big mess. I think I don't have to name examples, we are all using them... > I think the problem isn't that code naturally decays over > time but that it wasn't well designed in the first place. Flaws Exactly! -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From elewars@alchemy.chem.utoronto.ca Wed Jul 23 11:12:57 1997 Received: from alchemy.chem.utoronto.ca for elewars@alchemy.chem.utoronto.ca by www.ccl.net (8.8.3/950822.1) id KAA19425; Wed, 23 Jul 1997 10:26:40 -0400 (EDT) Received: (from elewars@localhost) by alchemy.chem.utoronto.ca (8.7.4/8.7.3) id KAA14915 for chemistry@www.ccl.net; Wed, 23 Jul 1997 10:26:39 -0400 (EDT) Date: Wed, 23 Jul 1997 10:26:39 -0400 (EDT) From: "E. Lewars" Message-Id: <199707231426.KAA14915@alchemy.chem.utoronto.ca> To: chemistry@www.ccl.net Subject: OBJECT_ORIENTED PROGRAMMING ETC 1997 July 23 Hello, Regarding the recent discussions on the list about obect-oriented programming and why no single computer language will please everyone: there is an interesting article, primarily about Java, in _American Scientist_ (not _Scientific American_), July-August 1997, 304-308, by Brian Hayes [bhayes@amsci.org]. It begins: "An unfulfilled dream of computer science is the one true programming language, equally suited to all programs, all programmers, and all computers." E. Lewars ========================== From chall003@maroon.tc.umn.edu Wed Jul 23 11:22:56 1997 Received: from mhub1.tc.umn.edu for chall003@maroon.tc.umn.edu by www.ccl.net (8.8.3/950822.1) id LAA19637; Wed, 23 Jul 1997 11:09:38 -0400 (EDT) Received: from maroon.tc.umn.edu by mhub1.tc.umn.edu; Wed, 23 Jul 97 10:09:38 -0500 Received: from localhost by maroon.tc.umn.edu; Wed, 23 Jul 97 10:09:37 -0500 Date: Wed, 23 Jul 1997 10:09:37 -0500 (CDT) From: Matt Challacombe To: Konrad Hinsen cc: dalke@ks.uiuc.edu, chemistry@www.ccl.net Subject: Optimization hinders evolution In-Reply-To: <199707231304.PAA32729@lmspc1.ibs.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, This OO debate is very interesting. I have a different perspective that I would like to share. It is nicely summarized in a quote by Alan Perlis: Optimization hinders evolution. Thus, if we strive only for optimal re-usable code, we reach a standstill and risk programming very well engineered dinosaurs. This is certainly true of more numerically intensive codes. Excellent examples of algorithms superceeding well engineered implementations include linear scaling electronic structure methods, fast Ewald methods, fast multipole methods, multiple time step methods, multigrid, etc etc. To me, the issue is one of engineering vs science. If computational chemistry is to progress, it is important to focus on building physics and chemistry into our mathematical implementations. To be fair, some areas, such as the visualization of molecular structure, appear to be well developed, and can certainly benefit >from an engineering perspective. On the other hand, it makes little sense to quibble over factors of 1-2 between Fortran and C, when factors of N and N^2 are still to be had. With best regards and wishes, Matt ------------------------------------------------------------------- Dr. Matt Challacombe mf10111@msi.umn.edu Minnesota Supercomputer Inst. TEL: 612-626-0763 1200 Washington Avenue South Minneapolis, MN 55415 -------------------------------------------------------------------- From lestaw.k.bieniasz@uni-tuebingen.de Wed Jul 23 12:12:59 1997 Received: from outmail.zdv.uni-tuebingen.de for lestaw.k.bieniasz@uni-tuebingen.de by www.ccl.net (8.8.3/950822.1) id LAA19706; Wed, 23 Jul 1997 11:17:12 -0400 (EDT) Received: from echem5.orgchemie.chemie (echem5.orgchemie.chemie.uni-tuebingen.de) by outmail.zdv.uni-tuebingen.de (4.1/ZDV-Uni-Tuebingen-1.0) id AA03775; Wed, 23 Jul 97 17:16:54 MES Date: Wed, 23 Jul 1997 17:16:59 +0200 (W. Europe Daylight Time) From: "Lestaw K. Bieniasz" To: Konrad Hinsen Cc: dalke@ks.uiuc.edu, chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means In-Reply-To: <199707231304.PAA32729@lmspc1.ibs.fr> Message-Id: X-X-Sender: coibi01@mailserv.uni-tuebingen.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Tuebingen, 23.07.97 Hello, On Wed, 23 Jul 1997, Konrad Hinsen wrote: > But I think the basic idea makes sense: since scientists are not > able to develop non-trivial high-quality code of their own, due to > lack of time and technical knowledge, then some institution should > take care of that task and assemble a team of the right experts. One possible and evident solution to this problem would be to let the scientists learn more about programming, and let them be much more interdisciplinary than they are allowed to nowadays. They could then produce a quality software without creating additional institution and additional beaurocracy. I am convinced that nobody can produce a really useful software for science, without actively participating in real-life research. This means that only properly educated scientists can do this. Some people would say that interdisciplinary teams can do this (for example brilliant chemists together with brilliant programmers), but I don't agree. Sometimes it takes more time and effort to organize such a team that to produce the software. Of course, this idea requires that the traditional disciplinary structure of science be changed. People should be allowed to make scientific careers in interdisciplinary fields such as for example chemistry-computational science. Otherwise, you will not find interested, right people for the job. There is much talk about this, especially in US, where a substantial revision of higher education programs is suggested, and similar changes are proposed. I hope they will not remain there but will also come to the conservative Europe. Bye, L. *-------------------------------------------------------------------* | Dr. Leslaw Bieniasz | | temporary address: (3rd April 1997 - 31st August 1997) | | Institut fuer Organische Chemie, Universitaet Tuebingen | | Auf der Morgenstelle 18, 72076 Tuebingen, Germany. | | E-mail: lestaw.k.bieniasz@uni-tuebingen.de | *-------------------------------------------------------------------* | permanent address: | | Institute of Physical Chemistry of the Polish Academy of Sciences,| | Molten Salts Laboratory, ul. Zagrody 13, 30-318 Cracow, Poland. | | E-mail: nbbienia@cyf-kr.edu.pl | *-------------------------------------------------------------------* From dalke@ks.uiuc.edu Wed Jul 23 16:13:01 1997 Received: from london.ks.uiuc.edu for dalke@ks.uiuc.edu by www.ccl.net (8.8.3/950822.1) id PAA20885; Wed, 23 Jul 1997 15:19:16 -0400 (EDT) Received: from bilbao.ks.uiuc.edu by london.ks.uiuc.edu with ESMTP (1.37.109.20/16.2 [TBG Mods]) id AA088455556; Wed, 23 Jul 1997 14:19:16 -0500 Received: (from dalke@localhost) by bilbao.ks.uiuc.edu (940816.SGI.8.6.9/8.6.9)id OAA14690; Wed, 23 Jul 1997 14:19:15 -0500 Date: Wed, 23 Jul 1997 14:19:15 -0500 From: Andrew Dalke Message-Id: <199707231919.OAA14690@bilbao.ks.uiuc.edu> To: chall003@maroon.tc.umn.edu Subject: Re: Optimization hinders evolution Cc: chemistry@www.ccl.net Hello, I agree with your statement that emphasis on optimization of current methods without exploration of alternate approaches can cause "very well engineered dinosaurs." What I like about current advances in C++ (templates) is you get the ability to organize your data in more complicated ways (with classes and better data hiding) without the effort it would take to achieve the same in Fortran and without appreciable performance loss. This yields the chance to develop newer and often more complicated methods with less effort; aiding just the sort of exploration into new methods you want. Adding a well-designed scripting language (like Python) makes trying new concepts even easier. Now for a real-life example of where C++ is more useful than Fortran ... I was involved in the development of NAMD, a molecular mechanics program written at UIUC. It has two main goals: * to run well in distributed memory parallel architectures (like workstation clusters) * to be a viable testbed for new methods in molecular modeling, both for us and other groups We made a deliberate decision to use C++ instead of Fortran because the problems we want to address are not only those of computation, but of data management. We need to shuttle computations between, say, 32 processors w/o shared memory and ensure that each processor has the data it needs. It is a tricky job, but by turning the computations into objects and allowing the compute objects to migrate from machine to machine we can simplify the problem. Load balancing can then be achieved by forcing specific compute objects to migrate to specific machines. New algorithms, like fast multipole methods, can be (are!) implemented as new compute objects while methods like multiple time stepping turn into a scheduling problem (ie, "when are the different compute objects called?"). That's not to say this couldn't be done in Fortran, but it would be much more complicated implementation, and less likely that others would use NAMD to develop their own new algorithms. BTW, as another reason for choosing C++; no one in the group knew enough Fortran to develop a large project. Andrew Dalke dalke@ks.uiuc.edu From PDu@synapticcorp.com Tue Jul 22 09:12:42 1997 Received: from S2 for PDu@synapticcorp.com by www.ccl.net (8.8.3/950822.1) id IAA12694; Tue, 22 Jul 1997 08:48:10 -0400 (EDT) Received: by S2 from localhost (router,SLMAILNT V2.2); Tue, 22 Jul 1997 08:39:48 Eastern Daylight Time Received: by S2 from S47.synapticcorp.com (38.232.56.47::mail daemon; unverified,SLMAILNT V2.2); Tue, 22 Jul 1997 08:39:48 Eastern Daylight Time Comments: Authenticated sender is From: "Ping Du" To: chemistry@www.ccl.net Date: Tue, 22 Jul 1997 07:45:08 +0000 Subject: CCL:Object-oriented means for computational chemist Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-Id: <19970722083948.138bb7cb.in@S2> Hi, I found the discussions on OO programming very useful! However, there is a point that I would like to bring up. That is, is it possible to implement an OO design using a non-OO language? The main design features of OOD are abstraction, encapsulation, and inheritance. One may achieve abstraction and encapsulation in a non-OO language by forcing discipline. For example, use struct in C as if there were classes and access data members through "interface" functions. However, implementing inheritance is impossible without an OO language. Inheritance is pobably the most important feature of OO design if you would like your program to be extensible and reusable. > > One can DESIGN software based on these principles (OOD) regardless of > > what language the software is to be implemented in. > > Right. But implementing an OO design in a non-OO language requires > a lot of experience and discipline - to be expected of a professional > programmer, but not of a programming scientist. Ping Du Synaptic Pharmaceutical *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Ping Du, PhD Senior Scientist, Computational Chemistry Email: pdu@synapticcorp.com Synaptic Pharmaceutical Corporation Tel: (201) 261-1331x642 215 College Road, Paramus, NJ 07652 Fax: (201) 261-0623 *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* From bruce@cosy.utmb.edu Tue Jul 22 10:12:44 1997 Received: from cosy.utmb.edu for bruce@cosy.utmb.edu by www.ccl.net (8.8.3/950822.1) id JAA13017; Tue, 22 Jul 1997 09:50:43 -0400 (EDT) Received: (from bruce@localhost) by cosy.utmb.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA05419 for CHEMISTRY@www.ccl.net; Tue, 22 Jul 1997 08:51:53 -0500 From: "Bruce Luxon" Message-Id: <9707220851.ZM5417@cosy.utmb.edu> Date: Tue, 22 Jul 1997 08:51:52 -0500 Organization: Sealy Center for Structural Biology Reply-To: bruce@nmr.utmb.edu X-Phone: (409) 747-6802 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: CHEMISTRY@www.ccl.net Subject: Re: CCL:Vizualization of 3-D flow field: mac-win Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Iraj, I use TRANSFORM and PLOT from Fortner Research on Mac and SGI and have been very pleased with their power and simplicity of use. The URL is http://www.fortner.com/ Bruce Luxon On Jul 22, 12:05am, Iraj Daizadeh wrote: > Subject: CCL:Vizualization of 3-D flow field: mac-win > Hello. > > My new question is the same as the previous one except that it centers on > software (commercial or otherwise) that can display a 2-d or 3-d flow field > (vector field) as well as contours for a mac (preferable) or pc environment. > > Thanks in advance... > > Iraj. > >-- End of excerpt from Iraj Daizadeh -- *=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-* * Bruce A. Luxon, Ph.D * * Assistant Professor * * Sealy Center for Structural Biology U * Dept. of Human Biological Chemistry & Genetics T * University of Texas Medical Branch M * Galveston, TX 77555-1157 B * * * (409)747-6802; Fax (409)747-6850 http://www.hbcg.utmb.edu/ * * bruce@nmr.utmb.edu http://www.nmr.utmb.edu/ * *=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-* From jtgolab@amoco.com Tue Jul 22 10:12:53 1997 Received: from interlock.amoco.com for jtgolab@amoco.com by www.ccl.net (8.8.3/950822.1) id JAA12870; Tue, 22 Jul 1997 09:31:41 -0400 (EDT) Received: by interlock.amoco.com id AA25064 (InterLock SMTP Gateway 3.0 for CHEMISTRY@www.ccl.net); Tue, 22 Jul 1997 08:31:40 -0500 Message-Id: <199707221331.AA25064@interlock.amoco.com> Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-4); Tue, 22 Jul 1997 08:31:40 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-3); Tue, 22 Jul 1997 08:31:40 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-2); Tue, 22 Jul 1997 08:31:40 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-1); Tue, 22 Jul 1997 08:31:40 -0500 From: jtgolab@amoco.com (Joe Golab) Date: Tue, 22 Jul 1997 08:30:27 -0500 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: CHEMISTRY@www.ccl.net Subject: SUMMARY - Reaction Pathway Programs, Part II Cc: jtgolab@amoco.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Hi CCL: Below is an updated summary of responses to the "retro-synthesis" question I asked on 7/21. Thanks to all who have responded. I have edited some of the answers and so I take full responsibility for any errors. Some good references are in the replies themselves, i.e. I did not bother to summarize them. If I get any more answers, I will re-post summary. <> Execute Summary of Answers 1) SYNGEN, Jim Hendrickson, Brandeis University 2) CAMEO, Bill Jorgensen, Yale (<-- Reaction Simulation) 3) SYNTREE, Commerical Software, Vendor? 4) SYNLIB, Dan Chodosh, may not exist anymore 5) REACCS, MDL 6) CAS's reaction data base 7) Chiron, Steve Hannisan (spl?) of U. of Montreal. 8) LAHSA, E.J. Corey, Harvard U. 9) Unknown, Michael Mavrovouniotis, Northwestern 10) Crossfile, Beilstein 11) EROS, Dr. Johann Gasteiger, Erlangen University. 12) ORAC, Pergamon. 13) SECS W. Todd Wipke, University of California, Santa Cruz. 14) WODCA, J. Gasteiger. 15) IGOR/RAIN, Ugi 16) PASCOP, Gerard Kaufmann, University of Strasbourg 17) SYNCHEM, H. Gelernter U.S. Stony Brook ______________________________ Original Note __________________________________ Subject: CCL:Reaction Pathway Program Author: chemistry-request (chemistry-request@www.ccl.net) at unix,sh Date: 7/14/97 4:43 PM Dear CCL Member: Do you know of any (engineering, chemistry, biological, etc) program that given a compound would suggest any and all reaction pathways toward that compound (no matter how outlandish from a thermodyanmic standpoint)? For example, given tolune, the program would suggest: 1) benzene + methane -> toluene 2) methylcyclohexane -> toluene + H2 3) methane + heat/pressure -> toluene + H2 4) ETC. Perhaps this is really a database that is part of a program. Any leads would be gratefully appreciated! Thanks. :Joe Golab, jtgolab@amoco.com _____________________________Reply Separator_________________________________ Subject: Re: CCL:Reaction Pathway Program Author: lchen (lchen@mdli.com) at unix,mime Date: 7/14/97 5:16 PM Dear Joe: Please check the following SYNGEN site: http://syngen2.chem.brandeis.edu/syngen.html you may find something interesting you. -Lingran ********************************************************** Lingran Chen, Ph.D. Senior Scientific Programmer MDL Information Systems, Inc. 14600 Catalina Street San Leandro CA 94577 Phone: (510) 895-1313, Ext. 1305 FAX: (510) 614-3616 Email: LCHEN@MDLI.COM URL: http://www.mdli.com http://syngen2.chem.brandeis.edu/~chen/lingran.html ********************************************************** _____________________________Reply Separator_________________________________ Subject: Re: CCL:Reaction Pathway Program Author: eslone (eslone@patriot.net) at unix,mime Date: 7/14/97 6:32 PM Talk to Jim Hendrickson at Brandeis University. He has a program called SynGen. ___________________________________________________________________ J. Eric Slone Scientific Consulting Services 5500 Holmes Run Parkway, Suite 501 Alexandria, Virginia 22304-2851 Phone: (703) 461-7078 mailto:eslone@patriot.net Fax: (703) 751-6639 http://www.patriot.net/users/eslone ___________________________________________________________________ _____________________________Reply Separator_________________________________ Subject: Re: CCL:Reaction Pathway Program Author: dsmith (dsmith@CTCnet.Net) at unix,mime Date: 7/14/97 9:12 PM Joe: I am not familiar with any program that will suggest ALL reaction pathways... there are just way too many possibilities, which is why we still have synthetic organic chemists. You are probably familiar with Bill Jorgensen's CAMEO program (I hope I have the name correct), which can suggest 'reasonable' synthetic routes to various types of compounds and functionality. There is also a commercial program (not that Bill doesn't sell his programs, ;)) called SYNTREE (I believe). There were some papers about this at either the last ACS National meeting in San Francisco or at the Midland, MI, ACS Regional meeting in May. I can look for more information if you wish, but I am at home and just finishing up a vacation while I write this. Regardless, both of these programs use a combination (I believe) of data bases and "expert" algorithms to select likely reactions. I don't know of anything that will give you all possible routes, except perhaps an aggressive undergraduate who has just finished his/her organic final exam. There was also SYNLIB that came from the late Dan Chodosh... I don't know if anyone picked up that program so I can't tell you if it still exists. This was purely data base based and matched based on user-defined descriptors, if I remember correctly from my postdoc days. MDL REACCS and CAS's reaction data base are two others that come to mind. I would also love to hear from anyone else about similar programs. Please post to CCL rather than just to Joe. Doug Smith -- Dr. Douglas A. Smith, President and CEO | voice: (814) 255-7859 The DASGroup, Inc. | fax: (814) 255-3517 1732 Lyter Drive, 2nd Floor | email: dsmith@dasgroup.com Johnstown, PA 15905 | WWW: http://www.dasgroup.com Contract R&D specialists in modeling, simulation, synthesis and risk assessment for chemistry, materials science, and biotechnology. _____________________________Reply Separator_________________________________ Subject: Re: CCL:Reaction Pathway Program Author: Willie (Willie@microsimulations.com) at unix,mime Date: 7/15/97 1:12 AM Joe, Two programs that can do retrosynthetic analysis, 1. Chiron, from Prof. Steve Hannisan (wrong spelling?) of U. of Montreal. 2. LAHSA, from prof. E.J. Corey of Harvard U. -- Willie Cui, Ph.D. voice 201-512-0486 MicroSimulations fax: 201-512-0489 478 Green Mountain Rd. email: willie@microsimulations.com Mahwah, NJ 07430 URL: http://www.microsimulations.com _____________________________Reply Separator_________________________________ Subject: RE: Reaction Pathway Program Author: RICHEYFA (RICHEYFA@ucarb.com) at unix,mime Date: 7/15/97 6:12 AM Hi, Joe, I had a similar question when looking for new routes to commodity chemicals. I found references to techniques for making expensive [usually pharmaceutical] chemicals which would take a target structure and elaborate[!] multistep pathways from known precursors. I think one was E.J. Corey's group's product. At least one of these gave synthetically viable guesses for transformations so probably weeded out a lot of the thermodynamically infeasible routes. I haven't pursued this very far but was left with the feeling that there was a lot of work in the 80's and the only thing that has survived outside academe has been the pharmaceutical part. I may be wrong in this. I never did summarize my work but if you are interested I can send you references with brief comments. I wanted this approach to automate the cataloging of possible synthetic routes including finding the ones that I'd overlook because of my particular chemical background. Forrest Richey Union Carbide Corporation Technical Center Bldg 740 Room 4107 S. Charleston, WV 25303 (304)747-4964 Two things happen when you reach fifty, and if I could remember one, I wouldn't worry about the other two. _____________________________Reply Separator_________________________________ Subject: Reaction Pathways Author: burkhart (burkhart@goodyear.com) at unix,mime Date: 7/15/97 9:00 AM Hi Joe, If I'm not mistaken, Prof. Bill Jorgensen's group @Yale worked on a program called CAMEO. As I remember it, they were trying to use it as a reaction chemistry "assistant"--but I'm not sure how far they got. ----------------------------------+------------------------------------ Papernet: Craig W. Burkhart | Baseball & summer--What could be Goodyear Research | better? The birds are singing and 142 Goodyear Blvd. | the BATS are out! Akron, OH 44305 | Indians update: 48-37 (.564) Mouthnet: 330.796.3163 | 'Best little .500 club' $60 mil Faxnet: .3304 | can buy... (swampland, anyone?) Internet: cburkhart@goodyear.com | Pitching REALLY Stinks!!! UGH! ----------------------------------+------------------------------------ _____________________________Reply Separator_________________________________ Subject: Re: CCL-Reaction Pathway Pro Author: mnliebman (mnliebman@vysis.com) at unix,sh Date: 7/15/97 9:59 AM RE>CCL:Reaction Pathway Program 7/15/97 Joe try contactine Michael Mavrovouniotis at Northwestern- mlmavro@nwu.edu I think Michael 271 7190 _____________________________Reply Separator_________________________________ Subject: Your e-mail to CCL Author: pierre (pierre@mdli.com) at unix,mime Date: 7/15/97 10:14 AM Dear Joe, I received a copy of your e-mail attached at the end of my reply. You may remember that we talked on the phone a few month ago. Although my answer is obviously biased by the fact that I work for MDL, my experience after 9 years working with the large pharma and chemical industries in Europe and in the US is that there seems to be no good way to have a prediction program. A lot of companies have tried, and they have ended up licensing our databases or other (like Beilstein Crossfire). The advantage they have found in our system, compared to other database systems, (especially since we introduced ISIS, the client server system we provide now) is the flexibility of our querying interface. You can search not only on exact reactions, but also on things like " find an example of a reaction where this fragment is formed". Or "find an example of a reaction using these conditions where a fragment is unaltered". As an example, to address your query below, we would draw the toluene, and define it as a product, and then we would perform a search known as "structure as product not as reactant, or "sub-structure as product, not as reactant". Which basically defines that the toluene has to be formed during the reaction. You could also refine the query by specifying certain classes of reactions you do not want (list catalysts that are expensive etc). Running the query you use as an example on our databases leaded to 113 reactions out of 107 publications. The query was exclusively dealing with the toluene as product, no substituted toluene was allowed. In some of these reactions the benzene is a by product, and probably a lot of them are dealing with cleavage from a larger structure, but these reactions could still be of interest, you would have to judge. >> [Parts of Original Message Edited/Deleted] << Sincerely Pierre Allemand Ph.D. Senior Account Manager _____________________________Reply Separator_________________________________ Subject: Re: CCL:Reaction Pathway Program Author: chamot (chamot@chamotlabs.com) at unix,sh Date: 7/16/97 3:28 PM Hi Joe, I haven't heard anything about it for a while, but I think you want the program: o LHASA (Logic and Heuristics Applied to Synthetic Analysis) is a backward chaining synthesis planning program which uses a database of specially coded chemical reactions and definitions for strategic bonds to analyze potential synthetic pathways for a molecule. The target molecule is analyzed according to the number of rules and likely synthetic pathways are produced for examination. -- Alan Long (last contact I know of), Harvard University. At the time, it seemed very systematic, and would develop a retrosynthetic tree (basically, "unsynthesize" the compound), showing all precursors for all reasonable reactions for however many reaction steps you cared to follow back. You could control how focused it was by defining minimum expected yields, and paring branches you didn't want it to follow, or you could let it go unconstrained. I don't know much about the following programs, from the list I keep on my web site for reference, but you may be interested in one of them, too: o CAMEO (Computer Assisted Mechanistic Evaluation of Organic Reactions) is a forward chaining reaction prediction program. Runs on VAX/VMS computer systems and uses Tektronix graphics. -- William L. Jorgensen, Yale University. o EROS (Elaboration of Reactions for Organic Synthesis) is a computer assisted synthesis program developed by Gasteiger et.al. which uses a set of rules to propose synthetic routes. -- Dr. Johann Gasteiger, Erlangen University. o ORAC - (Organic Reaction Accessed by Computer) Computer Assisted Synthesis -- Pergamon. o SECS (Simulation and Evaluation of Chemical Synthesis) is a retro-synthesis analysis program in much the same mold as LHASA and SYNCHEM. The target molecule is analyzed according to strategic reactions using a database of known reactions as a guide for predicting single step transformations to simplified compounds. Several iterations of the procedure are required to develop a synthesis plan. -- W. Todd Wipke, University of California, Santa Cruz. o WODCA - Computer Assisted Synthesis -- J. Gasteiger. EC --- Ernest Chamot Chamot Labs, Inc. 530 E. Hillside Rd. Naperville, Illinois 60540 (630)637-1559 echamot@chamotlabs.com http://www.chamotlabs.com/cl _____________________________Reply Separator_________________________________ Subject: Re: CCL:Re: CCL:Reaction Pathway Program Author: chemistry-request (chemistry-request@www.ccl.net) at unix,mime Date: 7/15/97 3:18 PM Programs which perform exhaustive bond reordering for reaction prediction or synthesis planning, or assemble reaction networks between speicified endpoints, can do this. Typically, these programs employ additional constraints to prevent entering the outlandish domains, but these checks can be disabled :-), and thus all reaction pathways generated. Be warned: You quickly generate truly enourmous numbers of pathways. Example programs which could work in this mode are EROS5 (Gasteiger) and IGOR/RAIN (Ugi). For literature references and an overview, see Angewandte Chemie, Int. Ed. 1995, 34, 2613-2633. -- Dr. Wolf-D. Ihlenfeldt Computer Chemistry Center, University of Erlangen-Nuernberg Naegelsbachstrasse 25, D-91052 Erlangen (Germany) Tel (+49)-(0)9131-85-6579 Fax (+49)-(0)9131-85-6566 --- The three proven methods for ultimate success and fame: 1) Nakanu nara koroshite shimae hototogisu 2) Nakanu nara nakasete miseyou hototogisu 3) Nakanu nara naku made matou hototogisu _____________________________Reply Separator_________________________________ Subject: CCL:Re:CCL: Reaction Pathway Program Author: chemistry-request (chemistry-request@www.ccl.net) at unix,mime Date: 7/16/97 4:09 AM Douglas, Pure and Appl. Chem. vol.62, 10, pp 1921 "Abstract- An interactive computer program, CAMEO, has been developed to predict products of organic reactions given the starting materials and conditions..." At the beginning CAMEO was a reaction simulator, but is there a new module now in CAMEO that " can suggest 'reasonable' synthetic routes to various types of compounds and functionality"? I don't know if they are all maintained and commercialized but a lots of Computer Assisted Organic Synthesis (CAOS) programs that works in a retrosynthetic way have been designed. I suggest you to have a look at: "Computer-assisted Solution of Chemical Problems - The historical Development and the Present State of the Art of a New discipline of Chemistry" by Ivar Ugi and al. in Angew. Chem. Int. Ed. Engl. 1993, 32, 201-227 It's a huge review on computer chemistry, but a good part of it deals with CAOS. Now if you want a quick answer on one of the commercial products, try http://www.chem.leeds.ac.uk/LUK/ Hope it helps Jean-Francois Marchaland _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Dr J.F. Marchaland jfm@mi.leeds.ac.uk _/ _/ ICAMS, School of Chemistry UK: 0113 233 6567 _/ _/ University of Leeds internat.: +44 113 233 6567 _/ _/ LS29JT LEEDS FAX: 6563 _/ _/ _/ _/ http://chem.leeds.ac.uk/ICAMS/people/jfm.html _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _____________________________Reply Separator_________________________________ Subject: Retrosynthesis analysis Author: jfm (jfm@mi.leeds.ac.uk) at unix,mime Date: 7/17/97 12:36 PM CAMEO does not do "retro-synthesis", but reaction simulation. Besides you could add: PASCOP: Gerard Kaufmann, University of Strasbourg SYNCHEM: H. Gelernter U.S. Stony Brook http://www.cs.sunysb.edu/~ors/Fall-1994/gelern-94.html SECS: W.T. Wipke UC Santa-Cruz regards Jeff _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Dr J.F. Marchaland jfm@mi.leeds.ac.uk _/ _/ ICAMS, School of Chemistry UK: 0113 233 6567 _/ _/ University of Leeds internat.: +44 113 233 6567 _/ _/ LS29JT LEEDS FAX: 6563 _/ _/ _/ _/ http://chem.leeds.ac.uk/ICAMS/people/jfm.html _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _____________________________Reply Separator_________________________________ Subject: RE: CCL:SUMMARY - Reaction Pathway Programs Author: yvonne.c.martin (yvonne.c.martin@abbott.com) at unix,mime Date: 7/18/97 6:10 PM There is also CESA from Peter Johnson @ Leeds. (johnson@mi.leeds.ac.uk) >-- END Tue Jul 22 08:24:32 CDT 1997 -- :Joe jtgolab@amoco.com (630) 961-7878 +------------------------------------------------+ | A man doesn't automatically get my respect. | | He has to get down in the dirt and beg for it. | | - Jack Handey | +------------------------------------------------+ --MimeMultipartBoundary-- From mckennam@curie.ml.wpafb.af.mil Tue Jul 22 16:12:46 1997 Received: from curie.ml.wpafb.af.mil for mckennam@curie.ml.wpafb.af.mil by www.ccl.net (8.8.3/950822.1) id QAA15174; Tue, 22 Jul 1997 16:07:28 -0400 (EDT) From: Received: (from mckennam@localhost) by curie.ml.wpafb.af.mil (8.8.5/8.8.5) id QAA16725; Tue, 22 Jul 1997 16:07:27 -0400 (EDT) Date: Tue, 22 Jul 1997 16:07:27 -0400 (EDT) Message-Id: <199707222007.QAA16725@curie.ml.wpafb.af.mil> To: chemistry@www.ccl.net Subject: Insight II [MSI] periodic cell correl. f's Reply-To: mckennam@curie.ml.wpafb.af.mil I'm looking for people who are pretty familiar with MSI's Insight II application, especially the Amorphous Cell module, *OR* who are familiar with how correlation functions are computed on periodic systems for chemical research. I am trying to reproduce some Insight output, and failing. My Problem (in brief): -------------------- I wrote a program to compute pair and orientational correlation functions from molecular conformations (e.g., PDB files.) To test it, I use Insight II to compute the same functions for the same conformations. When I compare the functions using *NON* periodic systems, I get the same answers. When I compare them using *PERIODIC* systems, our functions agree FOR SEPARATION DISTANCES (r) LESS THAN SOME RADIUS (r_a) (r_a is a bit more than 1/2 the smallest period.) For larger "r" values, our functions sometimes agree, but sometimes my pair correlation function is larger. (Mine is never smaller.) My program appears to be finding more pairs of atoms than Insight. When computing the orientational correlation, the results are also consistent with my program finding more pairs than Insight for r > r_a. I need to know (a) if Insight II is doing something unexpected, and/or (b) whether my idea of how to handle periodic systems is corect (see below.) [Yes, I have contacted MSI about this. They don't appear eager to invest much effort in getting to the bottom of it, which is understandable, since it could be my bug or mistake.] How I Handle Periodic Systems (or, "Is This Correct?") ----------------------------- For non-periodic systems, I consider all pairs of atoms with one atom chosen from subset A and one from B. For periodic systems, I consider subset B to also include images of atoms chosen from subset B, i.e., for each "parent" position in B, I also consider "image" positions of the form (image pos.) = (parent pos.) + i*v1 + j*v2 + k*v3 where v1, v2, and v3 are the image, or "periodicity" vectors (each has the same length and direction as an edge of the periodic cell) and i, j, and k are arbitrary integers. Since "arbitrary" i, j, and k would produce an infinite number of pairs, I use the fact that we are not interested in pairs with separation (r) more than some r_max, and compute a crude upper bound for |i|, |j|, and |k| , so we start with a finite number of pairs. (Later on, we throw away the remaining pairs that have r > r_max.) As far as I can see, as long as the upper bounds are large enough, I should get all possible pairs with r < r_max. Any mistakes should result in my leaving out a pair I should have. Such mistakes would not have the effect that I see -- me getting more pairs than Insight. Conclusion ---------- Please send me any specific suggestions, questions, etc., via E-mail, and I will summarize what I find out. ------------------------------------------------------------------------ Alan McKenney Wright-Patterson AFB, Dayton, OH From tvd@msi.com Wed Jul 23 18:13:07 1997 Received: from bioc1.msi.com for tvd@msi.com by www.ccl.net (8.8.3/950822.1) id RAA22455; Wed, 23 Jul 1997 17:33:05 -0400 (EDT) Received: by bioc1.msi.com (5.64/0.0) id AA17349; Wed, 23 Jul 97 14:32:40 -0700 Received: from iris69.msi.com(146.202.3.69) by bioc1.msi.com via smap (V2.0) id xma017340; Wed, 23 Jul 97 14:32:24 -0700 Received: by iris69.msi.com (950413.SGI.8.6.12/930416.SGI) for CHEMISTRY@www.ccl.net id OAA23918; Wed, 23 Jul 1997 14:32:14 -0700 Date: Wed, 23 Jul 1997 14:32:14 -0700 From: tvd@msi.com (Ton van Daelen) Message-Id: <199707232132.OAA23918@iris69.msi.com> To: CHEMISTRY@www.ccl.net Subject: Re: Biosym scripting language Hello Pieter - The Insight scripting language is indeed called BCL, which stands for Biosym Command Language. The syntax has now been fully documented (in the Insight user manual) and we can assist you with any questions that you still might have. The simulation environment Discover has its own scripting language which is based on Tcl. With many users migrating to the Cerius2 environment, we have developed a C2 scripting language based on Tcl, hence called C2.Tcl. This language takes advantage of all the Tcl control structures, list functions etc, and combines that with Cerius2 commands. In addition you can add a simple GUI to a script using a Tk like GUI definition file. However, C2.Tcl is designed for relatively simple customization. For an efficient and flexible integration of an external code, you can choose to use the C2.SDK toolkit and API set to write a much more interactive interface to your code. For more information on C2.Tcl and C2.SDK visit the following URLs: http://www.msi.com/support/sdk/ http://www.msi.com/support/sdk/pub/scripting/macro_language.html Regards - Ton >>That's actually what Biosym has been doing for last couple of years. >>Their script language was actually Tcl >>(if I am not mistaken...) >> >Discover's scripting language is TCL, but the regular Biosym scripting >language is an abomination called BCL (Biosym Control Language ?). The >syntax is not fully documented (kind of strange as there is a BCL >interpreter), nor does there seem to be anybody at MSI who has anywhere >near complete BCL knowledge. When we were still actively working on our >BForce implementation (the MSI version is known as Affinity), we ran into >many problems, most often related to parameter passing. It would have made >sense to change from BCL to TCL with specific Biosym extensions if it were >not for the fact that it can be expected (conjecture on my part) that over >time users will migrate from insightII to Cerius2 and, therefore, revamping >insightII does not make sense. > > Pieter Stouten Ton van Daelen Product Manager Software Developer's Kit __o E: tvd@msi.com _`\<,_ Molecular Simulations P: -1-619-546-5329 (*)/ (*) 9685 Scranton Road F: -1-619-458-0136 /\/\/\/\/\/\ San Diego, CA 92121 W: http://www.msi.com Check out What's New in SDK on the SDK web pages at http://www.msi.com/support/sdk/ From gbarbeau@eagle.ibc.edu Wed Jul 23 19:13:01 1997 Received: from eagle.ibc.edu for gbarbeau@eagle.ibc.edu by www.ccl.net (8.8.3/950822.1) id SAA22629; Wed, 23 Jul 1997 18:14:19 -0400 (EDT) Received: from localhost by eagle.ibc.edu (5.65/1.35) id AA00603; Wed, 23 Jul 97 18:07:25 -0500 Date: Wed, 23 Jul 1997 18:07:24 -0500 (CDT) From: Gina Barbeau To: chemistry@www.ccl.net Subject: Help with the Docking module of Biosym Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear CCL members: In a previous query sent to all CCL members I requested help on docking. I am trying to use the Docking module of Biosym with little success. I have computed the grid using the default grid step size of 0.666. But when I go to use the intermolecular evaluation on the grid choosing only the grid to monitor, to make docking in real time faster I am only able to get vdW values for the area. The total energy and elect energy consistently displays either inf or -inf. I have tried a larger grid size and smaller cutoff values, but it still gives me inf or -inf. How do I get around this problem? Unfortunately, the Biosym manual has offered no useful information in regards to this. Thanks again. Gina Barbeau email: gbarbeau@eagle.ibc.edu From brian@bert.chem.wsu.edu Wed Jul 23 20:13:11 1997 Received: from cheetah.it.wsu.edu for brian@bert.chem.wsu.edu by www.ccl.net (8.8.3/950822.1) id TAA23000; Wed, 23 Jul 1997 19:48:19 -0400 (EDT) Received: from bert.chem.wsu.edu (bert.chem.wsu.edu [134.121.43.22]) by cheetah.it.wsu.edu (8.8.5/8.8.5) with SMTP id QAA10960 for ; Wed, 23 Jul 1997 16:46:01 -0700 (PDT) Received: by bert.chem.wsu.edu (AIX 3.2/UCB 5.64/4.03) id AA19495; Wed, 23 Jul 1997 16:36:04 -0700 From: brian@bert.chem.wsu.edu (Brian W. Beck) Message-Id: <9707232336.AA19495@bert.chem.wsu.edu> Subject: CHM:2^n restriction on parallel To: charmm-bbs@emperor.harvard.edu (CHARMM LIST) Date: Tue, 22 Jul 1997 15:34:14 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: brian@bert.chem.wsu.edu I currently using CHARMM24a3 on a 16node IBM SP2. I've noticed that I can only run in parallel if I request a power of 2 number of nodes (1,2,4,8,16). However, a couple of years ago, I had some runs done on a CONVEX which didn't have this power of 2 restriction. Am I doing something wrong or is this restriction a function of the parallel environment of the AIX/SP2? (The reason I ask is that there are occasionally times when I could grab 12 nodes, but can't because it doesn't work.) -Brian -- ============================================================================= | .---------.| Brian W. Beck | E-mail Addresses: | |/\ | || Biochem/Biophysics | brian@bert.chem.wsu.edu | || \\ WSU || Washington St. Univ| brian_beck@wsu.edu | |\ - *|| 639 Fulmer | URL http://elmo.chem.wsu.edu/~brian | | | || Pullman, WA, USA | VOICE (509) 335-4083 | | \___________|| 99164-4660 | FAX (509) 335-9688 | =============================================================================