cclib-devel — Developer's mailing list

Re: [cclib-devel] GAMESS-US 2012

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

Hi again,

I've got the remaining logfiles ready, and am comparing them with the
old ones before uploading. For the dvb_ir test, in the 2012 output,
which I attach here, I get this new warning:

     *******************************************************
     * THIS IS NOT A STATIONARY POINT ON THE MOLECULAR PES *
     *     THE VIBRATIONAL ANALYSIS IS NOT VALID !!!       *
     *******************************************************

I suppose this is because this is not the transition state anymore
for the particular combination of method/basis set that gave a
transition state in the older version logfile.

Do you think this warrants generating a new transition state, or should
we just live with this warning?

Cheers,
Karol

On Nov 30 2012, Karol M. Langner wrote:
> On Nov 28 2012, Noel O'Boyle wrote:
> > Sounds fine. We should never remove a test though, so I'd appreciate
> > if you could move the old test to regressions.py with some sort of
> > basic testing code (e.g. that it has the right number of etsecs).
> 
> What I did is call the appropriate unit test from a dynamically
> generated function in the regression suite. This function is generated
> as long as the logfile location is added to a list called 'old_tests'
> inside the unit test class. It is clear from the code (I hope).
> 
> This makes archiving old logfiles as regressions easy and should scale
> reasonably for doing such updates in the future. To withhold the unit
> test for any reason for a particular regressed logfile (like in the
> triplet TD case I brought up) just omit it from old_tests.
> 
> That being said, I will now update all GAMESS-US unit tests to the
> newest 2012 version. Feel free to follow suit for other parsers, if you
> like.
> 
> > Regarding parsing the version, I'm not too keen on parsing such
> > metadata. That's going down a particular path we haven't gone down
> > before. Maybe you can argue me around, but for sure we should not use
> > version information during the parsing.
> 
> That's not what I had in mind. In any case, I don't wish or have the
> free time to do this without a particular reason.
> 
> Cheers,
> Karol
> 
> > On 28 November 2012 00:16, Karol M. Langner <kar...@gm...> wrote:
> > > OK, I took another look at the GAMESS-US test files. It seems that
> > > the files in basicGAMESS-US are from various different versions.
> > > So, it seems more reasonable to just update the one output file
> > > that gives more consistent results for dvb_td_triplet (that is, etsecs
> > > sum up closer to 1), and possibly those that have changed substantially
> > > in the new version of GAMESS-US and require parser work.
> > >
> > > That leaves the question, then, what to do with the old output files,
> > > which are not from one set version. Rename with a version postfix and
> > > transfer to regressions?
> > >
> > > Another option would be to just add additional logfiles for the outputs
> > > that have changes, by adding _a or _b to the names like was done in the
> > > case of several other parser.
> > >
> > > Let me know what you think,
> > > Karol
> > >
> > > P.S. It also seems now a good idea to me to parse the version of a
> > > program for information purposes, and it should be quite easy.
> > >
> > > On Nov 28 2012, Karol M. Langner wrote:
> > >> Hi guys,
> > >>
> > >> I propose to update the GAMESS-US standard tests. The main motivation
> > >> for this is that the dvb_td_triplet test in the 2012 version actually
> > >> passes all the unit tests we have (the 2010 fails in one case). Also,
> > >> there are some formatting changes in the output files, so some
> > >> straightforward update to the parser is in order. I have all the output
> > >> files ready.
> > >>
> > >> Let me know what you think. And, what do we do with the current output
> > >> files in basicGAMESS-US? We should still make sure they are parsed
> > >> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
> > >> discussed some time ago, or rather to the regression suite?
> > >>
> > >> - Karol
> 
> -- 
> written by Karol M. Langner
> Fri Nov 30 00:00:09 CET 2012

-- 
written by Karol M. Langner
Sat Dec  1 13:28:58 CET 2012

Re: [cclib-devel] GAMESS-US 2012

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

On Nov 28 2012, Noel O'Boyle wrote:
> Sounds fine. We should never remove a test though, so I'd appreciate
> if you could move the old test to regressions.py with some sort of
> basic testing code (e.g. that it has the right number of etsecs).

What I did is call the appropriate unit test from a dynamically
generated function in the regression suite. This function is generated
as long as the logfile location is added to a list called 'old_tests'
inside the unit test class. It is clear from the code (I hope).

This makes archiving old logfiles as regressions easy and should scale
reasonably for doing such updates in the future. To withhold the unit
test for any reason for a particular regressed logfile (like in the
triplet TD case I brought up) just omit it from old_tests.

That being said, I will now update all GAMESS-US unit tests to the
newest 2012 version. Feel free to follow suit for other parsers, if you
like.

> Regarding parsing the version, I'm not too keen on parsing such
> metadata. That's going down a particular path we haven't gone down
> before. Maybe you can argue me around, but for sure we should not use
> version information during the parsing.

That's not what I had in mind. In any case, I don't wish or have the
free time to do this without a particular reason.

Cheers,
Karol

> On 28 November 2012 00:16, Karol M. Langner <kar...@gm...> wrote:
> > OK, I took another look at the GAMESS-US test files. It seems that
> > the files in basicGAMESS-US are from various different versions.
> > So, it seems more reasonable to just update the one output file
> > that gives more consistent results for dvb_td_triplet (that is, etsecs
> > sum up closer to 1), and possibly those that have changed substantially
> > in the new version of GAMESS-US and require parser work.
> >
> > That leaves the question, then, what to do with the old output files,
> > which are not from one set version. Rename with a version postfix and
> > transfer to regressions?
> >
> > Another option would be to just add additional logfiles for the outputs
> > that have changes, by adding _a or _b to the names like was done in the
> > case of several other parser.
> >
> > Let me know what you think,
> > Karol
> >
> > P.S. It also seems now a good idea to me to parse the version of a
> > program for information purposes, and it should be quite easy.
> >
> > On Nov 28 2012, Karol M. Langner wrote:
> >> Hi guys,
> >>
> >> I propose to update the GAMESS-US standard tests. The main motivation
> >> for this is that the dvb_td_triplet test in the 2012 version actually
> >> passes all the unit tests we have (the 2010 fails in one case). Also,
> >> there are some formatting changes in the output files, so some
> >> straightforward update to the parser is in order. I have all the output
> >> files ready.
> >>
> >> Let me know what you think. And, what do we do with the current output
> >> files in basicGAMESS-US? We should still make sure they are parsed
> >> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
> >> discussed some time ago, or rather to the regression suite?
> >>
> >> - Karol

-- 
written by Karol M. Langner
Fri Nov 30 00:00:09 CET 2012

Re: [cclib-devel] GAMESS-US 2012

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

Sounds fine. We should never remove a test though, so I'd appreciate
if you could move the old test to regressions.py with some sort of
basic testing code (e.g. that it has the right number of etsecs).

Regarding parsing the version, I'm not too keen on parsing such
metadata. That's going down a particular path we haven't gone down
before. Maybe you can argue me around, but for sure we should not use
version information during the parsing.

- Noel

On 28 November 2012 00:16, Karol M. Langner <kar...@gm...> wrote:
> OK, I took another look at the GAMESS-US test files. It seems that
> the files in basicGAMESS-US are from various different versions.
> So, it seems more reasonable to just update the one output file
> that gives more consistent results for dvb_td_triplet (that is, etsecs
> sum up closer to 1), and possibly those that have changed substantially
> in the new version of GAMESS-US and require parser work.
>
> That leaves the question, then, what to do with the old output files,
> which are not from one set version. Rename with a version postfix and
> transfer to regressions?
>
> Another option would be to just add additional logfiles for the outputs
> that have changes, by adding _a or _b to the names like was done in the
> case of several other parser.
>
> Let me know what you think,
> Karol
>
> P.S. It also seems now a good idea to me to parse the version of a
> program for information purposes, and it should be quite easy.
>
> On Nov 28 2012, Karol M. Langner wrote:
>> Hi guys,
>>
>> I propose to update the GAMESS-US standard tests. The main motivation
>> for this is that the dvb_td_triplet test in the 2012 version actually
>> passes all the unit tests we have (the 2010 fails in one case). Also,
>> there are some formatting changes in the output files, so some
>> straightforward update to the parser is in order. I have all the output
>> files ready.
>>
>> Let me know what you think. And, what do we do with the current output
>> files in basicGAMESS-US? We should still make sure they are parsed
>> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
>> discussed some time ago, or rather to the regression suite?
>>
>> - Karol
>
> --
> written by Karol M. Langner
> Wed Nov 28 01:06:36 CET 2012
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] GAMESS-US 2012

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

OK, I took another look at the GAMESS-US test files. It seems that
the files in basicGAMESS-US are from various different versions.
So, it seems more reasonable to just update the one output file
that gives more consistent results for dvb_td_triplet (that is, etsecs
sum up closer to 1), and possibly those that have changed substantially
in the new version of GAMESS-US and require parser work.

That leaves the question, then, what to do with the old output files,
which are not from one set version. Rename with a version postfix and
transfer to regressions?

Another option would be to just add additional logfiles for the outputs
that have changes, by adding _a or _b to the names like was done in the
case of several other parser.

Let me know what you think,
Karol

P.S. It also seems now a good idea to me to parse the version of a
program for information purposes, and it should be quite easy.

On Nov 28 2012, Karol M. Langner wrote:
> Hi guys,
> 
> I propose to update the GAMESS-US standard tests. The main motivation
> for this is that the dvb_td_triplet test in the 2012 version actually
> passes all the unit tests we have (the 2010 fails in one case). Also,
> there are some formatting changes in the output files, so some
> straightforward update to the parser is in order. I have all the output
> files ready.
> 
> Let me know what you think. And, what do we do with the current output
> files in basicGAMESS-US? We should still make sure they are parsed
> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
> discussed some time ago, or rather to the regression suite?
> 
> - Karol

-- 
written by Karol M. Langner
Wed Nov 28 01:06:36 CET 2012

[cclib-devel] GAMESS-US 2012

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

Hi guys,

I propose to update the GAMESS-US standard tests. The main motivation
for this is that the dvb_td_triplet test in the 2012 version actually
passes all the unit tests we have (the 2010 fails in one case). Also,
there are some formatting changes in the output files, so some
straightforward update to the parser is in order. I have all the output
files ready.

Let me know what you think. And, what do we do with the current output
files in basicGAMESS-US? We should still make sure they are parsed
correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
discussed some time ago, or rather to the regression suite?

- Karol

-- 
written by Karol M. Langner
Wed Nov 28 00:30:53 CET 2012

[cclib-devel] [ cclib-Bugs-3168810 ] Problem parsing Gaussian ONIOM

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

Bugs item #3168810, was opened at 2011-01-31 09:11
Message generated for change (Settings changed) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&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: Noel O'Boyle (baoilleach)
>Assigned to: Noel O'Boyle (baoilleach)
Summary: Problem parsing Gaussian ONIOM

Initial Comment:
This came from a GaussSum user ((kar...@ug...). I didn't see a quick fix so I'm posting here to avoid forgetting about it...

The attached ONIOM file fails to parse correctly.

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2012-11-07 01:53

Message:
I don't think so. I'm assigning it to me.

I'm going to be spending some time sorting out my non-Open Babel projects
between now and the end of the year, so I'll come back to this. Right now
I'll making some changes to GaussSum.

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

Comment By: Karol Langner (langner)
Date: 2012-11-05 13:43

Message:
Has this been fixed in the end?

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-02-01 04:11

Message:
Yes - that's it.

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

Comment By: Adam Tenderholt (atenderholt)
Date: 2011-01-31 13:27

Message:
What is the parsing error? I'm getting the following error, which seems
easy-ish to fix:

---
Attempting to parse ortho_prod_freq.log
Traceback (most recent call last):
  File "/usr/local/bin/ccget", line 99, in <module>
    main()
  File "/usr/local/bin/ccget", line 81, in main
    data = log.parse()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/logfileparser.py",
line 221, in parse
    self.extract(inputfile, line)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/gaussianparser.py",
line 866, in extract
    mocoeffs = [numpy.zeros((self.nmo, self.nbasis), "d")]
AttributeError: 'Gaussian' object has no attribute 'nmo'
---



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

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-01-31 09:15

Message:
File too large to attach. Please find it at
http://www.redbrick.dcu.ie/~noel/tmp/ortho_prod_freq.zip. I can confirm
that it was placed in the public domain (by the bug reporter).

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

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

[cclib-devel] [ cclib-Bugs-3168810 ] Problem parsing Gaussian ONIOM

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

Bugs item #3168810, was opened at 2011-01-31 09:11
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&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: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing Gaussian ONIOM

Initial Comment:
This came from a GaussSum user ((kar...@ug...). I didn't see a quick fix so I'm posting here to avoid forgetting about it...

The attached ONIOM file fails to parse correctly.

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

>Comment By: Noel O'Boyle (baoilleach)
Date: 2012-11-07 01:53

Message:
I don't think so. I'm assigning it to me.

I'm going to be spending some time sorting out my non-Open Babel projects
between now and the end of the year, so I'll come back to this. Right now
I'll making some changes to GaussSum.

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

Comment By: Karol Langner (langner)
Date: 2012-11-05 13:43

Message:
Has this been fixed in the end?

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-02-01 04:11

Message:
Yes - that's it.

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

Comment By: Adam Tenderholt (atenderholt)
Date: 2011-01-31 13:27

Message:
What is the parsing error? I'm getting the following error, which seems
easy-ish to fix:

---
Attempting to parse ortho_prod_freq.log
Traceback (most recent call last):
  File "/usr/local/bin/ccget", line 99, in <module>
    main()
  File "/usr/local/bin/ccget", line 81, in main
    data = log.parse()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/logfileparser.py",
line 221, in parse
    self.extract(inputfile, line)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/gaussianparser.py",
line 866, in extract
    mocoeffs = [numpy.zeros((self.nmo, self.nbasis), "d")]
AttributeError: 'Gaussian' object has no attribute 'nmo'
---



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

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-01-31 09:15

Message:
File too large to attach. Please find it at
http://www.redbrick.dcu.ie/~noel/tmp/ortho_prod_freq.zip. I can confirm
that it was placed in the public domain (by the bug reporter).

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

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

[cclib-devel] [ cclib-Bugs-3476063 ] Failed hessian parsing for newer GAMESS-US

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

Bugs item #3476063, was opened at 2012-01-19 06:23
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3476063&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: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Karol Langner (langner)
Assigned to: Karol Langner (langner)
Summary: Failed hessian parsing for newer GAMESS-US

Initial Comment:
Chengju Wang reported this on the cclib-users list.

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

>Comment By: Karol Langner (langner)
Date: 2012-11-05 16:16

Message:
Closing, since fixed and file is now a regression.

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

Comment By: Karol Langner (langner)
Date: 2012-01-19 06:49

Message:
Fixed with commit r951. The log file now parses.

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

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

[cclib-devel] [ cclib-Bugs-3184890 ] ORCA doesn't parse scf energy

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

Bugs item #3184890, was opened at 2011-02-17 06:24
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3184890&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: mretegan ()
Assigned to: Nobody/Anonymous (nobody)
Summary: ORCA doesn't parse scf energy

Initial Comment:
If you include solvent effects via COSMO interface, the parser fails to parse the scfenergies, since the printing changes in the output.
Attached you will find a patch and a test case, both released under public domain.

Also I've tried to induce a particular situation in this computation. If you limit orca to a specific number of scf cycles, it does not print the total energy after the scf has finished if this is not converged. As far as I can tell everithing else gets printed (energy change, density change etc).


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

>Comment By: Karol Langner (langner)
Date: 2012-11-05 16:16

Message:
Both of these bugs related to scfenergies in ORCA are fixed in r997. File
added to regressions.

Thanks.

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

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

[cclib-devel] [ cclib-Bugs-3168810 ] Problem parsing Gaussian ONIOM

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

Bugs item #3168810, was opened at 2011-01-31 09:11
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&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: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing Gaussian ONIOM

Initial Comment:
This came from a GaussSum user ((kar...@ug...). I didn't see a quick fix so I'm posting here to avoid forgetting about it...

The attached ONIOM file fails to parse correctly.

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

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:43

Message:
Has this been fixed in the end?

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-02-01 04:11

Message:
Yes - that's it.

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

Comment By: Adam Tenderholt (atenderholt)
Date: 2011-01-31 13:27

Message:
What is the parsing error? I'm getting the following error, which seems
easy-ish to fix:

---
Attempting to parse ortho_prod_freq.log
Traceback (most recent call last):
  File "/usr/local/bin/ccget", line 99, in <module>
    main()
  File "/usr/local/bin/ccget", line 81, in main
    data = log.parse()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/logfileparser.py",
line 221, in parse
    self.extract(inputfile, line)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/gaussianparser.py",
line 866, in extract
    mocoeffs = [numpy.zeros((self.nmo, self.nbasis), "d")]
AttributeError: 'Gaussian' object has no attribute 'nmo'
---



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

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-01-31 09:15

Message:
File too large to attach. Please find it at
http://www.redbrick.dcu.ie/~noel/tmp/ortho_prod_freq.zip. I can confirm
that it was placed in the public domain (by the bug reporter).

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

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

[cclib-devel] [ cclib-Bugs-2908926 ] I never get the attribute 'scfvalues'

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

Bugs item #2908926, was opened at 2009-12-04 08:56
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2908926&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: Invalid
Priority: 5
Private: No
Submitted By: xaverxn (xaverxn)
Assigned to: Nobody/Anonymous (nobody)
Summary: I never get the attribute 'scfvalues'

Initial Comment:
Hi,
I'm not sure if I'm doing anything wrong here, so forgive my if this is not a bug.
Using current trunk (rev. 826) or stable, I can't seem to get the attribute 'scfvalues' when parsing any of my gaussian log files ("AttributeError: 'ccData' object has no attribute 'scfvalues'"). Please try it with the file attached to my last bug report (Title "Assertion error trying ...", file g03_test_complete.log.tar.bz2). Attached find the python console output.

Regards, Xaver

>>> myfile=cclib.parser.ccopen('testfiles/g03_test_complete.log')
>>> data = myfile.parse()
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute charge: -2
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute mult: 5
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute atomnos[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute natom: 31
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute gbasis[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute nbasis: 286
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute nmo: 286
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute scfenergies[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute moenergies[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute homos[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute grads[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute geovalues[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute geotargets[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute atomcoords[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute coreelectrons[]
>>> data.scfenergies
array([-55160.82711683, -55160.82713724, -55160.82713724])
>>> data.scfvalues
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ccData' object has no attribute 'scfvalues'



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

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:38

Message:
I guest this can be closed. I added a note about the #P needed for Gaussian
on the wiki.

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

Comment By: xaverxn (xaverxn)
Date: 2009-12-10 06:35

Message:
Sure. I meant using cclib fo parsing (which does not give me back single
lines).

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2009-12-10 04:03

Message:
line.split()[-2] will give you '34'.

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

Comment By: xaverxn (xaverxn)
Date: 2009-12-10 03:58

Message:
Yes, I guessed sth like this. So there is no way to extract the '34' out of
the line
 SCF Done:  E(UB+HF-LYP) =  -2027.12313726     a.u. after   34 cycles
? In my understanding, that should be the same as (or a part of what)  you
would extract from #P log files.

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2009-12-10 03:10

Message:
Presumably your files don't contain this data (compare with dvb_gopt.out in
the distribution). You need to use #P if you want scf convergence
information to be included.

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

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

[cclib-devel] [ cclib-Bugs-1784327 ] Can't handle GAMESS TD-DFT

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

Bugs item #1784327, was opened at 2007-08-29 11:23
Message generated for change (Settings changed) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1784327&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: Out of Date
Priority: 5
Private: No
Submitted By: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't handle GAMESS TD-DFT

Initial Comment:
Vitaliy Gorbenko contacted GaussSum. It seems that cclib can't handle GAMESS and PC GAMESS TD-DFT. I haven't verified the problem.

He provided an input and output file but I include here only the keywords for the input:

GAMESS:
 $CONTRL SCFTYP=RHF DFTTYP=B3LYP TDDFT=EXCITE $END
 $SYSTEM TIMLIM=3000 MWORDS=50 $END
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END
 $TDDFT NSTATE=10 $END
 $DAT

He also reported problems with PC GAMESS:

 $CONTRL SCFTYP=RHF CITYP=CIS COORD=CART MAXIT=1000 $END                      
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                       
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $CIS NSTATE=80 ISTSYM=0 ISTATE=1 $END                                          
 $DAT

and also:

 $CONTRL SCFTYP=RHF DFTTYP=B3LYP CITYP=TDDFT COORD=CART MAXIT=1000 $END       
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                        
 $BASIS  GBASIS=STO ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $TDDFT NSTATE=80 ISTSYM=0 ISTATE=1 TDA=.t. $END                                
 $DAT


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

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:26

Message:
We've been handling TD logfiles for some time now, and I believe these
input decks are covered by the unit tests.

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2007-11-06 07:47

Message:
Logged In: YES 
user_id=850620
Originator: YES

The problem appears to be that etoscs is not parsed. I am looking into
this...

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

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

[cclib-devel] [ cclib-Bugs-1775665 ] empty mosyms

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

Bugs item #1775665, was opened at 2007-08-16 10:57
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1775665&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: empty mosyms

Initial Comment:
I have a calculation that doesn't have mosyms parsed at all. I believe it is because I used SCF=QC and it gives a section that starts with 'Orbital Symmetries in SymMO:' before the 'Orbital Symmetries:' section. I still need to generate an appropriate test file.

Quick workaround is as follows. On line 328, change

if line[1:19] == 'Orbital symmetries' and not hasattr(self, "mosyms"):

to

if line[1:20] == 'Orbital symmetries:' and not hasattr(self, "mosyms"):

Basically this just ignores the incorrect section by checking to make sure the Orbital symmetries is followed immediately by a colon.

Adam



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

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:20

Message:
Just looked at the code and this was fixed at some point in the past. FTR,
this was in the Gaussian parser.

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

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

[cclib-devel] [ cclib-Bugs-1756794 ] GAMESS: Raman parsing fails

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

Bugs item #1756794, was opened at 2007-07-19 05:32
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756794&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: Wont Fix
Priority: 5
Private: No
Submitted By: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: GAMESS: Raman parsing fails

Initial Comment:
Reported by Charlie Bradshaw, but IP issues prevent me looking at the test file.

Dear Noel,

The attached .zip file contains a gamess log with runtype=raman on the
musk ambrette molecule.  GaussSum fails to open the log due to a
parsing error.  According to the documentation IR_raman.py should
handle this.  This log file also crashes Chemcraft, so it may be a
problem with the log.  There were a number of modes with *******
instead of activity where I changed the string of "*" to 0.0.

Best regards,

Charlie

Dr. Charles F. Bradshaw
The MITRE Corporation

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

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:14

Message:
No point in keeping this open. We cannot fix it without the file anyway.

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

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

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

I've added a regression test for Gaussian 09 Lowdin charges (dvb_lowdin).
The logfile should be wget-able, and the regression file currently fails
because it can't find lowdin in atomcharges (but can find mulliken).

On Mon, Oct 8, 2012 at 9:14 AM, Karol M. Langner <kar...@gm...>wrote:

> Sure, if you can spare the time, add them as a regression or replace the
> current unit test.
>
> - Karol
>
> P.S. I also took a stab at updating the wiki for atomcharges/atomspins,
> but in the end it would be good to generate some of the wiki (parsed data
> tables) automatically.
>
> On Oct 08 2012, Adam Tenderholt wrote:
> > Hi Karol,
> >
> > Thanks for working on these attributes. Looks like you covered the big
> five
> > (Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for
> > Gaussian that causes Lowdin charges to be printed. Want me to try this?
> >
> > Adam
> >
> >
> > On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner
> > <kar...@gm...>wrote:
> >
> > > On Oct 06 2012, Karol M. Langner wrote:
> > > > On Oct 05 2012, Noel O'Boyle wrote:
> > > > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...>
> > > wrote:
> > > > > > Copying to cclib-dev instead of cclib-users...
> > > > > >
> > > > > >> So, Noel, Adam... what do you think? We can't have na attribute
> for
> > > > > >> every type of population analysis parsed. I see two options:
> > > > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
> > > > > >> 2) use a list of tuples consisting of a string and an array of
> > > charges
> > > > > >
> > > > > >
> > > > > > I agree that it's bad form to have to deal with all permutations
> of
> > > > > > attributes like mulliken_charges, loewdin_charges, etc, so it's
> best
> > > to have
> > > > > > just have charges and densities attributes.
> > > > > >
> > > > > > I think dictionaries are more elegant than a list of tuples. For
> > > example,
> > > > > > getting the Mulliken charges is simply charges["Mulliken"]
> instead
> > > of having
> > > > > > to iterate over the elements in a charges list looking for
> > > "Mulliken" in
> > > > > > tuple[0].
> > > > >
> > > > > +1
> > > >
> > > > I just implemented this in recent commits, for several parsers and
> > > > Mulliken/Lowdin charges where they are printed. In some cases (Molpro
> > > > and Jaguar) I could not find them and I think some flag in the input
> > > > would need to be turned on in order to print them. I don't think I
> will
> > > > update the data files and parsers for that unless somebody asks,
> though.
> > > >
> > > > The attribute is called atomcharges and I added unit tests for their
> > > > length (should equal natom) and sum (should be zero for the unit
> tests).
> > > >
> > > > As far as spin densities are concerned, this is also easily done --
> > > > should we call the corresponding attribute atomspins?
> > >
> > > I went ahead and implemented this for ORCA, too. If you guys think a
> > > different attribute name will better, jsut change it. Implementing this
> > > for other parsers will require updating output files to have spin
> > > densities. I might do that for GAMESS and one more sometime in the
> > > future, but I suppose the rest will be upon request.
> > >
> > > - Karol
> > >
> > > --
> > > written by Karol M. Langner
> > > Sat Oct  6 20:32:38 CEST 2012
> > >
>
> --
> written by Karol M. Langner
> Mon Oct  8 18:13:15 CEST 2012
>

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

I was thinking more of a Python script that infers all of the parsed attributes from the cclib codebase. No need for manual intervention after we get something like that working. It should be possible, since we have unit tests designed explicitely to test the parsed attributes.

- Karol

On Oct 08 2012, Noel O'Boyle wrote:
> I've been thinking that a shared Google spreadsheet would be a good
> way to go. If it's in there, I can write a script to generate the wiki
> text from that.
> 
> - Noel
> 
> On 8 October 2012 17:14, Karol M. Langner <kar...@gm...> wrote:
> > Sure, if you can spare the time, add them as a regression or replace the
> > current unit test.
> >
> > - Karol
> >
> > P.S. I also took a stab at updating the wiki for atomcharges/atomspins,
> > but in the end it would be good to generate some of the wiki (parsed data
> > tables) automatically.
> >
> > On Oct 08 2012, Adam Tenderholt wrote:
> >> Hi Karol,
> >>
> >> Thanks for working on these attributes. Looks like you covered the big five
> >> (Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for
> >> Gaussian that causes Lowdin charges to be printed. Want me to try this?
> >>
> >> Adam
> >>
> >>
> >> On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner
> >> <kar...@gm...>wrote:
> >>
> >> > On Oct 06 2012, Karol M. Langner wrote:
> >> > > On Oct 05 2012, Noel O'Boyle wrote:
> >> > > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...>
> >> > wrote:
> >> > > > > Copying to cclib-dev instead of cclib-users...
> >> > > > >
> >> > > > >> So, Noel, Adam... what do you think? We can't have na attribute for
> >> > > > >> every type of population analysis parsed. I see two options:
> >> > > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
> >> > > > >> 2) use a list of tuples consisting of a string and an array of
> >> > charges
> >> > > > >
> >> > > > >
> >> > > > > I agree that it's bad form to have to deal with all permutations of
> >> > > > > attributes like mulliken_charges, loewdin_charges, etc, so it's best
> >> > to have
> >> > > > > just have charges and densities attributes.
> >> > > > >
> >> > > > > I think dictionaries are more elegant than a list of tuples. For
> >> > example,
> >> > > > > getting the Mulliken charges is simply charges["Mulliken"] instead
> >> > of having
> >> > > > > to iterate over the elements in a charges list looking for
> >> > "Mulliken" in
> >> > > > > tuple[0].
> >> > > >
> >> > > > +1
> >> > >
> >> > > I just implemented this in recent commits, for several parsers and
> >> > > Mulliken/Lowdin charges where they are printed. In some cases (Molpro
> >> > > and Jaguar) I could not find them and I think some flag in the input
> >> > > would need to be turned on in order to print them. I don't think I will
> >> > > update the data files and parsers for that unless somebody asks, though.
> >> > >
> >> > > The attribute is called atomcharges and I added unit tests for their
> >> > > length (should equal natom) and sum (should be zero for the unit tests).
> >> > >
> >> > > As far as spin densities are concerned, this is also easily done --
> >> > > should we call the corresponding attribute atomspins?
> >> >
> >> > I went ahead and implemented this for ORCA, too. If you guys think a
> >> > different attribute name will better, jsut change it. Implementing this
> >> > for other parsers will require updating output files to have spin
> >> > densities. I might do that for GAMESS and one more sometime in the
> >> > future, but I suppose the rest will be upon request.
> >> >
> >> > - Karol
> >> >
> >> > --
> >> > written by Karol M. Langner
> >> > Sat Oct  6 20:32:38 CEST 2012
> >> >
> >
> > --
> > written by Karol M. Langner
> > Mon Oct  8 18:13:15 CEST 2012
> >
> > ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel

-- 
written by Karol M. Langner
Mon Oct  8 18:25:25 CEST 2012

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

I've been thinking that a shared Google spreadsheet would be a good
way to go. If it's in there, I can write a script to generate the wiki
text from that.

- Noel

On 8 October 2012 17:14, Karol M. Langner <kar...@gm...> wrote:
> Sure, if you can spare the time, add them as a regression or replace the
> current unit test.
>
> - Karol
>
> P.S. I also took a stab at updating the wiki for atomcharges/atomspins,
> but in the end it would be good to generate some of the wiki (parsed data
> tables) automatically.
>
> On Oct 08 2012, Adam Tenderholt wrote:
>> Hi Karol,
>>
>> Thanks for working on these attributes. Looks like you covered the big five
>> (Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for
>> Gaussian that causes Lowdin charges to be printed. Want me to try this?
>>
>> Adam
>>
>>
>> On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner
>> <kar...@gm...>wrote:
>>
>> > On Oct 06 2012, Karol M. Langner wrote:
>> > > On Oct 05 2012, Noel O'Boyle wrote:
>> > > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...>
>> > wrote:
>> > > > > Copying to cclib-dev instead of cclib-users...
>> > > > >
>> > > > >> So, Noel, Adam... what do you think? We can't have na attribute for
>> > > > >> every type of population analysis parsed. I see two options:
>> > > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
>> > > > >> 2) use a list of tuples consisting of a string and an array of
>> > charges
>> > > > >
>> > > > >
>> > > > > I agree that it's bad form to have to deal with all permutations of
>> > > > > attributes like mulliken_charges, loewdin_charges, etc, so it's best
>> > to have
>> > > > > just have charges and densities attributes.
>> > > > >
>> > > > > I think dictionaries are more elegant than a list of tuples. For
>> > example,
>> > > > > getting the Mulliken charges is simply charges["Mulliken"] instead
>> > of having
>> > > > > to iterate over the elements in a charges list looking for
>> > "Mulliken" in
>> > > > > tuple[0].
>> > > >
>> > > > +1
>> > >
>> > > I just implemented this in recent commits, for several parsers and
>> > > Mulliken/Lowdin charges where they are printed. In some cases (Molpro
>> > > and Jaguar) I could not find them and I think some flag in the input
>> > > would need to be turned on in order to print them. I don't think I will
>> > > update the data files and parsers for that unless somebody asks, though.
>> > >
>> > > The attribute is called atomcharges and I added unit tests for their
>> > > length (should equal natom) and sum (should be zero for the unit tests).
>> > >
>> > > As far as spin densities are concerned, this is also easily done --
>> > > should we call the corresponding attribute atomspins?
>> >
>> > I went ahead and implemented this for ORCA, too. If you guys think a
>> > different attribute name will better, jsut change it. Implementing this
>> > for other parsers will require updating output files to have spin
>> > densities. I might do that for GAMESS and one more sometime in the
>> > future, but I suppose the rest will be upon request.
>> >
>> > - Karol
>> >
>> > --
>> > written by Karol M. Langner
>> > Sat Oct  6 20:32:38 CEST 2012
>> >
>
> --
> written by Karol M. Langner
> Mon Oct  8 18:13:15 CEST 2012
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

Sure, if you can spare the time, add them as a regression or replace the
current unit test.

- Karol

P.S. I also took a stab at updating the wiki for atomcharges/atomspins,
but in the end it would be good to generate some of the wiki (parsed data
tables) automatically.

On Oct 08 2012, Adam Tenderholt wrote:
> Hi Karol,
> 
> Thanks for working on these attributes. Looks like you covered the big five
> (Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for
> Gaussian that causes Lowdin charges to be printed. Want me to try this?
> 
> Adam
> 
> 
> On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner
> <kar...@gm...>wrote:
> 
> > On Oct 06 2012, Karol M. Langner wrote:
> > > On Oct 05 2012, Noel O'Boyle wrote:
> > > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...>
> > wrote:
> > > > > Copying to cclib-dev instead of cclib-users...
> > > > >
> > > > >> So, Noel, Adam... what do you think? We can't have na attribute for
> > > > >> every type of population analysis parsed. I see two options:
> > > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
> > > > >> 2) use a list of tuples consisting of a string and an array of
> > charges
> > > > >
> > > > >
> > > > > I agree that it's bad form to have to deal with all permutations of
> > > > > attributes like mulliken_charges, loewdin_charges, etc, so it's best
> > to have
> > > > > just have charges and densities attributes.
> > > > >
> > > > > I think dictionaries are more elegant than a list of tuples. For
> > example,
> > > > > getting the Mulliken charges is simply charges["Mulliken"] instead
> > of having
> > > > > to iterate over the elements in a charges list looking for
> > "Mulliken" in
> > > > > tuple[0].
> > > >
> > > > +1
> > >
> > > I just implemented this in recent commits, for several parsers and
> > > Mulliken/Lowdin charges where they are printed. In some cases (Molpro
> > > and Jaguar) I could not find them and I think some flag in the input
> > > would need to be turned on in order to print them. I don't think I will
> > > update the data files and parsers for that unless somebody asks, though.
> > >
> > > The attribute is called atomcharges and I added unit tests for their
> > > length (should equal natom) and sum (should be zero for the unit tests).
> > >
> > > As far as spin densities are concerned, this is also easily done --
> > > should we call the corresponding attribute atomspins?
> >
> > I went ahead and implemented this for ORCA, too. If you guys think a
> > different attribute name will better, jsut change it. Implementing this
> > for other parsers will require updating output files to have spin
> > densities. I might do that for GAMESS and one more sometime in the
> > future, but I suppose the rest will be upon request.
> >
> > - Karol
> >
> > --
> > written by Karol M. Langner
> > Sat Oct  6 20:32:38 CEST 2012
> >

-- 
written by Karol M. Langner
Mon Oct  8 18:13:15 CEST 2012

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

Hi Karol,

Thanks for working on these attributes. Looks like you covered the big five
(Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for
Gaussian that causes Lowdin charges to be printed. Want me to try this?

Adam


On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner
<kar...@gm...>wrote:

> On Oct 06 2012, Karol M. Langner wrote:
> > On Oct 05 2012, Noel O'Boyle wrote:
> > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...>
> wrote:
> > > > Copying to cclib-dev instead of cclib-users...
> > > >
> > > >> So, Noel, Adam... what do you think? We can't have na attribute for
> > > >> every type of population analysis parsed. I see two options:
> > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
> > > >> 2) use a list of tuples consisting of a string and an array of
> charges
> > > >
> > > >
> > > > I agree that it's bad form to have to deal with all permutations of
> > > > attributes like mulliken_charges, loewdin_charges, etc, so it's best
> to have
> > > > just have charges and densities attributes.
> > > >
> > > > I think dictionaries are more elegant than a list of tuples. For
> example,
> > > > getting the Mulliken charges is simply charges["Mulliken"] instead
> of having
> > > > to iterate over the elements in a charges list looking for
> "Mulliken" in
> > > > tuple[0].
> > >
> > > +1
> >
> > I just implemented this in recent commits, for several parsers and
> > Mulliken/Lowdin charges where they are printed. In some cases (Molpro
> > and Jaguar) I could not find them and I think some flag in the input
> > would need to be turned on in order to print them. I don't think I will
> > update the data files and parsers for that unless somebody asks, though.
> >
> > The attribute is called atomcharges and I added unit tests for their
> > length (should equal natom) and sum (should be zero for the unit tests).
> >
> > As far as spin densities are concerned, this is also easily done --
> > should we call the corresponding attribute atomspins?
>
> I went ahead and implemented this for ORCA, too. If you guys think a
> different attribute name will better, jsut change it. Implementing this
> for other parsers will require updating output files to have spin
> densities. I might do that for GAMESS and one more sometime in the
> future, but I suppose the rest will be upon request.
>
> - Karol
>
> --
> written by Karol M. Langner
> Sat Oct  6 20:32:38 CEST 2012
>

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

On Oct 06 2012, Karol M. Langner wrote:
> On Oct 05 2012, Noel O'Boyle wrote:
> > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...> wrote:
> > > Copying to cclib-dev instead of cclib-users...
> > >
> > >> So, Noel, Adam... what do you think? We can't have na attribute for
> > >> every type of population analysis parsed. I see two options:
> > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
> > >> 2) use a list of tuples consisting of a string and an array of charges
> > >
> > >
> > > I agree that it's bad form to have to deal with all permutations of
> > > attributes like mulliken_charges, loewdin_charges, etc, so it's best to have
> > > just have charges and densities attributes.
> > >
> > > I think dictionaries are more elegant than a list of tuples. For example,
> > > getting the Mulliken charges is simply charges["Mulliken"] instead of having
> > > to iterate over the elements in a charges list looking for "Mulliken" in
> > > tuple[0].
> > 
> > +1
> 
> I just implemented this in recent commits, for several parsers and
> Mulliken/Lowdin charges where they are printed. In some cases (Molpro
> and Jaguar) I could not find them and I think some flag in the input
> would need to be turned on in order to print them. I don't think I will
> update the data files and parsers for that unless somebody asks, though.
> 
> The attribute is called atomcharges and I added unit tests for their
> length (should equal natom) and sum (should be zero for the unit tests).
> 
> As far as spin densities are concerned, this is also easily done --
> should we call the corresponding attribute atomspins?

I went ahead and implemented this for ORCA, too. If you guys think a
different attribute name will better, jsut change it. Implementing this
for other parsers will require updating output files to have spin
densities. I might do that for GAMESS and one more sometime in the
future, but I suppose the rest will be upon request.

- Karol

-- 
written by Karol M. Langner
Sat Oct  6 20:32:38 CEST 2012

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

On Oct 05 2012, Noel O'Boyle wrote:
> On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...> wrote:
> > Copying to cclib-dev instead of cclib-users...
> >
> >> So, Noel, Adam... what do you think? We can't have na attribute for
> >> every type of population analysis parsed. I see two options:
> >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
> >> 2) use a list of tuples consisting of a string and an array of charges
> >
> >
> > I agree that it's bad form to have to deal with all permutations of
> > attributes like mulliken_charges, loewdin_charges, etc, so it's best to have
> > just have charges and densities attributes.
> >
> > I think dictionaries are more elegant than a list of tuples. For example,
> > getting the Mulliken charges is simply charges["Mulliken"] instead of having
> > to iterate over the elements in a charges list looking for "Mulliken" in
> > tuple[0].
> 
> +1

I just implemented this in recent commits, for several parsers and
Mulliken/Lowdin charges where they are printed. In some cases (Molpro
and Jaguar) I could not find them and I think some flag in the input
would need to be turned on in order to print them. I don't think I will
update the data files and parsers for that unless somebody asks, though.

The attribute is called atomcharges and I added unit tests for their
length (should equal natom) and sum (should be zero for the unit tests).

As far as spin densities are concerned, this is also easily done --
should we call the corresponding attribute atomspins?

- Karol

-- 
written by Karol M. Langner
Sat Oct  6 12:22:16 CEST 2012

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...> wrote:
> Copying to cclib-dev instead of cclib-users...
>
>> So, Noel, Adam... what do you think? We can't have na attribute for
>> every type of population analysis parsed. I see two options:
>> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
>> 2) use a list of tuples consisting of a string and an array of charges
>
>
> I agree that it's bad form to have to deal with all permutations of
> attributes like mulliken_charges, loewdin_charges, etc, so it's best to have
> just have charges and densities attributes.
>
> I think dictionaries are more elegant than a list of tuples. For example,
> getting the Mulliken charges is simply charges["Mulliken"] instead of having
> to iterate over the elements in a charges list looking for "Mulliken" in
> tuple[0].

+1

> Adam
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

Copying to cclib-dev instead of cclib-users...

So, Noel, Adam... what do you think? We can't have na attribute for
> every type of population analysis parsed. I see two options:
> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
> 2) use a list of tuples consisting of a string and an array of charges
>

I agree that it's bad form to have to deal with all permutations of
attributes like mulliken_charges, loewdin_charges, etc, so it's best to
have just have charges and densities attributes.

I think dictionaries are more elegant than a list of tuples. For example,
getting the Mulliken charges is simply charges["Mulliken"] instead of
having to iterate over the elements in a charges list looking for
"Mulliken" in tuple[0].

Adam

Re: [cclib-devel] cclib bugfix

[Björn D. <bd...@kt...>]

Sorry, disregard last email. I managed to revert my changes from last time
making this a duplicate of the same bug I already reported.

/Björn

On Mon, Oct 1, 2012 at 1:51 PM, Björn Dahlgren <bd...@kt...> wrote:

> Hi again,
>
> I found another bug in cclib/parser/gaussianparser.py
>
> It is of the same kind as the previous one I reported a couple of weeks
> ago, and the solution is just as simple:
>
> adding a "hasattr" if-statment around line 350 solves the bug:
>
>         if self.coupledcluster and line[1:9] == "CCSD(T)=":
>
>             *if not hasattr(self, "ccenergy"):*
>                 self.ccenergy = self.float(line.split()[1])
>
> I attach the log-file that fails in cclib 1.0.1, you may make it
> publically available and include it in the test suite.
>
> Best regards,
> Björn Dahlgren
>
>
> On Mon, Sep 10, 2012 at 10:39 PM, Noel O'Boyle <bao...@gm...>wrote:
>
>> Hello Björn,
>>
>> I'm ccing this to the list.
>>
>> Thanks for the patch. Are you happy to place this logfile in the
>> public domain? If so, it means that we can add it to our test suite to
>> ensure that this problem does not recur.
>>
>> - Noel
>>
>> On 10 September 2012 14:21, Björn Dahlgren <bd...@kt...> wrote:
>> > Dear Noel O'Boyle,
>> >
>> > I guess this should go to the devel mailing list but I never figured
>> out how
>> > to deal with mailing lists so I send this directly to you. I hope it is
>> not
>> > a problem.
>> >
>> > There is a bug in cclib 1.0.1
>> >
>> > when parsing a gaussian log file with coincidently reoccuring CCSD(T)=
>> > statements ccenergies attribute is set twice. (affected gaussian log
>> file
>> > attached to this email)
>> >
>> > Changing line 353 in cclib/parser/gaussianparser.py to:
>> >
>> >             if not hasattr(self, 'ccenergy'):
>> >                 self.ccenergy = self.float(line.split()[1])
>> >
>> > fixes the bug
>> >
>> > All the best
>> > /Björn Dahlgren, KTH Royal Institute of Technology
>>
>
>

[cclib-devel] Fwd: cclib bugfix

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

(For the record...)


---------- Forwarded message ----------
From: Björn Dahlgren <bj...@gm...>
Date: 11 September 2012 06:13
Subject: Re: cclib bugfix
To: Noel O'Boyle <bao...@gm...>


Hi Noel,

Great, yes you may make it public and add it to the test suite.

Thanks
/Björn

Den 10 sep 2012 22:41 skrev "Noel O'Boyle" <bao...@gm...>:

> Hello Björn,
>
> I'm ccing this to the list.
>
> Thanks for the patch. Are you happy to place this logfile in the
> public domain? If so, it means that we can add it to our test suite to
> ensure that this problem does not recur.
>
> - Noel
>
> On 10 September 2012 14:21, Björn Dahlgren <bd...@kt...> wrote:
> > Dear Noel O'Boyle,
> >
> > I guess this should go to the devel mailing list but I never figured out how
> > to deal with mailing lists so I send this directly to you. I hope it is not
> > a problem.
> >
> > There is a bug in cclib 1.0.1
> >
> > when parsing a gaussian log file with coincidently reoccuring CCSD(T)=
> > statements ccenergies attribute is set twice. (affected gaussian log file
> > attached to this email)
> >
> > Changing line 353 in cclib/parser/gaussianparser.py to:
> >
> >             if not hasattr(self, 'ccenergy'):
> >                 self.ccenergy = self.float(line.split()[1])
> >
> > fixes the bug
> >
> > All the best
> > /Björn Dahlgren, KTH Royal Institute of Technology