cclib-devel — Developer's mailing list

Re: [cclib-devel] Correlated electronic energies

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

On Tuesday 23 of January 2007 09:20, Noel O'Boyle wrote:
> Regarding the attribute name, how many more similar attributes do you
> expect, and is it possible that several may be extracted at the same
> time? That is, if you do an MP4 calculation, does this imply an MP2
> calculation first of all, and would the user be interested in
> extracting both? If the user is only interested in the highest
> available correlated energy, a correlatedenergies attribute might be
> better, which would be MP4 for an MP4 calculation, and MP2 for an MP2
> calculation.
>
> The alternative to a specific mp2energies attribute, would be
> something like a dictionary of 'correlatedenergies' which would have
> an entry for MP2 (if present), another for MP4 (if present), etc. Or
> maybe not a dictionary, but a list of tuples, since MP4 is greater
> than MP2. I'm not very keen on separate attributes for every single
> possibility, but if you can describe some typical examples we can
> discuss this...

I was thinking about this the other day, actually, when adding the code for 
parsing MP2 energies. I think the subject needs some thought and possibly a 
longer discussion, but let me comment on your ideas here.

I think a "correlatedenergies" attribute is not suitable. My main problem with 
it is that the various methods for getting correlated energies are totally 
different (conceptually and numerically). But besides that, you can an MP2 
correction followed by multiconfigurational calculations (I would like to add 
these to the parser very soon, also). So some combinations are not 
unreasonable.

IMO having a dictionary is a better idea, becuase it introduces no 
limitations. But... going this way, it would be reasonable to extend this 
dictionary to include ANY total molecular energies, after only SCF or 
otherwise. After all, the present scfenergies attribute contains either 
Hartree-Fock and DFT energies, depending on the output (not to mention 
RHF/UHF).

I'm having some mixed feelings about whether a dictioary is the right way to 
go, but having everything in one place seems quite elegant. Something like 
this:

g = cclib.parser.Gaussian("mp2job.log")
g.parse()
(...)
print g.energies.keys()
["RHF", "MP2"]
print genergies["MP2"]
array( [......, ...., ...])

I'm curious what everyone else thinks about putting all theenergies in one 
place.

> We will need to add tests to ensure at least that the new attribute
> has the correct size and shape.

If no one else adds tests for the new file Noel uploaded, I'll do it in a few 
days.

Karol

-- 
written by Karol Langner
Wed Jan 24 14:59:33 CET 2007

[cclib-devel] MP2 calculations

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

Dear all,

I'm about to upload 8 files for Gaussian: water_MPx.com/log, where x is 2,3,4,5.

Each MP3 file also contains information on MP2 results. Each MP4 file,
also contains info on MP2 and MP3 results, and so on.

As Karol has already done, MP2 info is indicted by the word EUMP2. MP3
info is indicated by the word EUMP3.

MP4 calcs can be at various levels - I suggest we just extract the
figure for the highest level. The log file contains something like:

MP4(T)=     -.55601167D-04
E3=         -.10847902D-01      EUMP3=         -.75014575395D+02
E4(DQ)=     -.32068082D-02      UMP4(DQ)=      -.75017782203D+02
E4(SDQ)=    -.33238377D-02      UMP4(SDQ)=     -.75017899233D+02
E4(SDTQ)=   -.33794389D-02      UMP4(SDTQ)=    -.75017954834D+02

In this case, we would extract the UMP4(SDTQ) figure. In general, we
just extract the final figure in this block (which may alternatively
be UMP4(DQ) or UMP4(SDQ)).

MP5 calculations are simpler...we just extract the figure from:

DEMP5 =  -0.11048812312D-02 MP5 =  -0.75017172926D+02

How does this sound? We can stick the appropriate values into
mp2energies, etc. as proposed by Karol. The only drawback is that a
user who wants the most accurate figure will need to check for the
presence/absence of mp5energies, mp4energies, etc.

Regards,
    Noel

Re: [cclib-devel] CDA!

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

I have added some more code for the CDA method. It now reproduces the  
numbers (well, still off by a factor of two and am hopefully going to  
hear back from Frenking about this soon) that the C++ version of CDA  
gives. I have also created a wiki page on how to use it: http:// 
cclib.sourceforge.net/wiki/index.php/Charge_Decomposition_Analysis

I haven't tested my implementation against a "real" molecule with an  
appreciable number of basis functions, nor I have tested it against  
unrestricted S > 0 systems or fragments.

Adam

Re: [cclib-devel] Correlated electronic energies

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

I sent another email to Adam only... I'm so accustomed to clicking just 
"Reply" for mailing lists.

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

On Monday 22 of January 2007 23:08, you wrote:
> > I'd add a test and attach output files, but it seems it would be more
> > efficient to "upgrade" the dvb_gopt tests with MP2 calculations
> > (the SCF
> > energies and other attributes will still be there). In any case,
> > I'm not too
> > sure about your testing policies, and this addition is pretty
> > straightforward
> > anyway.
>
> Do your "upgraded" dvb_gopt files give the same numbers for the SCF
> energies as our current dvb_gopt files? If so, I'm ok with committing
> them in place of our current ones. Noel, what do you think?

I haven't run upgraded dvb_gopt tests yet, but I will soon. The SCF will most 
certainly be the same, but I'm not sure if any other tested won't be affected 
(something that bases on the electron density).

> >  I also included two minor things in these patches:
> > 1. Corrected and added some units to the LogFile class dosctring
> > 2. Added apparently missing 'if self.progress: self.progress.update
> > (nstep,
> > "Done")' at end of gamess parser.
>
> Noel's more experienced with the vibration-related attributes, so
> I'll let him make the call on whether to change the units like you
> suggest. I'm also under the impression that the SCF energies are
> hartrees, but again, I'll defer to Noel. See the attached diff.

I'm not experienced in vibrations, iether - just looked it up :)

As to the SCF energies, both GAMESS and Gaussian output them in hartrees, but 
cclib converts them to eV (line 237 in gaussianparser.py, line 126 in 
gamessparser.py, etc.). That is why I changed the scf entry in the docstring, 
and that is why I went along in converting the MP2 energies. I must admit, I 
don't support this conversion, as total molecule energies are usually given 
in hartress in computational chemistry, and I think it should be changed.

Karol

-- 
written by Karol Langner
Tue Jan 23 09:53:03 CET 2007

Re: [cclib-devel] Correlated electronic energies

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

Dear Karol,

I second that - thanks for the contributions.

I've been away for a few days, but will sort out wiki/svn access
today. Wiki Spam is a serious problem, and unfortunately the only way
we can deal with it is to prevent users from creating accounts.

Regarding the attribute name, how many more similar attributes do you
expect, and is it possible that several may be extracted at the same
time? That is, if you do an MP4 calculation, does this imply an MP2
calculation first of all, and would the user be interested in
extracting both? If the user is only interested in the highest
available correlated energy, a correlatedenergies attribute might be
better, which would be MP4 for an MP4 calculation, and MP2 for an MP2
calculation.

The alternative to a specific mp2energies attribute, would be
something like a dictionary of 'correlatedenergies' which would have
an entry for MP2 (if present), another for MP4 (if present), etc. Or
maybe not a dictionary, but a list of tuples, since MP4 is greater
than MP2. I'm not very keen on separate attributes for every single
possibility, but if you can describe some typical examples we can
discuss this...

> > Here goes for my first little contribution - just parsing total MP2
> > energies.
> > I'm attaching the diff files for the code that parses the MP2
> > energies, for
> > the GAMESS and GAUSSIAN parsers (don't have output files to the other
> > programs at hand right now). So, there are three files affected in
> > trunk/src/cclib/parser.
>
> > I'd add a test and attach output files, but it seems it would be more
> > efficient to "upgrade" the dvb_gopt tests with MP2 calculations
> > (the SCF
> > energies and other attributes will still be there). In any case,
> > I'm not too
> > sure about your testing policies, and this addition is pretty
> > straightforward
> > anyway.

We will need to add tests to ensure at least that the new attribute
has the correct size and shape.

> Do your "upgraded" dvb_gopt files give the same numbers for the SCF
> energies as our current dvb_gopt files? If so, I'm ok with committing
> them in place of our current ones. Noel, what do you think?

I think the diff should make this pretty clear. Having said that, I
haven't yet looked at them.

> >  I also included two minor things in these patches:
> > 1. Corrected and added some units to the LogFile class dosctring
Thanks!
> > 2. Added apparently missing 'if self.progress: self.progress.update
> > (nstep,
> > "Done")' at end of gamess parser.
>
> Noel's more experienced with the vibration-related attributes, so
> I'll let him make the call on whether to change the units like you
> suggest. I'm also under the impression that the SCF energies are
> hartrees, but again, I'll defer to Noel. See the attached diff.
The development wiki should tell the truth. It's at:

http://cclib.sourceforge.net/wiki/index.php/Development_parsed_data

The docstring is usually updated just before release, but of course
the sooner any mistakes are found, the better.

> The addition of the progress updater to GAMESS parser sounds good.
> GAMESS isn't something I use on a regular basis, so I haven't noticed
> it's progress missing. :-P
>
> Again, thanks for your contributions and I'm excited for you to be
> added to our list of developers.
Ditto :-)

Noel

[cclib-devel] Fwd: Re: Correlated electronic energies

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

Forwarding this also, as I sent it only to Adam by mistake. Note that a few 
mails that came to the list before this one were actually sent later.

Karol

----------  Forwarded Message  ----------

Subject: Re: [cclib-devel] Correlated electronic energies
Date: Sunday 21 of January 2007 21:16
From: Karol Langner <kar...@kn...>
To: Adam Tenderholt <a-t...@st...>

On Sunday 21 of January 2007 19:05, you wrote:
> Hi Karol,
>
> It's great to hear that you are interested in contributing to cclib!
> If you want to send code (either full or patched) to the list, Noel
> and/or I can look it over and add it to our SVN repository.
> (snip)

Here goes for my first little contribution - just parsing total MP2 energies.
I'm attaching the diff files for the code that parses the MP2 energies, for
the GAMESS and GAUSSIAN parsers (don't have output files to the other
programs at hand right now). So, there are three files affected in
trunk/src/cclib/parser.

I'd add a test and attach output files, but it seems it would be more
efficient to "upgrade" the dvb_gopt tests with MP2 calculations (the SCF
energies and other attributes will still be there). In any case, I'm not too
sure about your testing policies, and this addition is pretty straightforward
anyway.

 I also included two minor things in these patches:
1. Corrected and added some units to the LogFile class dosctring
2. Added apparently missing 'if self.progress: self.progress.update(nstep,
"Done")' at end of gamess parser.

Hope this is all OK.

Karol

--
written by Karol Langner
Sun Jan 21 19:44:19 CET 2007

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

-- 
written by Karol Langner
Tue Jan 23 07:58:16 CET 2007

[cclib-devel] Fwd: Re: Correlated electronic energies

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

Forwarding this mail to the list, becuase I just noticed I sent it only to 
Adam.

Karol

----------  Forwarded Message  ----------

Subject: Re: [cclib-devel] Correlated electronic energies
Date: Sunday 21 of January 2007 19:39
From: Karol Langner <kar...@kn...>
To: Adam Tenderholt <a-t...@st...>

On Sunday 21 of January 2007 19:05, you wrote:
> Hi Karol,
>
> It's great to hear that you are interested in contributing to cclib!
> If you want to send code (either full or patched) to the list, Noel
> and/or I can look it over and add it to our SVN repository. Are you
> using a cclib release (0.6) or SVN?
>
> I think mp2energies makes sense as the attribute to use. Noel, comments?
>
> I believe Noel has to give you access to the wiki.
>
> Adam

I'm using the newest svn version.

With access to the wiki, I wouldn't mind helping to clean/update some pages a
bit.

Karol

--
written by Karol Langner
Sun Jan 21 19:31:39 CET 2007

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

-- 
written by Karol Langner
Tue Jan 23 07:57:22 CET 2007

Re: [cclib-devel] Correlated electronic energies

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

Thank you for your contributions!!

> Here goes for my first little contribution - just parsing total MP2  
> energies.
> I'm attaching the diff files for the code that parses the MP2  
> energies, for
> the GAMESS and GAUSSIAN parsers (don't have output files to the other
> programs at hand right now). So, there are three files affected in
> trunk/src/cclib/parser.

I've committed the changes to those two parsers. :o)

> I'd add a test and attach output files, but it seems it would be more
> efficient to "upgrade" the dvb_gopt tests with MP2 calculations  
> (the SCF
> energies and other attributes will still be there). In any case,  
> I'm not too
> sure about your testing policies, and this addition is pretty  
> straightforward
> anyway.

Do your "upgraded" dvb_gopt files give the same numbers for the SCF  
energies as our current dvb_gopt files? If so, I'm ok with committing  
them in place of our current ones. Noel, what do you think?

>  I also included two minor things in these patches:
> 1. Corrected and added some units to the LogFile class dosctring
> 2. Added apparently missing 'if self.progress: self.progress.update 
> (nstep,
> "Done")' at end of gamess parser.

Noel's more experienced with the vibration-related attributes, so  
I'll let him make the call on whether to change the units like you  
suggest. I'm also under the impression that the SCF energies are  
hartrees, but again, I'll defer to Noel. See the attached diff.

The addition of the progress updater to GAMESS parser sounds good.  
GAMESS isn't something I use on a regular basis, so I haven't noticed  
it's progress missing. :-P

Again, thanks for your contributions and I'm excited for you to be  
added to our list of developers.

Adam

Re: [cclib-devel] Correlated electronic energies

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

Hi Karol,

It's great to hear that you are interested in contributing to cclib!  
If you want to send code (either full or patched) to the list, Noel  
and/or I can look it over and add it to our SVN repository. Are you  
using a cclib release (0.6) or SVN?

I think mp2energies makes sense as the attribute to use. Noel, comments?

I believe Noel has to give you access to the wiki.

Adam

On Jan 21, 2007, at 4:55 AM, Karol Langner wrote:

> Dear all,
>
>  This is my first post to the list, so I'd like to say Hi! I'm a  
> PhD student
> in quantum chemistry/molecular modelling. I've been working on a  
> set of
> python scripts to automate parsing in my research work. I was  
> thinking about
> expanding and publishing it, but then learned about cclib. So now I'm
> starting to use it my work, and would be happy to contribute in  
> areas that
> are also usefull for me.
>
>  The first thing I need is parsing electronic energies beyond SCF  
> (MP2, CC,
> MCSCF). As far as I can see on the wiki, more exact energies are  
> not parsed
> yet, unless I can't find it. It seems logical that MP2 energies  
> should be
> stored in an 'mp2energies' attribute, in analogy to 'scfenergies' -  
> yes?
>
>  As I'm a beginner, should I send the code to this list?
>
> Karol
>
> P.S. I can't seem to create an account on the cclib wiki. It says  
> "Check your
> spelling, or use the form below to create a new user account.", but  
> I see no
> such form.
>
> -- 
> written by Karol Langner
> Sun Jan 21 13:28:11 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

[cclib-devel] Correlated electronic energies

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

Dear all,

 This is my first post to the list, so I'd like to say Hi! I'm a PhD student 
in quantum chemistry/molecular modelling. I've been working on a set of 
python scripts to automate parsing in my research work. I was thinking about 
expanding and publishing it, but then learned about cclib. So now I'm 
starting to use it my work, and would be happy to contribute in areas that 
are also usefull for me.

 The first thing I need is parsing electronic energies beyond SCF (MP2, CC, 
MCSCF). As far as I can see on the wiki, more exact energies are not parsed 
yet, unless I can't find it. It seems logical that MP2 energies should be 
stored in an 'mp2energies' attribute, in analogy to 'scfenergies' - yes?

 As I'm a beginner, should I send the code to this list?

Karol

P.S. I can't seem to create an account on the cclib wiki. It says "Check your 
spelling, or use the form below to create a new user account.", but I see no 
such form.

-- 
written by Karol Langner
Sun Jan 21 13:28:11 CET 2007

[cclib-devel] CDA!

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

Work has officially begun on CDA. I've started by creating the  
FragmentAnalysis class, which converts the mocoeffs of a molecule  
from the atomic orbital basis to a fragment molecular orbital basis.  
This is the first step in the CDA methodology.

Currently, my implementation is as follows:

The FragmentAnalysis class takes the parser of the entire molecule  
(as well as the usual optional stuff). It implements that calculate()  
function, which expects a list of parsers corresponding to the  
fragments which are being analyzed. In both __init__() and calculate 
(), the parsers are supposed to have already called parsed() although  
this requirement can be removed with some simple checking. After  
calculate() finishes, there is an mocoeffs attribute which follows  
the same format as the parsers ([spin][mo index][basis index]).  
Additionally, various other attributes are created from the molecular  
parser so that the c-squared population analysis method can be used.  
For example:

----
mol = ccopen(filename)
mol.parse()
frag1 = ccopen(filename2)
frag1.parse()
frag2 = ccopen(filename3)
frag2.parse()

fraganalysis = FragmentAnalysis(mol)
fraganalysis.calculate([frag1,frag2])

cspa = CSPA(fraganalysis)
cspa.calculate()
---

Finally, the fonames is created during FragmentAnalysis.calculate()  
function based on a name (if available, created by frag1.names =  
"Fragment 1") and the fragment molecular orbital index.

There's also no reason it can't use more than two fragments, but I  
haven't tested it. I also haven't tested more than (BH3)(CO).

Things to finish:
Convert aooverlaps to the molecular basis
Implement the actual CDA electron counting stuff
Handle unrestricted molecules with restricted fragments
Insert progress info and try to optimize code if necessary

I'm going home for the holidays tomorrow, but I'll try to get to this  
stuff in the coming weeks.

Adam

Re: [cclib-devel] Recent developments

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

Sounds good. :o)

On Dec 10, 2006, at 1:36 PM, Noel O'Boyle wrote:

> Hello Adam,
>
> Just to let you know what I've been up to...
>
> (1) moenergies and mocoeffs have been redefined to a be a lists of
> arrays rather than arrays themselves (still need to update wiki)
> (2) all the vibration data has been tidied up (same units between
> different programs, and rotation/translations are not included now by
> any program) and there is a new attribute vibdisps. The only point to
> note about vibdisps is that in some cases it may be mass weighted; I
> don't think it's possible to convert to non-mass weighted. However,
> vibdisps isn't a fundamental 'algorithm' attribute - it's more for
> pretty pictures.
> (3) Some small bugs with atomnos have been fixed here and there.
>
> ...I need to update the wiki...
>
> 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

[cclib-devel] Recent developments

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

Hello Adam,

Just to let you know what I've been up to...

(1) moenergies and mocoeffs have been redefined to a be a lists of
arrays rather than arrays themselves (still need to update wiki)
(2) all the vibration data has been tidied up (same units between
different programs, and rotation/translations are not included now by
any program) and there is a new attribute vibdisps. The only point to
note about vibdisps is that in some cases it may be mass weighted; I
don't think it's possible to convert to non-mass weighted. However,
vibdisps isn't a fundamental 'algorithm' attribute - it's more for
pretty pictures.
(3) Some small bugs with atomnos have been fixed here and there.

...I need to update the wiki...

Noel

Re: [cclib-devel] yet another adf bug

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

> Remember that a dictionary doesn't have an explicit ordering, so if
> you need ordering a list of fragments is better than a dictionary of
> fragments. Apart from that, it sounds fine. 'frags' sounds good also,
> although it does remind me of Quake.

I've added two attributes to the ADF parser: frags  and fragnames.  
Fragnames is simply a list of names, and frags is a list of lists  
that contain the numbers corresponding to the ordering in atomnos/ 
atomcoords.

> I wonder though whether, in the end, reading the equivalent of a
> checkpoint file would be a more sensible solution. There is a limit to
> how complicated the output file can be while still being parsable.
> Since you are likely to be doing the coding, you may want to think
> about this long and hard, but it's up to you.

I do think I'd like to support the ADF checkpoint files at some  
point, but as I don't use it extensively, it's not high on my list. ;o)

Adam

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> I hadn't thought about the difficulty in maintaining a 0.7 branch and
> trunk. I do like the idea of a parser-specific branch for new
> parsers. I'm assuming you'll still include the more finished parsers?
> I'll let you handle it since you know what you have in mind.

I'm in the process of branching off Molpro. At the moment, I'm not
planning on including the other parsers, simply because any
fixes/changes to the other parsers should be done on the trunk; also,
the tests on the branch will only be for the developing parser; the
tests on the trunk will only be for the finished parsers. What will
happen is that people working on a new parser will develop on the
branch. Once all the tests pass, the results are merged into the
trunk.

Regards,
   Noel

[cclib-devel] Changes to the SVN address for sourceforge projects

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

Apologies for cross posting, but those of you who use Subversion with
sourceforge projects will probably be interested in the following
notice:

http://sourceforge.net/docs/E09/en/#notice

"""
On November 31, 2006 the access method for Subversion changed. This
document reflects those changes. The old method had numerous problems,
including spurious 50x error messages and other issues that kept it
from functioning fully. This newly documented access method solves
many, if not all of the issues with the old mechanism.

Users of the old method
(https://svn.sourceforge.net/svnroot/PROJECTNAME) should switch to the
new access method
(https://PROJECTNAME.svn.sourceforge.net/svnroot/PROJECTNAME) using
these steps:

   1. Make a copy of your local working copy.
   2. Run 'svn info' at the root of the repository content, it should
display a line that appears similar to: URL:
https://svn.sourceforge.net/svnroot/PROJECTNAME/trunk
   3. Run the following command at the root of the working copy: svn
switch --relocate
https://svn.sourceforge.net/svnroot/PROJECTNAME/trunk
https://PROJECTNAME.svn.sourceforge.net/svnroot/PROJECTNAME/trunk
"""

Regards,
   Noel

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> I need to think some more about this, as what I was proposing was
> slightly different. I think you're saying that we should do
> development on the 0.7 branch. I'm afraid it will get slightly
> confusing if we are developing both on the branch and the trunk (as
> changes may have to be merged in both directions). I was suggesting
> that development for new parsers should be done on a branch, e.g. the
> molpro parser branch. This would only have tests and data files for
> molpro, for instance, and wouldn't contain the bridges, methods, etc.
> modules, so that development would be more focused (and the only
> changes would be parser related). Since Jaguar is slated for inclusion
> in the next release, I think it'd be easier at this stage to leave it
> on the trunk and do the final development there.

I hadn't thought about the difficulty in maintaining a 0.7 branch and  
trunk. I do like the idea of a parser-specific branch for new  
parsers. I'm assuming you'll still include the more finished parsers?  
I'll let you handle it since you know what you have in mind.

>> My proposal for the 0.7 branch would be:
>>
>> Initial Jaguar parser (It parses most things, as i recall).
>> CDA method
>> DOS stuff?
>
> I'd like to get the volume stuff in shape and add that too. I think
> it's important to get some sort of volume data created so that some
> progress can be made on pop analysis methods that use volume data. In
> the course of getting this ready I will discuss its limitations on the
> list, and we can decide if it's enough.

Sounds good. You'll move the discussion about volume stuff to a new  
thread when you start working on it?

> Sounds good in general, but I should say that Christmas is an
> open-source free zone for me. mid-Jan...isn't that like, cclib's first
> anniversary? :-)

Ah, ok. I'm looking forward to Christmas break so that I can do some  
hacking. After visiting with the family of course!

> I think Step 1 is to reimplement it so that it gives the same answer
> as the original code, however you do it. Once this is done we can
> think about refactoring it. (I hope there are no computer scientists
> reading this list - we can call this prototyping if it makes them
> happier :-) )

So you don't think there's any problem with me basically translating  
the code I found into Python? Not even from a violating some license  
standpoint? I don't think there is since I'm going to write our  
method from the ground up using the CDA code as a guide, instead of  
just copying the code and altering after the fact. Also, I'm  
translating it to another language! So there will be unique code from  
my side anyways.

> I was thinking about whether it is important for all of the cclib
> algorithms to be 'identically' implemented, etc. In the end, I would
> just prefer to have implementations of various algorithms that work,
> rather than worry about this too much - after all, we would like
> contributions from outside cclib, and it's unlikely they will come
> packaged in the same way as our own functions/classes.

I agree with you, although I think we should try to keep things as  
consistent as possible. If we do get code contributions, I would  
suggest we should still create classes that have attributes which are  
created from a calculate function.

Adam

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> > BTW, regarding branches - I'm thinking of creating separate branches
> > for parsers under development. This will cut down on the error
> > messages we get when we run the tests on the trunk (too many errors
> > and the tests become meaningless); and also avoid the mistakes I made
> > when when creating the 0.6 release. Any thoughts?
>
> I think this is a good idea. We should create a numbered branch for
> our next release. Is that going to be 0.7? And only stuff that we
> agree on goes in the numbered branch? Should we also try to put a
> flexible timeframe on the branch so that we know what goes in it?

I need to think some more about this, as what I was proposing was
slightly different. I think you're saying that we should do
development on the 0.7 branch. I'm afraid it will get slightly
confusing if we are developing both on the branch and the trunk (as
changes may have to be merged in both directions). I was suggesting
that development for new parsers should be done on a branch, e.g. the
molpro parser branch. This would only have tests and data files for
molpro, for instance, and wouldn't contain the bridges, methods, etc.
modules, so that development would be more focused (and the only
changes would be parser related). Since Jaguar is slated for inclusion
in the next release, I think it'd be easier at this stage to leave it
on the trunk and do the final development there.

> My proposal for the 0.7 branch would be:
>
> Initial Jaguar parser (It parses most things, as i recall).
> CDA method
> DOS stuff?

I'd like to get the volume stuff in shape and add that too. I think
it's important to get some sort of volume data created so that some
progress can be made on pop analysis methods that use volume data. In
the course of getting this ready I will discuss its limitations on the
list, and we can decide if it's enough.

> I'd say the release happens sometime in mid-January (things are a bit
> busy at the moment for me, but I should be able to get around to it
> eventually). What do you think?

Sounds good in general, but I should say that Christmas is an
open-source free zone for me. mid-Jan...isn't that like, cclib's first
anniversary? :-)

> About the CDA method: I found the original CDA code for two fragments
> online. Do you think I can just "translate" it into Python and extend
> it for multiple fragments, or do I need to explain on the list what
> the code does and let you implement it for a more cleanroom-style
> implementation.

I think Step 1 is to reimplement it so that it gives the same answer
as the original code, however you do it. Once this is done we can
think about refactoring it. (I hope there are no computer scientists
reading this list - we can call this prototyping if it makes them
happier :-) )

I was thinking about whether it is important for all of the cclib
algorithms to be 'identically' implemented, etc. In the end, I would
just prefer to have implementations of various algorithms that work,
rather than worry about this too much - after all, we would like
contributions from outside cclib, and it's unlikely they will come
packaged in the same way as our own functions/classes.

> Adam
>
>

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> Secondly, there was some weird Numeric stuff going on that caused me
> to tear my hair out for a while. SetVector was working with (1.0, 1.0,
> 1.0) but choking on (coords[0], coords[1], coords[2]). It only
> accepted the latter when I converted coords to a list using
> coords.tolist(). I still don't know why :-/ I think this code used to
> work...it's time for a test routine that runs the doctests, I think.

Strangely, I only had this problem on Windows. My fix was to to use  
float() on coords first. Maybe its some differences between Numeric  
on Windows and Mac?

> I'll send around a publicity email asap.

I saw the email. Good work.

> BTW, regarding branches - I'm thinking of creating separate branches
> for parsers under development. This will cut down on the error
> messages we get when we run the tests on the trunk (too many errors
> and the tests become meaningless); and also avoid the mistakes I made
> when when creating the 0.6 release. Any thoughts?

I think this is a good idea. We should create a numbered branch for  
our next release. Is that going to be 0.7? And only stuff that we  
agree on goes in the numbered branch? Should we also try to put a  
flexible timeframe on the branch so that we know what goes in it?

My proposal for the 0.7 branch would be:

Initial Jaguar parser (It parses most things, as i recall).
CDA method
DOS stuff?

I'd say the release happens sometime in mid-January (things are a bit  
busy at the moment for me, but I should be able to get around to it  
eventually). What do you think?

About the CDA method: I found the original CDA code for two fragments  
online. Do you think I can just "translate" it into Python and extend  
it for multiple fragments, or do I need to explain on the list what  
the code does and let you implement it for a more cleanroom-style  
implementation.

Adam

[cclib-devel] ANN: cclib 0.6.1 released

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

cclib 0.6.1 is now available for download from http://cclib.sf.net.

cclib is an open source library, written in Python, for parsing and interpreting
the results of computational chemistry packages. It currently parses output
files from ADF, GAMESS (US), GAMESS-UK, Gaussian, and PC GAMESS.

This is a bug fix release. Compared to cclib 0.6, the main changes are:
   * cclib: The "import cclib.parsers" statement failed due to references to
              Molpro and Jaguar parsers which are not present in the release
   * Gaussian parser: can now handle calculations described using a z-matrix
For more details, see http://cclib.sf.net/wiki/index.php/Changelog

Among other data, cclib extracts:

   * coordinates
   * atomic orbital information
   * molecular orbital information
   * information on vibrational modes
   * the results of a TD-DFT calculation

(For a complete list see http://cclib.sf.net/wiki/index.php/Parsed_Data).

cclib also provides some calculation methods for interpreting some electronic
properties of molecules using analyses such as:

   * Mulliken population analysis
   * Overlap population analysis
   * Calculation of Mayer's bond orders.

For information on how to use cclib, see
     http://cclib.sf.net/wiki/index.php/Using_cclib.

If you need help, find a bug, want new features or have any questions, please
send an email to our mailing list:
       https://lists.sourceforge.net/lists/listinfo/cclib-users

If you implement any computational chemistry algorithms using cclib, please
consider donating the code to the project.

Regards,

  The cclib development team

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> Thanks for the link! Unfortunately, cclib's makeopenbabel (version
> 0.6) doesn't like it so much. I managed to get pyopenbabel installed
> by checking out revision 1593 of the openbabel svn and altering the
> setup.py file to only install pyopenbabel. Unfortunately, it doesn't
> like _openbabel.OBAtom_SetVector(*args). Do you have any insight into
> this?! My guess is I could make it use the SetVector(double, double,
> double).

First of all, makeopenbabel has needed some attention for some time
now. The first thing I did is remove the dependency on pyopenbabel, so
that it just requires the open babel module.

Secondly, there was some weird Numeric stuff going on that caused me
to tear my hair out for a while. SetVector was working with (1.0, 1.0,
1.0) but choking on (coords[0], coords[1], coords[2]). It only
accepted the latter when I converted coords to a list using
coords.tolist(). I still don't know why :-/ I think this code used to
work...it's time for a test routine that runs the doctests, I think.

In short, it should be fixed now.

> Also, it doesn't look like you've tagged cclib 0.6.1. How's that
> coming along?
Sorry - it has been  tagged and released but not publicised (I kind of
ran out of steam, after rushing out the bug fix). I guess you looked
at the instructions page and didn't see anything written there. I
stopped updating that as I feel more confident using log messages to
keep track of what's been merged/branched/etc.

I'll send around a publicity email asap.

BTW, regarding branches - I'm thinking of creating separate branches
for parsers under development. This will cut down on the error
messages we get when we run the tests on the trunk (too many errors
and the tests become meaningless); and also avoid the mistakes I made
when when creating the 0.6 release. Any thoughts?

Noel

Re: [cclib-devel] yet another adf bug

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

Remember that a dictionary doesn't have an explicit ordering, so if
you need ordering a list of fragments is better than a dictionary of
fragments. Apart from that, it sounds fine. 'frags' sounds good also,
although it does remind me of Quake.

I wonder though whether, in the end, reading the equivalent of a
checkpoint file would be a more sensible solution. There is a limit to
how complicated the output file can be while still being parsable.
Since you are likely to be doing the coding, you may want to think
about this long and hard, but it's up to you.

Noel

On 28/11/06, Adam Tenderholt <a-t...@st...> wrote:
> So I think there's another ADF bug. In the dvb_sp.adfout file, the
> atom number in fonames doesn't agree with the atom number in
> atomcoords. As near as I can tell, this is because ADF reorders the
> atoms. This is seen near the GEOMETRY section. The next section is
> FRAGMENTS, and there's not an obvious 1 to 1 mapping between the
> fragment names (also element names) and atoms in the fragment.
>
> As I recall, ADF is the only program that does fragment orbitals
> involving combinations of atomic orbitals. If this is the case, I
> propose we create a dictionary (say 'fragments') to store information
> about which fragment contains which atoms. The value of the
> dictionary is simply a tuple of atomic numbers and atomic coords. I
> propose a dictionary simply because it would make accessing the info
> for a specific fragment easier.
>
> What do you think?
>
> 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
>

[cclib-devel] yet another adf bug

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

So I think there's another ADF bug. In the dvb_sp.adfout file, the  
atom number in fonames doesn't agree with the atom number in  
atomcoords. As near as I can tell, this is because ADF reorders the  
atoms. This is seen near the GEOMETRY section. The next section is  
FRAGMENTS, and there's not an obvious 1 to 1 mapping between the  
fragment names (also element names) and atoms in the fragment.

As I recall, ADF is the only program that does fragment orbitals  
involving combinations of atomic orbitals. If this is the case, I  
propose we create a dictionary (say 'fragments') to store information  
about which fragment contains which atoms. The value of the  
dictionary is simply a tuple of atomic numbers and atomic coords. I  
propose a dictionary simply because it would make accessing the info  
for a specific fragment easier.

What do you think?

Adam

Re: [cclib-devel] frequency displacements?

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

Well, they're not really coordinates are they, they are delta
coordinates, if you know what I mean. But I see what you mean; vibcart
gives the impression it's coordinates too.

I was also thinking about vibdisp, i.e. vibrational displacement
vectors. Or even vibvects. Maybe one of these is better. What do you
think?

BTW, it's done for GAMESS now too, and I've added testvib.py, to do a
single test of the dimensions. I need to remove the 6 rotations and
translations (i.e. 3N-6) from the list of vibrations for GAMESS,
though.

Noel

On 27/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > Absolutely...it's been on things-to-do for some time...why don't we
> > actually do it? I've started the balling rolling with extracting the
> > 'vibcarts' for Gaussian, plus the wiki entries.
>
> Is there a reason you chose 'vibcarts'? I would have thought
> 'vibcoords' would make more sense as we have 'atomcoords'? Just a
> thought....
>
> Adam
>
>

Re: [cclib-devel] frequency displacements?

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

> Absolutely...it's been on things-to-do for some time...why don't we
> actually do it? I've started the balling rolling with extracting the
> 'vibcarts' for Gaussian, plus the wiki entries.

Is there a reason you chose 'vibcarts'? I would have thought  
'vibcoords' would make more sense as we have 'atomcoords'? Just a  
thought....

Adam