From Leif.Laaksonen@pobox.csc.fi Wed Feb 9 03:21:04 1994 Received: from pobox.csc.fi for Leif.Laaksonen@pobox.csc.fi by www.ccl.net (8.6.4/930601.1506) id CAA22039; Wed, 9 Feb 1994 02:44:47 -0500 Received: from [128.214.46.163] (laaksone.csc.fi) by pobox.csc.fi with SMTP id AA19533 (5.65c8+/IDA-1.4.4 for ); Wed, 9 Feb 1994 09:44:25 +0200 Date: Wed, 9 Feb 1994 09:44:25 +0200 Message-Id: <199402090744.AA19533@pobox.csc.fi> X-Sender: laaksone@finsun.csc.fi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 4 (Low) To: shepard@dirac.tcg.anl.gov (Ron Shepard) From: Leif.Laaksonen@csc.fi Subject: Re: CCL:CCL:Re: High Cost of Comp. Chem. Cc: chemistry@ccl.net We computational chemists (before we used to be quantum chemists) we used to be in the forefront of computational science. Usually this job involved the task of finding a solution to a diff. equation or a solution to some other equation. During the last 30 years we have developed huge program packages to tackle this problem. However, as I see it, computational sciences (and computational chemistry) is much more that that. Today we also have to use other tools like visualisation tools (molecular graphics), databases, information servers (Mosaic or Gopher). Traditional computational chemists have not contributed too much in these fields. In fact quite much of this has been developed by the Biology community. And surprising much of this is available free of charge (at least so far). Only time shows if the software from the Biology community also will be commercialised. > >>As the object orientation becomes stronger, >>so maintenance might just become less of a problem. > >Heh, Heh... ;-) > This is really a long time dream of mine. Just imagine if there would be more object oriented classes in computational chemistry code. You could just plug in and use a class for PM3, MP2, Leap-Frog algorithm and so on. All code would be easier reused. Today too much code is still developed for one particular approximation or application. It does not really bother me a bit if I have to learn a new operating system or programming language to solve a new scientific problem. The problem is the old code. The computational biochemists have been in a very lucky position because when they started hardly nobody wanted to program in FORTRAN (no war, please) and they could use all the nice networking tools available in Unix. I believe this is something we quantum chemists have in front of us very soon. The whole consept has to be redefined. Perhaps this will never happen because there is so much "old" code available which will never be rewritten. But for the sake of science I wish this will happen. After all as Ron Shepard said we all appreciate more the kind of knowledge that remains useful for decades rather than months or years. My $.02 -leif laaksonen ------------------------------------------------------------------- Leif Laaksonen | Center for Scientific Computing | Phone: 358 0 4572378 P.O. Box 405 | Telefax: 358 0 4572302 FIN-02101 Espoo | Voice Mail: 358 486257407 FINLAND | Mail: Leif.Laaksonen@csc.fi -------------URL: http://www.csc.fi/faces/leif.html---------------- New opinions are always suspected, and usually opposed, without any other reason but because they are not already common. John Locke ------------------------------------------------------------------- From ferenc@rchsg8.chemie.uni-regensburg.de Wed Feb 9 06:21:39 1994 Received: from rrzs1.rz.uni-regensburg.de for ferenc@rchsg8.chemie.uni-regensburg.de by www.ccl.net (8.6.4/930601.1506) id GAA23007; Wed, 9 Feb 1994 06:09:16 -0500 Received: from rchsg8.chemie.uni-regensburg.de by rrzs1.rz.uni-regensburg.de (4.1/URRZ-relay (1.4)) id AA18984; Wed, 9 Feb 94 12:08:49 +0100 Received: by rchsg8.chemie.uni-regensburg.de (920330.SGI/BelWue-1.0SG(subsidiary)) (for CHEMISTRY@ccl.net) id AA27014; Wed, 9 Feb 94 12:10:23 +0100 Date: Wed, 9 Feb 94 12:10:23 +0100 From: ferenc@rchsg8.chemie.uni-regensburg.de (Ferenc Molnar) Message-Id: <9402091110.AA27014@rchsg8.chemie.uni-regensburg.de> To: CHEMISTRY@ccl.net Subject: OOP in comp. chem. Leif Laaksonen wrote: >This is really a long time dream of mine. Just imagine if there would be >more object oriented classes in computational chemistry code. You could >just plug in and use a class for PM3, MP2, Leap-Frog algorithm and so on. >All code would be easier reused. Today too much code is still developed >for one particular approximation or application. . . . >I believe this is something we >quantum chemists have in front of us very soon. The whole consept >has to be redefined. Perhaps this will never happen because there is >so much "old" code available which will never be rewritten. But for >the sake of science I wish this will happen. After all as Ron Shepard >said we all appreciate more the kind of knowledge that remains useful >for decades rather than months or years. I agree with you, "something" has to happen. The old code shold be rewritten and the concepts should be altered. For example, a molecular dynamics program could be written very efficiently in the framework of an object oriented approach. Atoms and molecules designed as class objects, interacting by some virtual functions, would make it easy to add new types of features. The whole thing could be done for example in C++ (don't say C++ is not OOP). And as a bonus the administration of the code would be easier. These were my ideas when I started the project I am currently working on. But there are at least three drawbacks. First: You need quite a long time for designing your program in an OOP-language when you are used to modular programming. Second: FORTRAN 77 is the most portable language (C programmers forgive me!). Third and most important: As you always have a lack of hardware resources, you need a compiler which optimizes efficiently. Often the raw speed of your calculation is the crucial point. FORTRAN compilers have quite a history and are very effective in "number crunching" and are essentially bug free. The advantage of C++ (or say FORTRAN 90) is that you can handle dynamic memory allocations, but this can slow down the program and prevent effective optimization. And thus I decided (with considerable regrets) to use the hereditary style of programming for my project. In my oppinion OOP methods should only be used for large scale projects. These projects have to be supported by some organization like an university or a company and are scheduled for years. I think that in this case the financial grounds are there for even reprogramming functioning code (e.g. Hyperchem from Hypecube). I wonder if there are more such projects going on somwhere out there and I would be very much interested in details. Yours sincerely, Ferenc Molnar --------------------------------------------------------------------------- Institut fuer Physikalische und Theoretische Chemie - Lehrstuhl Prof. Dick - Tel.: (+49) 941 943-4466 /-4486 Universitaet Regensburg Fax.: (+49) 941 943-4488 Universitaetsstrasse 31 D-93053 Regensburg Deutschland / Germany --------------------------------------------------------------------------- EMail (SMTP): ferenc@rchsg8.chemie.uni-regensburg.de c5071@rchs1.chemie.uni-regensburg.de ferenc@rchnw2.ngate.uni-regensburg.de --------------------------------------------------------------------------- :-) There is more to live than increasing its speed. -- Ghandi ;-) --------------------------------------------------------------------------- From vkitzing@sunny.mpimf-Heidelberg.mpg.de Wed Feb 9 08:20:56 1994 Received: from foxy.mpimf-heidelberg.mpg.de for vkitzing@sunny.mpimf-Heidelberg.mpg.de by www.ccl.net (8.6.4/930601.1506) id HAA23969; Wed, 9 Feb 1994 07:22:32 -0500 Received: from sunny.mpimf-heidelberg.mpg.de by foxy.mpimf-heidelberg.mpg.de (5.65+/1.34) id AA19649; Wed, 9 Feb 94 13:19:28 +0100 Received: from [192.109.43.34] (mac10) by sunny.mpimf-Heidelberg.mpg.de (4.1/SMI-4.1) id AA21266; Wed, 9 Feb 94 13:17:54 +0100 Date: Wed, 9 Feb 94 13:17:54 +0100 Message-Id: <9402091217.AA21266@sunny.mpimf-Heidelberg.mpg.de> To: From: vkitzing@sunny.mpimf-Heidelberg.mpg.de (Eberhard von Kitzing) Subject: Re: CCL:activation barrier Cc: CHEMISTRY@ccl.net (Computational Chemistry List) >Hi netters, > >I was wondering whether someone can help me with the following problem: > >I have done several molecular dynamics simulations of an organic ring >system at different temperatures using SYBYL. At "low" temperatures only one >conformation could be detected (< 2000 K), whereas at high temperatures >(> 2000 K) an additional conformation occurs. Can I draw any conclusions >on the height of the activation barrier between the two conformations >from the dynamics runs? The inverse of the frequency of flipping should be in the order of the rate of going from one conformer to the other for a given temperature. ------------------------------------------------------------------------- Eberhard von Kitzing Max-Planck-Institut fuer Medizische Forschung Jahnstr. 29, D69120 Heidelberg, FRG FAX : +49-6221-486 459 (work) Tel.: +49-6221-486 467 (work) Tel.: +49-6221-385 129 (home) internet: vkitzing@sunny.MPImF-Heidelberg.mpg.de From ferenc@rchsg8.chemie.uni-regensburg.de Wed Feb 9 08:27:56 1994 Received: from rrzs1.rz.uni-regensburg.de for ferenc@rchsg8.chemie.uni-regensburg.de by www.ccl.net (8.6.4/930601.1506) id HAA24111; Wed, 9 Feb 1994 07:40:41 -0500 Received: from rchsg8.chemie.uni-regensburg.de by rrzs1.rz.uni-regensburg.de (4.1/URRZ-relay (1.4)) id AA23699; Wed, 9 Feb 94 13:40:19 +0100 Received: by rchsg8.chemie.uni-regensburg.de (920330.SGI/BelWue-1.0SG(subsidiary)) (for CHEMISTRY@ccl.net) id AA27361; Wed, 9 Feb 94 13:41:35 +0100 Date: Wed, 9 Feb 94 13:41:35 +0100 From: ferenc@rchsg8.chemie.uni-regensburg.de (Ferenc Molnar) Message-Id: <9402091241.AA27361@rchsg8.chemie.uni-regensburg.de> To: CHEMISTRY@ccl.net Subject: OOP in comp. chem. Oh, I guess something went wrong with my last mail! So here is another try, excuse me! Leif Laaksonen wrote: >This is really a long time dream of mine. Just imagine if there would be >more object oriented classes in computational chemistry code. You could >just plug in and use a class for PM3, MP2, Leap-Frog algorithm and so on. >All code would be easier reused. Today too much code is still developed >for one particular approximation or application. . . . >I believe this is something we >quantum chemists have in front of us very soon. The whole consept >has to be redefined. Perhaps this will never happen because there is >so much "old" code available which will never be rewritten. But for >the sake of science I wish this will happen. After all as Ron Shepard >said we all appreciate more the kind of knowledge that remains useful >for decades rather than months or years. I agree with you, "something" has to happen. The old code shold be rewritten and the concepts should be altered. For example, a molecular dynamics program could be written very efficiently in the framework of an object oriented approach. Atoms and molecules designed as class objects, interacting by some virtual functions, would make it easy to add new types of features. The whole thing could be done for example in C++ (don't say C++ is not OOP). And as a bonus the administration of the code would be easier. These were my ideas when I started the project I am currently working on. But there are at least three drawbacks. First: You need quite a long time for designing your program in an OOP-language when you are used to modular programming. Second: FORTRAN 77 is the most portable language (C programmers forgive me!). Third and most important: As you always have a lack of hardware resources, you need a compiler which optimizes efficiently. Often the raw speed of your calculation is the crucial point. FORTRAN compilers have quite a history and are very effective in "number crunching" and are essentially bug free. The advantage of C++ (or say FORTRAN 90) is that you can handle dynamic memory allocations, but this can slow down the program and prevent effective optimization. And thus I decided (with considerable regrets) to use the hereditary style of programming for my project. In my oppinion OOP methods should only be used for large scale projects. These projects have to be supported by some organization like an university or a company and are scheduled for years. I think that in this case the financial grounds are there for even reprogramming functioning code (e.g. Hyperchem from Hypecube). I wonder if there are more such projects going on somwhere out there and I would be very much interested in details. Yours sincerely, Ferenc Molnar --------------------------------------------------------------------------- Institut fuer Physikalische und Theoretische Chemie - Lehrstuhl Prof. Dick - Tel.: (+49) 941 943-4466 /-4486 Universitaet Regensburg Fax.: (+49) 941 943-4488 Universitaetsstrasse 31 D-93053 Regensburg Deutschland / Germany --------------------------------------------------------------------------- EMail (SMTP): ferenc@rchsg8.chemie.uni-regensburg.de c5071@rchs1.chemie.uni-regensburg.de ferenc@rchnw2.ngate.uni-regensburg.de --------------------------------------------------------------------------- :-) There is more to live than increasing its speed. -- Ghandi ;-) --------------------------------------------------------------------------- From ferenc@rchsg8.chemie.uni-regensburg.de Wed Feb 9 09:21:35 1994 Received: from rrzs1.rz.uni-regensburg.de for ferenc@rchsg8.chemie.uni-regensburg.de by www.ccl.net (8.6.4/930601.1506) id IAA24378; Wed, 9 Feb 1994 08:36:15 -0500 Received: from rchsg8.chemie.uni-regensburg.de by rrzs1.rz.uni-regensburg.de (4.1/URRZ-relay (1.4)) id AA14923; Wed, 9 Feb 94 14:35:59 +0100 Received: by rchsg8.chemie.uni-regensburg.de (920330.SGI/BelWue-1.0SG(subsidiary)) (for CHEMISTRY@ccl.net) id AA27683; Wed, 9 Feb 94 14:37:20 +0100 Date: Wed, 9 Feb 94 14:37:20 +0100 From: ferenc@rchsg8.chemie.uni-regensburg.de (Ferenc Molnar) Message-Id: <9402091337.AA27683@rchsg8.chemie.uni-regensburg.de> To: CHEMISTRY@ccl.net Subject: OOP in comp. chem. >Oh, I guess something went wrong with my last mail! >So here is another try, excuse me! It was an accidental dot in the first column! Please excuse! Leif Laaksonen wrote: >This is really a long time dream of mine. Just imagine if there would be >more object oriented classes in computational chemistry code. You could >just plug in and use a class for PM3, MP2, Leap-Frog algorithm and so on. >All code would be easier reused. Today too much code is still developed >for one particular approximation or application. > > > >I believe this is something we >quantum chemists have in front of us very soon. The whole consept >has to be redefined. Perhaps this will never happen because there is >so much "old" code available which will never be rewritten. But for >the sake of science I wish this will happen. After all as Ron Shepard >said we all appreciate more the kind of knowledge that remains useful >for decades rather than months or years. I agree with you, "something" has to happen. The old code shold be rewritten and the concepts should be altered. For example, a molecular dynamics program could be written very efficiently in the framework of an object oriented approach. Atoms and molecules designed as class objects, interacting by some virtual functions, would make it easy to add new types of features. The whole thing could be done for example in C++ (don't say C++ is not OOP). And as a bonus the administration of the code would be easier. These were my ideas when I started the project I am currently working on. But there are at least three drawbacks. First: You need quite a long time for designing your program in an OOP-language when you are used to modular programming. Second: FORTRAN 77 is the most portable language (C programmers forgive me!). Third and most important: As you always have a lack of hardware resources, you need a compiler which optimizes efficiently. Often the raw speed of your calculation is the crucial point. FORTRAN compilers have quite a history and are very effective in "number crunching" and are essentially bug free. The advantage of C++ (or say FORTRAN 90) is that you can handle dynamic memory allocations, but this can slow down the program and prevent effective optimization. And thus I decided (with considerable regrets) to use the hereditary style of programming for my project. In my oppinion OOP methods should only be used for large scale projects. These projects have to be supported by some organization like an university or a company and are scheduled for years. I think that in this case the financial grounds are there for even reprogramming functioning code (e.g. Hyperchem from Hypecube). I wonder if there are more such projects going on somwhere out there and I would be very much interested in details. Yours sincerely, Ferenc Molnar --------------------------------------------------------------------------- Institut fuer Physikalische und Theoretische Chemie - Lehrstuhl Prof. Dick - Tel.: (+49) 941 943-4466 /-4486 Universitaet Regensburg Fax.: (+49) 941 943-4488 Universitaetsstrasse 31 D-93053 Regensburg Deutschland / Germany --------------------------------------------------------------------------- EMail (SMTP): ferenc@rchsg8.chemie.uni-regensburg.de c5071@rchs1.chemie.uni-regensburg.de ferenc@rchnw2.ngate.uni-regensburg.de --------------------------------------------------------------------------- :-) There is more to live than increasing its speed. -- Ghandi ;-) --------------------------------------------------------------------------- From pault@tartt.reading.sgi.com Wed Feb 9 10:20:58 1994 Received: from sgi.sgi.com for pault@tartt.reading.sgi.com by www.ccl.net (8.6.4/930601.1506) id KAA25862; Wed, 9 Feb 1994 10:15:21 -0500 Received: from [192.132.133.50] by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for chemistry@ccl.net id AA12125; Wed, 9 Feb 94 07:15:19 -0800 Received: by tartt.reading.sgi.com (930416.SGI/930416.SGI) for @sgi.com:chemistry@ccl.net id AA20835; Wed, 9 Feb 94 15:16:39 GMT From: "Paul Townsend" Message-Id: <9402091516.ZM20833@tartt.reading.sgi.com> Date: Wed, 9 Feb 1994 15:16:38 +0000 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: chemistry@ccl.net Subject: OOP Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I must reply to some of the comments made so far. I have spent at least four years writing/ designing software using OOD techniques. (As an aside - you CANNOT have OOP without OOD ! Simple.) -- First: You need quite a long time for designing your program in an OOP-language when you are used to modular programming. -- Agreed. It is fine to say that code should be reusable. Try designing it. Whatever functionality is given to a class it will prove too restrictive for someone. If the designer is not careful, they will produce a 'begin, initialise, end ' template with some I/O routines in the middle. Language specific editors come close to this. This is not to say that a software company should not employ these techniques. But if you belive in a set of classes that will provide all chemists with program building blocks then I think you are dreaming. -- FORTRAN 77 is the most portable language (C programmers forgive me!). -- Strongly disagree. ANSI C is a VERY portable language and C++ is not bad given that it is so new. -- Third and most important: As you always have a lack of hardware resources, you need a compiler which optimizes efficiently. Often the raw speed of your calculation is the crucial point. FORTRAN compilers have quite a history and are very effective in "number crunching" and are essentially bug free. The advantage of C++ (or say FORTRAN 90) is that you can handle dynamic memory allocations, but this can slow down the program and prevent effective optimization. -- I find this point mildly hilarious ! Just yesterday I came across an Amber example where user in question had to increase an array parameter in order to perform a calculation. Time to edit and recompile was minutes. Increased execution time vs dynamic allocation (C etc ...) was probably a second at most. Fair trade ? I think not. One of the concepts behind OOD is that you trade huge maintenance costs against buying the latest hardware. If we take Ada as an extreme example, this is probably the most inefficient language in (fairly) common usage. To get any performance from this you need the latest hardware, yet people are willing to do this in part because of the portability and reduced maintenance costs of this language. If you consider your hardware investment versus that of your s/w, (add in man hours of training, writing, maintaining, maintenance fees etc ...) you may be surprised at the result. All opinions mine etc ... Paul. -- _________________________________________________________________________ Paul Townsend | Mail Stop - IUK-311 Sales Support | Fax - +44 (0)734 302550 Silicon Graphics | Tel. (direct) - +44 (0)734 257619 Forum 1, Station Rd, Theale | Email - pault@reading.sgi.com Reading, RG7 4RA UK | V Mail # - 59265 _________________________________________________________________________ From noy@tci005.uibk.ac.at Wed Feb 9 11:21:00 1994 Received: from uibk.ac.at for noy@tci005.uibk.ac.at by www.ccl.net (8.6.4/930601.1506) id KAA26026; Wed, 9 Feb 1994 10:34:40 -0500 Received: from tci005.uibk.ac.at by uibk.ac.at with SMTP id AA25424 (5.65c/IDA-1.4.4 for ); Wed, 9 Feb 1994 16:34:12 +0100 Received: by tci005.uibk.ac.at (AIX 3.2/UCB 5.64/CFIBK-2e.AIX) id AA26136; Wed, 9 Feb 1994 16:34:12 +0100 From: noy@tci005.uibk.ac.at (Noy) Message-Id: <9402091534.AA26136@tci005.uibk.ac.at> Subject: MOPAC for LINUX To: chemistry@ccl.net Date: Wed, 9 Feb 1994 16:34:10 +0100 (NFT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 273 Dear Netters, Sorry if this is a FAQ. Is anybody out there aware of MOPAC for LINUX or is there somebody porting it to LINUX ? If any, it would be greatly appreciated to provide the host address of anonymous FTP. Thanks a lot in advance. sincerely, Teerakiat From WANG@IRBM.IT Wed Feb 9 11:24:35 1994 Received: from V1.IRBM.IT for WANG@IRBM.IT by www.ccl.net (8.6.4/930601.1506) id KAA25996; Wed, 9 Feb 1994 10:30:25 -0500 From: Date: Wed, 9 Feb 1994 16:30:46 +0100 (WET) To: chemistry@ccl.net CC: WANG@IRBM.IT Message-Id: <940209163046.3ca7@IRBM.IT> Subject: codes for computations of mol. surfaces Dear netters, I am looking for a publicly available source code (in Fortran or C) which calculates: (1) The dot surface, with contact or Van der Waals surface, and the dots in uniform distribution. (2) Derivatives of the surface area over atomic coordinates. I will summarize to the net if there are sufficient responses. Bingze ---------------------------------------------------------------------- Bingze Wang, Ph.D. +39-6-91093625 (phone) Medicinal Chemistry, IRBM +39-6-91093225 (fax) Via Pontina Km. 30,600 e-mail: wang@irbm.it 00040 Pomezia (Roma), Italy ---------------------------------------------------------------------- From burkhart@goodyear.com Wed Feb 9 11:27:19 1994 Received: from goodyear.com for burkhart@goodyear.com by www.ccl.net (8.6.4/930601.1506) id KAA26454; Wed, 9 Feb 1994 10:55:17 -0500 Received: from rdsrv2 (rdsrv2.goodyear.com) by goodyear.com (4.1/SMI-4.1) id AA17299; Wed, 9 Feb 94 10:55:16 EST Received: from rds325 by rdsrv2 (4.1/SMI-4.1) id AA00659; Wed, 9 Feb 94 10:55:15 EST Received: by rds325 (920330.SGI/920502.SGI.AUTO) for @rdsrv2:chemistry@ccl.net id AA06974; Wed, 9 Feb 94 10:54:46 -0500 Date: Wed, 9 Feb 94 10:54:46 -0500 From: burkhart@goodyear.com (Craig W. Burkhart) Message-Id: <9402091554.AA06974@rds325> To: chemistry@ccl.net Subject: Re: CCL:Request for Molecular Graphics Software If you are interested in animating/property analysis, I believe there is a program from QCPE called mdXvu (QCPE #627). It is written for a pure X-windows environment, so it should be pretty portable. Check with them. Their salient info is: Quantum Chemistry Program Exchange Fone: 812.855.4784 Fax: .5539 Email: qcpe@ucs.indiana.edu ftp: qcpe6.chem.indiana.edu (anonymous ftp passwd: guest) P.S. mdXvu is written to deal with AMBER trajectory files. You can either input in this format, or write a routine to read your own custom trajectory files. -------------------------------------------------------------------------- Craig W. Burkhart, Ph.D. Senior Research Chemist E-mail: cburkhart@goodyear.com The Goodyear Tire & Rubber Co. Fone: 216.796.3163 Research Center Fax: 216.796.3304 142 Goodyear Boulevard Akron, OH 44305 -------------------------------------------------------------------------- For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled - Feynman -------------------------------------------------------------------------- From ps@ocisgi7.unizh.ch Wed Feb 9 11:33:40 1994 Received: from rzusuntk.unizh.ch for ps@ocisgi7.unizh.ch by www.ccl.net (8.6.4/930601.1506) id KAA26324; Wed, 9 Feb 1994 10:49:19 -0500 From: Received: from ocisgi7.unizh.ch by rzusuntk.unizh.ch (4.1/SMI-4.1.9) id AA02377; Wed, 9 Feb 94 16:49:19 +0100 Received: by ocisgi7.unizh.ch (920330.SGI/920502.SGI) for @rzusuntk.unizh.ch:CHEMISTRY@ccl.net id AA13266; Wed, 9 Feb 94 16:48:50 +0100 Date: Wed, 9 Feb 94 16:48:50 +0100 Message-Id: <9402091548.AA13266@ocisgi7.unizh.ch> To: CHEMISTRY@ccl.net Subject: SIBIQ - semiempirical quantum chemistry package for IBM PCs Dear Netters, We want to announce the availability of SIBIQ --- the IBM-PC tool to carry out semiempirical calculations and to build molecular structures using graphical interface. SIBIQ supports the following semiempirical methods: MNDO, AM1, PM3; MNDO/d and MNDOM (MNDO modified to correctly treat H-bonds). SIBIQ makes possible: 1) optimize geometry for both open and closed shell systems, 2) search for transition states, 3) calculate frequencies, 4) estimate entropy, 5) study solvent interactions, 6) calculate electrostatic potentials. It comes with the extensive library of molecular structures and templates to build new molecules with the graphic molecular editor. To find more about SIBIQ retrieve the file sibiq.note in the directory /pub/chemistry/info/software-packages in CCL archives via gopher/ftp or send a message: select chemistry get info/software-packages/sibiq.note to MAILSERV@ccl.net. You can retrive demo version of SIBIQ (which is fully functional, but limited to 17 atoms and 45 MOs) with anonymous ftp from ocisgi7.unizh.ch, directory /pub/sibiq. You are also most welcom to contact us directly/ Serge Pachkovsky, Roschibachstrasse 68 CH-8037 Zuerich Switzerland E-mail: ps@ocisgi7.unizh.ch Russian guy from the Zurich university... From slee@ccl.net Wed Feb 9 11:38:07 1994 Received: from mail.uunet.ca for slee@ccl.net by www.ccl.net (8.6.4/930601.1506) id KAA26119; Wed, 9 Feb 1994 10:40:02 -0500 Received: from hyper by mail.uunet.ca with UUCP id <60134(2)>; Wed, 9 Feb 1994 10:37:07 -0500 Received: by hyper.hyper.com (931110.SGI/890607.SGI) (for ccl.net!chemistry) id AA02351; Wed, 9 Feb 94 10:50:31 -0500 From: slee@ccl.net (Thomas Slee) Message-Id: <9402091550.AA02351@hyper.hyper.com> Subject: Re: activation barrier To: chemistry@ccl.net Date: Wed, 9 Feb 1994 10:50:30 -0500 In-Reply-To: <9402091217.AA21266@sunny.mpimf-Heidelberg.mpg.de>; from "Eberhard von Kitzing" at Feb 9, 94 7:17 am X-Mailer: ELM [version 2.3 PL9] Eberhard von Kitzing writes... | | >I have done several molecular dynamics simulations of an organic ring | >system at different temperatures using SYBYL. At "low" temperatures only one | >conformation could be detected (< 2000 K), whereas at high temperatures | >(> 2000 K) an additional conformation occurs. Can I draw any conclusions | >on the height of the activation barrier between the two conformations | >from the dynamics runs? | | The inverse of the frequency of flipping should be in the order of the | rate of going from one conformer to the other for a given temperature. | While this is true for realistic MD simulations, by the time one gets to 2000K any current force field is almost completely INaccurate. Carrying out high temperature MD runs is still useful as a means of conformational searching -- it enables you to shake the molecule vigorously to see if it can be jolted into different shapes, and generates a set of plausible structures that can be used for further analysis -- but that vigorous shaking no longer has any real relation to the behaviour of the physical system at the specified temperature (I'd like to see any organic ring system still in one piece at 2000K!). Any relation between calculated flipping frequency and actual activation barriers must be at best qualitative for these simulations, as you moving over a very unrealistic potential barrier. Tom Slee -- Tom Slee Hypercube, Inc., #7-419 Phillip St., Waterloo, Ont. N2L 3X2 Internet: slee@hyper.com Tel. (519) 725-4040 From jmiller@SANDCASTLE.COSC.BROCKU.CA Wed Feb 9 11:41:43 1994 Received: from nexus.BrockU.CA for jmiller@SANDCASTLE.COSC.BROCKU.CA by www.ccl.net (8.6.4/930601.1506) id KAA26360; Wed, 9 Feb 1994 10:50:38 -0500 Received: from sandcastle.cosc.BrockU.CA by nexus.BrockU.CA via SMTP (920110.SGI/911001.SGI.UNSUPPORTED.PROTOTYPE) for CHEMISTRY@ccl.net id AA13952; Wed, 9 Feb 94 10:44:10 -0500 Received: from applepie.chem.BrockU.CA by SANDCASTLE.COSC.BROCKU.CA via SMTP (920330.SGI/920502.SGI) for @NEXUS.BROCKU.CA:CHEMISTRY@ccl.net id AA03080; Wed, 9 Feb 94 10:50:39 -0500 Date: Wed, 9 Feb 94 10:50:39 -0500 Message-Id: <9402091550.AA03080@SANDCASTLE.COSC.BROCKU.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: CHEMISTRY@ccl.net From: jmiller@SANDCASTLE.COSC.BROCKU.CA (Jack Martin Miller) Subject: Re: CCL:CCL:Re: High Cost of Comp. Chem. Ron Shepard wrote: >>As the object orientation becomes stronger, >>so maintenance might just become less of a problem. > >Heh, Heh... ;-) Agreed > > In order to use new RISC workstations, you have to >learn unix and give up VMS. In order to use PHIGS, you have to give up >fortran and learn C. And now PHIGS may be replace by SGI's open 3D libraries and X or Motif are the standard. > >I have noticed however that this doesn't bother people in computing as >much as it does people in science. I think this is related to the >maturity of the different disciplines. It could be that our training in >science allows us to appreciate more the kind of knowledge that remains >useful for decades (or centuries) rather than months or years. > As a former chair of a Computer Science department let me say that there are two attitiudes --- "lets not change --- the VAX is the best invention since white bread" to "its new therefore we must have it --- even if it doesn't work, won't work and can't work" The experimental chemist is more likely tochange than the theoretician since no software for use with insttrumentation is currently being written in Fortran and most old fortran based stuff has been replaced with C. If your mass spec or nmr is driven from a UNIX workstation you have no choice but to mighrate to the new technology and deal with windows, C and UNIX - and if you want your data moved to your desktop Mac or PC you have to get involved in networking and networking standards. The theoretician is still likely to submit batch jobs and get out a single number or a little table after a day of number crunching --- there is no incentive to change from the Fortran they cut their teeth on --- and anyway Fortran code usually runs faster than C. Jack Martin Miller Professor of Chemistry Adjunct Professor of Computer Science Brock University, St. Catharines, Ontario, Canada, L2S 3A1. Phone (905) 688 5550, ext 3402 FAX (905) 682 9020 e-mail jmiller@sandcastle.cosc.brocku.ca From ascanio@salve3.salve.edu Wed Feb 9 12:21:08 1994 Received: from SALVE3.SALVE.EDU for ascanio@salve3.salve.edu by www.ccl.net (8.6.4/930601.1506) id MAA27386; Wed, 9 Feb 1994 12:14:05 -0500 From: Received: by salve3.salve.edu (MX V3.2) id 12449; Wed, 09 Feb 1994 12:21:48 EST Date: Wed, 09 Feb 1994 12:21:47 EST To: CHEMISTRY@ccl.net Message-ID: <00979CCE.B3675A00.12449@salve3.salve.edu> Subject: pKa for acety CoA I would appreciate values, with references if possible, of the pKa for the alpha hydrogens in the acetyl group of acetyl CoA. Please send directly and I will organize and return. Thank you. Ascanio Giuseppe DiPippo, C.H.S. Professor Salve Regina University Newport, Roe Dylin 02840 401-847-6650 x 3126 office 401-847-0372 FAX e-MAIL ascanio@salve3.salve.edu ***************************************************************** * "Neva trust any won whoo kan ownly spel a wird won whey" Mock Twane ***************************************************************** From dan@omega.chem.yale.edu Wed Feb 9 12:24:06 1994 Received: from omega.chem.yale.edu for dan@omega.chem.yale.edu by www.ccl.net (8.6.4/930601.1506) id MAA27468; Wed, 9 Feb 1994 12:19:03 -0500 Received: by omega.chem.yale.edu; Wed, 9 Feb 94 12:18:53 -0500 From: Dan Severance Message-Id: <9402091718.AA11038@omega.chem.yale.edu> Subject: CCL:OOP To: CHEMISTRY@ccl.net Date: Wed, 9 Feb 94 12:18:52 EST Organization: Laboratory for Computational Chemistry X-Mailer: ELM [version 2.3 PL11] ?? writes (sorry): > As you always have a lack of hardware resources, you > need a compiler which optimizes efficiently. > Often the raw speed of your calculation is the crucial point. > FORTRAN compilers have quite a history and are very effective in > "number crunching" and are essentially bug free. > The advantage of C++ (or say FORTRAN 90) is that you can handle > dynamic memory allocations, but this can slow down the program and > prevent effective optimization. Paul Townsend replies: > I find this point mildly hilarious ! Just yesterday I came across an Amber > example where user in question had to increase an array parameter in order > to perform a calculation. Time to edit and recompile was minutes. > Increased execution time vs dynamic allocation (C etc ...) was probably a > second at most. Fair trade ? I think not. > Hi, I am a postdoc in the lab of William Jorgensen here at Yale. The argument that only a second is saved assumes short run times. What you have to realize is that while not the rule, there are many of us to whom the CPU time required to do a project is days, weeks or even months of continuous running! Even a 10% increase in program speed is negligible for a 1 hour program run, but means a savings of 6 days for a 2 month program run! I'll gladly spend 3 minutes recompiling to save 6 days. We currently have 8 or 9 SGI machines that run BOSS and AMBER jobs 24 hours a day, 7 days a week, 365 days a year. Over a year, that 10% (or more) amounts to more than an extra month of CPU time available. Program speed, machine speed and functionality are all significant considerations to us, but a highly functional, less efficient code will tend to only be used in the specialized situations where it is essential, and not for anything else. We have some other packages, one is commercial (written in C), with a very nice graphics interface. The code is extremely slow, however, and we've never used it (or even considered it) for any research project. I'd love to have easy to use, object oriented code, but if we have to sacrifice a great deal of speed, it'll not become our software of choice. We spend money buying new machines to get faster turn around and then work on even larger problems, we aren't going to turn around and use slower code. (And no, a comparably priced IBM is slower for the money when running these programs, so don't question why we use SGIs!) Dan Severance Yale University Chemistry Dept. **** My opinions are my own :-) **** From berkley@wubs.wustl.edu Wed Feb 9 12:27:04 1994 Received: from wugate.wustl.edu for berkley@wubs.wustl.edu by www.ccl.net (8.6.4/930601.1506) id LAA27028; Wed, 9 Feb 1994 11:39:37 -0500 Received: by wugate.wustl.edu (5.67b+/WUSTL-0.3) with SMTP id AA23142; Wed, 9 Feb 1994 10:39:37 -0600 Received: by wubs.wustl.edu; (5.65/1.1.8.2/14Oct93-1217PM) id AA00482; Wed, 9 Feb 1994 10:42:26 -0600 Date: Wed, 9 Feb 1994 10:42:26 -0600 From: "Mr. Berkley Shands" Message-Id: <9402091642.AA00482@wubs.wustl.edu> To: chemistry@ccl.net Subject: System Benchmarks Once again, I can provide some CPU specific benchmark data, including multiprocessor benchmarks. Since SUN finally came into the 20th century by supporting MOTIF (X11R5) I can run on those machines as well. IBM and HP do not rate as I have no access to those systems. These benchmarks are all double precision floating point computations in molecular modelling. The software should be available in the June 1994 timeframe and does reflect ongoing research and automation. Other multiprocessor machines will be posted as they become available to me for testing. If you want serious compute power, see below... :-) Berkley Shands Receptor-III (TM - Tripos Associates) Beta Release version V2.4 timings for the ACE series. Uniform distance space scanning at 0.0625A maximum increment with Adaptive Scanning in modified mode applied. All bonds Adaptively scanned. Minimum scan factor 1.27 degrees, maximum scan factor 3.52 degrees, Average of 2.73. Uniform grid resolution of 0.25A. Fully automated setup and processing applied. All computations in double precision! This is the last time around for this dataset. Later benchmarks will use a MOPAC/AM1 minimized subset with torsions variable. ******************************************************************************* Benchmarks of the ACE series of 57 molecules IC50 > 6.0 ******************************************************************************* Elapsed Child_CPU System_CPU Chargable Forks Ratio ======= ========= ========== ========= ===== ===== * 1311 1264.400 6.140 1245.310 2 0.916 SUN 4m/690 SPARC2 GCC -O2 Solaris 2.3 * 1287 1301.180 10.270 1281.230 5 1.013 SUN 4m/690 SPARC2 SC -xO4 Solaris 2.3 * 1148 1108.950 4.980 1099.070 2 0.969 SGI Indigo 48Mb -O2 (R3K/33Mhz) IRIX 5.1.1.2 * 942 957.470 29.730 940.250 4 1.020 SGI 4d/380s 128Mb -O2 (R3K/33Mhz) * 643 579.383 5.633 567.733 2 0.907 AXP 3K/300L Gem CC -O4 32mb -feedback * 603 529.440 5.270 524.770 2 0.882 SGI Indigo2 64Mb -O2 (R4K/50Mhz) * 566 516.970 2.070 512.500 2 0.917 SGI Challenge M 96Mb -O2 (R4K/100Mhz) * 519 504.690 4.880 496.800 3 0.978 SUN Sparc-100 (2X10/51's) Solaris 2.3 SC -xO4 * 498 445.430 1.960 440.250 2 0.902 SGI Challenge M 96Mb -O3 -mips2 (R4K/100Mhz) * 437 414.233 2.450 407.533 2 0.952 AXP 3K/300 Std CC -O2 32mb * 388 337.350 1.717 331.200 2 0.876 AXP 3K/400 Gem CC -O4 32mb -feedback * 346 332.033 1.600 325.233 2 0.968 AXP 3K/300 Gem CC -O4 32mb -feedback ******************************************************************************* No current data - single precision mode only... Sorry :-( 239 212.367 1.503 200.117 7 0.904 DEC 3K/600 AXP 128mb GEM "CC" -O4 -feedback 201 187.817 1.333 177.183 7 0.949 DEC 3K/800 AXP 256mb GEM "CC" -O4 -feedback ******************************************************************************* Notes: DEC AXP 3000/300L is 100 Mhz, 3K/300 is 150 Mhz, 3K/600 is 175 Mhz, 3K/800 is 200 Mhz Many thanks to DEC for providing the 3K/600 and 3K/800 Machines. All SGI machines ran IRIX 4.0.5 except as indicated. All SUN machines ran Solaris 2.3 with Motif optimized to -xO4. All AXP machines ran some flavor of OSF1 :-) The "GEM" compiler is in save set CMPDEVENH on the OSF/1 CD. The "STD" compiler is the default "CC" for OSF/1. The "GCC" compiler is the GNU sun_sparc compiler. The "SC" compiler is the SUN Sparcworks optional C compiler. "Child_CPU" is the recorded total CPU for all forked processes, including overhead and I/O. "Elapsed" is the recorded elapsed time from command line parsing to the exit of the last child processes. "System_CPU" is the recorded UNIX system overhead from the times() function "Chargable" is the algorithmic chargable time from initial rotations to termination (child process CPU) ***************************************************************************** CPU benchmarking for current architectures February 1994. Software is an analytic ring closure method on an eight membered ring (cylooctane) from the Sybyl library. "Elapsed" is the wall clock time. "Child_CPU" is the total CPU over all forks. "System_CPU" is measured system overhead. "Conformers" are stericly allowed conformers. "Forks" is the number of fork() system calls. "Ratio" is Child_CPU / Elapsed "Ovhd/Fork" is the System_CPU / Forks. "Confs/Second" is the number of conformations per elapsed second. * CycloOctane Absolute Orientation 02/04/94 Full log files. wubs2 DEC Alpha AXP 3000/300 Ringsearch ringsearch -NOX11R4 -nrings -S0.050 -l -Bmodified cyclooctane -Tabsolute Elapsed Child_CPU System_CPU Conformers Forks Ratio Ovhd/Fork 336.5 confs/second 264 258.550 0.283 88843 1 xxx xxxxx STD CC -O2 Elapsed Child_CPU System_CPU Conformers Forks Ratio Ovhd/Fork 403.8 confs/second 220 219.200 0.033 88843 1 xxx xxxxx GEM CC -O4 -feedback ************ Multisearch (multi-threaded ringsearch) ***************** multisearch -NOX11R4 -m4 -nrings -S0.050 -l -Bmodified cyclooctane -Tabsolute (Absolute torsion orientation, 4 cpus concurent, Scan non-analytic ring sections in 0.050A increments, Adaptive search in Modified mode with log files for I/O Ring closure epsilon at 0.10A (a medium tolerance)). Sun 4m (Sparc2 class machine) 690 4 processor 128Mb SUN Sparcworks Compiler -xO4 Elapsed Child_CPU System_CPU Conformers Forks Ratio Ovhd/Fork 245.4 confs/second 362 1046.980 24.770 88843 179 2.892 0.138380 Sun Sparc-1000 (dual sparc10/51 cpus 128Mb Solaris 5.3 + motif) Elapsed Child_CPU System_CPU Conformers Forks Ratio Ovhd/Fork 396.6 confs/second 224 347.020 8.070 88843 179 1.549 0.045084 sgi 4d/380 4/8 cpus Elapsed Child_CPU System_CPU Conformers Forks Ratio Ovhd/Fork 475.0 confs/second 187 728.570 7.040 88843 179 3.896 0.039330 sgi 4d/380 8/8 cpus Elapsed Child_CPU System_CPU Conformers Forks Ratio Ovhd/Fork 897.4 confs/second 99 728.970 7.070 88843 179 7.363 0.039497 From norbert@akjung3.orgchemie.chemie.uni-tuebingen.de Wed Feb 9 14:21:46 1994 Received: from mailserv.zdv.uni-tuebingen.de for norbert@akjung3.orgchemie.chemie.uni-tuebingen.de by www.ccl.net (8.6.4/930601.1506) id OAA29240; Wed, 9 Feb 1994 14:12:52 -0500 Received: from akjung3.orgchemie.chemie.uni-tuebingen.de by mailserv.zdv.uni-tuebingen.de (4.1/ZDV-Uni-Tuebingen-1.0) id AA16324; Wed, 9 Feb 94 20:12:48 +0100 Received: by akjung3.orgchemie.chemie.uni-tuebingen.de (920330.SGI/911001.SGI) for @mailserv.zdv.uni-tuebingen.de:chemistry@ccl.net id AA15386; Wed, 9 Feb 94 20:12:47 +0100 Date: Wed, 9 Feb 94 20:12:47 +0100 From: norbert@akjung3.orgchemie.chemie.uni-tuebingen.de (Norbert Zimmermann) Message-Id: <9402091912.AA15386@akjung3.orgchemie.chemie.uni-tuebingen.de> To: chemistry@ccl.net Subject: AMBER trajectories -> Biosym Hi all, has anyone a program or macro to convert AMBER trajectories to BIOSYM's InsightII Analysis Module? Any help is appreciated. Norbert Zimmermann Institute of Organic Chemistry Univ. Tuebingen Germany From mercie@med.cornell.edu Wed Feb 9 14:26:28 1994 Received: from cumc.cornell.edu for mercie@med.cornell.edu by www.ccl.net (8.6.4/930601.1506) id OAA29199; Wed, 9 Feb 1994 14:05:49 -0500 Received: (mercie@localhost) by cumc.cornell.edu (8.6.6.Beta4/ECH1.13) id OAA08452; Wed, 9 Feb 1994 14:03:28 -0500 Date: Wed, 9 Feb 1994 14:03:28 -0500 (EST) From: Gustavo Mercier Sender: Gustavo Mercier Reply-To: Gustavo Mercier Subject: Re: CCL:OOP in comp. chem. To: Ferenc Molnar cc: CHEMISTRY@ccl.net In-Reply-To: <9402091337.AA27683@rchsg8.chemie.uni-regensburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi! My 0.02! A few years ago I had to make a decision about expanding my computational skills. Learn C, C++ ... etc. I was finished with my M.D.-Ph.D. and had extensive experience with Fortran, in fact all my Ph.D. work was done with it. Unfortunately, I was about to start my postgraduate medical training in Radiology, with one year of internal medicine. This meant severe constraints in my schedule for any research, particularly any programming. I needed a programming language for fast programming with little maintenance. I decided to become conversant with MATHEMATICA, although along the way I learned C, and now I am wetting my feet in C++. I have been very happy with MATHEMATICA. I do ALL my programming with it. The learning curve was steep since you have to think in terms of functional programming. Getting rid of Do Loops and IF statements was difficult (although these are present in Mathematic for Fortran diehards), but I have written an entire Integral, package (albeit not the most efficient) in about 100 lines of code by literally just transcribing the recursive formulae from Obaira and Saika (JCP 86(7),1986)! Moreover the symbolic capabilities allow you to explore the contribution of numerical methods to the errors. For example, Lowdin introduced Resolvent methods to solve the Schroedinger equation in the '60's. Experience in Numerical Methods suggests that Resolvent methods should be better than Perturbation or Variational techniques. Unfortunately, the Resolvent Method requires the Inverse of (H-z.I.E) where z is the resolvent variable, something difficult to program in Fortran. Without symbolic methods you need to implement a numerical method to solve for z within a host of other approximations. These could degrade the suspected power of the Resolvent technique. The symbolic capabilities of Mathematica allow you to compute this inverse exactly avoiding these limitations. Unfortunately, I never carried the project through since DFT became popular! Finally, now that I am learning C++ I am even more impressed with Mathematica. Many concepts of C++ like operator overloading are already included in Mathematica. Sure, Mathematica is not a perfect solution. You have to have the kernel running for your program to run. Moreover, I am sure that you can write very specific and more efficient numerical code in Fortran, C etc., if you are an expert and invest enough time. You won't write a graphical user interface with it, either. But given the cost of many commercial packages that don't have script languages built-in nor release their source code ... I think Mathematica is still a good idea. I am convinced that you can write and mantain what would normally be extensive code with less effort, an important factor in determining the cost of software. Noteworthy is the ability to use MathLink, a fully supported package included with many Mathematica platforms, to connect your own Fortran, C, C++ code with the Mathematica kernel. Communication is then possible from either program to the other, whether you are within Mathematica or your own program. In fact some commercial suppliers of such as Spyglass are already link their visualization software to Mathematica using MathLink. Finally, it seems to me that Mathematica has never "made it" within the computational chemistry community. As such, it probably falls within the area that mathematicians and physicists have exploited more extensively. In fact, the only application in chemistry published in the Mathematical Journal (that I can remember) was in coding the vibrational Schroedinger equation for molecules. The authors were using the symbolic capabilities of Mathematica together with its ability to generate Fortran Code to derive and code the high order terms in the potential (n> 2) expressed in powers of normal modes, these are messy from the algebraic point of view and prone to errors in programming. In the end OOP will take over, whether we like it or not. The key is how much we are willing to change and how much support large scale machines will have for it. Will programs vectorize? Will they ever do array boundary checks automatically? Will the perception that C cannot number crunch as fast as Fortran change? In the mean time, as long as I don't intend to write my own full blown Gaussian package, I will continue to write my Mathematica programs and run them in my SGI. gus mercier mercie@cumc.cornell.edu From norbert@akjung3.orgchemie.chemie.uni-tuebingen.de Wed Feb 9 15:21:10 1994 Received: from mailserv.zdv.uni-tuebingen.de for norbert@akjung3.orgchemie.chemie.uni-tuebingen.de by www.ccl.net (8.6.4/930601.1506) id PAA00375; Wed, 9 Feb 1994 15:03:33 -0500 Received: from akjung3.orgchemie.chemie.uni-tuebingen.de by mailserv.zdv.uni-tuebingen.de (4.1/ZDV-Uni-Tuebingen-1.0) id AA17308; Wed, 9 Feb 94 21:03:27 +0100 Received: by akjung3.orgchemie.chemie.uni-tuebingen.de (920330.SGI/911001.SGI) for @mailserv.zdv.uni-tuebingen.de:CHEMISTRY@ccl.net id AA15552; Wed, 9 Feb 94 21:03:25 +0100 Date: Wed, 9 Feb 94 21:03:25 +0100 From: norbert@akjung3.orgchemie.chemie.uni-tuebingen.de (Norbert Zimmermann) Message-Id: <9402092003.AA15552@akjung3.orgchemie.chemie.uni-tuebingen.de> To: CHEMISTRY@ccl.net Subject: AMBER trajectories -> Biosym Subject: AMBER trajectories -> Biosym Hi all, has anyone a program or macro to convert AMBER trajectories to BIOSYM's InsightII Analysis Module? Any help is appreciated. Norbert Zimmermann Institute of Organic Chemistry Univ. Tuebingen Germany From bak@isadora.albany.edu Wed Feb 9 15:24:23 1994 Received: from UACSC2.ALBANY.EDU for bak@isadora.albany.edu by www.ccl.net (8.6.4/930601.1506) id OAA00279; Wed, 9 Feb 1994 14:56:11 -0500 Received: from isadora.albany.edu by UACSC2.ALBANY.EDU (IBM VM SMTP V2R2) with TCP; Wed, 09 Feb 94 14:54:32 EST Received: by isadora.albany.edu (931110.SGI/920502.SGI) for @uacsc2.albany.edu:chemistry@ccl.net id AA04244; Wed, 9 Feb 94 14:55:59 -0500 From: bak@isadora.albany.edu (Brian A. Kell) Message-Id: <9402091955.AA04244@isadora.albany.edu> Subject: Re: CCL:pKa for acety CoA To: ascanio@salve3.salve.edu Date: Wed, 9 Feb 94 14:55:59 EST Cc: chemistry@ccl.net In-Reply-To: <00979CCE.B3675A00.12449@salve3.salve.edu>; from "ascanio@salve3.salve.edu" at Feb 9, 94 12:21 pm X-Mailer: ELM [version 2.3 PL11] > Salve Regina University > Newport, Roe Dylin 02840 Roe Dylin -- isn't that somewhere near Lon Gylin? ;-) ------------------------------------------------------------------ Brian A. Kell Technical Support Manager, Eastern Region bak@biosym.com (518) 482-1436 Biosym Technologies, Inc. ------------------------------------------------------------------ From 100012.1163@CompuServe.COM Wed Feb 9 15:28:03 1994 Received: from arl-img-2.compuserve.com for 100012.1163@CompuServe.COM by www.ccl.net (8.6.4/930601.1506) id PAA00405; Wed, 9 Feb 1994 15:06:15 -0500 Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id PAA04141; Wed, 9 Feb 1994 15:05:42 -0500 Date: 09 Feb 94 14:38:57 EST From: "100012.1163@compuserve.com" <100012.1163@CompuServe.COM> To: Subject: Re: Electronic Publishing Message-ID: <940209193856_100012.1163_BHB59-1@CompuServe.COM> To: >internet:chemistry@ccl.net Dear Fellow Netters, I enjoyed our discussion during the past weeks very much. Thank you for pointing me to the new technology. Today, I accessed the Imperial College's WWW server and looked at some files using Mosaic. I now understand your enthusiasm. I feel like a blind guy who was told about a blooming meadow and turns seeing. I am as enthusiastic as you are! Sincerely yours Dr. Rainer Stumpe Sciences Editorial Springer-Verlag Tiergartenstr. 17 D-69121 Heidelberg Phone: +49-(0)6221-487 310 Fax: +49-(0)6221-487 366 Internet: Stumpe@spint.compuserve.com From lsaw00@risque.chem.rochester.edu Wed Feb 9 16:21:47 1994 Received: from risque.chem.rochester.edu for lsaw00@risque.chem.rochester.edu by www.ccl.net (8.6.4/930601.1506) id PAA01330; Wed, 9 Feb 1994 15:57:50 -0500 From: Received: by risque.chem.rochester.edu (AIX 3.1/UCB 5.61/4.03) id AA13533; Wed, 9 Feb 94 15:48:14 -0500 Date: Wed, 9 Feb 94 15:48:14 -0500 Message-Id: <9402092048.AA13533@risque.chem.rochester.edu> To: CHEMISTRY@ccl.net, dan@omega.chem.yale.edu Subject: Re: CCL:CCL:OOP Paul Townsend replies: > I find this point mildly hilarious ! Just yesterday I came across an Amber > example where user in question had to increase an array parameter in order > to perform a calculation. Time to edit and recompile was minutes. > Increased execution time vs dynamic allocation (C etc ...) was probably a > second at most. Fair trade ? I think not. > I agree with Dan Severances reply to this. I do Monte Carlo simulations than often run 7 days or more on an RS6000. I have written code for this both in C and FORTRAN for this machine and frankly I must tell you that C is a poor second when it comes to number crunching speed. While I prefer C as a language, the overwhelming need for fast turnaround time requires that I stick to FORTRAN. I don't see this changing anytime soon. I would be interested to know if anyone else has done comparisons. *************** Jerry Perlstein Center for Photoinduced Charge Transfer Department of Chemistry University of Rochester Rochester,NY 14627-0216 Tel: (716)275-2511 FAX: (716)473-6889 lsaw00@risque.chem.rochester.edu From que@still3.chem.columbia.edu Wed Feb 9 16:26:41 1994 Received: from mailhub.cc.columbia.edu for que@still3.chem.columbia.edu by www.ccl.net (8.6.4/930601.1506) id PAA00918; Wed, 9 Feb 1994 15:36:04 -0500 Received: from still3.chem.columbia.edu by mailhub.cc.columbia.edu with SMTP id AA25226 (5.65c+CU/IDA-1.4.4/HLK for CHEMISTRY@ccl.net); Wed, 9 Feb 1994 15:36:03 -0500 Received: by still3.chem.columbia.edu (930416.SGI/930416.SGI.AUTO) for @cunixf.cc.columbia.edu:CHEMISTRY@ccl.net id AA24647; Wed, 9 Feb 94 15:35:59 -0500 Date: Wed, 9 Feb 94 15:35:59 -0500 From: que@still3.chem.columbia.edu (Quentin McDonald) Message-Id: <9402092035.AA24647@still3.chem.columbia.edu> To: que@still3.chem.columbia.edu, CHEMISTRY@ccl.net Subject: OOP in comp. chem February 9, 1994. Dear netters, I read with interest the comments of Ferenc Molnar (ferenc@rchsg8.chemie.uni-regensburg.de) on the use of object-oriented technology in chemistry. I have been thinking about this myself for some time and the preliminary experiments I have undertaken have left me convinced that OOA/OOD/OOP (Analysis,Design,Programming) is certainly the way to go. I should make it clear that these are my opinions and not necessarily shared (or even approved) by my employer. Firstly some comments on Ferenc's post: >>> You need quite a long time for designing your program in an OOP-language >>> when you are used to modular programming. This is the famous learning-curve. The most important thing is to develop "object-think" rather than learning any particular language syntax. You can write "FORTRAN" in any language including C++; this would be reduced if we had "pure" object-oriented languages available but for now the mixed-paradigm of C++ seems to be the only game in town. I should also point out that you can also write OO programs in C and even in FORTRAN (I have done the former myself and it works quite well for projects which cannot be migrated to C++). >> Second: >> FORTRAN 77 is the most portable language (C programmers forgive me!). You are forgiven. I think all languages actually have some portability problems as even if the vendors supply strict ANSI standard compilers it still requires discipline of the programmers not to use extensions (and this can happen unwittingly). We are using C++ on two platforms (SGI and RS/6000 both with the vendor supplied compilers) and we have not had any problems so far (but we do avoid templates and exceptions). >>> Third and most important: >>> As you always have a lack of hardware resources, you >>> need a compiler which optimizes efficiently. >>> Often the raw speed of your calculation is the crucial point. >>> FORTRAN compilers have quite a history and are very effective in >>> "number crunching" and are essentially bug free. >>> The advantage of C++ (or say FORTRAN 90) is that you can handle >>> dynamic memory allocations, but this can slow down the program and >>> prevent effective optimization. This I really disagree with. Certainly I always wish my calculations will go twice as fast but in reality I probably just have to wait for next year's machines. In my opinion the big challenge facing us at the moment is verification of correctness not optimization. If a language change makes a program slower by a factor of two or three then it is no big deal - that may set us back a year. But if we could introduce a better and more robust design that would benefit us for the lifetime of the program (which has been ~25years for codes like GAUSSIAN). If we want to go faster by orders of magnitude then only better algorithms and/or faster hardware can do it for us; not compiler optimizations. But most importantly we need the right answer not the fastest answer. >>> In my oppinion OOP methods should only be used for large scale projects. >>> These projects have to be supported by some organization like an >>> university or a company and are scheduled for years. >>> I think that in this case the financial grounds are there for even >>> reprogramming functioning code (e.g. Hyperchem from Hypecube). My own experience has in fact indicated that it is better to begin applying OOP to smaller, less mission-critical applications (but design for reusablity) and then be able to "iterate" the design while the local development environment builds up expertise in applying OO methods to the problem domain at hand. Unless you are a "natural" your first designs are likely to be most useful as learning experiences only. In my opinion the benefits we can obtain from object-oriented programming are : 1) Better modeling of the problem domain. Atoms, molecules, ensembles, and even electrons are objects and it begins to "feel" natural when these physical objects are encapsulated as "objects" in the code. 2) Better chance of correctness. There are three reasons for this: i) Better static (i.e. compile-time) checking in a language like C++ compared to FORTRAN and K&R C. ii) Object-oriented design allows complicated data structures to be expressed in a more natural way and one which is less likely to be misundertood. The concepts of data hiding enforce a discipline which is rare in FORTRAN. How many times have those of you who maintain large FORTRAN codes spent time scratching your head over what routine is fiddling with the value of FACTRX in COMMON? iii) If a program becomes a collection of "closed" objects then each of these can be tested and certified correct independant of any applications. Then the sort of errors that are hidden by "serendipitous compensation" ( and this does happen and cannot be revealed by application testing) will be less likely. 3) Reusablity. In the wider world OOP is considered as a boon to productivity as it boosts the effective number of lines of code a programmer can generate in a given time. In science the big gain will be in providing a set of tools which scientists can use to rapidly try out ideas. Take for example file conversion - this would be much easier if each format "vendor" provided a library which read their format and a standard interface for accessing the data. We have a small number of projects here at Columbia which use an objected-oriented approach (one will appear in the next release of MacroModel). Rather than inflate an already way-long message with the details I am happy to discuss our experiences with anyone who is interested and I would like to hear from other people who are using this approach. Quentin. ------------------------------------------------------------------------------- Quentin McDonald. (que@still3.chem.columbia.edu) * Still Group, Dept. of Chemistry, * * Columbia University, New York, NY. Telephone (212) 854-8402. * ------------------------------------------------------------------------------ From YQIN@aardvark.ucs.uoknor.edu Wed Feb 9 17:35:13 1994 Received: from aardvark.ucs.uoknor.edu for YQIN@aardvark.ucs.uoknor.edu by www.ccl.net (8.6.4/930601.1506) id QAA02368; Wed, 9 Feb 1994 16:50:28 -0500 From: Message-Id: <199402092150.QAA02368@www.ccl.net> Date: Wed, 9 Feb 94 15:51 CST Subject: Is any way to extract the coefficient of Slater determiant? To: CHEMISTRY@ccl.net X-VMS-To: IN%"CHEMISTRY@ccl.net" Hello Netters: I am having some difficulties to extract the coefficient of Slater determinant from the MP2 calculation by using Gaussian-92. Is any way allow me to do so? if it is, can you tell me how to extract the coefficient out. any suggestion will be great help. Any response please send to yqin@aardvark.ucs.uoknor.edu Thank you very much. yueyi qin From DSOUTH@uoft02.utoledo.edu Wed Feb 9 19:21:04 1994 Received: from uoft02.utoledo.edu for DSOUTH@uoft02.utoledo.edu by www.ccl.net (8.6.4/930601.1506) id SAA03613; Wed, 9 Feb 1994 18:22:47 -0500 Received: from UOFT02.UTOLEDO.EDU by UOFT02.UTOLEDO.EDU (PMDF V4.2-10 #3438) id <01H8OU5NOUAS000OMV@UOFT02.UTOLEDO.EDU>; Wed, 9 Feb 1994 18:18:57 EST Date: Wed, 09 Feb 1994 18:18:57 -0500 (EST) From: Dale Southard -- Grad Student/Skydiver Subject: Re: OOP To: chemistry@ccl.net Message-id: <01H8OU5NOUAU000OMV@UOFT02.UTOLEDO.EDU> X-Envelope-to: chemistry@ccl.net X-VMS-To: CCHEMLS MIME-version: 1.0 Content-transfer-encoding: 7BIT >Paul Townsend replies: >> I find this point mildly hilarious ! Just yesterday I came across an Amber >> example where user in question had to increase an array parameter in order >> to perform a calculation. Time to edit and recompile was minutes. >> Increased execution time vs dynamic allocation (C etc ...) was probably a >> second at most. Fair trade ? I think not. Jerry Perlstein responds: > I agree with Dan Severances reply to this. I do Monte Carlo simulations > than often run 7 days or more on an RS6000. I have written code for this > both in C and FORTRAN for this machine and frankly I must tell you that > C is a poor second when it comes to number crunching speed. While I prefer > C as a language, the overwhelming need for fast turnaround time requires > that I stick to FORTRAN. I don't see this changing anytime soon. I would > be interested to know if anyone else has done comparisons. The big question becomes: "on what basis do we benchmark a language?" "Number Crunching Speed" is an undefined property. Chemists (actually scientists in general) will all shout in unison that Fortran is faster (mainly because Fortran is a more restrictive language and thus easier for the COMPILER to optimize). Computer Scientists will (generally) favor C/C++ for reasons of flexibility and maintainability. I had great fun at the Parallel Circus (symposium on parallel/massively parallel programming) watching the presentations...the Fortran and C/C++ camps seemed to alternate presentations so that each talk could begin with a diatribe on the superiority of [Fortran, C, C++, ...] over everything else. The best moment was a Fortran group presenting the SAME algorithm a previous presenter had implemented in C, JUST SO IT WAS IN FORTRAN... you could have cut the air with a knife :-) Back to my initial point, much of the arguement centers around what one considers important.... Each of the langauges offers advantages and disadvantages. The problem with benchmarks (on languages or machines) is that they really only give one specific piece of information, "how fast can [machine, language] run this benchmark". Everything else is interpetation. Add to that the fact that a "good" C programmer can make or break any compiler's optimization attempts (a little pointer math, some register variables...) and you have a religious debate. Even better, if the debate gets boring just ask "which is better, UNIX or VMS?" and continue argueing without having to switch teams (since usually, Fortran --> VMS; C/C++ --> UNIX). My opinion (if anyone is still reading and cares) is to choose the langauge in which YOU work best, not the computer. In the long it always costs more to run the programmer than the program. Minimizing programmer time is more important than milking that last 5% out of your current hardware. If that were not the case, all of us would still be using Assembler (and in fact programmers that absolutely need that last 5% still use Asm -- ask anyone who writes video games what language they work in). As always your milage will vary. Dale Southard University of Toledo From jesus@canarylab.chem.nyu.edu Wed Feb 9 21:21:06 1994 Received: from ACF7.NYU.EDU for jesus@canarylab.chem.nyu.edu by www.ccl.net (8.6.4/930601.1506) id VAA04361; Wed, 9 Feb 1994 21:13:40 -0500 Received: from canarylab.chem.nyu.edu by ACFcluster.NYU.EDU (PMDF V4.2-13 #5342) id <01H8P20K4F9S9PM2GL@ACFcluster.NYU.EDU>; Wed, 9 Feb 1994 21:06:56 EST Received: by canarylab.chem.nyu.edu (920330.SGI.UNSUPPORTED.PROTOTYPE/920323.SGI.AUTO.ANONFTP) for @acfcluster.nyu.edu:chemistry@ccl.net id AA15322; Wed, 9 Feb 94 21:00:59 -0500 Date: Wed, 09 Feb 1994 21:00:59 -0500 From: jesus@canarylab.chem.nyu.edu (Jesus M. Castagnetto Mizuaray) Subject: Re: CCL:Request for Molecular Graphics Software To: chemistry@ccl.net Message-id: <9402100200.AA15322@canarylab.chem.nyu.edu> Content-transfer-encoding: 7BIT Sorry to use the bandwidth, but I tried to send the following message to the original poster, but I got a bounced mail. > To: faeder@ccl.net If you can output XYZ coordinates, maybe XMol it's for you. You can get info from xmol@msc.edu. Last time I saw it there was a working version for SGI machines, and versions for other platforms were in beta. Hope this helps. ----- Jesus M. Castagnetto Mizuaray | "Organic Chemistry: The practice Dep.of Chemistry - New York University | of transmuting vile substances 4 Washington Pl, Room 514. NY 10003 | into publications" (The Last Word- jesus@canarylab.chem.nyu.edu | The Ultimate Scientific Dictionary)