cclib-devel — Developer's mailing list

[cclib-devel] ANN: cclib 0.8 beta now available for download

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

Dear cclib users,

The beta version of cclib 0.8 is now available for download from our
project page at:
http://sourceforge.net/project/showfiles.php?group_id=161285&package_id=181681&release_id=546598

The website is currently being updated for this release.

The changelog is as follows:

Features:
	* New parser: cclib can now parse Molpro files
	* Separation of parser and data objects: Parsed data is now returned
	as a ccData object that can be pickled, and converted to and from JSON
	* Parsers: multiple files can be parsed with one parse command
	* NumPy support: Dropped Numeric support in favour of NumPy
	* API addition: 'charge' for molecular charge
	* API addition: 'mult' for spin multiplicity
	* API addition: 'atombasis' for indices of atom orbitals on each atom
	* API addition: 'nocoeffs' for Natural Orbital (NO) coefficients
	* GAMESS-US parser: added 'etoscs' (CIS calculations)
	* Jaguar parser: added 'mpenergies' (LMP2 calcualtions)
	* Jaguar parser: added 'etenergies' and 'etoscs' (CIS calculations)
	* New method: Lowdin Population Analysis (LPA)
	* Tests: unittests can be run from the Python interpreter, and for
	a single parser; the number of "passed" tests is also counted and shown

Bugfixes:
	* Several parsing errors were fixed
	* Fixed some methods to work with different numbers of alpha and beta
	MO coefficients in mocoeffs (MPA, CSPA, OPA)

Regards,
    Noel on behalf of the cclib development team

Re: [cclib-devel] Jaguar data files

[Karol L. <kar...@kn...>]

On Friday 12 October 2007 03:07, you wrote:
> On 12/10/2007, Karol Langner <kar...@kn...> wrote:
> > Hi all,
> >
> >  It's been fairly quiet for some time now.
>
> I'm going to get out a release (beta?) of cclib 0.8 this weekend.
> Would appreciate any relevant updates to the Changelog...
I added as much as I could find after looking through the logs yesterday.

> > Let me start things up again with a
> > simple issue - why do we have three different basicJaguar* directories in
> > trunk/data/? It seems logical to use data files for unittests only from
> > the newest Jaguar version and to change the rest to regressions. That is
> > the situation for Gaussian and ADF (although here basicADF2004 is not the
> > newest version). Why should Jaguar be an exception?
>
> If a newer version of Gaussian comes out or if we have access to a
> newer version of ADF, Jaguar won't be the exception. I'm not sure what
> you mean by changing the unittests to regressions. If we support
> JaguarX, then we should have unittests to ensure this.
There are probably more people using Gaussian98 than there are using 
Jaguar4.2, so I don't see why we should only support older version of Jaguar 
and not Gaussian.

I was referring to data files rather than unittests, of course. What I mean 
be 'changing the unittests to regressions' is not distributing the older data 
files with cclib anymore and adding them to the family of regression tests.

I think it is sufficient and more efficient to have a good set of test log 
files only for the newest available version of all the programs, and to 
support all older versions with appropriate regression tests (works fine for 
Gaussian, GAMESS, ADF).

> The historical reason we have unittests for different versions of
> Jaguar is that my colleagues in Cambridge were using Jag4.2 (or so),
> Adam's colleagues were using 6.?, and finally we got the latest Jaguar
> 6.5 (which is now superseded by Jag 7.0 - maybe we should ask for
> this).
This is redundant, since then we will have as many basicJaguar* directories as 
there are Jaguar versions being used. Already, the Jaguar4.2 and Jaguar6.0 
tests are "behind" Jaguar6.5 since we don't have easy access to them. 

Notice also that the Jaguar6.0 data files take up alot more space than the 
Jaguar6.5 ones. I would prefer to see a complete set of log files for 
Jaguar6.5 and everything else put in directories that can be downloaded as 
regressions (so we can still check if they are parsed and pass the tests we 
want).

My two cents,
Karol

-- 
written by Karol Langner
Fri Oct 12 20:12:49 EDT 2007

Re: [cclib-devel] Jaguar data files

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

On 12/10/2007, Karol Langner <kar...@kn...> wrote:
> Hi all,
>
>  It's been fairly quiet for some time now.
I'm going to get out a release (beta?) of cclib 0.8 this weekend.
Would appreciate any relevant updates to the Changelog...

> Let me start things up again with a
> simple issue - why do we have three different basicJaguar* directories in
> trunk/data/? It seems logical to use data files for unittests only from the
> newest Jaguar version and to change the rest to regressions. That is the
> situation for Gaussian and ADF (although here basicADF2004 is not the newest
> version). Why should Jaguar be an exception?
If a newer version of Gaussian comes out or if we have access to a
newer version of ADF, Jaguar won't be the exception. I'm not sure what
you mean by changing the unittests to regressions. If we support
JaguarX, then we should have unittests to ensure this.

The historical reason we have unittests for different versions of
Jaguar is that my colleagues in Cambridge were using Jag4.2 (or so),
Adam's colleagues were using 6.?, and finally we got the latest Jaguar
6.5 (which is now superseded by Jag 7.0 - maybe we should ask for
this).

Regards,
   Noel (aka 'test nut')

> Cheers,
> Karol
>
> --
> written by Karol Langner
> Thu Oct 11 23:59:44 EDT 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Jaguar data files

[Karol L. <kar...@kn...>]

Hi all,

 It's been fairly quiet for some time now. Let me start things up again with a 
simple issue - why do we have three different basicJaguar* directories in 
trunk/data/? It seems logical to use data files for unittests only from the 
newest Jaguar version and to change the rest to regressions. That is the 
situation for Gaussian and ADF (although here basicADF2004 is not the newest 
version). Why should Jaguar be an exception?

Cheers,
Karol

-- 
written by Karol Langner
Thu Oct 11 23:59:44 EDT 2007

[cclib-devel] [ cclib-Feature Requests-1810294 ] better error handling in CDA module

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

Feature Requests item #1810294, was opened at 2007-10-09 10:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819225&aid=1810294&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: Open
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: better error handling in CDA module

Initial Comment:
Check to see if atomnos from fragments are the same as in the entire molecule before proceeding. If not, throw an appropriate error. 

Next, check for atomcoords (I think it does this already) and finally the number of basis functions. Exit sanely.

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

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

Re: [cclib-devel] Problem putting release together

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

On 22/09/2007, Karol Langner <kar...@kn...> wrote:
> On Friday 21 September 2007 07:31, Noel O'Boyle wrote:
> > On 21/09/2007, Noel O'Boyle <bao...@gm...> wrote:
> > > Karol,
> > >
> > > I'm getting bogged down in the changes you made to setup.py in r643. I
> > > didn't realise (from the log message at the time) that you had done
> > > this, and I'm not sure what the purpose of these changes are.
> The purpose was to simplify creating new source distributions, by not having
> to run manifest.py every time. According to the Pythons docs, MANIFEST.in s
> supposed to be platform-independent.

I think the MANIFEST.in is probably fine (although I'm not sure :-/).
The problem is that there were several changes around that time and I
couldn't figure out which was causing the specific problem. For
example, when I removed all references to the data directory from
MANIFEST.in, it still copied the data directory into the installation
(and I tried deleting all temporary directories and so on). Once we've
done the release, I'd like to spend a little time on this going
through step by step, and discussing the results with you guys. It's
not very interesting, of course.

> > > You
> > > appear to have hardcoded the location of site-package on the user's
> > > system, for example. This is just asking for trouble...
> True. I generalized this in r682 (in the spirit of NumPy, if I remember
> correctly), although I'm not certain that it is now entirely OK.
>
> > > I'm trying to track down the problems with the files included in the
> > > distribution (when I create it on Windows). Currently, even the .svn
> > > directories in the data dir are being included. This encourages me to
> > > go back to using manifest.py, rather than MANIFEST.in...
> >
> > This issue is resolved now. I just needed to clean out the temporary
> > directories from the build, and there are no problems. Maybe it's all
> > okay now...I'll try and see can I make another release....
> Please keep us informed on the list on how things are behaving on Windows. I
> test cclib on a daily basis only under Linux, so some things are bound to
> escape my attention. This is a marginal issue in terms of functonality, so it
> doesn't really matter which revision goes into 0.8b, as long as it works.

It was only when I concentrated on making a distribution that I
realised that there were problems. The "setup.py install" has been
working fine.

> > > I'd like to get out a beta release as soon as possible...
> I've been travelling alot in the past 2-3 weeks and been quite busy at work.
> In the nearest week(s) I will have the time to help out with any problems
> with the release.
>
> Cheers,
> Karol
>
> --
> written by Karol Langner
> Sat Sep 22 01:10:51 EDT 2007
>

Re: [cclib-devel] Problem putting release together

[Karol L. <kar...@kn...>]

On Friday 21 September 2007 07:31, Noel O'Boyle wrote:
> On 21/09/2007, Noel O'Boyle <bao...@gm...> wrote:
> > Karol,
> >
> > I'm getting bogged down in the changes you made to setup.py in r643. I
> > didn't realise (from the log message at the time) that you had done
> > this, and I'm not sure what the purpose of these changes are.
The purpose was to simplify creating new source distributions, by not having 
to run manifest.py every time. According to the Pythons docs, MANIFEST.in s 
supposed to be platform-independent.

> > You 
> > appear to have hardcoded the location of site-package on the user's
> > system, for example. This is just asking for trouble...
True. I generalized this in r682 (in the spirit of NumPy, if I remember 
correctly), although I'm not certain that it is now entirely OK.

> > I'm trying to track down the problems with the files included in the
> > distribution (when I create it on Windows). Currently, even the .svn
> > directories in the data dir are being included. This encourages me to
> > go back to using manifest.py, rather than MANIFEST.in...
>
> This issue is resolved now. I just needed to clean out the temporary
> directories from the build, and there are no problems. Maybe it's all
> okay now...I'll try and see can I make another release....
Please keep us informed on the list on how things are behaving on Windows. I 
test cclib on a daily basis only under Linux, so some things are bound to 
escape my attention. This is a marginal issue in terms of functonality, so it 
doesn't really matter which revision goes into 0.8b, as long as it works.

> > I'd like to get out a beta release as soon as possible...
I've been travelling alot in the past 2-3 weeks and been quite busy at work. 
In the nearest week(s) I will have the time to help out with any problems 
with the release.

Cheers,
Karol

-- 
written by Karol Langner
Sat Sep 22 01:10:51 EDT 2007

[cclib-devel] cclib 0.8 release branch

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

I'd appreciate if you could update the Changelog on the trunk with any
memorable events since the last release. I've decided not to be anal
about listing bug fixes this time, but it would be good if we could
remember all the new features.

Noel

Re: [cclib-devel] Problem putting release together

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

On 21/09/2007, Noel O'Boyle <bao...@gm...> wrote:
> Karol,
>
> I'm getting bogged down in the changes you made to setup.py in r643. I
> didn't realise (from the log message at the time) that you had done
> this, and I'm not sure what the purpose of these changes are. You
> appear to have hardcoded the location of site-package on the user's
> system, for example. This is just asking for trouble...
>
> I'm trying to track down the problems with the files included in the
> distribution (when I create it on Windows). Currently, even the .svn
> directories in the data dir are being included. This encourages me to
> go back to using manifest.py, rather than MANIFEST.in...

This issue is resolved now. I just needed to clean out the temporary
directories from the build, and there are no problems. Maybe it's all
okay now...I'll try and see can I make another release....

> I'd like to get out a beta release as soon as possible...
>
> Noel
>

[cclib-devel] Problem putting release together

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

Karol,

I'm getting bogged down in the changes you made to setup.py in r643. I
didn't realise (from the log message at the time) that you had done
this, and I'm not sure what the purpose of these changes are. You
appear to have hardcoded the location of site-package on the user's
system, for example. This is just asking for trouble...

I'm trying to track down the problems with the files included in the
distribution (when I create it on Windows). Currently, even the .svn
directories in the data dir are being included. This encourages me to
go back to using manifest.py, rather than MANIFEST.in...

I'd like to get out a beta release as soon as possible...

Noel

Re: [cclib-devel] cleanup of tests

[Adam T. <a-t...@st...>]

> Also, a few tests still fail for ADF -  I fixed some but some new  
> ones fail
> after I copied them from testGeoOpt. Most notably, testscfenergies  
> fails for
> testSP, which should NOT be happening!!!

Weird. I didn't notice any of my recent ADF commits affecting this,  
although it was dying on Jaguar tests. I also don't see it going into  
the new code I added since it's not logging warning messages for the  
basicADF tests. Reverting to revision 745 (before my commits) doesn't  
fix the problem either.

Adam

Re: [cclib-devel] cleanup of tests

[Karol L. <kar...@kn...>]

On Tuesday 04 September 2007 11:34, Noel O'Boyle wrote:
> On the other hand, I have no problem with adding more tests, so if you
> want to copy tests from testGeoOpt to testSP, that sounds good to me.

A follow up on this... the only test methods that SP and GeoOpt don't have in 
common is the two for overlaps (testaooverlaps and testdimaooverlaps).

You could consider taking testdimmocoeffs out of GeoOpt.py, since a number of 
the GeoOpt test files currently don't have mocoeffs (Jaguar, Gaussian) or 
only the first few virtuals (Jaguar, GAMESS-UK). On the other hand, often 
atombasis comes along with mocoeffs output.

Also, a few tests still fail for ADF -  I fixed some but some new ones fail 
after I copied them from testGeoOpt. Most notably, testscfenergies fails for 
testSP, which should NOT be happening!!!

-- 
written by Karol Langner
Wed Sep  5 23:04:48 EDT 2007

Re: [cclib-devel] ADF output error again

[Adam T. <a-t...@st...>]

> I agree that this is probably the right thing to do, it's just
> harder. ;-) And I still think we need to write unittests that make
> sure it doesn't break the "normal" cases without us knowing for sure.
> I'll try to get to it this afternoon, but as we all know, research
> takes priority...

I've just committed a change that fixes the CF bug. It basically  
stores the starting index of non-CF functions (ie. the SFOs) for each  
symmetry. When parsing the mocoeffs, it makes sure the SFO index is  
greater than or equal to this starting index. The regression tests  
still parse, and it *shouldn't* screw up the values of mocoeffs for  
these tests, but I haven't looked into it.

> There is currently a file in the ADF2004.01 directory called Au2-
> fixed.adfout.gz which doesn't print the CF coeffs. It's a different
> version of ADF (2004 vs 2006), but as near as I can tell, everything
> is the same.

I looked at these files a bit closer and it turns out that they have  
a different number of basis functions. I'll try to get comparable  
calculations up in the next day or so.

Adam

[cclib-devel] Fwd: CCL: Amsterdam Density Functional software, version ADF2007 released

[Karol L. <kar...@kn...>]

Just in case someone didn't get in on CCL - Karol

----------  Forwarded Message  ----------
Subject: CCL: Amsterdam Density Functional software, version ADF2007 released
Date: Monday 03 September 2007 09:09
From: "Stan van Gisbergen vangisbergen~~scm.com" <own...@cc...>

Sent to CCL by: Stan van Gisbergen [vangisbergen]_[scm.com]
Dear CCL subscribers,

The Amsterdam Density Functional package (ADF) is a premium quality
software package for quantum chemistry and materials science research
using Density Functional Theory (DFT). ADF offers various
spectroscopic properties and environment models for almost any
molecule, and excels at transition metal and heavy element compounds.

Scientific Computing & Modelling (SCM) has now released version
ADF2007 (http://www.scm.com/News/NewinADF2007.pdf).
* For periodic structures (BAND program): Geometry optimizations and
Time-Dependent DFT enhancements
* GUI enhancements: remote job control, export movies, more
visualization options, surface builder
* Improved geometry optimization, transition state search, and SCF
convergence
* Vibrational Circular Dichroism spectra
* MO6 xc energy functionals
* Parallel Windows desktop version
* Spin-orbit coupled gradients
* Check the release notes for other enhancements: http://www.scm.com/
Doc/Doc2007.01/Background/Updates/page1.html

Download a free 30-day trial: http://www.scm.com/SCMForms/
TrialRequest.jsp or contact us for further information.

Best regards, Stan van Gisbergen, on behalf of the SCM team.
http://www.scm.com                     E-mail: info|-|scm.com

-- 
written by Karol Langner
Tue Sep  4 21:16:03 EDT 2007

Re: [cclib-devel] ADF output error again

[Karol L. <kar...@kn...>]

On Tuesday 04 September 2007 12:16, Adam Tenderholt wrote:
> >> 2) Modify the parser to ignore the CF coeffs. I believe this could be
> >> done by keeping the starting index of the orbitals. This information
> >> is present when we parse fonames. I'm hesitant to do this because we
> >> should first make the ADF unittests more robust, either by checking
> >> the validity of a number of mocoeffs or by making sure the MPA is
> >> reasonable, since it's could potentially be a pretty drastic change.
> >
> > Well - this is probably the right thing to do to be honest. If you did
> > a calculation with and without the CF coeffs, the results should be
> > identical, right? So all we need is a stand-alone unit test which
> > reads two output files, one with, and one without, this option, and
> > compares all of the attributes. If you can create the additional
> > "without this option" output file, I'll write the unittest and
> > incorporate it into our framework.
>
> I agree that this is probably the right thing to do, it's just
> harder. ;-) And I still think we need to write unittests that make
> sure it doesn't break the "normal" cases without us knowing for sure.
> I'll try to get to it this afternoon, but as we all know, research
> takes priority...

My two cents... even though the situation is esoteric, I also agree that this 
is the right choice. In March I started using ADF and got interested, but the 
project I needed it for died so finally I didn't get around to solving the 
problem. If no one finds the time/energy to make it happen before the 
release, be sure to file it with the bug or feature tracker for later.

-- 
written by Karol Langner
Tue Sep  4 21:08:12 EDT 2007

Re: [cclib-devel] cleanup of tests

[Karol L. <kar...@kn...>]

On Tuesday 04 September 2007 11:34, Noel O'Boyle wrote:
> On 04/09/07, Karol Langner <kar...@kn...> wrote:
> > I think it is a good idea to also clean up the unittests a bit before
> > releasing 0.8. In the interest of this, I added a "SKIPPED" column in the
> > test summary and the appropriate code for monitoring this (currently
> > based on PASS being in the docstring). This way it easier to see where we
> > are skipping unittests. Also, in my last commit I merged testmodule into
> > testall as Noel suggested (although the name 'testall' does not reflect
> > its function anymore!).
> >
> > Other issues that you might want to comment on:
> > 1) there should be more coverage of unittests for methods(?)
> > 2) should unittests for parsers and methods be either better integrated
> > (possibly run through the same function) or better separated (in separate
> > directories)? Presently, testall.py runs only parser unittests, so
> > shouldn't it be renamed to testparsers.py?
> > 3) I noticed that there are a number of tests in GeoOpt that can be done
> > for SP, so should they be only in SP or in both?
>
> All of these ideas are good and should be done, but I don't know about
> doing them right now - perhaps you could do them on a branch (or maybe
> it's time for cclib-0.8 to branch off)?. For example, rename
> testall.py to testparsers.py; create a directory parsertests and put
> testGeoOpt.py etc into these; make it possible to run testparsers.py
> with "GAMESSUK SP" to just test GAMESSUK SP, or SP everything, or
> GAMESSUK everything (then we can remove the code for running the test
> from testSP.py, etc.).
I'll be more than happy to do all that since it'll clarify the tests, but I'll 
wait until after the release. It probably won't be as simple as adding a few 
lines like the commit I made yesterday. Still, I wanted to mention the things 
here, since I would otherwise forget about them soon.

> On the other hand, I have no problem with adding more tests, so if you
> want to copy tests from testGeoOpt to testSP, that sounds good to me.
That I will do - no harm in having more tests...

-- 
written by Karol Langner
Tue Sep  4 21:00:57 EDT 2007

Re: [cclib-devel] ADF failures (was Re: cclib 0.8 lock down)

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

On 04/09/07, Adam Tenderholt <a-t...@st...> wrote:
> >> When "INPUT FILE" is found, it checks for scftargets as I figure all
> >> calculations, finished or not, should have scftargets set. If so, it
> >> logs a warning and skips to the end of the file. Sound reasonable?
> >
> > Maybe you should raise an Exception? I think our policy should be to
> > not handle these files at all, and let the user know this. Otherwise,
> > it will pass silently (except for the warning) through cclib...what do
> > you think?
>
> Won't this just cause the parser to fail?
>
> I think we should have it
> exit "sanely" by printing a warning/error message and skipping to the
> end of the file. cclib's default loglevel is INFO, so this
> information will be printed, and the results of the first calculation
> will still be available.

Maybe I was a little hasty...I guess you're right.

> Adam
>
>

Re: [cclib-devel] ADF output error again

[Adam T. <a-t...@st...>]

>> 2) Modify the parser to ignore the CF coeffs. I believe this could be
>> done by keeping the starting index of the orbitals. This information
>> is present when we parse fonames. I'm hesitant to do this because we
>> should first make the ADF unittests more robust, either by checking
>> the validity of a number of mocoeffs or by making sure the MPA is
>> reasonable, since it's could potentially be a pretty drastic change.
>
> Well - this is probably the right thing to do to be honest. If you did
> a calculation with and without the CF coeffs, the results should be
> identical, right? So all we need is a stand-alone unit test which
> reads two output files, one with, and one without, this option, and
> compares all of the attributes. If you can create the additional
> "without this option" output file, I'll write the unittest and
> incorporate it into our framework.

I agree that this is probably the right thing to do, it's just  
harder. ;-) And I still think we need to write unittests that make  
sure it doesn't break the "normal" cases without us knowing for sure.  
I'll try to get to it this afternoon, but as we all know, research  
takes priority...

There is currently a file in the ADF2004.01 directory called Au2- 
fixed.adfout.gz which doesn't print the CF coeffs. It's a different  
version of ADF (2004 vs 2006), but as near as I can tell, everything  
is the same.

Adam

Re: [cclib-devel] ADF failures (was Re: cclib 0.8 lock down)

[Adam T. <a-t...@st...>]

>> When "INPUT FILE" is found, it checks for scftargets as I figure all
>> calculations, finished or not, should have scftargets set. If so, it
>> logs a warning and skips to the end of the file. Sound reasonable?
>
> Maybe you should raise an Exception? I think our policy should be to
> not handle these files at all, and let the user know this. Otherwise,
> it will pass silently (except for the warning) through cclib...what do
> you think?

Won't this just cause the parser to fail? I think we should have it  
exit "sanely" by printing a warning/error message and skipping to the  
end of the file. cclib's default loglevel is INFO, so this  
information will be printed, and the results of the first calculation  
will still be available.

Adam

Re: [cclib-devel] ADF output error again

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

On 04/09/07, Adam Tenderholt <a-t...@st...> wrote:
> To summarize, the error arises because it prints the core function
> (CF) coefficients in the mocoeffs matrix. I have no idea why you'd
> ever turn on this print option since they don't have any physical
> meaning. As near as I can tell, we have two options:
>
> 1) Catch the IndexError and log which orbital is "broken", while
> allowing the parser to finish. This would just call into question the
> values of mocoeffs; the rest of the parser/ccData attributes *should*
> be fine. Obviously this is a less than perfect solution, but it is
> also the easiest option. We would simply not handle this extra info
> and would put something on the wiki saying which option(s) should NOT
> be used.

This is equivalent to saying we don't handle log files with this
option. I've no problem with this in principle as we need to draw the
line somewhere. The downside is that this error might arise
legitimately for some other type of logfile we have not yet seen, and
could flag a bug in cclib.

> 2) Modify the parser to ignore the CF coeffs. I believe this could be
> done by keeping the starting index of the orbitals. This information
> is present when we parse fonames. I'm hesitant to do this because we
> should first make the ADF unittests more robust, either by checking
> the validity of a number of mocoeffs or by making sure the MPA is
> reasonable, since it's could potentially be a pretty drastic change.

Well - this is probably the right thing to do to be honest. If you did
a calculation with and without the CF coeffs, the results should be
identical, right? So all we need is a stand-alone unit test which
reads two output files, one with, and one without, this option, and
compares all of the attributes. If you can create the additional
"without this option" output file, I'll write the unittest and
incorporate it into our framework.

> What do y'all think? I should point out that I've already coded
> option 1 for debugging, but it prints several error messages during
> regression.py so it might need some modification.
>
> Adam
>
> On Sep 3, 2007, at 11:51 AM, Noel O'Boyle wrote:
>
> > This is the thread about Au2.out that died out in March of this year.
> > Karol seemed to have the last word, but I'm not sure what he is
> > referring to. The parsing error is:
> >
> >   File "c:\program files\python25\lib\site-packages\cclib-0.7-
> > py2.5.egg\cclib\pa
> > rser\adfparser.py", line 702, in extract
> >     self.mocoeffs[spin][moindices[i],aoindex] = coeffs[i]
> > IndexError: index (108) out of range (0<=index<108) in dimension 1
> >
> > Noel
> >
> > On 28/03/07, Karol Langner <kar...@kn...> wrote:
> >> On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote:
> >>> I've uploaded a new Au2 logfile to the website, but I couldn't
> >>> put it
> >>> in the ADF2006.01 directory because I didn't have permissions (Noel,
> >>> can you take care of this and regressionfiles.txt). I removed the
> >>> keyword that prints the CF moceoffs and it now finishes correctly. A
> >>> Mulliken analysis using PyMOlyze gives approximately the same LUMO
> >>> composition as is printed in the logfile (there are always slight
> >>> differences since ADF doesn't print every contribution), so
> >>> everything should be ok.
> >>
> >> So the question is how we should handle the core functions - just
> >> skip them?
> >>
> >> --
> >> written by Karol Langner
> >> Wed Mar 28 11:12:09 CEST 2007
> >>
> >> ---------------------------------------------------------------------
> >> ----
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to
> >> share your
> >> opinions on IT & business topics through brief surveys-and earn cash
> >> http://www.techsay.com/default.php?
> >> page=join.php&p=sourceforge&CID=DEVDEV
> >> _______________________________________________
> >> cclib-devel mailing list
> >> ccl...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >>
> >
> > ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] ADF failures (was Re: cclib 0.8 lock down)

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

On 03/09/07, Adam Tenderholt <a-t...@st...> wrote:
> I've made a couple of changes to fix the Frags_NiCO4 errors
>
> >> We can try to fix the first issue by looking for "Create" or "create"
> >> in the next couple of lines after an INPUT FILE statement.
> >
> > Sounds fine.
>
> If there is a blank line after an INPUT FILE statement, it looks at
> the following line. It now checks for "create" in addition to "Create".
>
> >> I think the second issue should be addressed either by trying to
> >> catch the KeyError or looking for multiple jobs. Either way, we need
> >> to warn the user about the "problem" with their file. Comments?
> >
> > I don't think we should try to handle multiple jobs. All of our
> > scripts assume one job per file, and it's quite easy for the user to
> > ensure that the input is like this. I say log an error, and return
> > None.
>
> When "INPUT FILE" is found, it checks for scftargets as I figure all
> calculations, finished or not, should have scftargets set. If so, it
> logs a warning and skips to the end of the file. Sound reasonable?

Maybe you should raise an Exception? I think our policy should be to
not handle these files at all, and let the user know this. Otherwise,
it will pass silently (except for the warning) through cclib...what do
you think?

> Adam
>
>

Re: [cclib-devel] cleanup of tests

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

On 04/09/07, Karol Langner <kar...@kn...> wrote:
> I think it is a good idea to also clean up the unittests a bit before
> releasing 0.8. In the interest of this, I added a "SKIPPED" column in the
> test summary and the appropriate code for monitoring this (currently based on
> PASS being in the docstring). This way it easier to see where we are skipping
> unittests. Also, in my last commit I merged testmodule into testall as Noel
> suggested (although the name 'testall' does not reflect its function
> anymore!).
>
> Other issues that you might want to comment on:
> 1) there should be more coverage of unittests for methods(?)
> 2) should unittests for parsers and methods be either better integrated
> (possibly run through the same function) or better separated (in separate
> directories)? Presently, testall.py runs only parser unittests, so shouldn't
> it be renamed to testparsers.py?
> 3) I noticed that there are a number of tests in GeoOpt that can be done for
> SP, so should they be only in SP or in both?

All of these ideas are good and should be done, but I don't know about
doing them right now - perhaps you could do them on a branch (or maybe
it's time for cclib-0.8 to branch off)?. For example, rename
testall.py to testparsers.py; create a directory parsertests and put
testGeoOpt.py etc into these; make it possible to run testparsers.py
with "GAMESSUK SP" to just test GAMESSUK SP, or SP everything, or
GAMESSUK everything (then we can remove the code for running the test
from testSP.py, etc.).

On the other hand, I have no problem with adding more tests, so if you
want to copy tests from testGeoOpt to testSP, that sounds good to me.

> Cheers,
> Karol
>
> --
> written by Karol Langner
> Tue Sep  4 01:02:43 EDT 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] ADF output error again

[Adam T. <a-t...@st...>]

To summarize, the error arises because it prints the core function  
(CF) coefficients in the mocoeffs matrix. I have no idea why you'd  
ever turn on this print option since they don't have any physical  
meaning. As near as I can tell, we have two options:

1) Catch the IndexError and log which orbital is "broken", while  
allowing the parser to finish. This would just call into question the  
values of mocoeffs; the rest of the parser/ccData attributes *should*  
be fine. Obviously this is a less than perfect solution, but it is  
also the easiest option. We would simply not handle this extra info  
and would put something on the wiki saying which option(s) should NOT  
be used.

2) Modify the parser to ignore the CF coeffs. I believe this could be  
done by keeping the starting index of the orbitals. This information  
is present when we parse fonames. I'm hesitant to do this because we  
should first make the ADF unittests more robust, either by checking  
the validity of a number of mocoeffs or by making sure the MPA is  
reasonable, since it's could potentially be a pretty drastic change.

What do y'all think? I should point out that I've already coded  
option 1 for debugging, but it prints several error messages during  
regression.py so it might need some modification.

Adam

On Sep 3, 2007, at 11:51 AM, Noel O'Boyle wrote:

> This is the thread about Au2.out that died out in March of this year.
> Karol seemed to have the last word, but I'm not sure what he is
> referring to. The parsing error is:
>
>   File "c:\program files\python25\lib\site-packages\cclib-0.7- 
> py2.5.egg\cclib\pa
> rser\adfparser.py", line 702, in extract
>     self.mocoeffs[spin][moindices[i],aoindex] = coeffs[i]
> IndexError: index (108) out of range (0<=index<108) in dimension 1
>
> Noel
>
> On 28/03/07, Karol Langner <kar...@kn...> wrote:
>> On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote:
>>> I've uploaded a new Au2 logfile to the website, but I couldn't  
>>> put it
>>> in the ADF2006.01 directory because I didn't have permissions (Noel,
>>> can you take care of this and regressionfiles.txt). I removed the
>>> keyword that prints the CF moceoffs and it now finishes correctly. A
>>> Mulliken analysis using PyMOlyze gives approximately the same LUMO
>>> composition as is printed in the logfile (there are always slight
>>> differences since ADF doesn't print every contribution), so
>>> everything should be ok.
>>
>> So the question is how we should handle the core functions - just  
>> skip them?
>>
>> --
>> written by Karol Langner
>> Wed Mar 28 11:12:09 CEST 2007
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

[cclib-devel] cleanup of tests

[Karol L. <kar...@kn...>]

I think it is a good idea to also clean up the unittests a bit before 
releasing 0.8. In the interest of this, I added a "SKIPPED" column in the 
test summary and the appropriate code for monitoring this (currently based on 
PASS being in the docstring). This way it easier to see where we are skipping 
unittests. Also, in my last commit I merged testmodule into testall as Noel 
suggested (although the name 'testall' does not reflect its function 
anymore!).

Other issues that you might want to comment on:
1) there should be more coverage of unittests for methods(?)
2) should unittests for parsers and methods be either better integrated 
(possibly run through the same function) or better separated (in separate 
directories)? Presently, testall.py runs only parser unittests, so shouldn't 
it be renamed to testparsers.py?
3) I noticed that there are a number of tests in GeoOpt that can be done for 
SP, so should they be only in SP or in both?

Cheers,
Karol

-- 
written by Karol Langner
Tue Sep  4 01:02:43 EDT 2007

Re: [cclib-devel] What remains to be done

[Karol L. <kar...@kn...>]

OK, I changed it to a warning.

On Monday 03 September 2007 05:53, Noel O'Boyle wrote:
> I understand error to mean an error in cclib. "Not a correct
> calculation" sounds like a problem with the log file, and should be a
> warning.
>
> On 03/09/07, Karol Langner <kar...@kn...> wrote:
> > On Monday 03 September 2007 02:56, Noel O'Boyle wrote:
> > > There's a Molpro regression failure for C_bigbasis_cart or something.
> >
> > I moved that from the data directory, becuase it was duplicating
> > C_bigbasis, and it is not a correct calculation (augmented basis set in
> > cartesian representation) which is why it has bogus output (stars in the
> > mocoeffs because the cofficients are too large).
> >
> > I added an excpetion for this in the Molpro parser, which calls
> > logger.error() with a message so that the parser doesn't crash. Now I see
> > this gives alot of output when running the regressions, becuase the
> > loglevel is set to ERROR. Should the loglevel be set lower, or should I
> > issue a warning instead of an error to the logger in this case?
> >
> > Karol
> >
> > --
> > written by Karol Langner
> > Mon Sep  3 11:31:38 EDT 2007

-- 
written by Karol Langner
Tue Sep  4 01:03:28 EDT 2007