cclib-devel — Developer's mailing list

Re: [cclib-devel] Jaguar parser errors

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

On Wednesday 21 of February 2007 21:15, Noel O'Boyle wrote:
> Just to be clear, there's no problem handling these files - it's just
> that the tests were written for files containing all of the orbitals,
> and need to be specialised for those with less than that
> number...which is what I've now done.

Yes, good call.

-- 
written by Karol Langner
Thu Feb 22 11:46:54 CET 2007

[cclib-devel] Fwd: Things to do before release

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

I sent this to the wrong dev list first time :-)

---------- Forwarded message ----------
From: Noel O'Boyle <bao...@gm...>
Date: 21-Feb-2007 20:21
Subject: Things to do before release
To: openbabel-devel <ope...@li...>


We are currently in the happy position of having all tests pass, which
hasn't happened for quite some time.

What remains to do before release:
(1) Documentation (volume.py...Noel)
(2) Jaguar mpenergies for water at MP2/3/4/5...no need for all the
orbitals and overlap matrices
(3) coreelectron tests and parsing (may need test files)
(4) Change testcda.py into unittest format

Anything else?

Noel

Re: [cclib-devel] Jaguar parser errors

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

Just to be clear, there's no problem handling these files - it's just
that the tests were written for files containing all of the orbitals,
and need to be specialised for those with less than that
number...which is what I've now done.

On 21/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > The last one, the test for moenergies for Jaguar 6.5, was failing
> > becuase not
> > all the virtual orbitals are printed for dvb_sp_un. In order to
> > print all of
> > them, "ipvirt=-1" needs to be in the input file (as in the input
> > files for
> > the other Jaguar versions).
>
> I think we should try to handle the cases when not all of the virtual
> orbitals are printed. Most population analyses can be done on
> individual MOs, and for a large system, it's not always practical to
> print information about every virtual orbital. (Plus my Jaguar-using
> labmates claim that on big systems the job will crash because it's
> trying to write a swap file larger than 2 GB.)
>
> Adam
>
>
> -------------------------------------------------------------------------
> 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
>

Re: [cclib-devel] Jaguar parser errors

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

On 21/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > The last one, the test for moenergies for Jaguar 6.5, was failing
> > becuase not
> > all the virtual orbitals are printed for dvb_sp_un. In order to
> > print all of
> > them, "ipvirt=-1" needs to be in the input file (as in the input
> > files for
> > the other Jaguar versions).
>
> I think we should try to handle the cases when not all of the virtual
> orbitals are printed. Most population analyses can be done on
> individual MOs, and for a large system, it's not always practical to
> print information about every virtual orbital. (Plus my Jaguar-using
> labmates claim that on big systems the job will crash because it's
> trying to write a swap file larger than 2 GB.)

The other tests weren't possible to pass since the files did not
contain the necessary attributes to test against. I've changed this
one so that it tests against the contents of the input file. That is,
it verifies that there are alpha moenergies for homos[0]+11 orbitals,
and beta moenergies for homos[1]+11 orbitals. Bearing in mind that
homos does *not* contain the number of occupied orbitals, but rather
is a lookup index, this means that there is information on 10 virtual
orbitals, which is in agreement (I hope) with what we expect.

Re: [cclib-devel] Jaguar parser errors

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

> The last one, the test for moenergies for Jaguar 6.5, was failing  
> becuase not
> all the virtual orbitals are printed for dvb_sp_un. In order to  
> print all of
> them, "ipvirt=-1" needs to be in the input file (as in the input  
> files for
> the other Jaguar versions).

I think we should try to handle the cases when not all of the virtual  
orbitals are printed. Most population analyses can be done on   
individual MOs, and for a large system, it's not always practical to  
print information about every virtual orbital. (Plus my Jaguar-using  
labmates claim that on big systems the job will crash because it's  
trying to write a swap file larger than 2 GB.)

Adam

Re: [cclib-devel] Jaguar parser errors

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

OK, I added explicit passes to the Jaguar tests that were not working. Turns 
out all of them were due to the test files being incomplete. I wrote about 
them in previous mails.

The last one, the test for moenergies for Jaguar 6.5, was failing becuase not 
all the virtual orbitals are printed for dvb_sp_un. In order to print all of 
them, "ipvirt=-1" needs to be in the input file (as in the input files for 
the other Jaguar versions).

Karol

-- 
written by Karol Langner
Wed Feb 21 13:03:36 CET 2007

Re: [cclib-devel] Jaguar parser errors

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

For the record, here's one possibility using decorators:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288

Another is moving to 'nose'. Which might make things easier all round,
although I don't know if it will help with this particular problem...
    http://somethingaboutorange.com/mrl/projects/nose/

Noel

On 21/02/07, Noel O'Boyle <bao...@gm...> wrote:
> Agreed, we'll do something about this. But it might be after the release.
>
> On 21/02/07, Karol Langner <kar...@kn...> wrote:
> > On Wednesday 21 of February 2007 11:10, Noel O'Boyle wrote:
> > > The thing is, if we implicitly pass them, future generations of cclib
> > > developers may not be sure whether we just forgot to test it.
> >
> > Conversely, if someone sees that a test is passed in the print-out  (as it is
> > now with mocoeffs for Jaguar 4.2/6.5), they will assume that the test is
> > actually done and passes - that's what happened in my case. It took me some
> > time to figure out that the test method was explicitly overriden. So i would
> > opt for either eliminating these tests and not printing anything about them
> > (becuase, in fact, they are not done), or clearly noting in the test output
> > that the particular test is NOT done and explcitly passed.
> >
> > I think it is important to make the print-out very clear and not leaving any
> > doubts about which tests are really done, but maybe that is something for
> > after the upcoming release.
> >
> > --
> > written by Karol Langner
> > Wed Feb 21 11:45:28 CET 2007
> >
>

Re: [cclib-devel] Jaguar parser errors

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

Agreed, we'll do something about this. But it might be after the release.

On 21/02/07, Karol Langner <kar...@kn...> wrote:
> On Wednesday 21 of February 2007 11:10, Noel O'Boyle wrote:
> > The thing is, if we implicitly pass them, future generations of cclib
> > developers may not be sure whether we just forgot to test it.
>
> Conversely, if someone sees that a test is passed in the print-out  (as it is
> now with mocoeffs for Jaguar 4.2/6.5), they will assume that the test is
> actually done and passes - that's what happened in my case. It took me some
> time to figure out that the test method was explicitly overriden. So i would
> opt for either eliminating these tests and not printing anything about them
> (becuase, in fact, they are not done), or clearly noting in the test output
> that the particular test is NOT done and explcitly passed.
>
> I think it is important to make the print-out very clear and not leaving any
> doubts about which tests are really done, but maybe that is something for
> after the upcoming release.
>
> --
> written by Karol Langner
> Wed Feb 21 11:45:28 CET 2007
>

Re: [cclib-devel] Jaguar parser errors

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

On Wednesday 21 of February 2007 11:10, Noel O'Boyle wrote:
> The thing is, if we implicitly pass them, future generations of cclib
> developers may not be sure whether we just forgot to test it.

Conversely, if someone sees that a test is passed in the print-out  (as it is 
now with mocoeffs for Jaguar 4.2/6.5), they will assume that the test is 
actually done and passes - that's what happened in my case. It took me some 
time to figure out that the test method was explicitly overriden. So i would 
opt for either eliminating these tests and not printing anything about them 
(becuase, in fact, they are not done), or clearly noting in the test output 
that the particular test is NOT done and explcitly passed.

I think it is important to make the print-out very clear and not leaving any 
doubts about which tests are really done, but maybe that is something for 
after the upcoming release.

-- 
written by Karol Langner
Wed Feb 21 11:45:28 CET 2007

Re: [cclib-devel] Jaguar parser errors

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

That is convincing, it is better to do these things explicitly, as long as it 
is done the same way everywhere.

Karol

On Wednesday 21 of February 2007 11:10, Noel O'Boyle wrote:
> Well, there are two choices:
> (1) to override the test function with something like:
> testmocoeffs = None
> (hopefully this would override the function testmocoeffs)
>
> This amounts to implicitly passing these tests.
>
> or
>
> (2) To do as we are currently doing, and explicitly Pass these tests.
>
> I think that explicit is better than implicit, otherwise we *think*
> that we can handle Jaguar 4.2 mocoeffs, but this is not necessarily
> true. We can perhaps make this even more explicit, by using something
> like self.markUntested, or somehow analysing the docstring to identify
> that this is an untested test.
>
> The thing is, if we implicitly pass them, future generations of cclib
> developers may not be sure whether we just forgot to test it.
>
> What do you think?
>
> Noel
>
> On 21/02/07, Karol Langner <kar...@kn...> wrote:
> > On Wednesday 21 of February 2007 10:20, Noel O'Boyle wrote:
> > > Any missing log files can only be created for the version that Adam
> > > has access to, so we will need to add PASSes for everything else that
> > > we are unable to test. AFAIK, the only differences between any of
> > > these output files is in the vibrational frequency section, where Jag
> > > 4.2 is different.
> >
> > So why have all the tests done for all versions?
> >
> > --
> > written by Karol Langner
> > Wed Feb 21 10:52:42 CET 2007

-- 
written by Karol Langner
Wed Feb 21 11:36:48 CET 2007

Re: [cclib-devel] Jaguar parser errors

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

Well, there are two choices:
(1) to override the test function with something like:
testmocoeffs = None
(hopefully this would override the function testmocoeffs)

This amounts to implicitly passing these tests.

or

(2) To do as we are currently doing, and explicitly Pass these tests.

I think that explicit is better than implicit, otherwise we *think*
that we can handle Jaguar 4.2 mocoeffs, but this is not necessarily
true. We can perhaps make this even more explicit, by using something
like self.markUntested, or somehow analysing the docstring to identify
that this is an untested test.

The thing is, if we implicitly pass them, future generations of cclib
developers may not be sure whether we just forgot to test it.

What do you think?

Noel

On 21/02/07, Karol Langner <kar...@kn...> wrote:
> On Wednesday 21 of February 2007 10:20, Noel O'Boyle wrote:
> > Any missing log files can only be created for the version that Adam
> > has access to, so we will need to add PASSes for everything else that
> > we are unable to test. AFAIK, the only differences between any of
> > these output files is in the vibrational frequency section, where Jag
> > 4.2 is different.
>
> So why have all the tests done for all versions?
>
> --
> written by Karol Langner
> Wed Feb 21 10:52:42 CET 2007
>

Re: [cclib-devel] Jaguar parser errors

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

On Wednesday 21 of February 2007 10:20, Noel O'Boyle wrote:
> Any missing log files can only be created for the version that Adam
> has access to, so we will need to add PASSes for everything else that
> we are unable to test. AFAIK, the only differences between any of
> these output files is in the vibrational frequency section, where Jag
> 4.2 is different.

So why have all the tests done for all versions?

-- 
written by Karol Langner
Wed Feb 21 10:52:42 CET 2007

Re: [cclib-devel] Jaguar parser errors

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

Some of this mess is probably due to me having access to particular
versions of Jaguar when we started writing the parsers, and then since
Sept, only Adam has had access, and that was a different version
again. I've just checked: specifically, the Jag 4.2 and 6.5 files were
uploaded by me. The Jag 6.0 files were uploaded by Adam (and note that
some of these are not STO-3G).

Any missing log files can only be created for the version that Adam
has access to, so we will need to add PASSes for everything else that
we are unable to test. AFAIK, the only differences between any of
these output files is in the vibrational frequency section, where Jag
4.2 is different.

Regards,
    Noel

On 21/02/07, Karol Langner <kar...@kn...> wrote:
> OK, I didn't notice the following in testSP.py:
>
> class Jaguar42SPTest(GenericSPTest):
>     def setUp(self):
>         self.data = data[4]
>
>     def testdimmocoeffs(self):
>         """Are the dimensions of mocoeffs equal to 1 x nmo x nbasis? PASS"""
>         self.assertEquals(1, 1)
>
> So checking mocoeffs for Jaguar 4.2 is basically bypassed.
>
> This leads me to the conclusion that there is a bit of a mess between the
> various Jaguar test files. All the Jaguar 6.0 tests work fine, and 4.2 and
> 6.5 have missing keywords:
> for aooverlaps: ip18 = 2
> for mocoeffs: ip102=8 (although I'm not entirely sure we want 8 here)
>
> Karol
>
> On Wednesday 21 of February 2007 09:13, Karol Langner wrote:
> > Hi,
> >
> >  Noel... you beat me to the geotargets fix :)
> >
> >  I noticed that some of the errors that come up when testing Jaguar (4.2 &
> > 6.5) arise from the test jobs input file being incomplete.
> >
> >  Specifically, the jaguar parser does not create the aooverlap attribute,
> > becuase there is no such data in the output file, this being because the
> > input file dvb_un_sp.in does not have the keyword "ip18 = 2" in the gen
> > section (as does dvb_sp.in). So this can be fixed by uploading the proper
> > test jobs.
> >
> >  It also does not create the mocoeffs attribute, even though the testSP for
> > this passes:
> >
> > Python 2.5 (r25:51908, Dec 28 2006, 19:26:00)
> > [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> >
> > >>> import cclib
> > >>> a = cclib.parser.ccopen("dvb_sp.out")
> > >>> a.parse()
> >
> > [Jaguar dvb_sp.out INFO] Creating attribute: nbasis
> > [Jaguar dvb_sp.out INFO] Creating attributes: atomcoords, atomnos, natom
> > [Jaguar dvb_sp.out INFO] Creating attribute aooverlaps
> > [Jaguar dvb_sp.out INFO] Creating attribute: scfvalues,scftargets
> > [Jaguar dvb_sp.out INFO] Creating attribute scfenergies
> > [Jaguar dvb_sp.out INFO] Creating attributes: moenergies, mosyms
> > [Jaguar dvb_sp.out INFO] Creating attribute coreelectrons[]
> >
> > (the same happens for dvb_un_sp.out, except that aooverlaps is not created.
> >
> > Hope this helps solve something,
> > Karol
>
> --
> written by Karol Langner
> Wed Feb 21 09:29:51 CET 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
>

Re: [cclib-devel] Jaguar parser errors

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

OK, I didn't notice the following in testSP.py:

class Jaguar42SPTest(GenericSPTest):
    def setUp(self):
        self.data = data[4]

    def testdimmocoeffs(self):
        """Are the dimensions of mocoeffs equal to 1 x nmo x nbasis? PASS"""
        self.assertEquals(1, 1)

So checking mocoeffs for Jaguar 4.2 is basically bypassed.

This leads me to the conclusion that there is a bit of a mess between the 
various Jaguar test files. All the Jaguar 6.0 tests work fine, and 4.2 and 
6.5 have missing keywords:
for aooverlaps: ip18 = 2
for mocoeffs: ip102=8 (although I'm not entirely sure we want 8 here)

Karol

On Wednesday 21 of February 2007 09:13, Karol Langner wrote:
> Hi,
>
>  Noel... you beat me to the geotargets fix :)
>
>  I noticed that some of the errors that come up when testing Jaguar (4.2 &
> 6.5) arise from the test jobs input file being incomplete.
>
>  Specifically, the jaguar parser does not create the aooverlap attribute,
> becuase there is no such data in the output file, this being because the
> input file dvb_un_sp.in does not have the keyword "ip18 = 2" in the gen
> section (as does dvb_sp.in). So this can be fixed by uploading the proper
> test jobs.
>
>  It also does not create the mocoeffs attribute, even though the testSP for
> this passes:
>
> Python 2.5 (r25:51908, Dec 28 2006, 19:26:00)
> [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> import cclib
> >>> a = cclib.parser.ccopen("dvb_sp.out")
> >>> a.parse()
>
> [Jaguar dvb_sp.out INFO] Creating attribute: nbasis
> [Jaguar dvb_sp.out INFO] Creating attributes: atomcoords, atomnos, natom
> [Jaguar dvb_sp.out INFO] Creating attribute aooverlaps
> [Jaguar dvb_sp.out INFO] Creating attribute: scfvalues,scftargets
> [Jaguar dvb_sp.out INFO] Creating attribute scfenergies
> [Jaguar dvb_sp.out INFO] Creating attributes: moenergies, mosyms
> [Jaguar dvb_sp.out INFO] Creating attribute coreelectrons[]
>
> (the same happens for dvb_un_sp.out, except that aooverlaps is not created.
>
> Hope this helps solve something,
> Karol

-- 
written by Karol Langner
Wed Feb 21 09:29:51 CET 2007

[cclib-devel] Jaguar parser errors

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

Hi,

 Noel... you beat me to the geotargets fix :)

 I noticed that some of the errors that come up when testing Jaguar (4.2 & 
6.5) arise from the test jobs input file being incomplete.

 Specifically, the jaguar parser does not create the aooverlap attribute, 
becuase there is no such data in the output file, this being because the 
input file dvb_un_sp.in does not have the keyword "ip18 = 2" in the gen 
section (as does dvb_sp.in). So this can be fixed by uploading the proper 
test jobs.

 It also does not create the mocoeffs attribute, even though the testSP for 
this passes:

Python 2.5 (r25:51908, Dec 28 2006, 19:26:00) 
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cclib
>>> a = cclib.parser.ccopen("dvb_sp.out")
>>> a.parse()
[Jaguar dvb_sp.out INFO] Creating attribute: nbasis
[Jaguar dvb_sp.out INFO] Creating attributes: atomcoords, atomnos, natom
[Jaguar dvb_sp.out INFO] Creating attribute aooverlaps
[Jaguar dvb_sp.out INFO] Creating attribute: scfvalues,scftargets
[Jaguar dvb_sp.out INFO] Creating attribute scfenergies
[Jaguar dvb_sp.out INFO] Creating attributes: moenergies, mosyms
[Jaguar dvb_sp.out INFO] Creating attribute coreelectrons[]
>>> 
(the same happens for dvb_un_sp.out, except that aooverlaps is not created.

Hope this helps solve something,
Karol

-- 
written by Karol Langner
Wed Feb 21 08:53:35 CET 2007

Re: [cclib-devel] testMP print-out

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

I was hoping to be able to set the docstrings 'on-the-fly' but it
doesn't seem to be possible. Instead I've used code based on your
original testMP plus some extra GenericMP2/3/4/5 classes to do the
same thing.

On 19/02/07, Noel O'Boyle <bao...@gm...> wrote:
> Yes, I understand. I'll look into this...
>
> On 18/02/07, Karol Langner <kar...@kn...> wrote:
> > Hi,
> >
> > The reason I overloaded the test methods of GenericMPTest is to make the
> > docstrings different for MP2-5, which are printed out when runngin the tests.
> > Now they are back to being the same again, as so:
> >
> > **** Testing Gaussian ****
> > Are Moller-Plesset corrections negative? ... ok
> > Are the dimensions of mpenergies correct? ... ok
> >
> > ----------------------------------------------------------------------
> > Ran 2 tests in 0.001s
> >
> > OK
> >
> > **** Testing Gaussian ****
> > Are Moller-Plesset corrections negative? ... ok
> > Are the dimensions of mpenergies correct? ... ok
> >
> > so you don't see which MPx is failing in case of error.
> >
> > Is there an alternate way to print out something unique for various instances
> > of GenericMPTest.
> >
> > Cheers,
> > Karol
> >
> > --
> > written by Karol Langner
> > Sun Feb 18 15:44:35 CET 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
> >
>

Re: [cclib-devel] CDA/Numeric bug (was Moving towards release)

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

I've implemented this in SVN.

testcda.py now works for me. Can you add an assert statement or two
that tests something? I'll jiggle it around into a unittest format.
I'm thinking of something like...if run on its own, it will run the
tests and also print out the text; but if run as part of
testmethods.py (which doesn't exist yet), it will just run the tests.

Noel

On 19/02/07, Noel O'Boyle <bao...@gm...> wrote:
> 'd' it is so. This means that all Numeric arrays containing floats
> should be explicitly initialised to 'd'.
>
> I'll grep the parsers for any instances of implicit initialisation, or
> use of 'f'.
>
> On 18/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > To make things easier, we should probably just use the same type for
> > > all float arrays in cclib. I'd tend to go with 'd' to avoid having to
> > > figure out whether 'f' would truncate some of our data, but this is
> > > probably overkill. Any thoughts?
> >
> > I'm guessing going to 'd' won't be a problem. If we assume that
> > mocoeffs[0] is a monster 1024 x 1024 matrix which is most likely on
> > the high end, that's only 8 MB of memory. Double that for a spin
> > unrestricted calc and add aooverlaps gives us 24 MB. Add in a
> > population analysis, and we're still only approaching 50 MB. A bit
> > high, although an extreme case, but still reasonable I think...
> >
> > Adam
> >
> >
>

Re: [cclib-devel] CDA/Numeric bug (was Moving towards release)

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

'd' it is so. This means that all Numeric arrays containing floats
should be explicitly initialised to 'd'.

I'll grep the parsers for any instances of implicit initialisation, or
use of 'f'.

On 18/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > To make things easier, we should probably just use the same type for
> > all float arrays in cclib. I'd tend to go with 'd' to avoid having to
> > figure out whether 'f' would truncate some of our data, but this is
> > probably overkill. Any thoughts?
>
> I'm guessing going to 'd' won't be a problem. If we assume that
> mocoeffs[0] is a monster 1024 x 1024 matrix which is most likely on
> the high end, that's only 8 MB of memory. Double that for a spin
> unrestricted calc and add aooverlaps gives us 24 MB. Add in a
> population analysis, and we're still only approaching 50 MB. A bit
> high, although an extreme case, but still reasonable I think...
>
> Adam
>
>

Re: [cclib-devel] testMP print-out

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

Yes, I understand. I'll look into this...

On 18/02/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
> The reason I overloaded the test methods of GenericMPTest is to make the
> docstrings different for MP2-5, which are printed out when runngin the tests.
> Now they are back to being the same again, as so:
>
> **** Testing Gaussian ****
> Are Moller-Plesset corrections negative? ... ok
> Are the dimensions of mpenergies correct? ... ok
>
> ----------------------------------------------------------------------
> Ran 2 tests in 0.001s
>
> OK
>
> **** Testing Gaussian ****
> Are Moller-Plesset corrections negative? ... ok
> Are the dimensions of mpenergies correct? ... ok
>
> so you don't see which MPx is failing in case of error.
>
> Is there an alternate way to print out something unique for various instances
> of GenericMPTest.
>
> Cheers,
> Karol
>
> --
> written by Karol Langner
> Sun Feb 18 15:44:35 CET 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
>

Re: [cclib-devel] CDA/Numeric bug (was Moving towards release)

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

> To make things easier, we should probably just use the same type for
> all float arrays in cclib. I'd tend to go with 'd' to avoid having to
> figure out whether 'f' would truncate some of our data, but this is
> probably overkill. Any thoughts?

I'm guessing going to 'd' won't be a problem. If we assume that  
mocoeffs[0] is a monster 1024 x 1024 matrix which is most likely on  
the high end, that's only 8 MB of memory. Double that for a spin  
unrestricted calc and add aooverlaps gives us 24 MB. Add in a  
population analysis, and we're still only approaching 50 MB. A bit  
high, although an extreme case, but still reasonable I think...

Adam

[cclib-devel] testMP print-out

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

Hi,

The reason I overloaded the test methods of GenericMPTest is to make the 
docstrings different for MP2-5, which are printed out when runngin the tests. 
Now they are back to being the same again, as so:

**** Testing Gaussian ****
Are Moller-Plesset corrections negative? ... ok
Are the dimensions of mpenergies correct? ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK

**** Testing Gaussian ****
Are Moller-Plesset corrections negative? ... ok
Are the dimensions of mpenergies correct? ... ok

so you don't see which MPx is failing in case of error.

Is there an alternate way to print out something unique for various instances 
of GenericMPTest.

Cheers,
Karol

-- 
written by Karol Langner
Sun Feb 18 15:44:35 CET 2007

Re: [cclib-devel] CDA/Numeric bug (was Moving towards release)

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

To make things easier, we should probably just use the same type for
all float arrays in cclib. I'd tend to go with 'd' to avoid having to
figure out whether 'f' would truncate some of our data, but this is
probably overkill. Any thoughts?

On 17/02/07, Adam Tenderholt <a-t...@st...> wrote:
> It appears that there are problems with typecodes in the CDA method.
> The donations and fooverlaps arrays are of type 'f' (4 bytes) while
> the mocoeffs is of type 'd' (8 bytes). What should be changed? Keep
> in mind that mocoeffs here are in the fragment MO basis, so doesn't
> necessarily reflect those of parser mocoeffs (although we should be
> careful so that MPA/CSPA can still be performed in the fragment MO
> basis).
>
> Adam
>
>

Re: [cclib-devel] CDA/Numeric bug (was Moving towards release)

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

It appears that there are problems with typecodes in the CDA method.  
The donations and fooverlaps arrays are of type 'f' (4 bytes) while  
the mocoeffs is of type 'd' (8 bytes). What should be changed? Keep  
in mind that mocoeffs here are in the fragment MO basis, so doesn't  
necessarily reflect those of parser mocoeffs (although we should be  
careful so that MPA/CSPA can still be performed in the fragment MO  
basis).

Adam

Re: [cclib-devel] Moving towards release

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

>> Also, I need to alter the code a bit to put the
>> "factor of 2" into the result matrix, instead of just having an extra
>> 2 added when printing out results. I'll try to get to that sometime
>> this afternoon.
> Cool.

I've made this minor change. Hopefully I will iron out differences  
between my code and Frenking's code at some point soon, maybe before  
the release.

Adam

Re: [cclib-devel] Moving towards release

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

> > I cleaned out my cclib installation, and then re-installed from trunk
> > (rev. 522). I didn't get any errors from testcda.py. Can you post the
> > errors you get?
> Will do. Might be something weird at my end.

I've just done the same as you did, but the error remains. Might be
something to do with Numeric versions??

C:\Documents and Settings\AvrilNoel\Desktop\cclib\test>python testcda.py
[CDA Gaussian log file ..\data\Gaussian\CDA\BH3CO-sp.log INFO] Creating attribut
e fonames[]
[CDA Gaussian log file ..\data\Gaussian\CDA\BH3CO-sp.log INFO] Creating mocoeffs
 in new fragment MO basis: mocoeffs[]
[CDA Gaussian log file ..\data\Gaussian\CDA\BH3CO-sp.log INFO] Creating fooverla
ps: array[x,y]
[CDA Gaussian log file ..\data\Gaussian\CDA\BH3CO-sp.log INFO] Creating donation
s, bdonations, and repulsions: array[]
Traceback (most recent call last):
  File "testcda.py", line 19, in ?
    fa.calculate([parser2, parser3])
  File "C:\Python24\Lib\site-packages\cclib\method\cda.py", line 82, in calculat
e
    donations[spin][i] += occs * self.mocoeffs[spin][i,k] \
TypeError: return array has incorrect type

C:\Documents and Settings\AvrilNoel\Desktop\cclib\test>python
Python 2.4.3 - Enthought Edition 1.0.0 (#69, Aug  2 2006, 12:09:59) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import Numeric
>>> Numeric.__version__
'24.2'
>>> ^Z

Noel