Re: [cclib-devel] New developer

[Dr N. O'B. <no...@ca...>]

On Sep 5 2006, Adam Tenderholt wrote:

>> * methods: nothing new in methods except a half-finished volume.py,  
>> which I need to tidy up. On my things to do is to convert the  
>> population functions to have explicit data passed, rather than the  
>> whole parser object. Was thinking about finding common elements  
>> between population methods and abstracting them out, e.g. a  
>> fragments object.
>
>I did try to make the population methods derive from an abstract  
>class that implemented as much as possible. When you say fragments  
>object, do you mean you want a Python object that contains the  
>population information for fragments that are passed to the calculate 
>() method? (It is called calculate(), right?! I honestly haven't  
>looked at it in ages.) As I recall, a Numeric array is returned right  
>now.

I must admit that I haven't looked at it too closely myself - I think I 
should just keep quiet about that until I have a proper look (just talking 
thru my hat again). On the other hand, I do now believe strongly in 
explicit passing of information, although when we first discussed this I 
wasn't sure whether it made any difference. What convinced me in the end 
was writing the bridges where, when you want to make an openbabel molecule 
(for instance) you need to explicitly pass coordinates (as there may be 
several sets in a geometry optimization). In the DOS example, someone might 
only want to calculate the contributions to the HOMO, and they could just 
pass in a Numeric array of the right dimensions, but just containing the 
HOMO.

>> * parsers: I think GAMESS-UK parser is ready for release. Jaguar is  
>> still only half-finished. Check the logs for some small changes to  
>> ADF, Gaussian and GAMESS. Added gbasis attribute, and .clean()  
>> method. We intend to add the cartesian displacement vectors (from a  
>> frequency calculation) and the force constant matrix.
>
>Sounds good.
>
>> * bridges: nothing new. Have learned that the release version of  
>> OpenBabel doesn't include pyopenbabel though, so I should probably  
>> change the OB bridge to use the openbabel module.
>
>Ok. Since you're most familiar with this, I'll let you handle it. ;o)
Sure.

>> * test: have been trying to simplify the tests. Some more work to  
>> do. Going to replace regression.py with ccopen.py. The idea will be  
>> that ccopen.py attempts to guess the type of every test file we  
>> have, parse it, and if necessary, run a regression test. Am also  
>> thinking that life would be simpler if we simply unloaded our large  
>> test files to SVN also. We can zip them up, and teach cclib to open  
>> zipped files (part of the standard Python library, I think). I  
>> think that we shouldn't worry about sourceforge running out of space.
>
>I think you are right that the standard python library contain  
>functions for dealing with zipped files. Is there someone we can  
>contact at sourceforge about svn space limits? I really think we  
>should check just in case...
Will do. And in addition, it would be nice if we could use SF's bug 
tracking system...no more emailing to a gmail account.

BTW, I'm moving all opensource discussions to my gmail account, 
bao...@gm..., so if could you update your address book, that'd be 
great.

>Adam
>
>
>