Menu
▾
▴
cclib-devel
|
From: Gregory M. <gm...@MI...> - 2010-04-06 19:01:49
|
Hello cclib developers, I've recently started to use cclib with the reaction mechanism generation software that I work on (http://rmg.sourceforge.net). I figured I would pass along some of the modifications I have made to cclib (see the attached .gitpatch file; these assume v1.0 as the starting point) in case they could be of benefit to you or other users. The modifications include: 1. Fixed (or at least partially fixed) a bug encountered when parsing triplet oxygen atom results from Gaussian03. Originally, this case (see attached QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital symmetry and assignment of HOMOS due to the fact that there were no alpha virtual orbitals. 2. Implemented parsing of certain quantities from MOPAC2009 results. 3. Parsed a few additional quantities from Gaussian output, like molecular mass, rotational symmetry number, and rotational constants. I have tested my changes mostly, if not exclusively, with PM3 calculations from Gaussian03 and MOPAC2009, but testall.py with the modified code seems to give the same results for Gaussian03 as it did before my modifications (91 tests pass and 3 tests are skipped). If you think any of these changes are useful, please feel free to include them (or something based on them) in the next cclib release (and feel free to remove any of my superfluous comments). Also, if you have any questions about the changes, please let me know. Thanks very much for your work on cclib and for making it open-source, Greg Magoon |
|
From: Noel O'B. <bao...@gm...> - 2010-04-06 19:12:26
|
Thanks for the patch Greg and the positive comments. We'll look into integrating this as soon as possible - in particular, it would be great to beef up our MOPAC support. We'll probably have more questions later but right now, I've got three that spring to mind: (1) Are you happy to place the attached log file in the public domain? (This is a requirement for our test suite) (2) Why are you interested in parsing the rotational data? (3) RMG looks like a nice project, but how are you using cclib given that it's a Java/FORTRAN project? - Noel On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote: > Hello cclib developers, > I've recently started to use cclib with the reaction mechanism generation > software that I work on (http://rmg.sourceforge.net). I figured I would pass > along some of the modifications I have made to cclib (see the attached > .gitpatch file; these assume v1.0 as the starting point) in case they could be > of benefit to you or other users. > The modifications include: > 1. Fixed (or at least partially fixed) a bug encountered when parsing triplet > oxygen atom results from Gaussian03. Originally, this case (see attached > QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital > symmetry and assignment of HOMOS due to the fact that there were no alpha > virtual orbitals. > 2. Implemented parsing of certain quantities from MOPAC2009 results. > 3. Parsed a few additional quantities from Gaussian output, like molecular mass, > rotational symmetry number, and rotational constants. > I have tested my changes mostly, if not exclusively, with PM3 calculations from > Gaussian03 and MOPAC2009, but testall.py with the modified code seems to give > the same results for Gaussian03 as it did before my modifications (91 tests > pass and 3 tests are skipped). > > If you think any of these changes are useful, please feel free to include them > (or something based on them) in the next cclib release (and feel free to remove > any of my superfluous comments). Also, if you have any questions about the > changes, please let me know. > > Thanks very much for your work on cclib and for making it open-source, > Greg Magoon > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > |
|
From: Gregory M. <gm...@MI...> - 2010-04-06 20:08:14
|
Hi Noel, Thanks for the quick response. In answer to your questions: 1. I have no objections to your use of the Gaussian log file. 2. I use the rotational constants as part of the rotational partition function for computing gas-phase thermodynamic quantities (entropy, enthalpy, heat capacity). I suppose I could instead calculate the moments of inertia based on the atomic coordinates and masses, but it is easier to just read in the result that Gaussian/MOPAC calculates. (For rotational symmetry number, I actually don't end up using the value from the Gaussian log file since it is often underestimated by Gaussian...I have instead been using a program called SYMMETRY which allows point group calculation within a user-specified tolerance: http://www.cobalt.chem.ucalgary.ca/ps/symmetry/ ). 3. I have written some Python scripts that provide an interface between the Java code and cclib (I haven't included them in the public version of RMG yet). The Python scripts are executed from the Java code using Runtime.getRuntime().exec() and the Python script produces output read in by the Java code in a particular format. I have the Java code interface with RDKit in a similar way. (For what it's worth, there is also a Python version of RMG in development: http://github.com/GreenGroup/RMG-Py ) Greg Quoting Noel O'Boyle <bao...@gm...>: > Thanks for the patch Greg and the positive comments. > > We'll look into integrating this as soon as possible - in particular, > it would be great to beef up our MOPAC support. We'll probably have > more questions later but right now, I've got three that spring to > mind: > (1) Are you happy to place the attached log file in the public domain? > (This is a requirement for our test suite) > (2) Why are you interested in parsing the rotational data? > (3) RMG looks like a nice project, but how are you using cclib given > that it's a Java/FORTRAN project? > > - Noel > > On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote: >> Hello cclib developers, >> I've recently started to use cclib with the reaction mechanism generation >> software that I work on (http://rmg.sourceforge.net). I figured I would pass >> along some of the modifications I have made to cclib (see the attached >> .gitpatch file; these assume v1.0 as the starting point) in case >> they could be >> of benefit to you or other users. >> The modifications include: >> 1. Fixed (or at least partially fixed) a bug encountered when >> parsing triplet >> oxygen atom results from Gaussian03. Originally, this case (see attached >> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital >> symmetry and assignment of HOMOS due to the fact that there were no alpha >> virtual orbitals. >> 2. Implemented parsing of certain quantities from MOPAC2009 results. >> 3. Parsed a few additional quantities from Gaussian output, like >> molecular mass, >> rotational symmetry number, and rotational constants. >> I have tested my changes mostly, if not exclusively, with PM3 >> calculations from >> Gaussian03 and MOPAC2009, but testall.py with the modified code >> seems to give >> the same results for Gaussian03 as it did before my modifications (91 tests >> pass and 3 tests are skipped). >> >> If you think any of these changes are useful, please feel free to >> include them >> (or something based on them) in the next cclib release (and feel >> free to remove >> any of my superfluous comments). Also, if you have any questions about the >> changes, please let me know. >> >> Thanks very much for your work on cclib and for making it open-source, >> Greg Magoon >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> >> > |
|
From: Karol M. L. <km...@mm...> - 2010-04-07 11:10:07
|
Hi! Great. I added the file to our regression suite. I used the parts of your patch that fix scfenergies and homos, so that the regression parses correctly. As far as adding new attributes and the MOPAC parser, I suppose we need to discuss that a bit more. Basically three issues I see here: 1) Do we want to add the MOPAC parser now? Probably should be as a separate branch. 2) Do we add the molmass attribute? Perhaps it would be more usefull to add an atomicmass attribute; more information and can be easily summed. 3) Do we want to add the rotation constants and symmetries now? I don't know if and how these things are printed in other programs (GAMESS, ADF). Thanks again for the contribution, Karol On Tuesday 06 April 2010 22:08:06 Gregory Magoon wrote: > 1. I have no objections to your use of the Gaussian log file. > > 2. I use the rotational constants as part of the rotational partition > function for computing gas-phase thermodynamic quantities (entropy, > enthalpy, heat capacity). I suppose I could instead calculate the moments > of inertia based on the atomic coordinates and masses, but it is easier to > just read in the result that Gaussian/MOPAC calculates. (For rotational > symmetry number, I actually don't end up using the value from the Gaussian > log file since it is often underestimated by Gaussian...I have instead been > using a program called SYMMETRY which allows point group calculation within > a user-specified tolerance: http://www.cobalt.chem.ucalgary.ca/ps/symmetry/ > ). > > 3. I have written some Python scripts that provide an interface between > the Java > code and cclib (I haven't included them in the public version of RMG yet). > The Python scripts are executed from the Java code using > Runtime.getRuntime().exec() and the Python script produces output read in > by the Java code in a particular format. I have the Java code interface > with RDKit > in a similar way. (For what it's worth, there is also a Python version > of RMG in > development: http://github.com/GreenGroup/RMG-Py ) > > Greg > > Quoting Noel O'Boyle <bao...@gm...>: > > Thanks for the patch Greg and the positive comments. > > > > We'll look into integrating this as soon as possible - in particular, > > it would be great to beef up our MOPAC support. We'll probably have > > more questions later but right now, I've got three that spring to > > mind: > > (1) Are you happy to place the attached log file in the public domain? > > (This is a requirement for our test suite) > > (2) Why are you interested in parsing the rotational data? > > (3) RMG looks like a nice project, but how are you using cclib given > > that it's a Java/FORTRAN project? > > > > - Noel > > > > On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote: > >> Hello cclib developers, > >> I've recently started to use cclib with the reaction mechanism > >> generation software that I work on (http://rmg.sourceforge.net). I > >> figured I would pass along some of the modifications I have made to > >> cclib (see the attached .gitpatch file; these assume v1.0 as the > >> starting point) in case they could be > >> of benefit to you or other users. > >> The modifications include: > >> 1. Fixed (or at least partially fixed) a bug encountered when > >> parsing triplet > >> oxygen atom results from Gaussian03. Originally, this case (see attached > >> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of > >> orbital symmetry and assignment of HOMOS due to the fact that there were > >> no alpha virtual orbitals. > >> 2. Implemented parsing of certain quantities from MOPAC2009 results. > >> 3. Parsed a few additional quantities from Gaussian output, like > >> molecular mass, > >> rotational symmetry number, and rotational constants. > >> I have tested my changes mostly, if not exclusively, with PM3 > >> calculations from > >> Gaussian03 and MOPAC2009, but testall.py with the modified code > >> seems to give > >> the same results for Gaussian03 as it did before my modifications (91 > >> tests pass and 3 tests are skipped). > >> > >> If you think any of these changes are useful, please feel free to > >> include them > >> (or something based on them) in the next cclib release (and feel > >> free to remove > >> any of my superfluous comments). Also, if you have any questions about > >> the changes, please let me know. > >> > >> Thanks very much for your work on cclib and for making it open-source, > >> Greg Magoon -- written by Karol Langner Wed Apr 7 12:25:50 CEST 2010 |
|
From: Adam T. <ate...@gm...> - 2010-04-08 19:10:20
|
> 2) Do we add the molmass attribute? Perhaps it would be more usefull to add an > atomicmass attribute; more information and can be easily summed. I'm actually interested in adding the atomic masses, and have already done so in the Turbomole branch for the turbomole, Gaussian, and ADF parsers. I've been calling the vibmasses since my interest in them is to calculate isotope-dependent vibrational spectra (NRVS, to be precise). Any thoughts on keeping them as vibmasses or should we call them atomicmasses? Adam |
|
From: Noel O'B. <bao...@gm...> - 2010-04-08 20:16:50
|
On 8 April 2010 20:10, Adam Tenderholt <ate...@gm...> wrote: >> 2) Do we add the molmass attribute? Perhaps it would be more usefull to add an >> atomicmass attribute; more information and can be easily summed. > > I'm actually interested in adding the atomic masses, and have already > done so in the Turbomole branch for the turbomole, Gaussian, and ADF > parsers. I've been calling the vibmasses since my interest in them is > to calculate isotope-dependent vibrational spectra (NRVS, to be > precise). > > Any thoughts on keeping them as vibmasses or should we call them atomicmasses? It sounds like atommasses (like atomnos) would make most sense. > Adam > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol M. L. <kar...@gm...> - 2010-04-09 09:39:35
|
On Thursday 08 April 2010 22:16:38 Noel O'Boyle wrote: > On 8 April 2010 20:10, Adam Tenderholt <ate...@gm...> wrote: > >> 2) Do we add the molmass attribute? Perhaps it would be more usefull to > >> add an atomicmass attribute; more information and can be easily summed. > > > > I'm actually interested in adding the atomic masses, and have already > > done so in the Turbomole branch for the turbomole, Gaussian, and ADF > > parsers. I've been calling the vibmasses since my interest in them is > > to calculate isotope-dependent vibrational spectra (NRVS, to be > > precise). > > > > Any thoughts on keeping them as vibmasses or should we call them > > atomicmasses? > > It sounds like atommasses (like atomnos) would make most sense. I assume we will be using daltons. -- written by Karol Langner Fri Apr 9 11:36:29 CEST 2010 |
|
From: Karol M. L. <kar...@gm...> - 2010-04-09 08:07:00
|
On Thursday 08 April 2010 22:16:38 Noel O'Boyle wrote: > On 8 April 2010 20:10, Adam Tenderholt <ate...@gm...> wrote: > >> 2) Do we add the molmass attribute? Perhaps it would be more usefull to > >> add an atomicmass attribute; more information and can be easily summed. > > > > I'm actually interested in adding the atomic masses, and have already > > done so in the Turbomole branch for the turbomole, Gaussian, and ADF > > parsers. I've been calling the vibmasses since my interest in them is > > to calculate isotope-dependent vibrational spectra (NRVS, to be > > precise). > > > > Any thoughts on keeping them as vibmasses or should we call them > > atomicmasses? > > It sounds like atommasses (like atomnos) would make most sense. OK, I can do this in the trunk later today. Adam, you'll have to sync the branches you develop. - Karol -- written by Karol Langner Fri Apr 9 10:03:52 CEST 2010 |
|
From: Adam T. <ate...@gm...> - 2010-04-09 18:05:37
|
>>> >>> >>> Any thoughts on keeping them as vibmasses or should we call them >>> atomicmasses? >> >> It sounds like atommasses (like atomnos) would make most sense. > > OK, I can do this in the trunk later today. Adam, you'll have to sync the > branches you develop. > Karol, do you just want to merge the changes I made for the Gaussian and ADF parsers (turbomol branch) into trunk before you start working on them? You'll have the rename them from vibmasses to atomicmasses. Adam |
|
From: Karol M. L. <kar...@gm...> - 2010-04-09 18:21:57
|
On Friday 09 April 2010 19:39:11 Adam Tenderholt wrote: > >>> Any thoughts on keeping them as vibmasses or should we call them > >>> atomicmasses? > >> > >> It sounds like atommasses (like atomnos) would make most sense. > > > > OK, I can do this in the trunk later today. Adam, you'll have to sync the > > branches you develop. > > Karol, do you just want to merge the changes I made for the Gaussian and > ADF parsers (turbomol branch) into trunk before you start working on them? > You'll have the rename them from vibmasses to atomicmasses. > > Adam Oops! I forgot about that, went ahead and wrote the code for the Gaussian parser on my own. I will look at the TM branch to check if it differs. The ADF code should be merged, though. I will not be doing that today, however, so if you want to do it now, go ahead. Sorry, Karol -- written by Karol Langner Fri Apr 9 20:31:47 CEST 2010 |
|
From: Gregory M. <gm...@MI...> - 2010-04-29 15:22:57
|
On a related note: Would there be any license-related issues if we were to include the modified cclib code with our RMG distribution (cf. http://github.com/GreenGroup/RMG-Java/ and http://rmg.sourceforge.net/)? RMG is distributed under the MIT/X11 License (http://rmg.sourceforge.net/license.html), and, as I understand, cclib is available under the LGPL license. Thanks in advance, Greg Quoting Gregory Magoon <gm...@mi...>: > Hi Noel, > Thanks for the quick response. In answer to your questions: > > 1. I have no objections to your use of the Gaussian log file. > > 2. I use the rotational constants as part of the rotational partition > function > for computing gas-phase thermodynamic quantities (entropy, enthalpy, heat > capacity). I suppose I could instead calculate the moments of inertia > based on > the atomic coordinates and masses, but it is easier to just read in > the result > that Gaussian/MOPAC calculates. (For rotational symmetry number, I actually > don't end up using the value from the Gaussian log file since it is often > underestimated by Gaussian...I have instead been using a program called > SYMMETRY which allows point group calculation within a user-specified > tolerance: http://www.cobalt.chem.ucalgary.ca/ps/symmetry/ ). > > 3. I have written some Python scripts that provide an interface > between the Java > code and cclib (I haven't included them in the public version of RMG > yet). The > Python scripts are executed from the Java code using > Runtime.getRuntime().exec() and the Python script produces output read in by > the Java code in a particular format. I have the Java code interface > with RDKit > in a similar way. (For what it's worth, there is also a Python > version of RMG in > development: http://github.com/GreenGroup/RMG-Py ) > > Greg > > Quoting Noel O'Boyle <bao...@gm...>: > >> Thanks for the patch Greg and the positive comments. >> >> We'll look into integrating this as soon as possible - in particular, >> it would be great to beef up our MOPAC support. We'll probably have >> more questions later but right now, I've got three that spring to >> mind: >> (1) Are you happy to place the attached log file in the public domain? >> (This is a requirement for our test suite) >> (2) Why are you interested in parsing the rotational data? >> (3) RMG looks like a nice project, but how are you using cclib given >> that it's a Java/FORTRAN project? >> >> - Noel >> >> On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote: >>> Hello cclib developers, >>> I've recently started to use cclib with the reaction mechanism generation >>> software that I work on (http://rmg.sourceforge.net). I figured I >>> would pass >>> along some of the modifications I have made to cclib (see the attached >>> .gitpatch file; these assume v1.0 as the starting point) in case >>> they could be >>> of benefit to you or other users. >>> The modifications include: >>> 1. Fixed (or at least partially fixed) a bug encountered when >>> parsing triplet >>> oxygen atom results from Gaussian03. Originally, this case (see attached >>> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital >>> symmetry and assignment of HOMOS due to the fact that there were no alpha >>> virtual orbitals. >>> 2. Implemented parsing of certain quantities from MOPAC2009 results. >>> 3. Parsed a few additional quantities from Gaussian output, like >>> molecular mass, >>> rotational symmetry number, and rotational constants. >>> I have tested my changes mostly, if not exclusively, with PM3 >>> calculations from >>> Gaussian03 and MOPAC2009, but testall.py with the modified code >>> seems to give >>> the same results for Gaussian03 as it did before my modifications (91 tests >>> pass and 3 tests are skipped). >>> >>> If you think any of these changes are useful, please feel free to >>> include them >>> (or something based on them) in the next cclib release (and feel >>> free to remove >>> any of my superfluous comments). Also, if you have any questions about the >>> changes, please let me know. >>> >>> Thanks very much for your work on cclib and for making it open-source, >>> Greg Magoon >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> cclib-devel mailing list >>> ccl...@li... >>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >>> >>> >> > > > |
|
From: Adam T. <ate...@gm...> - 2010-04-29 17:33:59
|
My understanding is that you can distribute any program (proprietary or open source) with a LGPL'd library. However, if you make modifications to that library, you must make those changes available under the LGPL and make note of which files were changed. As I recall, you already submitted patches of your changes to us which might satisfy the requirement to make those changes available. Also, if you have an "About dialog" that mentions the copyright and license of RMG, you need to include appropriate copyright/license information for cclib and I believe include a copy of the LGPL. There are probably a couple of other points in the text of the LGPL (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html) that you need to consider, but it's a pretty intense document so I don't know the finer details. Perhaps give it a skim to see if there is anything that jumps out at you. Adam On Thu, Apr 29, 2010 at 8:22 AM, Gregory Magoon <gm...@mi...> wrote: > On a related note: > Would there be any license-related issues if we were to include the modified > cclib code with our RMG distribution (cf. > http://github.com/GreenGroup/RMG-Java/ and > http://rmg.sourceforge.net/)? RMG is > distributed under the MIT/X11 License > (http://rmg.sourceforge.net/license.html), > and, as I understand, cclib is available under the LGPL license. > > Thanks in advance, > Greg > > Quoting Gregory Magoon <gm...@mi...>: > >> Hi Noel, >> Thanks for the quick response. In answer to your questions: >> >> 1. I have no objections to your use of the Gaussian log file. >> >> 2. I use the rotational constants as part of the rotational partition >> function >> for computing gas-phase thermodynamic quantities (entropy, enthalpy, heat >> capacity). I suppose I could instead calculate the moments of inertia >> based on >> the atomic coordinates and masses, but it is easier to just read in >> the result >> that Gaussian/MOPAC calculates. (For rotational symmetry number, I actually >> don't end up using the value from the Gaussian log file since it is often >> underestimated by Gaussian...I have instead been using a program called >> SYMMETRY which allows point group calculation within a user-specified >> tolerance: http://www.cobalt.chem.ucalgary.ca/ps/symmetry/ ). >> >> 3. I have written some Python scripts that provide an interface >> between the Java >> code and cclib (I haven't included them in the public version of RMG >> yet). The >> Python scripts are executed from the Java code using >> Runtime.getRuntime().exec() and the Python script produces output read in by >> the Java code in a particular format. I have the Java code interface >> with RDKit >> in a similar way. (For what it's worth, there is also a Python >> version of RMG in >> development: http://github.com/GreenGroup/RMG-Py ) >> >> Greg >> >> Quoting Noel O'Boyle <bao...@gm...>: >> >>> Thanks for the patch Greg and the positive comments. >>> >>> We'll look into integrating this as soon as possible - in particular, >>> it would be great to beef up our MOPAC support. We'll probably have >>> more questions later but right now, I've got three that spring to >>> mind: >>> (1) Are you happy to place the attached log file in the public domain? >>> (This is a requirement for our test suite) >>> (2) Why are you interested in parsing the rotational data? >>> (3) RMG looks like a nice project, but how are you using cclib given >>> that it's a Java/FORTRAN project? >>> >>> - Noel >>> >>> On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote: >>>> Hello cclib developers, >>>> I've recently started to use cclib with the reaction mechanism generation >>>> software that I work on (http://rmg.sourceforge.net). I figured I >>>> would pass >>>> along some of the modifications I have made to cclib (see the attached >>>> .gitpatch file; these assume v1.0 as the starting point) in case >>>> they could be >>>> of benefit to you or other users. >>>> The modifications include: >>>> 1. Fixed (or at least partially fixed) a bug encountered when >>>> parsing triplet >>>> oxygen atom results from Gaussian03. Originally, this case (see attached >>>> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital >>>> symmetry and assignment of HOMOS due to the fact that there were no alpha >>>> virtual orbitals. >>>> 2. Implemented parsing of certain quantities from MOPAC2009 results. >>>> 3. Parsed a few additional quantities from Gaussian output, like >>>> molecular mass, >>>> rotational symmetry number, and rotational constants. >>>> I have tested my changes mostly, if not exclusively, with PM3 >>>> calculations from >>>> Gaussian03 and MOPAC2009, but testall.py with the modified code >>>> seems to give >>>> the same results for Gaussian03 as it did before my modifications (91 tests >>>> pass and 3 tests are skipped). >>>> >>>> If you think any of these changes are useful, please feel free to >>>> include them >>>> (or something based on them) in the next cclib release (and feel >>>> free to remove >>>> any of my superfluous comments). Also, if you have any questions about the >>>> changes, please let me know. >>>> >>>> Thanks very much for your work on cclib and for making it open-source, >>>> Greg Magoon >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> cclib-devel mailing list >>>> ccl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >>>> >>>> >>> >> >> >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Gregory M. <gm...@MI...> - 2010-04-29 20:06:30
|
Hi Adam, Thanks for clarifying this and pointing me to version 2.1 of the LGPL. I was originally looking at LGPL v3, which isn't as clear to me as LGPL 2.1 (despite the fact that it is shorter). I've included the following notice in our license documentation (http://github.com/GreenGroup/RMG-Java/blob/6a4a5130af709f20433c71c2c16ad21c53ce2ddd/web/source/license.txt): "The contents of source/cclib/ are modified portions of cclib 1.0 (http://cclib.sourceforge.net) and form a software library available under the terms of the LGPL: [LGPL 2.1 license text]" I've also included a notice at the top of the files I've modified, as described in Section 2 of LGPL 2.1. Thanks again for your feedback, Greg Quoting Adam Tenderholt <ate...@gm...>: > My understanding is that you can distribute any program (proprietary > or open source) with a LGPL'd library. However, if you make > modifications to that library, you must make those changes available > under the LGPL and make note of which files were changed. As I recall, > you already submitted patches of your changes to us which might > satisfy the requirement to make those changes available. > > Also, if you have an "About dialog" that mentions the copyright and > license of RMG, you need to include appropriate copyright/license > information for cclib and I believe include a copy of the LGPL. > > There are probably a couple of other points in the text of the LGPL > (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html) that you need > to consider, but it's a pretty intense document so I don't know the > finer details. Perhaps give it a skim to see if there is anything that > jumps out at you. > > Adam > > > On Thu, Apr 29, 2010 at 8:22 AM, Gregory Magoon <gm...@mi...> wrote: >> On a related note: >> Would there be any license-related issues if we were to include the modified >> cclib code with our RMG distribution (cf. >> http://github.com/GreenGroup/RMG-Java/ and >> http://rmg.sourceforge.net/)? RMG is >> distributed under the MIT/X11 License >> (http://rmg.sourceforge.net/license.html), >> and, as I understand, cclib is available under the LGPL license. >> >> Thanks in advance, >> Greg >> >> Quoting Gregory Magoon <gm...@mi...>: >> >>> Hi Noel, >>> Thanks for the quick response. In answer to your questions: >>> >>> 1. I have no objections to your use of the Gaussian log file. >>> >>> 2. I use the rotational constants as part of the rotational partition >>> function >>> for computing gas-phase thermodynamic quantities (entropy, enthalpy, heat >>> capacity). I suppose I could instead calculate the moments of inertia >>> based on >>> the atomic coordinates and masses, but it is easier to just read in >>> the result >>> that Gaussian/MOPAC calculates. (For rotational symmetry number, I actually >>> don't end up using the value from the Gaussian log file since it is often >>> underestimated by Gaussian...I have instead been using a program called >>> SYMMETRY which allows point group calculation within a user-specified >>> tolerance: http://www.cobalt.chem.ucalgary.ca/ps/symmetry/ ). >>> >>> 3. I have written some Python scripts that provide an interface >>> between the Java >>> code and cclib (I haven't included them in the public version of RMG >>> yet). The >>> Python scripts are executed from the Java code using >>> Runtime.getRuntime().exec() and the Python script produces output >>> read in by >>> the Java code in a particular format. I have the Java code interface >>> with RDKit >>> in a similar way. (For what it's worth, there is also a Python >>> version of RMG in >>> development: http://github.com/GreenGroup/RMG-Py ) >>> >>> Greg >>> >>> Quoting Noel O'Boyle <bao...@gm...>: >>> >>>> Thanks for the patch Greg and the positive comments. >>>> >>>> We'll look into integrating this as soon as possible - in particular, >>>> it would be great to beef up our MOPAC support. We'll probably have >>>> more questions later but right now, I've got three that spring to >>>> mind: >>>> (1) Are you happy to place the attached log file in the public domain? >>>> (This is a requirement for our test suite) >>>> (2) Why are you interested in parsing the rotational data? >>>> (3) RMG looks like a nice project, but how are you using cclib given >>>> that it's a Java/FORTRAN project? >>>> >>>> - Noel >>>> >>>> On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote: >>>>> Hello cclib developers, >>>>> I've recently started to use cclib with the reaction mechanism >>>>> generation >>>>> software that I work on (http://rmg.sourceforge.net). I figured I >>>>> would pass >>>>> along some of the modifications I have made to cclib (see the attached >>>>> .gitpatch file; these assume v1.0 as the starting point) in case >>>>> they could be >>>>> of benefit to you or other users. >>>>> The modifications include: >>>>> 1. Fixed (or at least partially fixed) a bug encountered when >>>>> parsing triplet >>>>> oxygen atom results from Gaussian03. Originally, this case (see attached >>>>> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital >>>>> symmetry and assignment of HOMOS due to the fact that there were no alpha >>>>> virtual orbitals. >>>>> 2. Implemented parsing of certain quantities from MOPAC2009 results. >>>>> 3. Parsed a few additional quantities from Gaussian output, like >>>>> molecular mass, >>>>> rotational symmetry number, and rotational constants. >>>>> I have tested my changes mostly, if not exclusively, with PM3 >>>>> calculations from >>>>> Gaussian03 and MOPAC2009, but testall.py with the modified code >>>>> seems to give >>>>> the same results for Gaussian03 as it did before my modifications >>>>> (91 tests >>>>> pass and 3 tests are skipped). >>>>> >>>>> If you think any of these changes are useful, please feel free to >>>>> include them >>>>> (or something based on them) in the next cclib release (and feel >>>>> free to remove >>>>> any of my superfluous comments). Also, if you have any questions >>>>> about the >>>>> changes, please let me know. >>>>> >>>>> Thanks very much for your work on cclib and for making it open-source, >>>>> Greg Magoon >>>>> ------------------------------------------------------------------------------ >>>>> Download Intel® Parallel Studio Eval >>>>> Try the new software tools for yourself. Speed compiling, find bugs >>>>> proactively, and fine-tune applications for parallel performance. >>>>> See why Intel Parallel Studio got high marks during beta. >>>>> http://p.sf.net/sfu/intel-sw-dev >>>>> _______________________________________________ >>>>> cclib-devel mailing list >>>>> ccl...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >>>>> >>>>> >>>> >>> >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > ------------------------------------------------------------------------------ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol M. L. <kar...@gm...> - 2011-01-10 14:39:42
|
On Friday 09 April 2010 19:39:11 Adam Tenderholt wrote: > >>> Any thoughts on keeping them as vibmasses or should we call them > >>> atomicmasses? > >> > >> It sounds like atommasses (like atomnos) would make most sense. > > > > OK, I can do this in the trunk later today. Adam, you'll have to sync the > > branches you develop. > > Karol, do you just want to merge the changes I made for the Gaussian and > ADF parsers (turbomol branch) into trunk before you start working on them? > You'll have the rename them from vibmasses to atomicmasses. Adam, This is something I never did last year after this discussion, so I've finished it now. I merged your vibmasses parser for ADF into trunk, renaming the attribute to atommasses. For the Gaussian parser, I think my solution is more general than the one I saw in the Turbomole parser (relies on thermochemistry being printed), and the values contain more digits. Maybe you would like to merge it into there. - Karol -- written by Karol M. Langner Mon Jan 10 15:42:20 CET 2011 |
|
From: Adam T. <ate...@gm...> - 2011-01-18 03:20:43
|
Karol (and others),
Thanks for the heads-up. I've just merged changes from trunk back into the turbomole parser branch.
Also, I'm getting regression errors for Gaussian98/test_Cu2.log.gz and GAMESS-US/zolm_dft3a.log.zip and a ccopen failure for ORCA2.8/co.out. This appears to be the case for my trunk install too. The testall.py script (Turbomole branch) gives the following:
********* SUMMARY PER PACKAGE ****************
Total Passed Failed Errors Skipped
ADF2007.01 53 51 0 0 2
GAMESS-UK 58 58 0 0 0
GAMESS-US 76 73 1 0 2
Gaussian03 95 92 0 0 3
Jaguar7.0 55 48 0 0 7
Molpro2006 63 59 0 0 4
ORCA2.6 54 46 5 1 2
PCGAMESS 75 74 0 0 1
Turbomole 37 18 0 19 0
--
Lots of errors with Turbomole. Clearly I have work to do. ;-) Any idea about the Orca and GAMESS-US problems?
Adam
> This is something I never did last year after this discussion, so I've
> finished it now. I merged your vibmasses parser for ADF into trunk, renaming
> the attribute to atommasses.
>
> For the Gaussian parser, I think my solution is more general than the one I
> saw in the Turbomole parser (relies on thermochemistry being printed), and
> the values contain more digits. Maybe you would like to merge it into there.
>
> - Karol
>
> --
> written by Karol M. Langner
> Mon Jan 10 15:42:20 CET 2011
|
|
From: Karol M. L. <kar...@gm...> - 2011-01-18 10:19:42
|
Hi, On Tuesday 18 January 2011 04:20:45 Adam Tenderholt wrote: > Also, I'm getting regression errors for Gaussian98/test_Cu2.log.gz and > GAMESS-US/zolm_dft3a.log.zip and a ccopen failure for ORCA2.8/co.out. This > appears to be the case for my trunk install too. I also get errors with the first two. However, ORCA2.8/co.out should parse correctly with my latest commit. Are you sure you've updated your local copy? > The testall.py script > (Turbomole branch) gives the following: > > ********* SUMMARY PER PACKAGE **************** > Total Passed Failed Errors Skipped > ADF2007.01 53 51 0 0 2 > GAMESS-UK 58 58 0 0 0 > GAMESS-US 76 73 1 0 2 > Gaussian03 95 92 0 0 3 > Jaguar7.0 55 48 0 0 7 > Molpro2006 63 59 0 0 4 > ORCA2.6 54 46 5 1 2 > PCGAMESS 75 74 0 0 1 > Turbomole 37 18 0 19 0 This is the same I get using trunk, besides the Turbomole line of course. > Lots of errors with Turbomole. Clearly I have work to do. ;-) Any idea > about the Orca and GAMESS-US problems? I would love to work on the turbomole parser, however for the near future you are on your own :) As far as ORCA is concerned, four fails and the error are connected to vibration attributes, which are very low on my "priority list". The fifth fail happens for scftargets when parsing the geometry optimization test, which I think will be easy to fix. The fail for GAMESS-US is connected to etsecs not summing up to 1. I don't know what to do with that, however, at the moment. Best, Karol -- written by Karol M. Langner Tue Jan 18 11:22:27 CET 2011 |
|
From: Noel O'B. <bao...@gm...> - 2011-01-18 11:26:09
|
The two failures are long term historic failures - they basically map out the limit of what cclib can be expected to do. What I really should do is keep a historic record of SVN revisions versus the regressions. I'll put that on my list of things to do! - Noel On 18 January 2011 10:22, Karol M. Langner <kar...@gm...> wrote: > Hi, > > On Tuesday 18 January 2011 04:20:45 Adam Tenderholt wrote: >> Also, I'm getting regression errors for Gaussian98/test_Cu2.log.gz and >> GAMESS-US/zolm_dft3a.log.zip and a ccopen failure for ORCA2.8/co.out. This >> appears to be the case for my trunk install too. > > I also get errors with the first two. However, ORCA2.8/co.out should parse > correctly with my latest commit. Are you sure you've updated your local copy? > >> The testall.py script >> (Turbomole branch) gives the following: >> >> ********* SUMMARY PER PACKAGE **************** >> Total Passed Failed Errors Skipped >> ADF2007.01 53 51 0 0 2 >> GAMESS-UK 58 58 0 0 0 >> GAMESS-US 76 73 1 0 2 >> Gaussian03 95 92 0 0 3 >> Jaguar7.0 55 48 0 0 7 >> Molpro2006 63 59 0 0 4 >> ORCA2.6 54 46 5 1 2 >> PCGAMESS 75 74 0 0 1 >> Turbomole 37 18 0 19 0 > > This is the same I get using trunk, besides the Turbomole line of course. > >> Lots of errors with Turbomole. Clearly I have work to do. ;-) Any idea >> about the Orca and GAMESS-US problems? > > I would love to work on the turbomole parser, however for the near future you > are on your own :) > > As far as ORCA is concerned, four fails and the error are connected to > vibration attributes, which are very low on my "priority list". The fifth > fail happens for scftargets when parsing the geometry optimization test, > which I think will be easy to fix. > > The fail for GAMESS-US is connected to etsecs not summing up to 1. I don't > know what to do with that, however, at the moment. > > Best, > Karol > > -- > written by Karol M. Langner > Tue Jan 18 11:22:27 CET 2011 > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X