From: Edward H. <hol...@ca...> - 2012-04-23 09:15:10
|
Hi Both, Thanks for reviewing my changes, let me address your comments. Adam: Yes, the relaxed scan case in not handled by this code. This is due to issues implementing the extraction of geometries. I think the best way to do this would be to look for "optimisation complete" messages and then add the last parsed geometry to a list of scan geometries. However currently the gaussian parser stops searching after a "optimisation complete" message; changing this would affect the exposed list of geometries and potentially break scripts based on cclib. If you can think of a better way of implementing this I would be happy to provide a patch. Karol: 1) I agree with variable seems an odd choice to be publicly accessible. However it deals with cases where gaussian ends optimisation because of "Optimization completed on the basis of negligible forces". In this case the geovalues is not lower than geotargets at the optimised step. Perhaps this case could instead be dealt with by changing geotargets when this message is found. How to select appropriate values to ensure only the correct geometries appear optimised I am unsure. 2) This seems sensible 3) I agree this seems sensible for the rigid scan case. However it brings us back to the issue of the relaxed scan again; these are a series of optimisations so reusing scfenergies could cause confusion as to the exact meaning of the values and it would also mean that data on the individual optimisation steps is lost. It would seem a choice between simplicity of the interface and completeness of the data collected needs to be made. This is perhaps something we should discuss. I have also attached the test cases for both relaxed and rigid scans. I hope this explains my thoughts on the topic, if anything is unclear please let me know. Yours Ed Holland On 23 Apr 2012, at 09:18, Karol M. Langner wrote: > Hi guys, > > Yes, it would be good to standardize this. > > Several initial thoughts: > 1) attribute optdone is not useful and in fact not used > 2) we should separate the changes related to thermochem. and scans > 3) do we have test output files to work on scans? do we really need > attributes such as scanenergies, when, for example for geometry > optimization, we pack all the values into 'scfenergies', etc.? In > principle we could do the same in this case > > - Karol > > On Apr 22 2012, Adam Tenderholt wrote: >> Hi Ed, >> >> Thank you for the patch. I made a few changes, the most important >> being renaming temp to temperature. I noticed for the relaxed energy >> scan (ethanol.out), the attributes related to the scan are not added. >> Is this something that should be handled? >> >> Noel, Karol: shall we standardize the thermochemistry info (i.e. >> temperature, freeenergy, enthalpy, entropy), and add it to the other >> parsers? This info should already be in the IR and Raman logfiles. >> >> Adam >> >> >> On Tue, Apr 17, 2012 at 6:41 AM, Edward Holland <hol...@ca...> wrote: >>> Hi All, >>> >>> I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this. >>> I have attached the patch file >>> >>> Hope you find the changes acceptable >>> >>> Yours >>> >>> Ed Holland >>> >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> cclib-devel mailing list >>> ccl...@li... >>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >>> >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel > > -- > written by Karol M. Langner > Mon Apr 23 10:11:41 CEST 2012 |