From chemistry-request@ccl.net Sat Aug 8 02:30:30 1992 Date: Fri, 7 Aug 92 23:51 EDT From: Subject: SHAKE problem solved To: chemistry@ccl.net Status: RO Hi and thanks to everyone who replied to my dilemma with SHAKE and a late thanks to those who responded to my questions about cutoffs. The problem turned out to make perfect sense and it explains why MD worked perfectly in the absence of SHAKE. I was not recalculating the velocities after using SHAKE thus they just added up as if SHAKE were not in use. I have now added code to calculate a finite difference approximation to the velocities by setting v(t + 0.5 dt) to (r(t + dt) - r(t)) / dt after performing SHAKE. This works very well (big surprise :-))... This leads to another minor question: Is it OK to scale this new finite difference velocity for temperature coupling when I am using the leapfrog rather than verlet integration scheme? I would guess yes but I thought I'd ask the experts... Scott --- Administrivia: This message is automatically appended by the mail exploder. CHEMISTRY@ccl.net --- everybody; CHEMISTRY-REQUEST@ccl.net --- coordinator only OSCPOST@ccl.net : send something from chemistry; FTP: www.ccl.net --- From chemistry-request@ccl.net Sat Aug 8 18:16:46 1992 Date: Sat, 8 Aug 92 12:04:16 -0400 From: mgauss@alchemy.chem.utoronto.ca (Mike Peterson / Monstergauss) To: chemistry@ccl.net Subject: MONSTERGAUSS source code correction Status: R For those who are still using the MONSTERGAUSS program, here is a source code correction to make the program work on SGI and HP-UX systems at -O optimization: In file 'gl0702.f', reverse the order of 2 lines at about lines 223-224: incorrect version: C IF NO PURE D FUNCTIONS, RETURN. IF(IOP(8).EQ.0.OR.MAXTYP.LE.1)RETURN IF(KEY.NE.0)GO TO 100 <---- switch these R=H*DSQRT(THREE) <---- switch these C REVISE AOS, AND COMPUTE NAO, A MAP FROM OLD AO TO NEW AO NUMBERS. correct version: C IF NO PURE D FUNCTIONS, RETURN. IF(IOP(8).EQ.0.OR.MAXTYP.LE.1)RETURN R=H*DSQRT(THREE) IF(KEY.NE.0)GO TO 100 C REVISE AOS, AND COMPUTE NAO, A MAP FROM OLD AO TO NEW AO NUMBERS. This problem has existed for >10 years, and only shows up on systems whose compilers/hardware manage to retain a value in a register so it doesn't get preserved across subroutine calls (there are 2 calls to this routine in a row, so the value of 'R' would be preserved by accident on many systems, and would always be preserved on systems that don't use dynamic ("stack") allocation for local variables). None of the systems I have used have managed to flag this at compile time (due to the conditional skipping of the definition), though some do a good job of analyzing the code (e.g. Apollo DN10000). I wonder how many other errors like this exist in programs developed before FORTRAN compilers started paying attention to SAVE statements? Mike. --- Administrivia: This message is automatically appended by the mail exploder. CHEMISTRY@ccl.net --- everybody; CHEMISTRY-REQUEST@ccl.net --- coordinator only OSCPOST@ccl.net : send something from chemistry; FTP: www.ccl.net ---