Menu
▾
▴
cclib-devel
|
From: Karol L. <kar...@kn...> - 2007-02-21 08:14:35
|
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
|
|
From: Karol L. <kar...@kn...> - 2007-02-21 08:37:07
|
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
|
|
From: Noel O'B. <bao...@gm...> - 2007-02-21 09:20:50
|
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
>
|
|
From: Karol L. <kar...@kn...> - 2007-02-21 09:54:04
|
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 |
|
From: Noel O'B. <bao...@gm...> - 2007-02-21 10:10:34
|
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 > |
|
From: Karol L. <kar...@kn...> - 2007-02-21 10:43:33
|
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 |
|
From: Karol L. <kar...@kn...> - 2007-02-21 10:56:29
|
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 |
|
From: Noel O'B. <bao...@gm...> - 2007-02-21 11:02:36
|
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 > |
|
From: Noel O'B. <bao...@gm...> - 2007-02-21 11:26:37
|
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
> >
>
|
|
From: Karol L. <kar...@kn...> - 2007-02-21 12:14:00
|
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 |
|
From: Adam T. <a-t...@st...> - 2007-02-21 16:57:57
|
> 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 |
|
From: Noel O'B. <bao...@gm...> - 2007-02-21 20:13:54
|
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. |
|
From: Noel O'B. <bao...@gm...> - 2007-02-21 20:15:14
|
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 > |
|
From: Karol L. <kar...@kn...> - 2007-02-22 10:48:19
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X