cclib-devel Mailing List for cclib

It really depends on why it's failing, I guess. If it's the same
problem as before, where the assert was added 'just in case' but where
everything was in fact okay, then the assert can simply be removed.

- Noel

On 29 August 2010 23:35, Adam Tenderholt <ate...@gm...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

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

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

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

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

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

> 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

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
>

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

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

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
>

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