From scsupham@reading.ac.uk Wed Jan 13 06:04:46 1993 From: scsupham@reading.ac.uk Date: Wed, 13 Jan 93 10:37:32 GMT Message-Id: <26522.9301131037@scsscsc3> To: chemistry@ccl.net Subject: Cartesian vs Internal coordinates ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 15 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 ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: .signature X-Sun-Content-Lines: 3 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 From harbowy@chemres.tn.cornell.edu Wed Jan 13 05:34:52 1993 Message-Id: <199301131536.AA01687@oscsunb.ccl.net> From: m.e. Subject: gradient norm question To: CHEMISTRY@ccl.net (computational chemists) Date: Wed, 13 Jan 93 10:34:52 EST Organization: Cornell Chem Grad Student I have a question concerning the gradient norm in MOPAC: when I minimize a transition state structure using SIGMA and XYZ in one calculation, I can minimize the gradient to about 10. When I take that optimized geometry and plug it into a FORCE calculation, with XYZ as a keyword, it reports the GNORM as 35. Does anyone have any idea why this could be? -- 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 jkl@ccl.net Wed Jan 13 06:12:31 1993 From: Jan Labanowski Date: Wed, 13 Jan 1993 11:12:31 -0500 Message-Id: <199301131612.AA00365@krakow.ccl.net> To: chemistry@ccl.net Subject: Sorry for doubled messages Dear Subscribers, Some of you (especially towards the end of the alphabet) receive double messages from the list. The problem is that our Electric Company (they are selling electric current and UPSes - Uninterruptable Power Supplies). For some time, when we complain about the power blinking (they just switch the power off for 0.1 second, usually once in two days or something), they give us an advice: "Buy yourself a UPS". The problem is, it is not cheap. When they went into a business of selling UPSes, (before, they were selling only electric power) the quality of power they supply is terrible. Of course, these things are unrelated... How could they be... It would be a crime... And you actually do not have to commit a crime, you need only a smart personel policy and budgetary planning to make it legal. The Electric Company is a monopoly. This is called a free market economy. We will probably buy the damned UPS, but for the time being, please have patience. When the machine boots, it resets mail-queue to the beginning (at power outage, the info on which message from the queue was already sent, is lost). To say something useful. Many people ask: Question: Can I read a file from the anonymous ftp before getting it? Answer: If you are on the UNIX system and want to read the file: file_name before you decide to get it, you can try: ftp> get file_name |more Note space between file_name and | no space betwee | and more Of course, the file should be ASCII and you should be in ASCII mode. Jan Labanowski Ohio Supercomputer Center jkl@ccl.net From rsefeck@watson.ibm.com Wed Jan 13 08:38:09 1993 Message-Id: <199301131906.AA05508@oscsunb.ccl.net> Date: Wed, 13 Jan 93 13:38:09 EST From: rsefeck@watson.ibm.com To: chemistry@ccl.net Subject: data-flow programs for molecular modeling I would like to add some comments on the issue of data-flow programs and importing data from various modeling and Ab-initio programs. One of the advantages I found of the IBM Data Explorer Program is the way in which data is handled ie... Data Explorer has a true data model, the data is self describing and as a result importing data into DX is relatively painless. Regualar grided data like electron densities, Potential fields results of MO calculations etc. are easily handled with the addition of a few lines of header information. Molecular geometries require a list of X,Y,Z's and a connection table which is a bit more work but over all I have not found a need to have specific filters for importing various chemistry data types. What's nice with a true data model is that multiple data types and be imported together to do some correlative analysis . From rsefeck@watson.ibm.com Wed Jan 13 08:38:09 1993 Message-Id: <199301131906.AA05508@oscsunb.ccl.net> Date: Wed, 13 Jan 93 13:38:09 EST From: rsefeck@watson.ibm.com To: chemistry@ccl.net Subject: data-flow programs for molecular modeling I would like to add some comments on the issue of data-flow programs and importing data from various modeling and Ab-initio programs. One of the advantages I found of the IBM Data Explorer Program is the way in which data is handled ie... Data Explorer has a true data model, the data is self describing and as a result importing data into DX is relatively painless. Regualar grided data like electron densities, Potential fields results of MO calculations etc. are easily handled with the addition of a few lines of header information. Molecular geometries require a list of X,Y,Z's and a connection table which is a bit more work but over all I have not found a need to have specific filters for importing various chemistry data types. What's nice with a true data model is that multiple data types and be imported together to do some correlative analysis . From rsefeck@watson.ibm.com Wed Jan 13 08:38:09 1993 Message-Id: <199301131906.AA05508@oscsunb.ccl.net> Date: Wed, 13 Jan 93 13:38:09 EST From: rsefeck@watson.ibm.com To: chemistry@ccl.net Subject: data-flow programs for molecular modeling I would like to add some comments on the issue of data-flow programs and importing data from various modeling and Ab-initio programs. One of the advantages I found of the IBM Data Explorer Program is the way in which data is handled ie... Data Explorer has a true data model, the data is self describing and as a result importing data into DX is relatively painless. Regualar grided data like electron densities, Potential fields results of MO calculations etc. are easily handled with the addition of a few lines of header information. Molecular geometries require a list of X,Y,Z's and a connection table which is a bit more work but over all I have not found a need to have specific filters for importing various chemistry data types. What's nice with a true data model is that multiple data types and be imported together to do some correlative analysis . From J_BROWN@uvmvax.uvm.edu Wed Jan 13 11:37:00 1993 Date: Wed, 13 Jan 1993 16:37 EST From: J_BROWN@uvmvax.uvm.edu Subject: Sending thanks to all who helped with MM2 (87) dihedral angle drivers To: chemistry@ccl.net Message-Id: <01GTH6D842U800077D@uvmvax.uvm.edu> Thanks to all that responded to my question about MM2 (87) dihedral angle driver problems. I can not provide a compiled list of all responses because during a VMS/VAX operating system and CPU upgrade over the x-mas break I seem to have lost my VAX e-mail mail.mai folder. However, I always make paper copies as a backup (old habits sometimes pay off). I can FAX the responses (with literature references) to anyone who would like them. Please provide a FAX number and address in any request. -Jay Brown From m10!frisch@uunet.UU.NET Wed Jan 13 11:52:12 1993 Message-Id: <9301132205.AA14390@relay1.UU.NET> Date: Wed, 13 Jan 93 16:52:12 EST From: m10!frisch@uunet.UU.NET (Michael Frisch) Subject: Re: Cartesian vs Internal coordinates To: chemistry@ccl.net 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 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. In a practical calculation, there are two major sources of differing answers: 1. Unless you do analytic second derivatives at every point in your optimization (e.g., OPT=CALCALL in Gaussian) then the optimization algorithm will start with a guess for the Hessian and update it based on the forces at each point during the optimization. Whether the initial guess for the Hessian is different for different coordinate systems but the same initial structure is program-dependant. (It differed in Gaussian 88 and earlier, but not in Gaussian 90 and 92. I can't comment on other packages.) Even if the starting Hessians are effectively the same for the two coordinate systems (e.g. are produced from cartesian force constants determined from the initial structure and converted to each of the two coordinate systems) the Hessians will be different later in the optimization, after being updated using any of the popular update methods. 2. The optimization is stopped when some convergence criteria are reached. These typically require that both the forces and estimated next step size are sufficiently small. Since the next step depends on the current approximate Hessian, a point might be considered close enough with the approximate Hessian produced by one set of coordinates and update method and not with either different coordinates or update method. (This again is not a problem if analytic second derivatives are used at every point). Also, if the test on whether the forces are small enough involves quantities such as the maximum and/or RMS values, these depend on the coordinate system, and so one point might have small enough forces to be considered optimized in one coordinate system but not another. (The resulting structures from the two optimization should be pretty close if the convergence criteria are reasonable, but coordinates might differ by a couple of times the convergence criterion if the two approximate minima located are on opposite sides of the exact minimum. Gaussian has an option Opt=Tight to make sure things are adequately converged for very flat surfaces, on which this problem is more likely to occur.) 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 ------- From AHOLDER@VAX1.UMKC.EDU Wed Jan 13 15:25:40 1993 Date: 13 Jan 1993 21:25:40 -0600 (CST) From: Andy Holder Subject: gnorms To: CHEMISTRY@ccl.net Message-Id: <01GTHFL825HUA8CMW4@VAX1.UMKC.EDU> Dear All, In an AMPAC/MOPAC calculation the gnorm is a "quality of fit" rating. It is a normalized rating of the individual gradient components for each of the optimizable geometric parameters. If this number is large (10 is HUGE!) you are not at a critical point on the potential energy surface and, mathematically, the results you compute are meaningless. Results from a calculation like this are valid only at critical points. (Note that any constraint on the geometry such as not optim- izing a particular parameter or turning on symmetry also invalidate location of a stationary point, as not all degrees of freedom are allowed to vary.) Now for some rules of thumb/tips/painfil lessons: 1. The GRAD keyword should be used in all geometry optimizations so that you get a report of components and the final gnorm. the final gnorm is found in the summary section of the .OUT file with the heat of formation. 2. The gnorm should generally be reduced below 1.0 for a "good" geometry. This may vary in very large systems where the sheer number of contributors make it impossible to reduce it this far. In that case, check each component to make sure there are no "sore thumbs." 3. Further refinement of the gnorm is recommended when a frequen- cy analysis is to be performed (either via FORCE or LTRD). In fact, the program should not allow one to proceed with a freq- uency analysis if the gnorm is found to be too large. (The actual cutoff will vary depending on whether you are using MOPAC, AMPAC 2.1, or AMPAC 4.0). This is because the results of a frequency analysis are NOT VALID at anywhere except a crit- ical point! This can be circumvented by using the evil and dec- eptive keyword LET. Do this at your own risk! If the paper comes to me for review and you used LET, you are dead! 4. Ways to reduce the gnorm: a. Use the keyword PRECISE. (The actual function of this keyword also varies according to your brand of semi- empirical code. Check the manual.) b. Specify GNORM=x.xx and give it a really low value. The optimization may not make it all the way due to other termination criteria, but this will generally improve matters. c. Use a gradient minimizer rather than an energy minimizer (almost always required to find TS). In various programs these include POWELL, NEWTON, LTRD and so forth. 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. Enough for now. If anyone has any specific questions, I'll be happy to help. Hope that this was useful... Andy =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= DR. ANDREW HOLDER Assistant Professor of Computational/Organic Chemistry Department of Chemistry || BITNET Addr: AHOLDER@UMKCVAX1 University of Missouri - Kansas City || Internet Addr: aholder@vax1.umkc.edu Spencer Chemistry, Room 315 || Phone Number: (816) 235-2293 Kansas City, Missouri 64110 || FAX Number: (816) 235-1717 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=