Menu
▾
▴
cclib-devel
|
From: Noel O'B. <bao...@gm...> - 2007-02-17 12:21:01
|
Almost ready to release...we just need to get a few tests to pass and
polish off some attributes. Here's what I've been doing/thinking as
well as some suggestions...
(1) I've uploaded MP files for GAMESS-UK. All that's left is Jaguar,
which I guess Adam will have to look into. Possibly, PC-GAMESS
too...I'll look into that.
(2) I've simplified testMP (no need to overload testsizeandshape and
testchange), and added the tests for GAMESS-UK (which currently fail).
(3) I've added N/P "Not possible" and T/D "to do" to some entries in
the table in "Development Parsed Data" on the wiki. There's more to
add, but it's a start.
(4) Is coreelectrons going to make it into the next release? If so,
we're going to need some tests on it (although there's not a lot to
test really, is there?) and the rest of the boxes checked on the wiki
(only ADF and Gaussian, currently)
(5) I've moved the test code from the end of cda.py to testcda.py.
There's a bug in here somewhere though, as the code fails with an
error (not due to me moving it). Could you look into this Adam? Once
sorted, I rearrange the testcda.py into a more formal unittest.
Regards,
Noel
|
|
From: Karol L. <kar...@kn...> - 2007-02-17 13:05:56
|
On Saturday 17 of February 2007 13:20, Noel O'Boyle wrote: > Almost ready to release...we just need to get a few tests to pass and > polish off some attributes. Here's what I've been doing/thinking as > well as some suggestions... > (1) I've uploaded MP files for GAMESS-UK. All that's left is Jaguar, > which I guess Adam will have to look into. Possibly, PC-GAMESS > too...I'll look into that. Thanks for the MP files for GAMESS-UK. Like I said, I'll take care of parsing mpenergies, but not before tommorow evening (some other urgent work). I already have most of it done. > (2) I've simplified testMP (no need to overload testsizeandshape and > testchange), and added the tests for GAMESS-UK (which currently fail). That was my quick hack to make the docstrings different for MP2/MP3/MP4/MP5. Cheers, Karol -- written by Karol Langner Sat Feb 17 14:00:46 CET 2007 |
|
From: Adam T. <a-t...@st...> - 2007-02-17 17:44:59
|
> (4) Is coreelectrons going to make it into the next release? If so, > we're going to need some tests on it (although there's not a lot to > test really, is there?) and the rest of the boxes checked on the wiki > (only ADF and Gaussian, currently) The advantage of parsing coreelectrons is the ability to "accurately" determine MPA and CSPA atomic charges for atoms with a frozen core. As I haven't altered MPA or CSPA to use this info, I don't see any real reason to officially include coreelectrons in this release. Is there a timeframe you're shooting for with this release? It sounds like you want to release soon. Do we have time to add coreelectrons to our other supported parsers? > (5) I've moved the test code from the end of cda.py to testcda.py. > There's a bug in here somewhere though, as the code fails with an > error (not due to me moving it). Could you look into this Adam? Once > sorted, I rearrange the testcda.py into a more formal unittest. 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? 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. Adam > > Regards, > Noel > > ---------------------------------------------------------------------- > --- > 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: Noel O'B. <bao...@gm...> - 2007-02-17 18:15:49
|
> Is there a timeframe you're shooting for with this release? It sounds > like you want to release soon. I think "release when ready" but it'd be nice to be ready in the near future. If we need a date to aim for, how about the end of the month, which is the 1st anniversary of cclib after all. > Do we have time to add coreelectrons > to our other supported parsers? I think this shouldn't be a big job. Do we need some test files? I'm going to sort out the remaining failing Jaguar tests first though. > > (5) I've moved the test code from the end of cda.py to testcda.py. > > There's a bug in here somewhere though, as the code fails with an > > error (not due to me moving it). Could you look into this Adam? Once > > sorted, I rearrange the testcda.py into a more formal unittest. > > 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. > 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. Noel |
|
From: Adam T. <a-t...@st...> - 2007-02-17 21:05:06
|
>> 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 |
|
From: Noel O'B. <bao...@gm...> - 2007-02-17 19:27:03
|
> > 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
|
|
From: Adam T. <a-t...@st...> - 2007-02-17 21:16:39
|
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 |
|
From: Noel O'B. <bao...@gm...> - 2007-02-18 08:56:04
|
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 > > |
|
From: Adam T. <a-t...@st...> - 2007-02-18 17:19:21
|
> 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 |
|
From: Noel O'B. <bao...@gm...> - 2007-02-19 08:12:19
|
'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 > > |
|
From: Noel O'B. <bao...@gm...> - 2007-02-19 13:16:17
|
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 > > > > > |
×
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