From: SourceForge.net <noreply@so...>  20091022 01:39:40

Bugs item #2883616, was opened at 20091021 19:14 Message generated for change (Tracker Item Submitted) made by adefusco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File Input/Output Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Albert DeFusco (adefusco) Assigned to: Miguel (migueljmol) Summary: GAMESS hssend optimization (with fix) Initial Comment: Optimizations performed with hssend=.true. in the $statpt group will compute the Hessian and frequencies immediately after optimization has completed. Currently this output does not display properly. It is manifest in two ways: (1) the normal mode displacements are applied starting from the first model (1.1) which is the input geometry before optimization (2) the normal mode atomSets are displayed with the starting geometry not the final. I have also attached an optimization (with hssend=.true.) to help illustrate this bug. In dimer.gamess there are 18 geometry steps. This means Jmol will identify 20 models for the optimization run. The first model is the input (COORDINATES (BOHR)). The second model is NSERCH=0. This is supposed to be identical to the first. The next 18 models are the optimization steps. The final 18 models are vibration frequencies. It is these last 18 models to which the normal mode displacements should be applied, not the first 18, and the geometry should match model 18. I have included an updated GamessReader.java based on revision 11151 which fixes the two issues above. Three changes were required: (1) Always clone from the LastModel. This works even without the optimization (runtyp=hessian). [lines 180183] (2) Use getCurrentAtomSetIndex to help find our current position in atoms[] which includes all atoms from all models. [lines 137144] (3) The vector displacements will only be applied to the new cloned atomSets. [lines 197199] It is possible there is a more elegant solution to changes 2 and 3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 
From: SourceForge.net <noreply@so...>  20091022 04:35:49

Bugs item #2883616, was opened at 20091021 19:14 Message generated for change (Comment added) made by hansonr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File Input/Output Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Albert DeFusco (adefusco) Assigned to: Miguel (migueljmol) Summary: GAMESS hssend optimization (with fix) Initial Comment: Optimizations performed with hssend=.true. in the $statpt group will compute the Hessian and frequencies immediately after optimization has completed. Currently this output does not display properly. It is manifest in two ways: (1) the normal mode displacements are applied starting from the first model (1.1) which is the input geometry before optimization (2) the normal mode atomSets are displayed with the starting geometry not the final. I have also attached an optimization (with hssend=.true.) to help illustrate this bug. In dimer.gamess there are 18 geometry steps. This means Jmol will identify 20 models for the optimization run. The first model is the input (COORDINATES (BOHR)). The second model is NSERCH=0. This is supposed to be identical to the first. The next 18 models are the optimization steps. The final 18 models are vibration frequencies. It is these last 18 models to which the normal mode displacements should be applied, not the first 18, and the geometry should match model 18. I have included an updated GamessReader.java based on revision 11151 which fixes the two issues above. Three changes were required: (1) Always clone from the LastModel. This works even without the optimization (runtyp=hessian). [lines 180183] (2) Use getCurrentAtomSetIndex to help find our current position in atoms[] which includes all atoms from all models. [lines 137144] (3) The vector displacements will only be applied to the new cloned atomSets. [lines 197199] It is possible there is a more elegant solution to changes 2 and 3.  >Comment By: Bob Hanson (hansonr) Date: 20091021 23:35 Message: I added slightly modified code to Jmol 11.9.7 and 11.8.8. Thanks for that, Jonathan.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 
From: SourceForge.net <noreply@so...>  20091022 04:36:42

Bugs item #2883616, was opened at 20091021 19:14 Message generated for change (Settings changed) made by hansonr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File Input/Output Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Albert DeFusco (adefusco) >Assigned to: Bob Hanson (hansonr) Summary: GAMESS hssend optimization (with fix) Initial Comment: Optimizations performed with hssend=.true. in the $statpt group will compute the Hessian and frequencies immediately after optimization has completed. Currently this output does not display properly. It is manifest in two ways: (1) the normal mode displacements are applied starting from the first model (1.1) which is the input geometry before optimization (2) the normal mode atomSets are displayed with the starting geometry not the final. I have also attached an optimization (with hssend=.true.) to help illustrate this bug. In dimer.gamess there are 18 geometry steps. This means Jmol will identify 20 models for the optimization run. The first model is the input (COORDINATES (BOHR)). The second model is NSERCH=0. This is supposed to be identical to the first. The next 18 models are the optimization steps. The final 18 models are vibration frequencies. It is these last 18 models to which the normal mode displacements should be applied, not the first 18, and the geometry should match model 18. I have included an updated GamessReader.java based on revision 11151 which fixes the two issues above. Three changes were required: (1) Always clone from the LastModel. This works even without the optimization (runtyp=hessian). [lines 180183] (2) Use getCurrentAtomSetIndex to help find our current position in atoms[] which includes all atoms from all models. [lines 137144] (3) The vector displacements will only be applied to the new cloned atomSets. [lines 197199] It is possible there is a more elegant solution to changes 2 and 3.  Comment By: Bob Hanson (hansonr) Date: 20091021 23:35 Message: I added slightly modified code to Jmol 11.9.7 and 11.8.8. Thanks for that, Jonathan.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 
From: SourceForge.net <noreply@so...>  20091022 05:38:51

Bugs item #2883616, was opened at 20091021 19:14 Message generated for change (Settings changed) made by hansonr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File Input/Output Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Albert DeFusco (adefusco) Assigned to: Miguel (migueljmol) Summary: GAMESS hssend optimization (with fix) Initial Comment: Optimizations performed with hssend=.true. in the $statpt group will compute the Hessian and frequencies immediately after optimization has completed. Currently this output does not display properly. It is manifest in two ways: (1) the normal mode displacements are applied starting from the first model (1.1) which is the input geometry before optimization (2) the normal mode atomSets are displayed with the starting geometry not the final. I have also attached an optimization (with hssend=.true.) to help illustrate this bug. In dimer.gamess there are 18 geometry steps. This means Jmol will identify 20 models for the optimization run. The first model is the input (COORDINATES (BOHR)). The second model is NSERCH=0. This is supposed to be identical to the first. The next 18 models are the optimization steps. The final 18 models are vibration frequencies. It is these last 18 models to which the normal mode displacements should be applied, not the first 18, and the geometry should match model 18. I have included an updated GamessReader.java based on revision 11151 which fixes the two issues above. Three changes were required: (1) Always clone from the LastModel. This works even without the optimization (runtyp=hessian). [lines 180183] (2) Use getCurrentAtomSetIndex to help find our current position in atoms[] which includes all atoms from all models. [lines 137144] (3) The vector displacements will only be applied to the new cloned atomSets. [lines 197199] It is possible there is a more elegant solution to changes 2 and 3.  Comment By: Bob Hanson (hansonr) Date: 20091021 23:35 Message: I added slightly modified code to Jmol 11.9.7 and 11.8.8. Thanks for that, Jonathan.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 
From: SourceForge.net <noreply@so...>  20100322 22:08:38

Bugs item #2883616, was opened at 20091021 19:14 Message generated for change (Settings changed) made by hansonr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File Input/Output Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Albert DeFusco (adefusco) Assigned to: Bob Hanson (hansonr) Summary: GAMESS hssend optimization (with fix) Initial Comment: Optimizations performed with hssend=.true. in the $statpt group will compute the Hessian and frequencies immediately after optimization has completed. Currently this output does not display properly. It is manifest in two ways: (1) the normal mode displacements are applied starting from the first model (1.1) which is the input geometry before optimization (2) the normal mode atomSets are displayed with the starting geometry not the final. I have also attached an optimization (with hssend=.true.) to help illustrate this bug. In dimer.gamess there are 18 geometry steps. This means Jmol will identify 20 models for the optimization run. The first model is the input (COORDINATES (BOHR)). The second model is NSERCH=0. This is supposed to be identical to the first. The next 18 models are the optimization steps. The final 18 models are vibration frequencies. It is these last 18 models to which the normal mode displacements should be applied, not the first 18, and the geometry should match model 18. I have included an updated GamessReader.java based on revision 11151 which fixes the two issues above. Three changes were required: (1) Always clone from the LastModel. This works even without the optimization (runtyp=hessian). [lines 180183] (2) Use getCurrentAtomSetIndex to help find our current position in atoms[] which includes all atoms from all models. [lines 137144] (3) The vector displacements will only be applied to the new cloned atomSets. [lines 197199] It is possible there is a more elegant solution to changes 2 and 3.  Comment By: Bob Hanson (hansonr) Date: 20091021 23:35 Message: I added slightly modified code to Jmol 11.9.7 and 11.8.8. Thanks for that, Jonathan.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 
From: Jonathan Gutow <gutow@uw...>  20091022 03:09:43

I may have a chance to look at this this weekend, if someone else cannot check it first. Off the top of my head this does sound like it should work, and I don't see how it would break other things. If you get to check this post to the list so that I won't duplicate effort. Jonathan On Oct 21, 2009, at 7:14 PM, SourceForge.net wrote: > Bugs item #2883616, was opened at 20091021 19:14 > Message generated for change (Tracker Item Submitted) made by adefusco > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 > > Please note that this message will contain a full copy of the > comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: File Input/Output > Group: None > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Albert DeFusco (adefusco) > Assigned to: Miguel (migueljmol) > Summary: GAMESS hssend optimization (with fix) > > Initial Comment: > Optimizations performed with hssend=.true. in the $statpt group will > compute the Hessian and frequencies immediately after optimization > has completed. Currently this output does not display properly. It > is manifest in two ways: > (1) the normal mode displacements are applied starting from the > first model (1.1) which is the input geometry before optimization > (2) the normal mode atomSets are displayed with the starting > geometry not the final. > > I have also attached an optimization (with hssend=.true.) to help > illustrate this bug. In dimer.gamess there are 18 geometry steps. > This means Jmol will identify 20 models for the optimization run. > The first model is the input (COORDINATES (BOHR)). The second model > is NSERCH=0. This is supposed to be identical to the first. The > next 18 models are the optimization steps. The final 18 models are > vibration frequencies. It is these last 18 models to which the > normal mode displacements should be applied, not the first 18, and > the geometry should match model 18. > > I have included an updated GamessReader.java based on revision 11151 > which fixes the two issues above. Three changes were required: > (1) Always clone from the LastModel. This works even without the > optimization (runtyp=hessian). [lines 180183] > (2) Use getCurrentAtomSetIndex to help find our current position in > atoms[] which includes all atoms from all models. [lines 137144] > (3) The vector displacements will only be applied to the new cloned > atomSets. [lines 197199] > It is possible there is a more elegant solution to changes 2 and 3. > > >  > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 > >  > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Jmoldevelopers mailing list > Jmoldevelopers@... > https://lists.sourceforge.net/lists/listinfo/jmoldevelopers Dr. Jonathan H. Gutow Chemistry Department gutow@... UWOshkosh Office:9204241326 800 Algoma Boulevard FAX:9204242042 Oshkosh, WI 54901 http://www.uwosh.edu/facstaff/gutow 
From: Robert Hanson <hansonr@st...>  20091027 04:06:06
Attachments:
Message as HTML

Fixed for 11.9.7 and 11.8.8  Bob On Wed, Oct 21, 2009 at 10:09 PM, Jonathan Gutow <gutow@...> wrote: > I may have a chance to look at this this weekend, if someone else > cannot check it first. Off the top of my head this does sound like it > should work, and I don't see how it would break other things. If you > get to check this post to the list so that I won't duplicate effort. > > Jonathan > On Oct 21, 2009, at 7:14 PM, SourceForge.net wrote: > > > Bugs item #2883616, was opened at 20091021 19:14 > > Message generated for change (Tracker Item Submitted) made by adefusco > > You can respond by visiting: > > > https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 > > > > Please note that this message will contain a full copy of the > > comment thread, > > including the initial issue submission, for this request, > > not just the latest update. > > Category: File Input/Output > > Group: None > > Status: Open > > Resolution: None > > Priority: 5 > > Private: No > > Submitted By: Albert DeFusco (adefusco) > > Assigned to: Miguel (migueljmol) > > Summary: GAMESS hssend optimization (with fix) > > > > Initial Comment: > > Optimizations performed with hssend=.true. in the $statpt group will > > compute the Hessian and frequencies immediately after optimization > > has completed. Currently this output does not display properly. It > > is manifest in two ways: > > (1) the normal mode displacements are applied starting from the > > first model (1.1) which is the input geometry before optimization > > (2) the normal mode atomSets are displayed with the starting > > geometry not the final. > > > > I have also attached an optimization (with hssend=.true.) to help > > illustrate this bug. In dimer.gamess there are 18 geometry steps. > > This means Jmol will identify 20 models for the optimization run. > > The first model is the input (COORDINATES (BOHR)). The second model > > is NSERCH=0. This is supposed to be identical to the first. The > > next 18 models are the optimization steps. The final 18 models are > > vibration frequencies. It is these last 18 models to which the > > normal mode displacements should be applied, not the first 18, and > > the geometry should match model 18. > > > > I have included an updated GamessReader.java based on revision 11151 > > which fixes the two issues above. Three changes were required: > > (1) Always clone from the LastModel. This works even without the > > optimization (runtyp=hessian). [lines 180183] > > (2) Use getCurrentAtomSetIndex to help find our current position in > > atoms[] which includes all atoms from all models. [lines 137144] > > (3) The vector displacements will only be applied to the new cloned > > atomSets. [lines 197199] > > It is possible there is a more elegant solution to changes 2 and 3. > > > > > >  > > > > You can respond by visiting: > > > https://sourceforge.net/tracker/?func=detail&atid=379133&aid=2883616&group_id=23629 > > > > >  > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart > > your > > developing skills, take BlackBerry mobile applications to market and > > stay > > ahead of the curve. Join us from November 9  12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Jmoldevelopers mailing list > > Jmoldevelopers@... > > https://lists.sourceforge.net/lists/listinfo/jmoldevelopers > > Dr. Jonathan H. Gutow > Chemistry Department gutow@... > UWOshkosh Office:9204241326 > 800 Algoma Boulevard FAX:9204242042 > Oshkosh, WI 54901 > http://www.uwosh.edu/facstaff/gutow > > > > > > > >  > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Jmoldevelopers mailing list > Jmoldevelopers@... > https://lists.sourceforge.net/lists/listinfo/jmoldevelopers >  Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 5077863107 If nature does not answer first what we want, it is better to take what answer we get.  Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 