From chemistry-request@ccl.net Fri Apr 17 09:51:34 1992 Date: Fri, 17 Apr 92 11:42+0000 From: Ales.Zupan%IJS.YU@OHSTVMA.ACS.OHIO-STATE.EDU Subject: Fortran 90 literature To: CHEMISTRY@ccl.net Status: R Dear Netters, I would like to get a thorough look into Fortran 90. What are in your opinion the best books/manuals/..... in this field? I'll be happy to summarize the responses and send them back to the net! Ales Zupan Jozef Stefan Institute Physical Chemistry Dept. Jamova 39 Ljubljana -- SLOVENIA Ales.Zupan@ijs.ac.mail.yu From chemistry-request@ccl.net Fri Apr 17 17:20:53 1992 Date: Fri, 17 Apr 1992 16:04 EST From: IRIKURA@ENH.NIST.GOV Subject: Gaussian experiences on IBM RS/6000? To: chemistry@ccl.net Status: R We have an IBM RS/6000-320 workstation and are considering purchasing Gaussian for it. Does anyone have any experience using Gaussian on this type of workstation or on competing platforms? In particular, how much memory and hard disk storage would you suggest? Comparisons with big machines such as as Crays would also be helpful. Thanks, Karl Irikura irikura@enh.nist.gov From chemistry-request@ccl.net Fri Apr 17 18:01:20 1992 Date: Fri, 17 Apr 1992 15:24 CST From: Andy Holder Subject: Semiempirical errors. To: CHEMISTRY@ccl.net Status: R Hello netters. Jack Houser asked anout some error messages that were generated when running an AM1 calculation. While many of these types of errors are relics of older codes, this one sounds pretty common, so I'll address it to the net in general. Large molecules sometimes have gradient problems, and this sounds a great deal like on of those. The FIRST thing that should be done is to check the actaul values of the individual gradients and the gnorm itself. (This is done in AMPAC by using the keyword GRAD.) If one of these gradients is enormous, there is the problem. The molecule can be redefined in order that the offending parameter is removed. In the case of such a large system, I am leery of using an automatic z-matrix generation routine. (Topical question: Why use it at all if you don't use it for big guys?) Defining symmetry to a large gradient parameter only worsens the situation in that the bad parameter is even more important now than when it caused generation of the first error! There are several ways to approach one of these. I'll list but a few below in no particular order. (Others please participate as well. There needs to be more discussion of "real" chemistry (i.e. quantum (haha)) on here anyhow.) 1. Redefine the molecule to get rid of the bad geomtric variable. This is not always possible and may lead to other problems. 2. Optimize a biggy in pieces. Divide the system into easily handled chunks and only set optimization flags on those pieces. After this is accomplished, put the optimized chunks back in and let the whole thing go again. This is a bit tedious, but I've had good success with it. 3. Use dummy atoms to redefine the parameters with big gradients. 4. The wavefunction for the molecule may not be stable. It may be that the system is a biradical and you are trying to define it via RHF. Polyenes also suffer from nonconvergence along this line as well. UHF or limited (or extensive) CI may be required if this happens. [ Side note: ALWAYS use DERINU keyword within AMPAC with CI. ] 5. Check the geometry for any wacky things, like atoms too close. AMPAC will warn you about this within limits. 6. Draw the final geometry that is dumped and see what has happened to the geometry. This may give you a clue about what is causing the optimization problem. A few more ideas. Users of AMPAC (yes, Virginia there is a MOPAC as well) MUST check final geometries by computing frequencies at the level of theory used to determine the geometry. This requires either use of FORCE (force constants in Cartesian coordinates) or LTRD (AMPAC only, force constants in internal coordinates). There should be no negative force constants for a ground state, one for a transition state and so forth (see page 13 of the AMPAC 2.1 manual). Before this can be done, however, the gnorm must be reduced. You must check this at the end of your optimization. I always use the PRECISE keyword when doing any AMPAC calculation. This requires better refinement of the wave function and the gnorms. It is almost required when doing FORCE analysis. For large systems, the geometry may need to be preminimized prior to application of PRECISE. 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 502 || Phone Number: (816) 235-2293 Kansas City, Missouri 64110 || FAX Number: (816) 235-1717 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From chemistry-request@ccl.net Fri Apr 17 19:22:21 1992 Date: Fri, 17 Apr 92 17:56:25 -0400 From: mckelvey@Kodak.COM Subject: ampac/mopac geometry optimisation problems...... To: osc@Kodak.COM Status: R It is easy to fix this problem... 1. Use "EF" in mopac...we've never had a problem with this in MOPAC. 2. In FLEPO you can fix the problem by reducing the variable DEL by a factor of 10 andrestore the previous geometry. This has ALWAYS worked for us. John McKelvey Eastman Kodak From chemistry-request@ccl.net Fri Apr 17 22:29:37 1992 Date: Fri, 17 Apr 92 20:08:28 -0400 From: mckelvey@Kodak.COM Subject: Fix for AMPAC/MOPAC FLEPO routine To: osc@Kodak.COM Status: R c...This contains patches to fix the recently discussed problem c...that can occur with FLEPO optimisation in AMPAC/MOPAC c...between the "cNEW........" lines C C * C RESTART SECTION C * C cNEW.............................. 89 continue cNEW.............................. RESET=.TRUE. DO 90 I=1,NVAR C C MAKE THE FIRST STEP A WEAK FUNCTION OF THE GRADIENT C STEP=ABS(GRAD(I))*0.0002D0 STEP=MAX(0.01D0,MIN(0.04D0,STEP)) C# XD(I)=XPARAM(I)-SIGN(STEP,GRAD(I)) XD(I)=XPARAM(I)-SIGN(DEL,GRAD(I)) 90 CONTINUE C# WRITE(6,'(10F8.3)')(XD(I)-XPARAM(I),I=1,NVAR) C C THIS CALL OF COMPFG IS USED TO CALCULATE THE SECOND-ORDER MATRIX IN H C IF THE NEW POINT HAPPENS TO IMPROVE THE RESULT, THEN IT IS KEPT. C OTHERWISE IT IS SCRAPPED, BUT STILL THE SECOND-ORDER MATRIX IS O.K. C C# WRITE(6,*)' RESET HESSIAN' CALL COMPFG (XD,.TRUE.,FUNCT2,.TRUE.,GD,.TRUE.) IF(.NOT. GEOOK .AND. SQRT(DOT(GD,GD,NVAR))/GNORM.GT.10. 1 AND.GNORM.GT.20.AND.JCYC.GT.2)THEN C C THE GEOMETRY IS BADLY SPECIFIED IN THAT MINOR CHANGES IN INTERNAL C COORDINATES LEAD TO LARGE CHANGES IN CARTESIAN COORDINATES, AND THESE C LARGE CHANGES ARE BETWEEN PAIRS OF ATOMS THAT ARE CHEMICALLY BONDED C TOGETHER. WRITE(IPRT,'('' GRADIENTS OF OLD GEOMETRY, GNORM='',F13.6)') 1 GNORM WRITE(IPRT,'(6F12.6)')(GRAD(I),I=1,NVAR) GDNORM=SQRT(DOT(GD,GD,NVAR)) WRITE(IPRT,'('' GRADIENTS OF NEW GEOMETRY, GNORM='',F13.6)') 1 GDNORM WRITE(IPRT,'(6F12.6)')(GD(I),I=1,NVAR) cNEW.............................. del=del/10.0 c...You may wish to play with thresh. thresh=0.00005d0 if(del.ge.0.thresh)then go to 89 else cNEW.............................. WRITE(IPRT,'(///20X,''CALCULATION ABANDONED AT THIS POINT!'' 1)') WRITE(IPRT,'(//10X,'' SMALL CHANGES IN INTERNAL COORDINATES 1ARE '',/10X,'' CAUSING A LARGE CHANGE IN THE DISTANCE BETWEEN'', 2/ 10X,'' CHEMICALLY-BOUND ATOMS. THE GEOMETRY OPTIMIZATION'',/ 3 10X,'' PROCEDURE WOULD LIKELY PRODUCE INCORRECT RESULTS'')') CALL GEOUT(1) STOP cNEW.............................. endif cNEW..............................