From darren@tau.ucg.ie Thu Jul 10 07:51:07 1997 Received: from tau.ucg.ie for darren@tau.ucg.ie by www.ccl.net (8.8.3/950822.1) id HAA28267; Thu, 10 Jul 1997 07:23:51 -0400 (EDT) Received: by tau.ucg.ie (940816.SGI.8.6.9/940406.SGI.AUTO) for chemistry@www.ccl.net id NAA24931; Thu, 10 Jul 1997 13:15:14 GMT From: "Darren D'Arcy" Message-Id: <9707101315.ZM24929@tau.ucg.ie> Date: Thu, 10 Jul 1997 13:15:08 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: chemistry@www.ccl.net Subject: Ring Interactions/Proteins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hello, I am doing a research Ph.D in protein crystallography. The proteins that i work with, uses FMN as a cofactor ( a 3 membered ring consisting of a di methyl 6 membered ring a pyrazine ring and a pyrmidine subnucleus ( collectively called isoalloxazine)). It is sandwiched between 2 hydrophobic residues, Tyrosine (a phenyl with an OH) above the ring and Tryptophan below the ring system. I would be interested in investigating semi emperically the interaction of the tyrosine and the isoalloxazine. The rest of the protein could be ignored. As my main concern is crystallography it should not be too time consuming. Does anyone have any ideas? All replys would be very much appreciated. E-mail darren@tau.ucg.ie -- Darren. From yubofan@guomai.sh.cn Thu Jul 10 09:51:07 1997 Received: from gm-email.guomai.sh.cn for yubofan@guomai.sh.cn by www.ccl.net (8.8.3/950822.1) id JAA29024; Thu, 10 Jul 1997 09:40:07 -0400 (EDT) Received: from aopen-k6-166 (dhcp01.belrose.visionet.com.au [210.0.0.19]) by gm-email.guomai.sh.cn (8.8.5/8.8.5) with ESMTP id WAA20460 for ; Thu, 10 Jul 1997 22:36:13 +0800 Message-Id: <199707101436.WAA20460@gm-email.guomai.sh.cn> From: "Yubo Fan" To: Subject: Summary: Which method is better for a rather big molecule. Date: Thu, 10 Jul 1997 21:38:18 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=HZ-GB-2312 Content-Transfer-Encoding: 8bit Hi, Thanks for the advice. Here's the summary. Hi, All, I want to optimize the conformations of some big molecules, for example, N-methyl-N-octadecylanaline. I think RHF or DFT methods are not suitable for this kind big system. Also, some semi-empirical methods are not accurate enough for such calculations. Which method can do this kind work? Thank you very much! Y. FAN -------This is added Automatically by the Software-------- -- Original Sender Envelope Address: yubofan@guomai.sh.cn -- Original Sender From: Address: yubofan@guomai.sh.cn CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: Coordinator MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73 Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search Web: http://www.ccl.net/chemistry.html =================================================== FAN, Yubo Department of Chemistry Fudan University Shanghai, 200433 P. R. China Voice(86-21)65492222-4294 =================================================== > Hello, > > Your molecule is not as big as you think. > > Have you tried the RIS method to find the minimum potential energy > conformation ? My friends once studied the polybenzozaxine dimer using > this method, and it worked very well. But you have to write the code or > find a package containing RIS module. > > Good luck. > > On Mon, 16 Jun 1997, [CN-GB] ~{76S}2(~} wrote: > > > Hi, All, > > > > I want to optimize the conformations of some big molecules, for example, > > N-methyl-N-octadecylanaline. I think RHF or DFT methods are not suitable > > for this kind big system. Also, some semi-empirical methods are not > > accurate enough for such calculations. > > > > Which method can do this kind work? > > > > > > Thank you very much! > > > > Y. FAN > > > > -------This is added Automatically by the Software-------- > > -- Original Sender Envelope Address: yubofan@guomai.sh.cn > > -- Original Sender From: Address: yubofan@guomai.sh.cn > > CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: > Coordinator > > MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net > 73 > > Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > > Web: http://www.ccl.net/chemistry.html > > > > A classic way of handling a molecule of this size is to break it down to > logical pieces. Perhaps do at least two optimizations 1) > N-ethyl-N-methylanaline, 2) N-dimethyl-N-alkylamine. Personally, I don't > know > of any other way. > > -- > Luke Anthony Burke tel:609-225-6158 (-6142) > Professor and Chair, fax:609-225-6506 > Department of Chemistry e-mail: > Rutgers University burke@camden.rutgers.edu > Camden, NJ 08102, USA http://camchem.rutgers.edu/~burke > > > Hi, All, > > > > I want to optimize the conformations of some big molecules, for example, > > N-methyl-N-octadecylanaline. I think RHF or DFT methods are not suitable > > for this kind big system. Also, some semi-empirical methods are not > > accurate enough for such calculations. > > > > Which method can do this kind work? > > > > > > Thank you very much! > > > > Y. FAN > > I think the best way is to do a DFT calculation, starting with B3LYP/4-31G > DFT is a good method for large molecules. > > bye, > > *-----*-----*-----*-----*-----*-----*-----* > / / > / Anselmo Elcana de Oliveira / > * Cidade Universitaria Zeferino Vaz * > / IQ - UNICAMP CEP 13083-970 \ > / Campinas, SP - Brasil \ > * elcana@iqm.unicamp.br * > / http://chope.iqm.unicamp.br \ > / \ > * To err is human, * > / To really foul up requires the root password \ > / \ > *-----*-----*-----*-----*-----*-----*-----*-----*-----*-----* > > You may use RHF with small basis sets. However, it still > depends how many memory your computer has. > > ================================================================= > Dr. Buyong Ma buyong@ibmnla.chem.uga.edu > Computational Center for Molecular Structure and Design > Department of Chemistry > University of Georgia > Athens, Georgia 30602 USA Voice (706) 542-2044 > ================================================================= > > > > On Mon, 16 Jun 1997, [CN-GB] ~{76S}2(~} wrote: > > > Hi, All, > > > > I want to optimize the conformations of some big molecules, for example, > > N-methyl-N-octadecylanaline. I think RHF or DFT methods are not suitable > > for this kind big system. Also, some semi-empirical methods are not > > accurate enough for such calculations. > > > > Which method can do this kind work? > > > > > > Thank you very much! > > > > Y. FAN > > > > -------This is added Automatically by the Software-------- > > -- Original Sender Envelope Address: yubofan@guomai.sh.cn > > -- Original Sender From: Address: yubofan@guomai.sh.cn > > CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: > Coordinator > > MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net > 73 > > Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > > Web: http://www.ccl.net/chemistry.html > > > > > > Optimize? You did not indicate what you wish to optimize but I shall > assume > that you are looking for the global minimum, i.e. the conformation with the > minimum energy. This is a non-trivial task and you want to use classical > methods to search conformational space for candidates. I use molecular > dynamics at 1000 K or 2000 K. I have also used Crippen's distance geometry > algorithm. Jeff Blaney has written a nice implementation of distance > geometry > which is available through QCPE. > > Once you have sampled conformational space, you need to minimize each > structure > using molecular mechanics and then sort the structures as to energy. If > you > want a good ab initio energy, you then want to apply quantum-mechanical > methods > to the best structures identified by the classical approach. You won't be > able > to do the entire problem quantum mechanically. Millions of structures are > involved. > From andy@neptune.chem.uga.edu Thu Jul 10 12:15:18 1997 Received: from neptune.chem.uga.edu for andy@neptune.chem.uga.edu by www.ccl.net (8.8.3/950822.1) id LAA29598; Thu, 10 Jul 1997 11:12:24 -0400 (EDT) Received: (from andy@localhost) by neptune.chem.uga.edu (8.7.4/8.7.3) id LAA16346 for CHEMISTRY@www.ccl.net; Thu, 10 Jul 1997 11:13:04 -0400 Date: Thu, 10 Jul 1997 11:12:57 -0400 (EDT) From: Andy Dustman Sender: andy@neptune.chem.uga.edu To: CHEMISTRY@www.ccl.net Subject: Subscribe to G, the GAUSSIAN mailing list Message-ID: -----BEGIN PGP SIGNED MESSAGE----- G is a mailing list devoted exclusively to the GAUSSIAN series of programs. With over 130 subscribers, someone is bound to have the answer to your question. (General computational chemistry questions should continue to be directed to CCL.) To subscribe to G, send mail with the subject "subscribe" to: g-request@ccmsd.chem.uga.edu Andy Dustman / Computational Center for Molecular Structure and Design / UGA To get my PGP public key, send me mail with subject "send file key". For the ultimate anti-spam procmail recipe, send me mail with subject "spam" "Encryption is too important to leave to the government." -- Bruce Schneier http://www.ilinks.net/~dustman mailto:andy@CCMSD.chem.uga.edu <}+++< -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQEPAwUBM8T7/ROPBZTHLz8dAQG+BQfLB+CgFwknV03fGvtDrjfkSqV6yoiZ1hdK aGLeH7aa30L9UDG++u3+h+PSxtpUYOwwUz2OpqX+dcXy/eellGuzoyXjlpYqBT1g HXNxh6Ab7VdH9TGpiheFCd6irDtAiBkd39iy0eJJ82vI4YcwNqgJst1ihaib0nqK YkGhlkSNfKukd0B9FdQ8XhecnfIjS2BNFkM75BgRSWWo4dRTUmnL7HHgayBNefRO FzZk7AQTsv3kjM3p+dFZDAKhwGnenW8JpRux9TPd1atxb5K07uJSpK9V/8lOe+Cl 70Bp+QRHfOOxNXURotjdTGEvCUoFT3RepwUAjw/hUyBQ5g== =iRLN -----END PGP SIGNATURE----- From daizadeh@kappa.ucdavis.edu Thu Jul 10 14:06:11 1997 Received: from kappa.ucdavis.edu for daizadeh@kappa.ucdavis.edu by www.ccl.net (8.8.3/950822.1) id NAA00470; Thu, 10 Jul 1997 13:14:17 -0400 (EDT) Received: (from daizadeh@localhost) by kappa.ucdavis.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA14978; Thu, 10 Jul 1997 10:12:28 -0700 Date: Thu, 10 Jul 1997 10:12:28 -0700 From: daizadeh@kappa.ucdavis.edu (Iraj Daizadeh) Subject: Summary: vizualization of 3-D flow field Message-Id: <199707101712.KAA14978@kappa.ucdavis.edu> To: daizadeh@kappa.ucdavis.edu, CHEMISTRY@www.ccl.net, Hello. Below is a summary of the responses I have received concerning visualization of 3-D data, in particular, visualization of a 3-d flow field. I have also included possible solutions to a recent problem sent to the CCL which corresponds to a related aspect of data analysis; viz., visualization of some sort of iso-surface (generalized contouring). I have attempted to make all listings below as anonymous as possible (plagarism). For the most part, all programs shown below were compiled (or precompiled binaries used) on a SGI (SiliconGraphics,Inc.) R10000 running IRIX 6.2 (except for the Fortner products). I should note that there were many others I have tested as well; a list of those follow: Plotmtv - Great, almost as easy as xmgr!!!!!! YetAnoextHuckMolorbprog - Nice for display of band structures, etc. graph3d - robot - scian - tecate - tipsy - uncert - The last six are vacuous since either I do not remember the programs efficacy or there were compilation problems. Any questions, comments or concerns, please do not hesitate to send me an email. Iraj. P.S. I should note that Vu is a beautiful program that has aided us in our projects tremendously (sp). Images created from this program can be found at http://www.cerca.umontreal.ca/vu/Welcome_eng.html. Make sure you check out the gallery at http://www.cerca.umontreal.ca/vu/gallery/Welcome_eng.html. The people behind Vu are very gratious and the program is free for those in acadamia. Iraj Daizadeh Department of Chemistry University of California Davis, CA 95616 email: daizadeh@indigo.ucdavis.edu Phone: 916.754.8695 -------------------------------------------------------------------------------- Below was the problem: Hello. Would anyone know an easy-to-learn program that allows for visualizing data from a file in 3-dimension Euclidean space something that looks like a fluid dynamics simulation? I started to write such a piece of code using Tcl/Tk but speed is of the essence (as always). Thanks in advance. Iraj Daizadeh Department of Chemistry University of California Davis, CA 95616 -------------------------------------------------------------------------------- #1) I use FAST, developed here, and available for free (I think). It does 3D scalar and vector fields on a wide variety of grids, including, of course, uniform cartesian. For some examples of what it can do for molecules, see http://science.nas.nasa.gov/~creon/papers/mgms96/ for availablitty of FAST, look at http://science.nas.nasa.gov/Software/FAST/ #2) Check out software at http://www.fortner.com/ I have never used their stuff, but it looks impressive (and they have been in business for a while). It is not free - but I think their main modules come as a package for less than $1,000. Fortner: http://www.fortner.com/docs/demos_all.html #3) Try pgplot. It's not available in netlib but it's excellent and free. See http://astro.caltech.edu/~tjp/pgplot/ It may not do *exactly* what you need but I think it'll come close, probably a lot closer than other free tools. #4) Sorry about the delay, but hours are not always so extensible as I might wish! Yes! VU can create pictures of 3-d fields using streamlines and/or vectors. Yes!! VU can displayed atoms and links between them using spheres and cylinders colored according to the usual standards. And Yes!!! you can put all of this on screen at the same time! We have created a couple of new images in the VU gallery representing small molecules in which a cutting plane is used to probe and visualize a scalar field. These are not big protein but rather small molecules, but the idea is the same. I invited you to go check again the VU home page at http://www.cerca.umontreal.ca/vu/gallery/ to check these new additions. VU is developped mainly for use in Computational Fluid Dynamics (CFD), but it also usefull for other application domains. It is being use extensively for chemistry applications here at Cerca and nearby universities, and also at the University of Hannover with AllChem (their web address is in VU HomePage). ** VU allows for 2-d and 3-d exploration of scalar fields as well as vector fields. Furthermore, VU can also display geometric entities such as curves and surfaces. ** Scalar fields can be probed/represented using either : - iso-surfaces in 3-d space, - iso-lines on arbitrary cutting planes - iso-lines on surfaces of constant coordinate from a structured grid. - graphs, i.e. continuously shaded images representing the values of a scalar field on cutting planes (or surfaces of constant coordinate from a structured grid). ** Vector fields can be probed/represented using either : - arrows (scalable) - streamlines in various number and location, all of which is specified interactivally. - dynamic particle tracing: non static images in which particle (represented as small spheres) are injected in various location to probe the vector fields. ** VU can extract information from these various fields and present them in a tabular form in a file or directly at the cursor location. ** VU uses `expressions' such as "sqrt(px*px+py*py+pz*pz)" to indicate color mapping, deformation or scaling factor for use in creating images (at least colorfull if not always meaningfull!). ** VU can also use transparency in any image, in order to be able able to `see' what is behind a cutting plane or an iso-surface. ** VU uses OpenGL and Motif (both fairly standard libraries) and works on UNIX workstations: IRIX, AIX, HP-UX, OSF1 and Linux. In a nutshell, VU can creates many and various images of 2-d and 3-d scalar and vector fields from a solution computed over a set of grid nodes. The input file for VU specifies the mesh used and the computed solution fields. You may see and read about some examples in the VU Web pages. However, if the fact that some of the web pages crucial for a full understanding of the capabilities of the program and of its input file might not be in english, you could forward a sample test case of your data to support_vu in order to establish its usuability in your case. Even if the documentation has not been yet completely translated and made avalailable on the Web, VU is nonetheless available in four languages: french, english, german and spanish. #5) IBM visualization data explorer/IRIS explorer will do. A while ago, i downloaded the comparison of these visualization softwares. Now I dont remember the URL. But u can find them in my homepage. http://144.16.73.100/~parthi/home.html and CLICK "visualization". u can see the comparison of four visualization softwares. #6) One possibility for almost all visualization tasks is to write a simple program to transform the data to a VRML file and then use a VRML browser to visualize it. For more information about VRML, look at the VRML repository (http://www.sdsc.edu/vrml/). For an example of code that generates VRML, look at the VRML module on my Python page (http://www.yi.com/home/HinsenKonrad/python.html). #7) I'm glad you enjoyed the site. I usually use Matlab or Mathematica to plot my vectors. Unfortunately, both of these programs are commercial so you must buy them. There may be shareware available on the internet to do the same thing. Happy hunting. #8) I don't know what your constraints are: systems, time, money, expertise ... but if I were in your position, I could knock out a visualization of "data from a file in 3-dimension Euclidean space something that looks like a fluid dynamics simulation" in 30-60 minutes using AVS. Have you any familiarity with it at all? There were other packages (IBM's Data Explorer and SGI's IRIS Explorer) which did much the same thing and were all the rage 3-4 years ago. #9) Vis5D will suit your needs if your data are sampled on a rectangular 3-D grid, and you have values for px, py and pz at each grid point. See Section 3.1 of the Vis5D README file for instructions about getting your data into Vis5D. I recommend map projection 0 (generic) and vertical coordinate system 0 (generic), since your data are not related to Earth coordinat (latitude and longitude). If you use the names 'U', 'V' and 'W' for px, py and pz then Vis5D will recognize these as the three components of a vector field. If you don't, then you can use the 'UVW VARS' widget to tell Vis5D which fields are vector components. In generic coordinates, vector components are in the units given for North, South, East, West, Top and Bottom bounds, per second. If you have a time sequence of data (i.e., a changing vector field), Vis5D will trace motion trajectories for you. You'll need to correctly assign dates and times to time steps to get realistic motions. If you only have one time step, you can still look at motion trajectories by just repeating the same data over a sequence of times. Good luck. #10) The purpose of this message is to give you a quick feeling for how the NCAR graphics package can be used to display graphs of your data from the Cray. The NCAR graphics package consists of libraries of C and Fortran callable subrou- tines for creating graphs and utilities for displaying them. #11) MSI's software developer's kit does exactly what you want. It includes an API set to visualize iso-surfaces, molecular structure, trajectories, normal modes, plots/graphs, etc. It also allows you in a few steps to put an interface together to any computational chemistry code. For general information about this toolkit visit: http://www.msi.com/support/sdk/ for specific information on plotting iso-surfaces visit: http://www.msi.com/support/sdk/users/examples/iso/README.html #12) Dear CCLers, although I'm pretty sure this question has been already posed (and I beg your pardon for posing it again), I have to ask about a 3D visualisation tool. I worked with SciAn, which is pretty good indeed, but the only existing version needs Z buffer and DGL. Looking on the net I found a software called vis5d, pretty good the same but tuned for metereological data and I found too time-expensive to adapt it to visualize orbitals, electronic density and so on. I'm using molden but I would like to find out soemthing more general (I'm trying to use ELF also, and this feature is not implemented in molden). The software I'm looking for should manage x,y,z,function_value in order to give isosurfaces of the function I'm trying to plot. Something not strictly platform-dependant would be very fine. Thank you for all the information you will provide. Iraj Daizadeh Department of Chemistry University of California Davis, CA 95616 email: daizadeh@indigo.ucdavis.edu Phone: 916.754.8695 Fax: 916.752.8995 From germano@dcci.unipi.it Sun Jul 13 11:06:55 1997 Received: from server1.dcci.unipi.it for germano@dcci.unipi.it by www.ccl.net (8.8.3/950822.1) id LAA15450; Sun, 13 Jul 1997 11:03:23 -0400 (EDT) Received: from hulk.icqem.pi.cnr.it by server1.dcci.unipi.it (SMI-8.6/SMI-SVR4) id RAA28386; Sun, 13 Jul 1997 17:03:17 +0200 Date: Sun, 13 Jul 1997 17:02:55 +0200 (MDT) From: Guido Germano X-Sender: guido@hulk.icqem.pi.cnr.it Reply-To: Guido Germano To: "M. Nicklaus" , "Nathaniel (noj) Malcolm" cc: chemistry@www.ccl.net Subject: Re: CCL:G:Gaussian bug? In-Reply-To: <199707111416.KAA21526@helix.nih.gov> Message-ID: Organization: Dipartimento di Chimica e Chimica Industriale - Univ. di Pisa MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 11 Jul 1997, M. Nicklaus wrote: > > Find enclosed a Gaussian 94 input file with a simple Hartree-Fock run. > > On a SGI Indigo 2 (Gaussian 94 Rev. D.4) its first SCF reads > > SCF Done: E(RHF) = -1090.96251553 A.U. after 11 cycles > > while the SAME input file yields on an IBM (Rev. B.3) and a DEC (Rev. D.4) > > SCF Done: E(RHF) = -1086.47515931 A.U. after 3 cycles > > I am running your exact same input file on an Intel > Pentium Pro 200 MHz machine, running RedHat Linux 4.1 > (kernel v. 2.0.27), using Gaussian 94, Rev. E.1. > Here are the first two SCF's: > SCF Done: E(RHF) = -1086.46226785 A.U. after 14 cycles > SCF Done: E(RHF) = -1086.46242745 A.U. after 8 cycles > > What were your final energies after optimization? Marc, thank you for running this input file on yet another platform with yet another revision of Gaussian 94, confirming thus that the correct energy is around -1086.5 and not -1091.0 atomic units. I must apologize because the very first SCF on the IBM yielded SCF Done: E(RHF) = -1086.47487935 A.U. after 14 cycles and not, as I wrote, -1086.47515931 A.U. after 3 cycles, which is the first SCF of the first restart file (it could be guessed also from the small number of cycles needed to reach self-consistency: 3 instead of 14, thanks Noj). I restarted the optimization twice, and stopped it after a total of 44 steps, because there were no significative changes. The lowest energy, reached at steps 28, 33, 37 and 41, was -1086.47517580. It surprises me that the first SCF on the Pentium differs after the second decimal figure from those on the IBM and the DEC, which were identical in spite of different g94 revisions. However, that's nothing compared with the 4.5 hartrees difference with the SGI... I didn't receive any answer from Gaussian, Inc. so far, nor any decisive hint from the CCL folks yet. Below I enclose the list of the energies at every optimization step. Regards, and thanks to Nathaniel Malcolm and Marc C. Nicklaus for answering. _____________________________________________________________________________ Guido Germano PhD student in Computational Chemistry Dipartimento di Chimica e Chimica Industriale e-mail germano@dcci.unipi.it Universita` di Pisa http://www.dcci.unipi.it/~germano Via Risorgimento 35 finger guido@hal.icqem.pi.cnr.it I-56126 Pisa phone +39-50-918.266, .295 or .239, fax .260 _____________________________________________________________________________ g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47487935 A.U. after 14 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47493464 A.U. after 7 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47131315 A.U. after 8 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47502780 A.U. after 8 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47479785 A.U. after 7 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47497507 A.U. after 8 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47510545 A.U. after 6 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47501048 A.U. after 8 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47517654 A.U. after 7 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47514597 A.U. after 6 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47516223 A.U. after 5 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47515896 A.U. after 5 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.47515784 A.U. after 2 cycles g94_pdtbuB1.out: SCF Done: E(RHF) = -1086.28464749 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.28464749 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47517564 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47515928 A.U. after 3 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47515786 A.U. after 2 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.28462806 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47517587 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47515933 A.U. after 3 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47515786 A.U. after 2 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.28492972 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47517581 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47515931 A.U. after 3 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47515786 A.U. after 2 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.28489904 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47517580 A.U. after 10 cycles g94_pdtbuB2.out: SCF Done: E(RHF) = -1086.47515931 A.U. after 3 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515931 A.U. after 3 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515786 A.U. after 2 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.28488924 A.U. after 10 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47517580 A.U. after 10 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515931 A.U. after 3 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515786 A.U. after 2 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.28488959 A.U. after 10 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47517580 A.U. after 10 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515931 A.U. after 3 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515786 A.U. after 2 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.28488960 A.U. after 10 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47517580 A.U. after 10 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515931 A.U. after 3 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.47515786 A.U. after 2 cycles g94_pdtbuB3.out: SCF Done: E(RHF) = -1086.28488959 A.U. after 10 cycles From rgab@proteus.co.uk Fri Jul 11 10:06:26 1997 Received: from petersgate.proteus.co.uk for rgab@proteus.co.uk by www.ccl.net (8.8.3/950822.1) id JAA07220; Fri, 11 Jul 1997 09:49:50 -0400 (EDT) Received: from Icthus.proteus.co.uk (Icthus [193.115.24.114]) by petersgate.proteus.co.uk (8.6.12/8.6.6) with ESMTP id OAA28712; Fri, 11 Jul 1997 14:12:26 GMT Message-Id: <199707111412.OAA28712@petersgate.proteus.co.uk> From: Richard Bone Date: Fri, 11 Jul 1997 14:39:10 +0100 To: CHEMISTRY@www.ccl.net Subject: SMILES Database? Cc: diversity@LISTSERV.ARIZONA.EDU Does anyone know of a public-domain database of SMILES strings for commonly- occurring small organic molecules and functional groups? I'm looking for something containing several hundred or more species. It would need to be something in ASCII format, for general utility, i.e., not in a format specific to some commercial package. Richard Bone P.S. #1 - Yes - I've done a web-search already; P.S. #2 - No, I don't have the Daylight software here. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Richard G. A. Bone, Ph.D. | | | Senior Computational Chemist | | | Proteus Molecular Design Ltd. | Tel: +44 (0)1625 500555 | | Lyme Green Business Park | Fax: +44 (0)1625 500666 | | Macclesfield, Cheshire | Email: rgab@proteus.co.uk | | United Kingdom SK11 0JL | Web: http://www.proteus.co.uk | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From support@mathtrek.com Fri Jul 11 10:14:51 1997 Received: from granite.sentex.net for support@mathtrek.com by www.ccl.net (8.8.3/950822.1) id JAA07153; Fri, 11 Jul 1997 09:40:06 -0400 (EDT) Received: from p22a.lithium.sentex.ca (p7a.neon.sentex.ca [207.245.212.200]) by granite.sentex.net (8.8.5/8.6.9) with SMTP id JAA06840; Fri, 11 Jul 1997 09:48:49 -0400 (EDT) Message-Id: <3.0.16.19970711093433.2f5f6850@mathtrek.com> X-Sender: mathtrek@mathtrek.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 11 Jul 1997 09:37:27 -0400 To: Konrad Hinsen , online@mactech.com, chemistry@www.ccl.net From: "W. R. Smith" Subject: Re: CCL:Object-oriented means for computational chemistry programming Cc: chemistry@www.ccl.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hello again, At 12:25 PM 7/11/97 +0200, Konrad Hinsen wrote: >> But, in a completely undefensible statement of preference: today, new >> code should be built in C/C++ (IMHO). I respect the fact that a huge [...] > >I don't disagree in principle, but a few clarifications can't hurt >(which are of course largely my personal opinion!): > >- C is no more OO than Fortran, but it doesn't have most of Fortran's > most severe problems. But Fortran-90 is no worse than C, and in some > respects better. i.e. Fortran can be OO too. A quote by a distinguished scientist that I recall from a scientific meeting about 10 years ago: "I don't know what type of programming language scientists will be using in the next millenium, but it will be CALLED Fortran" i.e. Fortran will evolve over time to incorporate newly desired features > >- The main advantage of C is support: there is a C compiler for every > imaginable machine, and there are plenty of high-quality libraries. > But there is little support for numerical work, and indeed many C > compilers are rather bad at optimizing standard numerical code. Note also that Microsoft seems to have dropped Fortran support - passed it on to DEC, it would appear. > >- C++ is an exceedingly complicated language, largely due to its > compatibility to C. It may seem simple at first, but the more > you get into the details the more surprises you will find. > Worse, there is a frightening number of "undefined" situations, > meaning that the meaning of certain pieces of code is compiler > dependent. Writing solid and portable C++ code requires a lot of > experience. The payoff may be worth it for professional programmers, > but most scientists are not professional programmers. > >The bottom line: no single language is perfect. I think scientists >should get used to the idea of mixed-language programming. For >a small number-crunching subroutine the best choice may well be >Fortran, but for the majority of a non-trivial program it certainly >isn't. But all modern operating systems have provisions to link >code in different languages together. > >Scientists should also have a closer look at high-level languages. >They make development and testing substantially easier by taking care >of much detail automatically. Of course that comes at a price in terms >of speed, but the majority of a typical scientific program is *not* >time-critical. The CPU intensive parts are specific subroutines that >can still be implemented in a low-level language. e.g. a Visual Basic front-end with Fortran or C .DLL's > >My personal recommendation for a high-level language is Python. It is >sufficiently simple, has a clear syntax, and a very convenient >interface to low-level languages. For C code, a Python interface can >even be generated automatically with a tool called SWIG. More on >Python at http://www.python.org, and on my "Python for Science" page >at http://starship.skyport.net/crew/hinsen/. Finally, for those who >don't mind a trip to San Jose, the 6th International Python Conference >from 14-17 October in San Jose will have tutorials, presentations, and >discussions on scientific applications of Python. No slight against Python, but we all remember the following historical sequence: Algol vs Fortran (1960's) PL1 vs Fortran (1970's) Pascal vs Fortran (1980's) and now, it's C vs Fortran On the left-hand side, it has usually been CS (computer-science) types. On the RH side, it has usually been scientists/engineers. > >-------This is added Automatically by the Software-------- >-- Original Sender Envelope Address: hinsen@lmspc1.ibs.fr >-- Original Sender From: Address: hinsen@ibs.ibs.fr >CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: Coordinator >MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73 >Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > Web: http://www.ccl.net/chemistry.html > > > -- W. R. Smith, PhD, P. Eng., Senior Scientist, Mathtrek Systems -- 3-304 Stone Road West, Suite 165, Guelph, Ontario CANADA N1G 4W4 EMail: support@mathtrek.com Tel:519-763-1356,FAX:519-763-4525 --------------------- http://www.mathtrek.com --------------------- -Mathtrek Systems - Home of EQS4WIN Chemical Equilibrium Software - From ccl@www.ccl.net Fri Jul 11 11:17:35 1997 Received: from bedrock.ccl.net for ccl@www.ccl.net by www.ccl.net (8.8.3/950822.1) id KAA07749; Fri, 11 Jul 1997 10:57:27 -0400 (EDT) Received: from relay5.UU.NET for frisch@lorentzian.com by bedrock.ccl.net (8.8.6/950822.1) id KAA07109; Fri, 11 Jul 1997 10:57:23 -0400 (EDT) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQcxtb26576; Fri, 11 Jul 1997 10:57:31 -0400 (EDT) Received: from m10.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 11 Jul 1997 10:57:23 -0400 Received: from holly by m10.lorentzian.com; Fri, 11 Jul 1997 10:08:21 -0400 Received: (from frisch@localhost) by holly (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA11011 for chemistry@ccl.net; Fri, 11 Jul 1997 10:08:16 -0400 From: frisch@lorentzian.com (Mike Frisch) Message-Id: <199707111408.KAA11011@holly> Subject: Re: CCL:G:G:Gaussian on a Mac ? ---Or Other Platforms To: chemistry@ccl.net Date: Fri, 11 Jul 1997 10:08:16 -0400 (EDT) In-Reply-To: <199707102154.RAA07432@helix.nih.gov> from "M. Nicklaus" at Jul 10, 97 05:54:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit M. Nicklaus writes: > > Hi, > > On Thu, 10 Jul 97, "Frederick R. Bennett" > > I know that Gaussian Inc. hates this sort of thing but I will ask anyway. I > > am wondering whether anyone has G94 running on a PowerMac running one of the > > Linux operating systems (MKLinux or the non-Micro Kernal). > > > > Just as a matter of opinion, I think that Gaussian Inc. should seriously > > consider supporting this platform, as they do the various Unices running on > > Intel machines. The motorola PowerPC chips are leaving Intel Pentiums for > > dead at the moment and with the new generation motorola chips on the way > > out, fast system buses and new cacheing technology, Mac's or Mac clones > > should/can provide the hardware for some high power/cost ratio workstations > > for chemistry. > > Since this can has been opened, let me chip in with a remark and a question. > > 1. I agree with Frederick R. Bennett in that Gaussian Inc. should support > more of the new fast, and *cheap*, platforms such as PowerPC systems > running Linux. I'd like to expand this request to include Alpha CPU systems > running axp Linux. These chips are even faster than the PowerPC's. We've > benchmarked them with other software. 500 MHz machines (non-DEC) can be had > for $5,000-6,000. The 600 MHz 21164 chip based systems are basically shipping > (albeit expensive, ~$11k), and the 800 MHz CPUs are in the pipeline. > We at Gaussian, Inc. agree with this, but in practice it requires a reliable operating system, and this is definately not the case for Linux/Alpha, and is questionable for Linux/PPC. > 2. We've tried to compile G94, Rev. E.1 for such a 21164 500 MHz Alpha based > system, running RedHat Linux 4.1, kernel v. 2.0.27 --- unfortunately, > unsuccessfully so far. We've experienced problems with f2c, gcc, as well as > the linker. So therefore my question: Has anyone been able to get G94 to > run on this platform? If yes, how? > We have an Alphax/Linux machine in house but Linux for Alpha has turned out to be very, very far from the stable environment Linux is for Intel machines. For example, there are well-documented and very serious problems linking large programs which have not yet been resolved. Anyone interested can subscribe to the Linux/Alpha mailing list and receive a dozen or so examples PER DAY of things that work under Linux/Intel but not under Linux/Alpha. When Linux is actually stable for production use on processors other than Intel, we certainly intend to support Gaussian there. Mike Frisch Gaussian, Inc. From bernhold@tarkovsky.npac.syr.edu Fri Jul 11 12:11:33 1997 Received: from postoffice.npac.syr.edu for bernhold@tarkovsky.npac.syr.edu by www.ccl.net (8.8.3/950822.1) id LAA07939; Fri, 11 Jul 1997 11:15:50 -0400 (EDT) Received: from tarkovsky.npac.syr.edu (tarkovsky-007.npac.syr.edu [128.230.7.175]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with ESMTP id LAA28557 for ; Fri, 11 Jul 1997 11:15:52 -0400 (EDT) Received: from localhost (bernhold@localhost) by tarkovsky.npac.syr.edu (8.8.5/8.7.1) with SMTP id LAA26253 for ; Fri, 11 Jul 1997 11:15:52 -0400 (EDT) Message-Id: <199707111515.LAA26253@tarkovsky.npac.syr.edu> X-Authentication-Warning: tarkovsky.npac.syr.edu: bernhold@localhost didn't use HELO protocol To: chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry In-reply-to: <9706118686.AA868636205@sctepsc2.sct.co.uk> Date: Fri, 11 Jul 1997 11:15:52 -0400 From: "David E. Bernholdt" There have been a lot of interesting and useful messages in this thread, but I think there is a core point that hasn't been emphasized enough: There is a difference between what I will refer to as "object-oriented design" (OOD) and "object-oriented languages" (OOL). I am intentionally avoiding the phrase "object-oriented programming" because I think it muddies the distinction. According to Booch ("Object-Oriented Analysis and Design"), the four basic elements of the object model of programming are o Abstraction -- extracting the essential characteristics that distinguish one object from another. o Encapsulation -- serves to separate the outside world's interface to and abstraction from its (internal) implementation o Modularity -- being able to decompose a system into a set of loosely coupled modules. o Hierarchy -- ranking or ordering of abstractions. At a basic level, these are little more than the ideas of what constitutes "good programming" that most of us have heard or read about from time immemorial, and which most of us (based on chemistry code I've seen) largely ignore. One can DESIGN software based on these principles (OOD) regardless of what language the software is to be implemented in. There are some languages around these days which support (or enforce) an object-oriented model to a greater extent than others. These we might refer to as object-oriented LANGUAGES. The problem with the popular phrase "object-oriented programming" is that people tend to lump the DESIGN and the IMPLEMENTATION together when they think of PROGRAMMING. In a discipline where Fortran remains the dominant implementation language, the distinction is important. Most people would agree that even Fortran90 is not an OOL. However it is most definitely possible to implement OOD software architectures in Fortran (and other non-OOLs). It takes more care and discipline. It may take more time, because it implies a serious effort at design, which I don't think a lot of people pay much attention to. I definitely think the benefits are worth it. The NWChem parallel computational chemistry package (http://www.emsl.pnl.gov:2080/docs/nwchem/nwchem.html) was developed using OOD principles and implemented in a mixture of Fortran and C. It is on the order of 700,000 lines of code, and it works (contrary to the opinion someone else expressed about being unable to create a Fortran code so large). We made a carefully-considered decision to go this route rather than using C++ at the time the project began. I think we would make the same decision today, though that doesn't mean that it might not change down the road. I disagree with the person who proposed C++ is "the" langauge for future work because it is an OOL. There are a lot of other considerations that (should) factor into the decision of which language to use. However I think that ALL projects should consider object-oriented DESIGN regardless of implementation language. -- David E. Bernholdt | Email: bernhold@npac.syr.edu Northeast Parallel Architectures Center | Phone: +1 315 443 3857 111 College Place, Syracuse University | Fax: +1 315 443 1973 Syracuse, NY 13244-4100 | URL: http://www.npac.syr.edu From online@mactech.com Fri Jul 11 13:06:37 1997 Received: from neon.chem.ucla.edu for online@mactech.com by www.ccl.net (8.8.3/950822.1) id MAA08419; Fri, 11 Jul 1997 12:16:16 -0400 (EDT) Received: from [164.67.23.39] (ts40-10.wla.ts.ucla.edu [164.67.23.39]) by neon.chem.ucla.edu (8.8.0/8.8.0) with ESMTP id JAA19857 for ; Fri, 11 Jul 1997 09:17:17 -0700 (PDT) X-Sender: nick@neon.chem.ucla.edu Message-Id: In-Reply-To: <3.0.16.19970711093433.2f5f6850@mathtrek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Jul 1997 09:22:18 -0800 To: chemistry@www.ccl.net From: "nick.c" Subject: Object-oriented means for computational chemistry programming me: >>> But, in a completely undefensible statement of preference: today, new >>> code should be built in C/C++ (IMHO). I respect the fact that a huge ("undefensible"... I gotta stop posting articles after midnight... :-) Konrad: >>- C is no more OO than Fortran, but it doesn't have most of Fortran's >> most severe problems. But Fortran-90 is no worse than C, and in some >> respects better. W.R.: >i.e. Fortran can be OO too. I respectfully disagree. I'm no language theory expert, but my understanding is Fortran isn't OOP (for reasons I've already posted). For that matter neither is C (I believe Konrad said exactly this). The only reason I mentioned C in the first place, was by way of a disclaimer. Each job is unique, and sometimes C++ is not the best way to solve the problem at hand. Frequently I find a procedural solution is sufficient or preferable. For that matter, in many cases Fortran is probably the way to go on a specific project. Issues of what compilers are available for a platform, what programming languages your team is comfortable with, what legacy code you have available, who you're going to turn the code over to for maintenance, how fast your dev cycle is, what your budget looks like, does your customer have a preference, which way the wind is blowing, and others end up deciding how a project is going to get coded. That said, C++ offers tremendous benefits for managing large projects. C++ has unique and powerful resources for easily reusing and improving on old code-- even that piece of code that you had no idea you were going to ever need to reuse, and so would not have made modular if you were using C or Fortran. It's the industry standard: there's a C++ compiler for every platform, there are huge commercial libraries of classes, there is a wealth of books, formatting tools, class browsers, visual development tools, and other neat toys for the C++ set. Anyway, I'm not going to convince anyone here that C++ is the "next-great-thing" (I think Java might have that title by now anyway :-), but I would strongly encourage anyone starting a new project to at least weigh the benefits of the C++ language against the speed of recycling Fortran legacy. That code is going to wear out sometime, the only question is: do you want to rewrite it in C++ now, or two years from now when it's that much larger? >A quote by a distinguished scientist that I recall from a scientific >meeting about 10 years ago: > >"I don't know what type of programming language scientists will be using in >the next millenium, but it will be CALLED Fortran" Hm... Algol 60 was influenced by Fortran. C derived from BCPL, which came from CPL, which is Algol 60 based. C with Classes and C++ are OOP implementations of C. One could argue that C++ is just a new flavor of Fortran, and who knows--maybe when 2000 rolls around and we'll all be calling it Fortran00 (or maybe FortranOO :-) >No slight against Python, but we all remember the following historical >sequence: > >Algol vs Fortran (1960's) >PL1 vs Fortran (1970's) >Pascal vs Fortran (1980's) > >and now, it's > >C vs Fortran > >On the left-hand side, it has usually been CS (computer-science) types. On >the RH side, it has usually been scientists/engineers. Maybe. Still I think the distinction between "computer-science types" and "scientist/engineer" types is getting increasingly slight. I also think you're bumping into a whole new generation of scientists, many of whom learned C before they found out what a d orbital was. It's not a matter of learning a programming language to solve a problem in science (and thus being influenced by the language choice of your advisor or the legacy code lying around the lab, like in 60's and 70's). Many new college students already know how to program--and frankly most grade schools, high schools and JC's are pushing C/C++, not Fortran. Add to that the portion of your faculty who graduated in '85 and are hard core C++ fanatics (Pascal wasn't the only thing pushing on Fortran in the 80's :-). Explaining the value of Fortran to new college students these days is a lot like trying to explain why TVs didn't always have remote controls. I tip my hat to Fortran, I tipped my hat to Ali, but it was pretty clear when Ali stepped into the ring for the last time, that it was the last time. It looks like Fortran has run it's course as well. Dunno what the next great thing will be: Objective C, Java, C++. Dunno. But if you like, you *can* still call it Fortran :-) ____Nicholas C. DeMello, Ph.D.________________________________________ Online at MacTech Magazine, the Journal of Macintosh Programming http://www.MacTech.com/ _/ _/ _/ _/_/_/ _/ _/ Chemistry: Nick@chem.UCLA.edu _/_/ _/ _/ _/ _/ _/_/_/ MacTech: Online@MacTech.com _/ _/_/ _/ _/ _/ _/ http://www.chem.ucla.edu/~nick/ _/ _/ _/_/_/ _/ _/ From bernhold@tarkovsky.npac.syr.edu Fri Jul 11 14:37:08 1997 Received: from postoffice.npac.syr.edu for bernhold@tarkovsky.npac.syr.edu by www.ccl.net (8.8.3/950822.1) id NAA08661; Fri, 11 Jul 1997 13:14:23 -0400 (EDT) Received: from tarkovsky.npac.syr.edu (tarkovsky-007.npac.syr.edu [128.230.7.175]) by postoffice.npac.syr.edu (8.7.5/8.7.1) with ESMTP id NAA00145; Fri, 11 Jul 1997 13:13:25 -0400 (EDT) Received: from localhost (bernhold@localhost) by tarkovsky.npac.syr.edu (8.8.5/8.7.1) with SMTP id NAA27510; Fri, 11 Jul 1997 13:13:25 -0400 (EDT) Message-Id: <199707111713.NAA27510@tarkovsky.npac.syr.edu> X-Authentication-Warning: tarkovsky.npac.syr.edu: bernhold@localhost didn't use HELO protocol To: chemistry@www.ccl.net cc: berriz@chasma.harvard.edu (Gabriel Berriz) Subject: Re: CCL:Object-oriented means for computational chemistry programming In-reply-to: <9707111440.AA24246@chasma.harvard.edu> Date: Fri, 11 Jul 1997 13:13:25 -0400 From: "David E. Bernholdt" It idea of mixed language programming is to use languages most appropriate for the task at hand, not just for speed, but for ease of implementation. Such decisions are usually fairly coarse-grained. For example, you might prefer to use C code to implement operations on a fairly complex data structure, while a computationally-intensive section might better be written in Fortran. If the code is well encapsulated, there should be little problem (conceptually) and no performance degredation from hooking up code written in multiple languages. Of course that's different from making a poor choice of programming language to implement a given component. It is true that interlanguage programming is not standardized (yet), but as a practical matter, on a given platform you can expect that most languages (from the same vendor at least) will follow a similar underlying structure and _will_ be able to interface. It is also true that relatively little documentation of these interfaces is available, but in most cases it is really fairly straightforward. Some things, like mixed Fortran77 and C, are now so common that there is a community of people out there who understand pretty well how to do this and even some packages/templates to help you do it in a platform-independent way. If you seek out such people, you can probably find them without too much trouble. I can't recall a case where I had to know more about the "processor-dependent nitty-gritty of numerical computation" to do mixed-language programming than I needed to do a good job of scientific programming in one language -- the interfaces are rarely so fine-grained as that. > Ultimately, most folks are more concerned with optimizing their time > use than the computer's :-) . In my opinion, this is the reason _to_ use mixed language programming. If I wanted to write a robust input parser for a large chemistry software package, I'm sure I could write it in Fortran, but it would take a lot of work. These days, there are tools to do this quite easily in C (lex, yacc, etc.). For many people, the time required to write the parser in C _and_ the time to sort out the interface to Fortran would be shorter than writing it in scratch from Fortran. And the C-Fortran interfacing skills learned during the exercise could easily be reused for other projects. -- David E. Bernholdt | Email: bernhold@npac.syr.edu Northeast Parallel Architectures Center | Phone: +1 315 443 3857 111 College Place, Syracuse University | Fax: +1 315 443 1973 Syracuse, NY 13244-4100 | URL: http://www.npac.syr.edu From MAILER-DAEMON@www.ccl.net Sat Jul 12 10:06:36 1997 Received: from schiele for MAILER-DAEMON@www.ccl.net by www.ccl.net (8.8.3/950822.1) id JAA11949; Sat, 12 Jul 1997 09:16:19 -0400 (EDT) Received: by schiele (950911.SGI.8.6.12.PATCH825/940406.SGI.AUTO) for chemistry@www.ccl.net id PAA15694; Sat, 12 Jul 1997 15:16:52 +0200 From: "Wolf-Dietrich Ihlenfeldt" Message-Id: <9707121516.ZM15692@eros.ccc.uni-erlangen.de> Date: Sat, 12 Jul 1997 15:16:48 -0600 In-Reply-To: "Bob Goldstein" "CCL:Object-oriented means for computational chemistry programming" (Jul 11, 14:10) References: <199707111915.PAA09791@www.ccl.net> Reply-To: wdi@eros.ccc.uni-erlangen.de X-Phones: +49-9131-85-6579 X-Fax: +49-9131-85-6566 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry programming Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit On Jul 11, 14:10, Bob Goldstein wrote: > Subject: CCL:Object-oriented means for computational chemistry programming > > > > Some things, like mixed Fortran77 and C, are now so common that there > > is a community of people out there who understand pretty well how to > > > >Are you offering your services? :-) Perhaps it's not as bad as it > >looks from my end, but if I had to rely on the kindness of unpaid > [...snip ...] > > Hmm. How about mixed tcl/C ? The tcl interpreter is done in C, > so rebuilding the interpreter is not mixed-language. But the > result would be -- use tcl (slow as molasses, but lots of > high level constructs like hashes, regular expressions, flow > control) for the putting-together-the-tools part, and let > C (or fortran) do the heavy lifting. > > Someone could provide a toolkit of tcl commands written in C, > and anyone could put the tools together in new ways using > a highlevel scripting language. I think perl and python > would also work as scripting languages here. This is > not just object-oriented (for the programmer) but also > somewhat component-oriented (for the application builder or > end user). Such a toolkit does indeed exist. See http://schiele.organik.uni-erlangen.de/cactvs/ >-- End of excerpt from Bob Goldstein -- 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 From gerwalin@iris1.chemie.uni-kl.de Sun Jul 13 12:06:59 1997 Received: from uni-kl.de for gerwalin@iris1.chemie.uni-kl.de by www.ccl.net (8.8.3/950822.1) id LAA16180; Sun, 13 Jul 1997 11:42:16 -0400 (EDT) Received: from iris1.chemie.uni-kl.de by news.uni-kl.de id aa00265; 13 Jul 97 17:42 MET DST Received: by iris1.chemie.uni-kl.de (940816.SGI.8.6.9/940406.SGI.AUTO) for chemistry@www.ccl.net id RAA03439; Sun, 13 Jul 1997 17:42:14 +0200 Date: Sun, 13 Jul 1997 17:42:14 +0200 From: Elmar Gerwalin Message-Id: <199707131542.RAA03439@iris1.chemie.uni-kl.de> To: chemistry@www.ccl.net Subject: G94:freq iterations SUMMARY (I asked : How much steps including the output line "Re-enter D2Numr: IAtom= 1 IXYZ=2 IStep= 1." does a G94 calculation " B3LYP freq=(numer,restart)" (using Cs symmetry) perform ? ) Thanks for all who answered ! Here's the summary (on your request) The "opinions" cover the range from 3N*1 "mostly" to 7N steps. I can't give a correct answer now, just read the following statements that were sent to me. It hasn't become clear (to me) why G94 "mostly" does 6 (or 7) steps for each atom, only 5 steps for atoms lying in the symmetry plane and why my job performs 6 steps for ANY atom, although working in Cs symmetry. I will go on checking that out and perhaps tell you soon! ------ here's the summary ------ 1.) 3N to 6N From wall@phys.chem.ethz.ch Fri Jul 11 13:49:59 1997 It's easy: N atoms, 3 cartesian coordinates each, 1 step most of the time, 2 steps if g94 finds one is not sufficient. Hence the number of calcs will be somewhere between 3N and 6N. 2.) 6N(+1), decreased by symmetry, 5 or 6 steps per atom For example, in the case of CH2 molecule, Gaussian calculates force constants like next 10 steps. 1 The SCF and gradient calculation at the equilibrium point. 2 Re-enter D2Numr: IAtom= 1 IXYZ=1 IStep= 1. Carbon X axis + direction 3 Re-enter D2Numr: IAtom= 1 IXYZ=2 IStep= 1. Carbon Y axis + direction 4 Re-enter D2Numr: IAtom= 1 IXYZ=3 IStep= 1. Carbon Z axis + direction 5 Re-enter D2Numr: IAtom= 1 IXYZ=3 IStep= 2. Carbon Z axis - direction 6 Re-enter D2Numr: IAtom= 2 IXYZ=1 IStep= 1. hydrogen X axis + direction 7 Re-enter D2Numr: IAtom= 2 IXYZ=2 IStep= 1. hydrogen Y axis + direction 8 Re-enter D2Numr: IAtom= 2 IXYZ=2 IStep= 2. hydrogen Y axis - direction 9 Re-enter D2Numr: IAtom= 2 IXYZ=3 IStep= 1. hydrogen Z axis + direction 10 Re-enter D2Numr: IAtom= 2 IXYZ=3 IStep= 2. hydrogen Z axis - direction The number of steps are 6N+1, (N=number of atom). But, symmetry(for example C2V) can decrease the number to 10(from 19). The skipped 9 steps are, 1 Re-enter D2Numr: IAtom= 1 IXYZ=1 IStep= 2. 2 Re-enter D2Numr: IAtom= 1 IXYZ=2 IStep= 2. 3 Re-enter D2Numr: IAtom= 2 IXYZ=1 IStep= 2. 4 Re-enter D2Numr: IAtom= 3 IXYZ=1 IStep= 1. 5 Re-enter D2Numr: IAtom= 3 IXYZ=1 IStep= 2. 6 Re-enter D2Numr: IAtom= 3 IXYZ=2 IStep= 1. 7 Re-enter D2Numr: IAtom= 3 IXYZ=2 IStep= 2. 8 Re-enter D2Numr: IAtom= 3 IXYZ=3 IStep= 1. 9 Re-enter D2Numr: IAtom= 3 IXYZ=3 IStep= 2. In the case of triatomic molecule XMY(Cs symmetry) is calculated, the required number of steps is 16, 1 The SCF and gradient calculation at the equilibrium point. 2 Re-enter D2Numr: IAtom= 1 IXYZ=1 IStep= 1. 3 Re-enter D2Numr: IAtom= 1 IXYZ=1 IStep= 2. 4 Re-enter D2Numr: IAtom= 1 IXYZ=2 IStep= 1. 5 Re-enter D2Numr: IAtom= 1 IXYZ=2 IStep= 2. 6 Re-enter D2Numr: IAtom= 1 IXYZ=3 IStep= 1. 7 Re-enter D2Numr: IAtom= 2 IXYZ=1 IStep= 1. 8 Re-enter D2Numr: IAtom= 2 IXYZ=1 IStep= 2. 9 Re-enter D2Numr: IAtom= 2 IXYZ=2 IStep= 1. 10 Re-enter D2Numr: IAtom= 2 IXYZ=2 IStep= 2. 11 Re-enter D2Numr: IAtom= 2 IXYZ=3 IStep= 1. 12 Re-enter D2Numr: IAtom= 3 IXYZ=1 IStep= 1. 13 Re-enter D2Numr: IAtom= 3 IXYZ=1 IStep= 2. 14 Re-enter D2Numr: IAtom= 3 IXYZ=2 IStep= 1. 15 Re-enter D2Numr: IAtom= 3 IXYZ=2 IStep= 2. 16 Re-enter D2Numr: IAtom= 3 IXYZ=3 IStep= 1. 3.) 6N, decreased by symmetry, 5 steps for atoms on the symmetry plane, 6 others From carola@tc.uni-bielefeld.de Fri Jul 11 14:09:45 1997 From: Carola Begemann Hallo Elmar In C1 Symmetrie( d.h. ohne Symmetrie) fuer jedes Atom im Molekuel 6 Schritte (zwei je Koordinate:x, y, z). (2. Ableitung der Energie nach der Auslenkung) Mit Symmetrie entsprechend weniger. Cs hat eine Spiegelebene, also halb so viel, wenn kein Atom auf der Spiegelebene liegt, fuer jedes Atom in der Spiegelebene nur 5 statt 6 Schritte. ---------------------------------------------- Carola Begemann email: carola@tc1.chemie.uni-bielefeld.de adress: Leuchte 21a, 32657 Lemgo, Germany ---------------------------------------------- 4.) 7N From mbdtsnm@hpf.ch.man.ac.uk Fri Jul 11 14:53:44 1997 From: "Nathaniel (noj) Malcolm" ... [a very rough rule of thumb would say that (given analytical gradients - and no symmetry) for each atom you will need about 7 gradient calculations - finite differences in 3D] ------ end of this summary ----- If you have further comments, please post them to me or the CCC mailing list. Thanks Bye Elmar ================================================= Elmar Gerwalin , University of Kaiserslautern, Germany Dept. of Theoretical Chemistry (coming soon: http://iris2.chemie.uni-kl.de ) Please send mail to: gerwalin@chemie.uni-kl.de =================================================== From chipot@host7.lctn.u-nancy.fr Sun Jul 13 14:06:53 1997 Received: from host7.lctn.u-nancy.fr for chipot@host7.lctn.u-nancy.fr by www.ccl.net (8.8.3/950822.1) id NAA16898; Sun, 13 Jul 1997 13:21:04 -0400 (EDT) From: Received: (from chipot@localhost) by host7.lctn.u-nancy.fr (AIX4.2/UCB 8.7/8.7) id TAA21614 for chemistry@www.ccl.net; Sun, 13 Jul 1997 19:17:06 +0200 (DFT) Message-Id: <199707131717.TAA21614@host7.lctn.u-nancy.fr> Subject: Chambery Meeting - April 1998 To: chemistry@www.ccl.net Date: Sun, 13 Jul 1997 19:17:05 +0200 (DFT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Division de Chimie Physique Societe Francaise de Chimie CHAMBERY, 20 to 24 April 1998 COMPUTATIONAL CHEMISTRY AND THE LIVING WORLD: FROM SEQUENCE TO FUNCTION A European meeting of the Division de Chimie Physique Chambery, French Alps, 20 to 24 April 1998 organized jointly with: BUNSEN-GESELLSCHAFT fuer Physicalische-Chemie DIVISIONE DI CHIMICA FISICA (SCI) FARADAY DIVISION (RSC) SOCIETE FRANCAISE DE BIOPHYSIQUE FIRST CIRCULAR _______________________________________________________________________ COMPUTATIONAL CHEMISTRY AND THE LIVING WORLD: FROM SEQUENCE TO FUNCTION The results of the genome projects are expected to lead to a scientific revolution in the beginning of the next century. The exploitation of the genetic information will require an understanding of the relation- ships between sequence, structure and function. Both theory and expe- riment are expected to play major roles in obtaining this understanding The meeting at Chambery will focus on the role of computational chemis- try in the activity sparked by the genome results. How can numerical calculation help us to understand and exploit genome sequences ? How can modelling and simulation help in understanding how amino-acid se- quences are translated into three-dimensional biological structures, the functional interactions of these structures and the effect of en- gineered modifications ? Practical and pharmaceutical applications will also be adressed. A famous example of `rational' structure based drug design is the very recent development of HIV protease inhibitors for the treatment of AIDS. MAIN TOPICS __________________________________ The meeting will be organized into three themes: 1 - Sequence analysis: the impact of genome sequencing projects will be assessed, genome organization discussed and the access and direct exploitation of sequence data reviewed. Evolutionary analysis of sequences will be examined, together with the classification of se- quences in terms of structure. 2 - Biomolecular structure and folding: experimental techniques capable of probing macromolecular structure will be discussed in relation to theoretical/computational techniques predicting protein structu- res from sequence. Our undersatnding of the principles of protein folding will be examined: the factors determining their thermodyna- mic stability and kinetic folding pathways. Modelling of protein structure by homology and with energy functions, the `inverse fol- ding' problems and techniques for global energy optimization will be discussed. Nucleic acid sequence-structure relationships will be examined. 3 - Functional interactions of biomolecules: calculation of binding mo- des and reaction mechanisms will be explored together with methods of calculating free energy changes associated with biological pro- cesses. The modelling and simulation of ordered biomolecular sys- tems will be reviewed. Dynamic processes in biological function will be examined from picosecond events to slower domain motions and allosteric phenomena. ORGANIZATION __________________________________ The meeting will be over five days and will consist of 45 minutes and 15 minutes lectures, poster sessions and informal discussion. Research into the chemistry and biological macromolecules requires close coope- ration between theorists and experimentalists, and scientists of both fields are welcome. The aim of the meeting is to emphasize the broad complementarity between theory and experiment in the lectures rather than specialized discussion of theoretical methodology. Industrial re- searchers working on these problems will also be invited to speak. The meeting is expected to be of interest to researchers in all bran- ches of computational chemistry, as well as structural and molecular biologists and biochemists. The meeting will be held in Chambery in the Savoie region of the French Alps. The proceedings will be published. INVITED LECTURES __________________________________ The following scientists have already accepted to give invited lectures - Prof. David Chandled (University of California, Berkeley) - Dr. Cyrus Chothia (Cambridge University) - Prof. Chris Dobson (Oxford University) - Prof. Manfred Sippl (Graz) - Prof. Wilfred van Gunsteren (ETH, Zuerich) - Prof. Harel Weinstein (Mnt. Sinai, New York) - Prof. Eric Westhoff (Strasbourg) - Prof. Michael Hecht (Princeton University) - Prof. Eugene Shakhnovitch (Harvard University) - Prof. Klaus Schulten (University of Illinois) CONTRIBUTIONS __________________________________ Title + 200-350 words abstract (typed on a single page) Deadline 31 October 1997 to be submitted to: Division de Chimie Physique / SFC Computational Chemistry and the Living World Laboratoire de Chmie Physique 11, rue P. et M. Curie 75005 Paris INTERNATIONAL SCIENTIFIC COMMITTEE __________________________________ Dr. J.C. Smith (CEA Saclay) - Chairman, Dr. R. Botter (DCP Paris) - Se- cretary, Prof. J. Brickmann (TH Darmstadt), Dr. C. Chipot (U. Nancy), Prof. J.E. Dubois (U. Paris VII), Dr. J. Garnier (INRA Jouy, NIH Beth- seda), Prof. M. Karplus (U. Strasbourg, Harvard U.), Dr. R. Lavery (IBPC Paris), Prof. B. Maigret (U. Nancy), Prof. G. Richards (Oxford U.), Dr. E. Soulie (CEA Saclay), Prof. J. Tomasi (U. Pisa), Dr. C. Tro- yanowsky (DCP Paris). INFORMATION __________________________________ From R. Botter, at above address Phone: 01-44-27-62-70 Fax : 01-44-27-62-23 ............................................................... >8 .... Division de Chimie Physique Societe Francaise de Chimie COMPUTATIONAL CHEMISTRY AND THE LIVING WORLD: FROM SEQUENCE TO FUNCTION A European meeting of the Division de Chimie Physique Chambery, French Alps, 20 to 24 April 1998 jointly organized with DBG, DCF/SCI, FD/RSC, SFB PREREGISTRATION __________________________________ NAME, First name (Prof, Dr, Mrs, Ms, Miss, Mr)......................... LABORATORY or COMPANY............................................................. MAILING ADDRESS........................................................ ....................................................................... Telephone.......................... Fax................................ - Wishes to receive the second circular................................ - Submits poster contribution(s)....................................... - Wishes poster contribution to be considered for oral presentation..................................... Pre-registration form to be received by 31.8.1997 at the following address: Division de Chimie Physique / SFC Computational Chemistry and the Living World Laboratoire de Chmie Physique 11, rue P. et M. Curie 75005 Paris Phone: 01-44-27-62-70 Fax : 01-44-27-62-23 ............................................................... >8 .... From jkl@ccl.net Sun Jul 13 15:06:55 1997 Received: from bedrock.ccl.net for jkl@ccl.net by www.ccl.net (8.8.3/950822.1) id OAA17360; Sun, 13 Jul 1997 14:46:52 -0400 (EDT) Received: from krakow.ccl.net for jkl@ccl.net by bedrock.ccl.net (8.8.6/950822.1) id OAA08751; Sun, 13 Jul 1997 14:46:51 -0400 (EDT) From: Jan Labanowski Received: for jkl@ccl.net by krakow.ccl.net (8.8.3/920428.1525) id OAA01774; Sun, 13 Jul 1997 14:46:51 -0400 (EDT) Date: Sun, 13 Jul 1997 14:46:51 -0400 (EDT) Message-Id: <199707131846.OAA01774@krakow.ccl.net> To: chemistry@www.ccl.net Subject: Take a new G9x input to XYZ format perl filter Cc: jkl@ccl.net Dear... I produced a perl script which converts the Gaussian input file (Zmatrix) to XYZ format as used in XMol. Obviously there are tons of such utilities, but mine is of course better {:-)} (no kidding, it checks the syntax). Grab it from CCL archives: ftp://www.ccl.net/software/PERL/geom/g9xinp2xyz.pl Before using, check the first line and see if your perl is there. Also, do not forget to do chmod 755 g9xinp2xyz.pl before using. Bugs reports and praises {:-)} to jkl@ccl.net Jan Labanowski jkl@ccl.net -- Dr. Jan K. Labanowski, Senior Research/Supercomputer Scientist/Specialist, etc. Ohio Supercomputer Center, 1224 Kinnear Rd, Columbus, OH 43212-1163 ph:(614)-292-9279, FAX:(614)-292-7168, E-mail: jkl@ccl.net JKL@OHSTPY.BITNET From rvenable@deimos.cber.nih.gov Sun Jul 13 15:49:40 1997 Received: from deimos.cber.nih.gov for rvenable@deimos.cber.nih.gov by www.ccl.net (8.8.3/950822.1) id OAA17030; Sun, 13 Jul 1997 14:07:05 -0400 (EDT) Received: from localhost by deimos.cber.nih.gov with SMTP (1.37.109.14/16.2) id AA128446479; Sun, 13 Jul 1997 13:54:39 -0400 Date: Sun, 13 Jul 1997 13:54:39 -0400 (EDT) From: Rick Venable To: chemistry@www.ccl.net Cc: Mike Frisch Subject: Re: CCL:Re: CCL:G:G:Gaussian on a Mac ? ---Or Other Platforms In-Reply-To: <199707111408.KAA11011@holly> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 11 Jul 1997, Mike Frisch wrote: > We at Gaussian, Inc. agree with this, but in practice it requires a reliable > operating system, and this is definately not the case for Linux/Alpha, and > is questionable for Linux/PPC. I can independently confirm that state of affairs; while Linux on Intel is a viable marketplace with a good Fortran compiler from AbSoft, both LinuxAXP (Alpha chip) and MkLinux (PPC chip) have serious efficiency problems, as well as being a bit buggy. LinuxAXP is a bit further along, with companies like MicroWay helping the effort, while Apple seems to be backing away from MkLinux. As a consequence, there's renewed effort for LinuxPPC (uses standard Linux kernel vs. Mach kernel for MkLinux). The real problem is g77, at least for compute intensive scientific applications; compared to the same code compiled under the vendor's OS, Linux g77 apps seem to be 3-5 times slower under LinuxAXP, and 8-10 times slower under MkLinux. Because of the large Intel base and the relatively low usage of LinuxAXP (vs. DEC Unix or MS WinNT) and MkLinux/LinuxPPC (vs. MacOS), it's not clear there will be a good commercial Fortran compiler anytime soon for either LinuxAXP or the PPC versions. An alternative would be an overhaul of the PPC and/or Alpha specific portions of g77 by a gifted volunteer with a knowledge of compiler design and RISC floating point architectures. [ Note: this not a criticism of g77 in general, and I think Mr. Burley has done an admirable job in providing it. While it is amazing that g77 works on so many different machines, it isn't surprising that the resulting code doesn't always provide comparable performance. ] Based on my own experiences with MkLinux and detailed perusal of both LinuxAXP and MkLinux FAQ lists and mailing list archives, I certainly would not criticize any software vendor who takes a "wait and see" attitude towards these variants of Linux. It is especially true if a good Fortran compiler is a requirement. -- Rick Venable =====\ |=| "Eschew Obfuscation" FDA/CBER Biophysics Lab |____/ |=| Bethesda, MD U.S.A. | \ / |=| ( Not an official statement or rvenable@deimos.cber.nih.gov | \ / |=| position of the FDA; for that, http://nmr1.cber.nih.gov/ \/ |=| see http://www.fda.gov ) From chpajt@bath.ac.uk Sun Jul 13 17:06:57 1997 Received: from goggins.bath.ac.uk for chpajt@bath.ac.uk by www.ccl.net (8.8.3/950822.1) id QAA18339; Sun, 13 Jul 1997 16:50:48 -0400 (EDT) Received: from bath.ac.uk (actually host ss1.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Sun, 13 Jul 1997 21:50:42 +0100 Date: Sun, 13 Jul 1997 21:50:34 +0100 (BST) From: A J Turner To: "nick.c" cc: chemistry@www.ccl.net Subject: Re: CCL:Object-oriented means for computational chemistry programming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! There seems to be one points that no-one has covered, especially when we say FORTRAN has run its coarse. If I am to spend a long time writing a piece of code to perform a very complex task - I need to be 100% sure that the code will be in a lagnuage that can be used in the future. There is only one language that can really offer that - FORTRAN. How long will it take for this FORTRAN is become too old to be of use. I am using routines that were first written in the sixties - enough said. The problem is that these other codes are not enough better to take the risk. As for commiting large ammounts of time to TCL, Python and the like. WIll they be around in ten years? FORTRAN will. Bets wishes Alex ------------------------------------------------------------------- |Alexander J Turner |A.J.Turner@bath.ac.uk | |Post Graduate |http://www.bath.ac.uk/~chpajt/home.html| |School of Chemistry |+144 1225 8262826 ext 5137 | |University of Bath | | |Bath, Avon, U.K. |Field: QM/MM modeling | -------------------------------------------------------------------