cclib-devel — Developer's mailing list

[cclib-devel] [ cclib-Bugs-3055615 ] atomnos not parsed in a g09 calc

[SourceForge.net <no...@so...>]

Bugs item #3055615, was opened at 2010-08-29 22:45
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3055615&group_id=161285

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: Parsers
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: atomnos not parsed in a g09 calc

Initial Comment:
Cclib trunk r914 does not correctly parse atomnos for a Gaussian 09 calc, although it does parse atomcoords. The input file specifies atoms with Cartesian coordinates while the basic test files use Z-matrices. The problematic file lacks the Input orientation section.

Note that the mocoeffs section has been removed from the file to make it small enough to upload.



----------------------------------------------------------------------

>Comment By: Noel O'Boyle (baoilleach)
Date: 2010-08-30 12:49

Message:
I've fixed the permissions. Let me know if it still doesn't work

----------------------------------------------------------------------

Comment By: Adam Tenderholt (atenderholt)
Date: 2010-08-29 23:53

Message:
Fixed in trunk r. 915.

The problematic file still needs to be added to the data part of the
website so that the regression test passes. I don't have permissions to
create files for some reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3055615&group_id=161285

[cclib-devel] [ cclib-Bugs-3055615 ] atomnos not parsed in a g09 calc

[SourceForge.net <no...@so...>]

Bugs item #3055615, was opened at 2010-08-29 14:45
Message generated for change (Comment added) made by atenderholt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3055615&group_id=161285

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: Parsers
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: atomnos not parsed in a g09 calc

Initial Comment:
Cclib trunk r914 does not correctly parse atomnos for a Gaussian 09 calc, although it does parse atomcoords. The input file specifies atoms with Cartesian coordinates while the basic test files use Z-matrices. The problematic file lacks the Input orientation section.

Note that the mocoeffs section has been removed from the file to make it small enough to upload.



----------------------------------------------------------------------

>Comment By: Adam Tenderholt (atenderholt)
Date: 2010-08-29 15:53

Message:
Fixed in trunk r. 915.

The problematic file still needs to be added to the data part of the
website so that the regression test passes. I don't have permissions to
create files for some reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3055615&group_id=161285

[cclib-devel] g98 error in regression

[Adam T. <ate...@gm...>]

In trying to fix my recent bug report, I see that /data/Gaussian/Gaussian98/test_Cu2.log.gz fails to parse correctly. The issue is line 801 (assert nbasis == self.nbasis).

Should the logger be throwing a critical message instead of outright dying?

Adam

[cclib-devel] [ cclib-Bugs-3055615 ] atomnos not parsed in a g09 calc

[SourceForge.net <no...@so...>]

Bugs item #3055615, was opened at 2010-08-29 14:45
Message generated for change (Tracker Item Submitted) made by atenderholt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3055615&group_id=161285

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: Parsers
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: atomnos not parsed in a g09 calc

Initial Comment:
Cclib trunk r914 does not correctly parse atomnos for a Gaussian 09 calc, although it does parse atomcoords. The input file specifies atoms with Cartesian coordinates while the basic test files use Z-matrices. The problematic file lacks the Input orientation section.

Note that the mocoeffs section has been removed from the file to make it small enough to upload.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3055615&group_id=161285

Re: [cclib-devel] g09 mocoeffs bug

[Noel O'B. <bao...@gm...>]

On 17 August 2010 17:36, Adam Tenderholt <ate...@gm...> wrote:
>> On 12 August 2010 23:33, Adam Tenderholt <ate...@gm...> wrote:
>>>
>>> One of my former labmates (Lei) has found a bug in cclib for parsing the mocoeffs section of a Gaussian 09 logfile. It has to do with the spacing of that section.
>>>
>>> Lines 890-895 of gaussianparser.py (trunk r912) are the relevant parts with parts = line[:11].split() being the main culprit. The part of Lei's file causing the crash is
>>>
>>>     Eigenvalues --  -372.66755-235.72701 -46.03921 -40.79270 -40.79111
>>>     1 1   Mn 1S        0.00000   0.47278   0.00000   0.00000   0.00000
>>>     2        2S        0.00000   0.40732   0.00000   0.00000   0.00000
>>>     3        3S        0.00000   0.21455   0.00000   0.00000   0.00000
>>>     4        4S        0.00000   0.01534   0.00000  -0.00002   0.00000
>>>
>>> Note that there are 5 spaces before the line begins, meaning 'parts = line[:13].split()' should be used. Other files only have 3 spaces.
>>
>> I'm sorting this out now. Did you mean 4 spaces (that's what I see
>> above)? To avoid any problems could you simply attach the part of the
>> file starting from "Molecular orbital coefficients" down to basis
>> function 4 as above?
>
> I decided to include the entire first block and the first couple of lines of the second block. Thanks for taking care of this. :-)
>

No problem. It should be fixed now. And the test suite can now handle
fragment files.

It's possible that a molecule with even more basis functions (more
than 100 on one atom) or atoms (again, more than 100 atoms) could
cause additional problems, but it's hard to predict that in advance.

- Noel

Re: [cclib-devel] g09 mocoeffs bug

[Adam T. <ate...@gm...>]

> On 12 August 2010 23:33, Adam Tenderholt <ate...@gm...> wrote:
>> 
>> One of my former labmates (Lei) has found a bug in cclib for parsing the mocoeffs section of a Gaussian 09 logfile. It has to do with the spacing of that section.
>> 
>> Lines 890-895 of gaussianparser.py (trunk r912) are the relevant parts with parts = line[:11].split() being the main culprit. The part of Lei's file causing the crash is
>> 
>>     Eigenvalues --  -372.66755-235.72701 -46.03921 -40.79270 -40.79111
>>     1 1   Mn 1S        0.00000   0.47278   0.00000   0.00000   0.00000
>>     2        2S        0.00000   0.40732   0.00000   0.00000   0.00000
>>     3        3S        0.00000   0.21455   0.00000   0.00000   0.00000
>>     4        4S        0.00000   0.01534   0.00000  -0.00002   0.00000
>> 
>> Note that there are 5 spaces before the line begins, meaning 'parts = line[:13].split()' should be used. Other files only have 3 spaces.
> 
> I'm sorting this out now. Did you mean 4 spaces (that's what I see
> above)? To avoid any problems could you simply attach the part of the
> file starting from "Molecular orbital coefficients" down to basis
> function 4 as above?

I decided to include the entire first block and the first couple of lines of the second block. Thanks for taking care of this. :-)

Adam

Re: [cclib-devel] g09 mocoeffs bug

[Noel O'B. <bao...@gm...>]

On 12 August 2010 23:33, Adam Tenderholt <ate...@gm...> wrote:
>
> One of my former labmates (Lei) has found a bug in cclib for parsing the mocoeffs section of a Gaussian 09 logfile. It has to do with the spacing of that section.
>
> Lines 890-895 of gaussianparser.py (trunk r912) are the relevant parts with parts = line[:11].split() being the main culprit. The part of Lei's file causing the crash is
>
>     Eigenvalues --  -372.66755-235.72701 -46.03921 -40.79270 -40.79111
>     1 1   Mn 1S        0.00000   0.47278   0.00000   0.00000   0.00000
>     2        2S        0.00000   0.40732   0.00000   0.00000   0.00000
>     3        3S        0.00000   0.21455   0.00000   0.00000   0.00000
>     4        4S        0.00000   0.01534   0.00000  -0.00002   0.00000
>
> Note that there are 5 spaces before the line begins, meaning 'parts = line[:13].split()' should be used. Other files only have 3 spaces.

I'm sorting this out now. Did you mean 4 spaces (that's what I see
above)? To avoid any problems could you simply attach the part of the
file starting from "Molecular orbital coefficients" down to basis
function 4 as above?

> We've tried to reproduce the spacing that breaks the parser, but so far have failed. It looks like it has to do with the number of basis functions (1128). Unfortunately, this results in a file that is probably too large to be included with a formal bug report and data files.
>
> Any thoughts on the best way to fix this bug? Put a conditional on where to split the line depending on the number of basis functions?
>
> Adam
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] g09 mocoeffs bug

[Noel O'B. <bao...@gm...>]

On 14 August 2010 17:13, Adam Tenderholt <ate...@gm...> wrote:
>>
>> bz2 seems to work better than the others. What size are we talking
>> about for a single point calc? If you have access to Gaussian, maybe
>> try "pop=full iop(3/33=1,3/36=-1)" and see if that reduces the file
>> size.
>>
>> If too big, I'll try and think of some way of getting a test into regression.py.
>
> The file is 265M and the bzip'd file is 39M. This is with the bzip2 default (-9 according to the man page), which I take to mean the "best" compression possible. Also, uncompressing this file takes 45s on my MacBook Pro. How efficient is cclib when parsing bzip'd files?

Well, maybe it's a biteen too big. I'll try to add a test directly
into regression.py somehow.

>
>>> Any thoughts on the best way to fix this bug? Put a conditional on where to split the line depending on the number of basis functions?
>>
>> Since we are not 100% sure of the cause, it'd be better if we didn't
>> rely on any data apart from this section. I think it should be easy
>> enough to do, e.g. find where the 1s ends (do all calculations have a
>> 1s on the first line?).
>
> I'd guess that the mocoeffs line always begin with 1s on the first line since it is numbering the basis functions. This is probably the best approach.

I'll make the change.

> Adam
>
>

Re: [cclib-devel] g09 mocoeffs bug

[Adam T. <ate...@gm...>]

> 
> bz2 seems to work better than the others. What size are we talking
> about for a single point calc? If you have access to Gaussian, maybe
> try "pop=full iop(3/33=1,3/36=-1)" and see if that reduces the file
> size.
> 
> If too big, I'll try and think of some way of getting a test into regression.py.

The file is 265M and the bzip'd file is 39M. This is with the bzip2 default (-9 according to the man page), which I take to mean the "best" compression possible. Also, uncompressing this file takes 45s on my MacBook Pro. How efficient is cclib when parsing bzip'd files?


>> Any thoughts on the best way to fix this bug? Put a conditional on where to split the line depending on the number of basis functions?
> 
> Since we are not 100% sure of the cause, it'd be better if we didn't
> rely on any data apart from this section. I think it should be easy
> enough to do, e.g. find where the 1s ends (do all calculations have a
> 1s on the first line?).

I'd guess that the mocoeffs line always begin with 1s on the first line since it is numbering the basis functions. This is probably the best approach.

Adam

Re: [cclib-devel] g09 mocoeffs bug

[Noel O'B. <bao...@gm...>]

On 12 August 2010 23:33, Adam Tenderholt <ate...@gm...> wrote:
>
> One of my former labmates (Lei) has found a bug in cclib for parsing the mocoeffs section of a Gaussian 09 logfile. It has to do with the spacing of that section.
>
> Lines 890-895 of gaussianparser.py (trunk r912) are the relevant parts with parts = line[:11].split() being the main culprit. The part of Lei's file causing the crash is
>
>     Eigenvalues --  -372.66755-235.72701 -46.03921 -40.79270 -40.79111
>     1 1   Mn 1S        0.00000   0.47278   0.00000   0.00000   0.00000
>     2        2S        0.00000   0.40732   0.00000   0.00000   0.00000
>     3        3S        0.00000   0.21455   0.00000   0.00000   0.00000
>     4        4S        0.00000   0.01534   0.00000  -0.00002   0.00000
>
> Note that there are 5 spaces before the line begins, meaning 'parts = line[:13].split()' should be used. Other files only have 3 spaces.
>
> We've tried to reproduce the spacing that breaks the parser, but so far have failed. It looks like it has to do with the number of basis functions (1128). Unfortunately, this results in a file that is probably too large to be included with a formal bug report and data files.

bz2 seems to work better than the others. What size are we talking
about for a single point calc? If you have access to Gaussian, maybe
try "pop=full iop(3/33=1,3/36=-1)" and see if that reduces the file
size.

If too big, I'll try and think of some way of getting a test into regression.py.

> Any thoughts on the best way to fix this bug? Put a conditional on where to split the line depending on the number of basis functions?

Since we are not 100% sure of the cause, it'd be better if we didn't
rely on any data apart from this section. I think it should be easy
enough to do, e.g. find where the 1s ends (do all calculations have a
1s on the first line?).

> Adam
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] g09 mocoeffs bug

[Adam T. <ate...@gm...>]

One of my former labmates (Lei) has found a bug in cclib for parsing the mocoeffs section of a Gaussian 09 logfile. It has to do with the spacing of that section. 

Lines 890-895 of gaussianparser.py (trunk r912) are the relevant parts with parts = line[:11].split() being the main culprit. The part of Lei's file causing the crash is 

     Eigenvalues --  -372.66755-235.72701 -46.03921 -40.79270 -40.79111
     1 1   Mn 1S        0.00000   0.47278   0.00000   0.00000   0.00000
     2        2S        0.00000   0.40732   0.00000   0.00000   0.00000
     3        3S        0.00000   0.21455   0.00000   0.00000   0.00000
     4        4S        0.00000   0.01534   0.00000  -0.00002   0.00000

Note that there are 5 spaces before the line begins, meaning 'parts = line[:13].split()' should be used. Other files only have 3 spaces. 

We've tried to reproduce the spacing that breaks the parser, but so far have failed. It looks like it has to do with the number of basis functions (1128). Unfortunately, this results in a file that is probably too large to be included with a formal bug report and data files.

Any thoughts on the best way to fix this bug? Put a conditional on where to split the line depending on the number of basis functions?

Adam



 

Re: [cclib-devel] atomnos in Gaussian 09

[Marius R. <mar...@gm...>]

Thank you.

On Wed, Jun 23, 2010 at 11:03 PM, Noel O'Boyle <bao...@gm...> wrote:

> Hi Marius,
>
> I fixed this in r910. The fix was simply to replace "natom" with "atomnos".
>
> - Noel
>
> On 23 June 2010 09:48, Marius Retegan <mar...@gm...> wrote:
> > Hello
> > I think there is a problem in the gaussian parser since I'm unable to get
> > the atomnos from a Gaussian 09 file.
> > Even though the atomnos are parsed from the log file, they are not
> assigned
> > to the self.atomnos due to the condition at line 187 in gaussianparser.py
> > (if not hasattr(self, "natom")).
> > Attached you will find a Gaussian 09 log file for the water molecule.
> > On a side note. would it be possible to use an internally stored
> dictionary
> > to change these atomic numbers into element symbols?
> > Thank you
> > Marius
> >
> >
> ------------------------------------------------------------------------------
> > ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
> >
>

Re: [cclib-devel] atomnos in Gaussian 09

[Noel O'B. <bao...@gm...>]

Hi Marius,

I fixed this in r910. The fix was simply to replace "natom" with "atomnos".

- Noel

On 23 June 2010 09:48, Marius Retegan <mar...@gm...> wrote:
> Hello
> I think there is a problem in the gaussian parser since I'm unable to get
> the atomnos from a Gaussian 09 file.
> Even though the atomnos are parsed from the log file, they are not assigned
> to the self.atomnos due to the condition at line 187 in gaussianparser.py
> (if not hasattr(self, "natom")).
> Attached you will find a Gaussian 09 log file for the water molecule.
> On a side note. would it be possible to use an internally stored dictionary
> to change these atomic numbers into element symbols?
> Thank you
> Marius
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] atomnos in Gaussian 09

[Noel O'B. <bao...@gm...>]

Hi Marius,

I'll look into this.

Regarding the second question,

... from cclib.parser.utils import PeriodicTable as pt
... help(pt)
Help on class PeriodicTable in module cclib.parser.utils:

class PeriodicTable(__builtin__.object)
 |  Allows conversion between element name and atomic no.
 |
 |  >>> t = PeriodicTable()
 |  >>> t.element[6]
 |  'C'
 |  >>> t.number['C']
 |  6
 |  >>> t.element[44]
 |  'Ru'
 |  >>> t.number['Au']
 |  79

- Noel

On 23 June 2010 09:48, Marius Retegan <mar...@gm...> wrote:
> Hello
> I think there is a problem in the gaussian parser since I'm unable to get
> the atomnos from a Gaussian 09 file.
> Even though the atomnos are parsed from the log file, they are not assigned
> to the self.atomnos due to the condition at line 187 in gaussianparser.py
> (if not hasattr(self, "natom")).
> Attached you will find a Gaussian 09 log file for the water molecule.
> On a side note. would it be possible to use an internally stored dictionary
> to change these atomic numbers into element symbols?
> Thank you
> Marius
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] [ cclib-Bugs-3017436 ] assert nmo == self.nmo fails

[Noel O'B. <bao...@gm...>]

On 23 June 2010 20:56, Karol M. Langner <km...@mm...> wrote:
> On Wednesday 23 June 2010 21:01:29 Noel O'Boyle wrote:
>> On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote:
>> > I've run into this before, but did not happen to run cclib on the file. I
>> > think this happens when Gaussian detects linear  dependencies in the
>> > basis set, which can happend as the geometry changes.
>>
>> That's right.
>>
>> > So, how do we deal with this? The parser shouldn't break at lease, so do
>> > we loosen the assert here and just issue a warning? Some further parts of
>> > the parser assume that nmo does not change, so it might raise other
>> > problems when nmo changes.
>>
>> I just removed the assert statement in r909. I only added it to be
>> careful. In reality, it doesn't affect anything, as the value will be
>> correct for whatever is parsed after that.
>
> Maybe issue a warning to the logger?

Well, you know, it's really our responsibility to sort it out -
passing the warning onto the user wouldn't be fair. I'm pretty happy
that this is fine. Everything is parsed in order, so the value of
nbasis available at any point will be the correct one.

> --
> written by Karol Langner
> Wed Jun 23 21:56:06 CEST 2010
>

Re: [cclib-devel] [ cclib-Bugs-3017436 ] assert nmo == self.nmo fails

[Karol M. L. <km...@mm...>]

On Wednesday 23 June 2010 21:01:29 Noel O'Boyle wrote:
> On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote:
> > I've run into this before, but did not happen to run cclib on the file. I
> > think this happens when Gaussian detects linear  dependencies in the
> > basis set, which can happend as the geometry changes.
>
> That's right.
>
> > So, how do we deal with this? The parser shouldn't break at lease, so do
> > we loosen the assert here and just issue a warning? Some further parts of
> > the parser assume that nmo does not change, so it might raise other
> > problems when nmo changes.
>
> I just removed the assert statement in r909. I only added it to be
> careful. In reality, it doesn't affect anything, as the value will be
> correct for whatever is parsed after that.

Maybe issue a warning to the logger?

-- 
written by Karol Langner
Wed Jun 23 21:56:06 CEST 2010

Re: [cclib-devel] [ cclib-Bugs-3017436 ] assert nmo == self.nmo fails

[Noel O'B. <bao...@gm...>]

On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote:
> I've run into this before, but did not happen to run cclib on the file. I
> think this happens when Gaussian detects linear  dependencies in the basis
> set, which can happend as the geometry changes.

That's right.

> So, how do we deal with this? The parser shouldn't break at lease, so do we
> loosen the assert here and just issue a warning? Some further parts of the
> parser assume that nmo does not change, so it might raise other problems when
> nmo changes.

I just removed the assert statement in r909. I only added it to be
careful. In reality, it doesn't affect anything, as the value will be
correct for whatever is parsed after that.

> - Karol
>
> On Thursday 17 June 2010 07:24:53 SourceForge.net wrote:
>> Bugs item #3017436, was opened at 2010-06-16 22:24
>> Message generated for change (Tracker Item Submitted) made by atenderholt
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_
>>id=161285
>>
>> 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: Parsers
>> Group: None
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: Adam Tenderholt (atenderholt)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: assert nmo == self.nmo fails
>>
>> Initial Comment:
>> Gaussian 03 log file from an optimization fails to parse correctly. NBsUse
>> changes during the optimization. I initially thought it was dropping
>> functions when converting from cartesian to spherical coordinates (d
>> orbitals), but specifying 5D didn't help.
>>
>> This is using Python 2.6.x on a Mac with cclib trunk (r908).
>
> --
> written by Karol Langner
> Sat Jun 19 13:25:50 CEST 2010
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] [ cclib-Bugs-3017436 ] assert nmo == self.nmo fails

[SourceForge.net <no...@so...>]

Bugs item #3017436, was opened at 2010-06-17 06:24
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285

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: Parsers
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: assert nmo == self.nmo fails

Initial Comment:
Gaussian 03 log file from an optimization fails to parse correctly. NBsUse changes during the optimization. I initially thought it was dropping functions when converting from cartesian to spherical coordinates (d orbitals), but specifying 5D didn't help. 

This is using Python 2.6.x on a Mac with cclib trunk (r908). 

----------------------------------------------------------------------

>Comment By: Noel O'Boyle (baoilleach)
Date: 2010-06-23 19:59

Message:
Fixed in r909.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285

Re: [cclib-devel] [ cclib-Bugs-3017436 ] assert nmo == self.nmo fails

[Karol M. L. <km...@mm...>]

I've run into this before, but did not happen to run cclib on the file. I 
think this happens when Gaussian detects linear  dependencies in the basis 
set, which can happend as the geometry changes.

So, how do we deal with this? The parser shouldn't break at lease, so do we 
loosen the assert here and just issue a warning? Some further parts of the 
parser assume that nmo does not change, so it might raise other problems when 
nmo changes.

- Karol

On Thursday 17 June 2010 07:24:53 SourceForge.net wrote:
> Bugs item #3017436, was opened at 2010-06-16 22:24
> Message generated for change (Tracker Item Submitted) made by atenderholt
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_
>id=161285
>
> 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: Parsers
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Adam Tenderholt (atenderholt)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: assert nmo == self.nmo fails
>
> Initial Comment:
> Gaussian 03 log file from an optimization fails to parse correctly. NBsUse
> changes during the optimization. I initially thought it was dropping
> functions when converting from cartesian to spherical coordinates (d
> orbitals), but specifying 5D didn't help.
>
> This is using Python 2.6.x on a Mac with cclib trunk (r908).

-- 
written by Karol Langner
Sat Jun 19 13:25:50 CEST 2010

[cclib-devel] [ cclib-Bugs-3017436 ] assert nmo == self.nmo fails

[SourceForge.net <no...@so...>]

Bugs item #3017436, was opened at 2010-06-16 22:24
Message generated for change (Tracker Item Submitted) made by atenderholt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285

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: Parsers
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: assert nmo == self.nmo fails

Initial Comment:
Gaussian 03 log file from an optimization fails to parse correctly. NBsUse changes during the optimization. I initially thought it was dropping functions when converting from cartesian to spherical coordinates (d orbitals), but specifying 5D didn't help. 

This is using Python 2.6.x on a Mac with cclib trunk (r908). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285

Re: [cclib-devel] Modifications to cclib 1.0

[Gregory M. <gm...@MI...>]

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
>

Re: [cclib-devel] Modifications to cclib 1.0

[Adam T. <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
>

Re: [cclib-devel] Modifications to cclib 1.0

[Gregory M. <gm...@MI...>]

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] Avogadro plugin

[Noel O'B. <bao...@gm...>]

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

Re: [cclib-devel] Modifications to cclib 1.0

[Karol M. L. <kar...@gm...>]

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