From harbowy@chemres.tn.cornell.edu Wed Jan 13 22:06:25 1993 Message-Id: <199301140808.AA09409@oscsunb.ccl.net> From: m.e. Subject: RE: gnorms To: CHEMISTRY@ccl.net (computational chemists) Date: Thu, 14 Jan 93 3:06:25 EST Organization: Cornell Chem Grad Student > 5. Some versions of MOPAC and AMPAC 2.1 are broken in certain places > when it comes to analytical gradient computation (CI to name just > one.) If you get wacko gradients, use the keywords DEBUG and > DERINU to get numerical derivatives. Warning: This takes many > times longer than speedy and efficient analytical gradients. How can I get MOPAC to do numerical derivatives? The keyword DERINU is not listed in the MOPAC6 manual. I'm interested in optimizing CI calcs. -- matt ----------------------------------------------------------------------------- |/ _ /\ Matthew Harbowy (ikf@lithium.tn.cornell.edu) |\ - /__\ "I'm the bear that went over the mountain" ----------------------------------------------------------------------------- What kind of rule Can overthrow a fool and leave the land with no stain? -Suzanne Vega From landman@hal.physics.wayne.edu Thu Jan 14 04:55:08 1993 Date: Thu, 14 Jan 93 09:55:08 EST From: landman@hal.physics.wayne.edu (Joe Landman) Message-Id: <9301141455.AA08216@hal.physics.wayne.edu> To: chemistry@ccl.net Subject: PCModel Fellow CCL readers: I have recently learned very little about a program called PC Model (or some permutation thereof) that will do a nice job of ball and stick visualization on data from MD runs. I am interested in giving this a shot, but archie cannot find it. I have written my own rudimentary ball and stick display program to toss up MD movies of my runs, but I do not want to reinvent this particular wheel unless absolutely necessary (its a big expenditure of time that I do not have). Barring PC Model, I could be satisfied with some sort of visualization tool (I have XMol, and I like it, but it will turn itself off in a few months...;-<) that will run either on an xterm or a PC (a 386/486 under dos, windows, or OS/2) Any suggestions ? (Input file format is not a problem for me,I have written a program to take my data and convert it to xyz format, and I can form any other sort of data file necessary) Thanks in advance! Joe Landman landman@hal.physics.wayne.edu From HERMAN@ULNA.BWH.HARVARD.EDU Thu Jan 14 05:44:56 1993 Date: Thu, 14 Jan 1993 10:44:56 -0500 (EST) From: HERMAN@ULNA.BWH.HARVARD.EDU Message-Id: <930114104456.1a95@ULNA.BWH.HARVARD.EDU> Subject: GAMESS and MOPAC To: chemistry@ccl.net Brian - The forces generated by MOPAC and GAMESS are vibrational force constants, not molecular mechanics parameters. What you want to do is a daunting task, which for everyone but a few software houses is done BY HAND, ie. you tune the parameters until the experimental results for some test system are reproduced by the MM method. Lee Herman From HERMAN@ULNA.BWH.HARVARD.EDU Thu Jan 14 05:42:35 1993 Date: Thu, 14 Jan 1993 10:42:35 -0500 (EST) From: HERMAN@ULNA.BWH.HARVARD.EDU Message-Id: <930114104235.1a95@ULNA.BWH.HARVARD.EDU> Subject: RE:HELP To: chemistry@ccl.net Ken - It sounds like a no-win situation. On the one hand, this division head does not seem to hold academic standards, and the written rules and policies of the department, in high regard. Nor does he seem to mind bulldozing his faculty members. On the other hand, if this fellow is the effective head of the department, you have to get along with him. Perhaps the best thing is to calmly express to him how this transaction undermined morale, and let this one go. Maybe it's better that this student is gone. As a last resort, I suppose, you could get together with fellow faculty members and go over the director's head. This would be risky, since the director could then favor the other five, more passive departments. Lee Herman Brigham and Women's Hospital / Harvard Medical From jle@world.std.com Thu Jan 14 06:18:26 1993 Date: Thu, 14 Jan 1993 11:18:26 -0500 From: jle@world.std.com (Joe M Leonard) Message-Id: <199301141618.AA14822@world.std.com> To: chemistry@ccl.net Subject: Why AVS has a Chemistry Datatype o wanted to post at least part of the rational for the AVS Chemistry Datatype, and why such datatypes are important. Granted, if one is willing to create customized datatypes for individual applications, they will be more suitable that the Molecule Datatype (MDT). If, however, one is interested in sharing modules among folks who aren't specifically working together, it is easier to utilize a standard, yet expandable datatype as a means of insuring that the modules developed in various places work together. It was pointed out that Chemical data can take several forms, ranging from a multi-dimensional grid to a tree/graph structure. While I am familiar with AVS, I am certain that all three packages (DX, SGI's Explorer and AVS) have many easy ways to import gridded data. There are also module generators, interface generators and the like that make visualization environments the best development environment I've seen to create new applications (which is a reason MSI adopted AVS for it's ChemistryViewer). Also, since the viz tools are source code compatible across all supported platforms, the cost of porting/maintenance is greatly reduced, since the coder(s) don't have to be concerned with data passing mechanisms, scheduling, graphics environment, etc. Having application-specific, standardized datatypes (such as MDT) allows data that is unique to a scientific and/or engineering discipline to flow among modules in a natural way. While I don't have any direct involvement with AVS or AVS-based projects (we use it for some prototyping here at Wavefunction), I was at Stardent when it was developed. Mark Benzel at MSI had tremendous contributions to the design of the MDT, and input was solicited from chemists is other disciplines. The MDT was a successful compromise, what it lacks explicit support for can be easily added as user-defined extensions (which then must be passed among developers to make modules interoperable). For a first attempt, I feel we hit about 80% on the nose, and there are easy additions which can be made if the marketplace needs/wants them. Hey, I tried to sell viz tools to chemists, and was repeatedly told that they lacked any chemistry (and didn't have anything that chemists could use, anyway). Sadly, only 10-20% are going to actually write code, so until there's a large number of application modules, viz systems are going to have limited acceptance. Having simple, standard intercommunication methods helps guarantee that modules created by different folks (and unaware of other's efforts) will work together. Finally, it is the proliferation of Chemical information formats that will force the need for 20-50 data input modules. Until us Chemists agree on a smaller number, or folks are willing to write a bunch of data description language, all that can be done is to write/clone input modules and make them available in a collection somewhere. These can also be suitable modified to create modules that output data in various formats as well. Joe Leonard jle@world.std.com P.S. Before I forget, there was a third guy who actually did the work to implement the MDT - Ed Bagdonas, also formerly of Stardent. He's still working closely with AVS, and has been since, well, our enforced vacation 15 months ago :-). From friedman@tammy.harvard.edu Thu Jan 14 08:05:52 1993 Date: Thu, 14 Jan 93 13:05:52 -0500 From: friedman@tammy.harvard.edu (Dawn Friedman) Message-Id: <9301141805.AA13614@tammy.harvard.edu> To: chemistry@ccl.net Subject: convergence failure I'm using G88 to do UHF calculations with a large basis set on some alkali oxides. I'm feeling out a reaction path using single-point calculations (optimizations to come later.) Some of these single points give me a convergence failure in SCF, although an energy is reported first. 1) Does this energy have any meaning? 2) Why should one geometry converge, while another, differing only by the C_inf_v symmetry being broken (180 -> 179.9 degrees) does not? The energies are identical. Sometimes the nonlinear version will converge where the linear did not. 3) Can I work around this problem and still have useful results? Is there some method a bit less sweeping than the SLEAZY keyword for getting SCF convergence? Unfortunately, I can't afford to do SCF=qc -- they take too long and often don't converge anyway. --Dawn From MEZEI@msvax.mssm.edu Thu Jan 14 08:28:58 1993 Date: 14 Jan 1993 13:28:58 -0500 (EST) From: MEZEI@msvax.mssm.edu Subject: High order multipole interactions To: chemistry@ccl.net Message-Id: <01GTIE1X2YVQ000GSM@msvax.mssm.edu> QCPE recently accepted my program package MAXWELL as QCPE 637. The programs calculate electrostatic interactions of either a finite set or of a crystal of polarizable molecules. The molecular charge distributions are characterized by a multipolar expansion in the form of general directional derivatives, based on the formalism of Maxwell. The package can also obtain multipole moments of arbitray order from a one-determinental Gaussian wave function. For crystals the permanent multipole contribution is calculated with E.S. Campbell's generalization of the Ewald method to lattices of multipoles of arbitrary order. Calculation of energy contributions in the form of inverse distance power terms is also provided for. Mihaly Mezei Department of Physiology and Biophysics, Mount Sinai School of Medicine, CUNY (212) 241-2186 MEZEI@MSRCVAX.BITNET MEZEI@MSVAX.MSSM.EDU MEMMS@CUNYVM.CUNY.EDU From theresa@si.fi.ameslab.gov Thu Jan 14 07:03:47 1993 From: theresa@si.fi.ameslab.gov (Theresa Windus) Message-Id: <9301141903.AA41282@si.fi.ameslab.gov> Subject: GAMESS force constants To: chemistry@ccl.net () Date: Thu, 14 Jan 93 13:03:47 CST Brian, There is an option in GAMESS that will perform a vibrational decomposition given a set of internal coordinates. This is most useful when looking at the internals that make up a normal mode, however it does give the force constants for the stretchs. Set the keyword DECOMP=.true. in the $FORCE group. You should do a normal hessian run, read in the $HESS group that is punched out in the .dat file, and then do the decomposition. Using this option you can define more that 3N-6 internals. This can be useful when a set of redundant coordinates is needed (ex. fused ring systems). Hope this helps! Theresa Windus Department of Chemistry Iowa State University Ames, IA 50011 e-mail: theresa@si.fi.ameslab.gov From friedman@tammy.harvard.edu Thu Jan 14 10:36:58 1993 Date: Thu, 14 Jan 93 15:36:58 -0500 From: friedman@tammy.harvard.edu (Dawn Friedman) Message-Id: <9301142036.AA26717@tammy.harvard.edu> To: chemistry@ccl.net Subject: Hyperchem coordinates Posting for a friend: Is it possible to directly modify the coordinates of, say, a medium-sized aromatic system in Hyperchem? The PDB files are accessible, but the only obvious way to input the geometry of an organic system is to draw it. I'm new to the program -- I hope I've missed something. Thank you, Dawn From jas@medinah.atc.ucarb.com Thu Jan 14 11:20:28 1993 Message-Id: <7001030643.AA14886@medinah.atc.ucarb.com> Date: Thu, 14 Jan 1993 16:20:28 -0500 To: chemistry@ccl.net From: jas@medinah.atc.ucarb.com (Jack Smith) Subject: Quantifying steric effects of a binding site I'm looking for ideas on how to quantify the steric effects associated with the coordination of a reactant to transition metal complex (catalyst) containing bulky ligands. Often a quantity called a cone angle is used to quantify the steric extent of the ligands, but I'm sure one can better quantify this. You drug desing folks must have some more sophisticated ways to quantify the steric contribution to substrate binding (docking)? Some sort of excluded volume overlap? Or a "substrate" accessible surface area? How does one currently measure the "goodness" of a binding (docking) site in drug design? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JACK A. SMITH ...................................................................... Union Carbide Corp. || Phone: (304) 747-5797 Catalyst Skill Center || FAX: (304) 747-5571 P.O. Box 8361 || S. Charleston, WV 25303 || Internet: jas@medinah.atc.ucarb.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From shepard@dirac.tcg.anl.gov Thu Jan 14 09:25:59 1993 Date: Thu, 14 Jan 93 15:25:59 CST From: shepard@dirac.tcg.anl.gov (Ron Shepard) Message-Id: <9301142125.AA02330@dirac.tcg.anl.gov> To: chemistry@ccl.net Subject: Re: Cartesian vs Internal coordinates John Upham writes: >>Dear All, >> I have always assumed that given the same starting geometry any >>program that has a choice as to how one enters it should (in the end) >>produce the same optimised final geometry. Is this true or false ? >>Without wishing to embarasses anyone I have at least one program >>genearally available where different final geometries are obtained. >> >>Any comments (apart form use internal coordinates) ? >> >>john upham >> >>John Upham, Dept. of Chemistry, University of Reading, Berks., RG6 2AD, UK. >>Email: scsupham%susssys1.rdg.ac.uk@uk.ac (BITnet), scsupham@rdg.susssys1 (Janet) >>Voice: +44 734 875123 x7441 (day), Fax: +44 734 311610 Mike Frisch replies: >If all calculations were done to infinite precision and all geometry >optimizations were continued until the forces were exactly zero, and all >optimizations used analytic first AND SECOND derivatives then optimizations >starting from the same structure but using different coordinate systems >would go to exactly the same place. [text deleted] >In fact, because of the differences in the Hessians, two optimizations with >different coordinates started at the same point far from any minimum might >fall down into different wells and to different minima. (This will not >be the case if the two optimizations use analytic rather than approximated >second derivatives at every point -- then every step should be the same >regardless of coordinate system.) > >All of these considerations apply to comparing cartesian with internal >coordinates and also to comparing two different sets of internal coordinates. > >Mike Frisch I agree with Mike Frisch's comments regarding multiple minima. Specifically, different optimization algorithms can lead to different minima on a surface. This includes different hessian update procedures in quasi-Newton approaches, different approximations to derivatives (analytic vs. forward difference vs. central difference vs. ...etc). However, I believe that this also applies to different definitions of a coordinate system, even for analytic (i.e. exact) derivatives. Consider minimixation of the 1-dimensional function f(x)=half*x**2. Newton-Raphson with analytic derivatives gives the update procedure Delta_x = -x0 where x0 is the initial guess. This gives xnew = x0 + Delta_x = 0 So that the minimum at x=0 is always reached in one iteration regardless of the initial guess. Now consider the "coordinate transformation" y = exp(x) This is a one-to-one onto mapping, so there are no problems with multiply-defined angles or such. Now, define an F(y) such that F(y)=f(x). That is, F(y) is the original function expressed in terms of the new coordinate, y. The answser using the above transformation is F(y) = half * (ln(y))**2 The original function was minimized at x=0, whereas the new function is minized at y=1. That is, f(0)=F(1)=0. Again using analytic derivatives, the NR method in this new coordinate system results in the update procedure Delta_y = ln(y) / ( ln(y) - 1 ) = -x0 / ( 1 - x0 ) The last line gives the y update in terms of the original x coordinate for comparison. Clearly, this does not converge in 1 iteration, although it does converge quadratically in the neighborhood of the minimum as all good NR methods do. Note however that in the neighborhood of x=1 (or y=e) there will be problems because of the denominator in the NR update expression in the "y" coordinate system. Specifically, the NR method diverges near x=1 using the procedure in the y "coordinate", whereas it is globally convergent, and converges in 1 iteration, when everything is done in the "x" coordinate system. If all of this is true for a simple 1-dimensional function, it is also true for more complicated (3N-6)-dimensional energy surfaces. In summary, convergence rates and convergence behavior depend on the coordinate system. -Ron Shepard shepard@tcg.anl.gov From shepard@dirac.tcg.anl.gov Thu Jan 14 11:30:04 1993 Date: Thu, 14 Jan 93 17:30:04 CST From: shepard@dirac.tcg.anl.gov (Ron Shepard) Message-Id: <9301142330.AA02383@dirac.tcg.anl.gov> To: chemistry@ccl.net Subject: Re: Cartesian vs Internal coordinates In the previous posting I wrote :-( >Again using analytic derivatives, the NR method in this new coordinate >system results in the update procedure > > Delta_y = ln(y) / ( ln(y) - 1 ) > = -x0 / ( 1 - x0 ) On closer inspection, I find that this should have been :-) Delta_y = y*ln(y) / ( ln(y) - 1) = -x0*exp(x0) / ( 1 - x0 ) -Ron Shepard shepard@tcg.anl.gov