cclib-devel Mailing List for cclib

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&#174; 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
>

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&#174; 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
>

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&#174; 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
>>>
>>>
>>
>
>
>

Here's some info on the plugin:
http://baoilleach.blogspot.com/2010/04/plug-cclib-into-avogadro.html

I'm not pushing it too strong at the moment because I think the
Avogadro guys could make things a bit easier for Python plugin
developers.

- Noel

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

>>> 
>>> 
>>> 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

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

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

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&#174; 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
>

> 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

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

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&#174; 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
>>
>>
>

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&#174; 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
>
>

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