cclib-devel — Developer's mailing list

[cclib-devel] [ cclib-Bugs-1767309 ] not parsing optimization steps

[SourceForge.net <no...@so...>]

Bugs item #1767309, was opened at 2007-08-03 13:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1767309&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: not parsing optimization steps

Initial Comment:
When the Symm(Follow) keyword is used to make geometry updates occur in the current symmetry, the resulting steps are not parsed. 

In the attached file, there are 4 steps; however, atomcoords is only length 1.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1767309&group_id=161285

[cclib-devel] Turbomole tests

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

I've enabled the Turbomole tests for geoopt and vibrations. If you
install cclib, and then go into the tests directory and run:

python testall.py

or perhaps more usefully:

python testGeoOpt.py
 and
python testvibs.py

You can monitor your progress.

Noel

Re: [cclib-devel] cclib 0.8 lock down

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

> I agree. Further refactoring can be done after the release, since  
> it really
> won't affect the way cclib is used and is aimed at making  
> developing easier
> in the future. If there is time, though, I would be happy to see  
> this go a
> bit further.

Ok, so we wait until after the release, unless Karol finds more time.  
As far as I know, there should only be minor changes for the methods.  
The things that come to mind are:

1. Pass ccData to constructor, instead of a parser
2. Remove any parser.parse() code.
3. ???

> I have code ready for a few types of electrostatic multipole analyses
> (including Stone's DMA), but I might not want to include this in  
> cclib before
> the release.

Ok.

I'll also upload some MP and TDDFT stuff for Orca in the next week or  
so.

Adam

[cclib-devel] Python 3000

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

This will not affect cclib for some time, but all developers (that use Python) 
should be aware what the future will bring:

http://www.artima.com/weblogs/viewpost.jsp?thread=208549

-- 
written by Karol Langner
Tue Jul 31 23:21:59 EDT 2007

Re: [cclib-devel] cclib 0.8 lock down

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

On Tuesday 31 July 2007 14:21, Nuno A. G. Bandeira wrote:
> Has the ADF parser been fixed yet ?

If I remember correctly, there are still a few regressions failing for the ADF 
parser. I will be looking into these after getting some other things done, if 
no one else does before me.

-- 
written by Karol Langner
Tue Jul 31 23:02:29 EDT 2007

Re: [cclib-devel] cclib 0.8 lock down

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

On Tuesday 31 July 2007 14:35, Noel O'Boyle wrote:
> On 31/07/07, Adam Tenderholt <a-t...@st...> wrote:
> > I agree, but we need to discuss a few things:
> >
> > ccData: are we done with this, or are we going to change the way the
> > various methods work?
>
> I think that we won't refactor any more at this stage. We'll just make
> sure it all currently works. The methods will have to be changed, but
> not that much right? If we fix/change one, we'll have an idea what the
> issues are.

I agree. Further refactoring can be done after the release, since it really 
won't affect the way cclib is used and is aimed at making developing easier 
in the future. If there is time, though, I would be happy to see this go a 
bit further.

> > methods: are we going to try to add any new ones?
>
> Well, this is the question. It depends on whether we have some already
> decent code around for some method.

I have code ready for a few types of electrostatic multipole analyses 
(including Stone's DMA), but I might not want to include this in cclib before 
the release.

> > On Jul 31, 2007, at 7:15 AM, Noel O'Boyle wrote:
> > > Dear devs,
> > >
> > > In the next few weeks let's focus on getting cclib 0.8 out the door.
> > > That is, finalising parsers, getting our methods back on-line and bug
> > > fixes. As a provisional date, let's say release end of Sept.
> > >
> > > What do you think?

I think the end of September is a good target, since the beginning of the 
academic year will mean less time for most of us.

Karol

-- 
written by Karol Langner
Tue Jul 31 22:53:33 EDT 2007

Re: [cclib-devel] Peeking with iterator

[Christopher R. <cro...@uo...>]

I think I'll be able to make it work based on what you and others have
suggested. I do believe it is a common enough problem, so it's something
to keep in mind if the parser methodology is resigned at some point.

Chris

-----Original Message-----
From: Noel O'Boyle [mailto:bao...@gm...] 
Sent: Tuesday, July 31, 2007 5:27 AM
To: Christopher Rowley
Cc: cclib-dev List
Subject: Re: [cclib-devel] Peeking with iterator

I would say avoid peeking and seeking and all that. All you need to do
is to make sure that the code for reading in the next section, follows
the code for reading in this section, and that the name of the
variable containing the "$" line is the same as the name of the
variable that is used in the big loop over all lines (typically the
variable name is "line").

Does this make sense? I've done this one before. Will this fit all
cases? (i.e. do you always know the order of the sections). Clearly,
it would be very helpful if you add comments indicating that the order
of a particular section is important if you use this method.

I see that you've uploaded some datafiles. Can you point to the
specific example? Maybe I can think of some other way...

Noel

On 31/07/07, Christopher Rowley <cro...@uo...> wrote:
>
>
>
>
> Is there a preferred way to peek ahead in inputfile iterator? The
problem
> I'm having is that the only way to tell if a section is over is if the
next
> line is the start of the new section (ie, it starts with a $). I can
think
> of one work around, which is to use tell() to get the starting
position of
> the new line, and then seeking back to that point it if it is the end
of the
> section. Please let me know if there a more elegant way to do this.
>
>
>
> Chris
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] cclib 0.8 lock down

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

On 31/07/07, Adam Tenderholt <a-t...@st...> wrote:
> I agree, but we need to discuss a few things:
>
> ccData: are we done with this, or are we going to change the way the
> various methods work?
I think that we won't refactor any more at this stage. We'll just make
sure it all currently works. The methods will have to be changed, but
not that much right? If we fix/change one, we'll have an idea what the
issues are.

> methods: are we going to try to add any new ones?
Well, this is the question. It depends on whether we have some already
decent code around for some method.

> parsers: what must be done before a parser is considered finished?
> for instance, the ORCA parser does everything i need for pymolyze,
> but it's missing the MP, TDDFT, and SCF things.
Would it be possible for you to create some test files for MP and
TDDFT? I have an incentive (i.e. GaussSum) to get TDDFT and SCF
working...

> Adam
>
>
> On Jul 31, 2007, at 7:15 AM, Noel O'Boyle wrote:
>
> > Dear devs,
> >
> > In the next few weeks let's focus on getting cclib 0.8 out the door.
> > That is, finalising parsers, getting our methods back on-line and bug
> > fixes. As a provisional date, let's say release end of Sept.
> >
> > What do you think?
> >
> > Noel
> >
> > ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] cclib 0.8 lock down

[Nuno A. G. B. <nun...@is...>]

Has the ADF parser been fixed yet ?

Regards,

-- 
Nuno A. G. Bandeira, AMRSC  
Graduate researcher and molecular sculptor
Inorganic and Theoretical Chemistry Group, 
Faculty of Science 
University of Lisbon - C8 building, Campo Grande, 
1749-016 Lisbon,Portugal
http://cqb.fc.ul.pt/intheochem/nuno.html 
Doctoral student @ IST,Lisbon
--

Re: [cclib-devel] cclib 0.8 lock down

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

I agree, but we need to discuss a few things:

ccData: are we done with this, or are we going to change the way the  
various methods work?

methods: are we going to try to add any new ones?

parsers: what must be done before a parser is considered finished?  
for instance, the ORCA parser does everything i need for pymolyze,  
but it's missing the MP, TDDFT, and SCF things.

Adam


On Jul 31, 2007, at 7:15 AM, Noel O'Boyle wrote:

> Dear devs,
>
> In the next few weeks let's focus on getting cclib 0.8 out the door.
> That is, finalising parsers, getting our methods back on-line and bug
> fixes. As a provisional date, let's say release end of Sept.
>
> What do you think?
>
> Noel
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

[cclib-devel] cclib 0.8 lock down

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

Dear devs,

In the next few weeks let's focus on getting cclib 0.8 out the door.
That is, finalising parsers, getting our methods back on-line and bug
fixes. As a provisional date, let's say release end of Sept.

What do you think?

Noel

Re: [cclib-devel] Peeking with iterator

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

On Tuesday 31 July 2007 05:27, Noel O'Boyle wrote:
> I would say avoid peeking and seeking and all that. All you need to do
> is to make sure that the code for reading in the next section, follows
> the code for reading in this section, and that the name of the
> variable containing the "$" line is the same as the name of the
> variable that is used in the big loop over all lines (typically the
> variable name is "line").

Caring about the order of the sections works, and remember that the following 
section does not have to be directly after the first one in the code (since 
the conditions in between will not be fullfilled).

I would recommend using a more explicit solution that is harder to break. In 
the first section set a unique flag if your special line is found. Then 
add "or <flag>" to the initial codnition of the second section. You will also 
need to add a condition for reading a new line (after the one with "$") in 
the second section, since it will have been read if the flag is set - so 
something like "if not <flag>: line = inputfile.next()" should be OK. I hope 
all that makes sense - I've also done something similar in the past.

> Does this make sense? I've done this one before. Will this fit all
> cases? (i.e. do you always know the order of the sections). Clearly,
> it would be very helpful if you add comments indicating that the order
> of a particular section is important if you use this method.

If we break up the extract() method into a dictionary of functions as 
discussed before, there would be no problem with this, since you could just 
call the second method from within the first. After separating the parser and 
data object, i seems to me that the dictionary of functions i within grasp.

> On 31/07/07, Christopher Rowley <cro...@uo...> wrote:
> > Is there a preferred way to peek ahead in inputfile iterator? The problem
> > I'm having is that the only way to tell if a section is over is if the
> > next line is the start of the new section (ie, it starts with a $). I can
> > think of one work around, which is to use tell() to get the starting
> > position of the new line, and then seeking back to that point it if it is
> > the end of the section. Please let me know if there a more elegant way to
> > do this.

-- 
written by Karol Langner
Tue Jul 31 13:02:27 EDT 2007

Re: [cclib-devel] Peeking with iterator

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

I would say avoid peeking and seeking and all that. All you need to do
is to make sure that the code for reading in the next section, follows
the code for reading in this section, and that the name of the
variable containing the "$" line is the same as the name of the
variable that is used in the big loop over all lines (typically the
variable name is "line").

Does this make sense? I've done this one before. Will this fit all
cases? (i.e. do you always know the order of the sections). Clearly,
it would be very helpful if you add comments indicating that the order
of a particular section is important if you use this method.

I see that you've uploaded some datafiles. Can you point to the
specific example? Maybe I can think of some other way...

Noel

On 31/07/07, Christopher Rowley <cro...@uo...> wrote:
>
>
>
>
> Is there a preferred way to peek ahead in inputfile iterator? The problem
> I'm having is that the only way to tell if a section is over is if the next
> line is the start of the new section (ie, it starts with a $). I can think
> of one work around, which is to use tell() to get the starting position of
> the new line, and then seeking back to that point it if it is the end of the
> section. Please let me know if there a more elegant way to do this.
>
>
>
> Chris
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

[cclib-devel] Peeking with iterator

[Christopher R. <cro...@uo...>]

Is there a preferred way to peek ahead in inputfile iterator? The
problem I'm having is that the only way to tell if a section is over is
if the next line is the start of the new section (ie, it starts with a
$). I can think of one work around, which is to use tell() to get the
starting position of the new line, and then seeking back to that point
it if it is the end of the section. Please let me know if there a more
elegant way to do this.
 
Chris

Re: [cclib-devel] Is there something you need from us?

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

> Also, I have not run the calculations with symmetry (although  
> turbomole
> can make use of symmetry if it is explicitly activated). My parser  
> won't
> work if the symmetry is anything other than c1 because I use the  
> $closed
> shells sections of the control file to calculate the number of homos.
> The format of this section is different if symmetry is enabled, and  
> this
> will require a little thinking to fix.

This is actually something we've had to deal with for the ADF parser.  
The format where moenergies is parsed is different depending on  
whether there is symmetry, whether its restricted or unrestricted,  
and (I think), whether certain options are given.  Luckily, these  
sections are all given different headings, so it wasn't too hard to  
figure out what to do. Hopefully Turbomole does something similar.

Adam

Re: [cclib-devel] Is there something you need from us?

[Christopher R. <cro...@uo...>]

Noel,

I've committed the optimization, single point, and vibrational frequency
calculations. One other thing I should mention is that turbomole doesn't
strictly have an input file. You run a specialized program (define) to
generate the control, coord, basis, auxbasis, and mos files. The
calculation is subsequently done by running one of the programs or
scripts that is part of turbomole. 

Also, I have not run the calculations with symmetry (although turbomole
can make use of symmetry if it is explicitly activated). My parser won't
work if the symmetry is anything other than c1 because I use the $closed
shells sections of the control file to calculate the number of homos.
The format of this section is different if symmetry is enabled, and this
will require a little thinking to fix.

Chris

-----Original Message-----
From: Noel O'Boyle [mailto:bao...@gm...] 
Sent: Monday, July 30, 2007 3:02 AM
To: Christopher Rowley
Cc: cclib-dev List; Adam Tenderholt
Subject: Re: Is there something you need from us?

Chris, can you upload some test files? I've created an example
directory structure that may be helpful with a directory per
calculation (unlike the other parsers, which have a file per
calculation). Until you upload a few test files, there's not a lot we
can do to help.

If you look at the test files available for the other parsers in the
"basicXXXXX" directory, you will see a number called dvb_something.
These are calculations on 1,4-divinylbenzene; a geometry optimization,
a single point calculation (with overlap matrix), an unrestricted
single point calculation (with overlap matrix), a frequency calc, a
TD-DFT, MPx calcs. Oh yeah, and it's useful to include the input file
too.

Once these are in place, we can add them into our test framework. From
then on, the aim is simply to make the parser pass all the tests (this
is a form of so-called test-driven development).

Noel

On 25/07/07, Christopher Rowley <cro...@uo...> wrote:
> Hi all,
>
> Sorry for the delay, I was busy with other work and the problem was a
> little more involved than I expected. I've committed a parser that
reads
> in coordinates and coefficients for closed shell species. It's not
> working with CDA yet, so there are a few bugs to work out. In any
case,
> the job is part done. Open shell species will take a little more time.
>
> I've added a new script called merge_turbo to combine the various
> turbomole files into a single output file.
>
> On an unrelated note, I've written a python script that reads in
> Cartesian coordinates of a coordination complex and divides the atoms
> into fragments automatically for use with CDA. It's not strictly a
cclib
> tool but I'd just as soon include it here as anywhere else.
>
> Chris
>
> -----Original Message-----
> From: Noel O'Boyle [mailto:bao...@gm...]
> Sent: Tuesday, July 24, 2007 10:39 AM
> To: Christopher Rowley
> Cc: cclib-dev List; Adam Tenderholt
> Subject: Is there something you need from us?
>
> Hello Chris,
>
> Just wondering whether you're waiting for us to do something, or
> whether you need any help to get started?
>
> BTW, anyone going to the ACS in Boston? Me, at least.
>
> Regards,
>    Noel
>
>

Re: [cclib-devel] Is there something you need from us?

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

Chris, can you upload some test files? I've created an example
directory structure that may be helpful with a directory per
calculation (unlike the other parsers, which have a file per
calculation). Until you upload a few test files, there's not a lot we
can do to help.

If you look at the test files available for the other parsers in the
"basicXXXXX" directory, you will see a number called dvb_something.
These are calculations on 1,4-divinylbenzene; a geometry optimization,
a single point calculation (with overlap matrix), an unrestricted
single point calculation (with overlap matrix), a frequency calc, a
TD-DFT, MPx calcs. Oh yeah, and it's useful to include the input file
too.

Once these are in place, we can add them into our test framework. From
then on, the aim is simply to make the parser pass all the tests (this
is a form of so-called test-driven development).

Noel

On 25/07/07, Christopher Rowley <cro...@uo...> wrote:
> Hi all,
>
> Sorry for the delay, I was busy with other work and the problem was a
> little more involved than I expected. I've committed a parser that reads
> in coordinates and coefficients for closed shell species. It's not
> working with CDA yet, so there are a few bugs to work out. In any case,
> the job is part done. Open shell species will take a little more time.
>
> I've added a new script called merge_turbo to combine the various
> turbomole files into a single output file.
>
> On an unrelated note, I've written a python script that reads in
> Cartesian coordinates of a coordination complex and divides the atoms
> into fragments automatically for use with CDA. It's not strictly a cclib
> tool but I'd just as soon include it here as anywhere else.
>
> Chris
>
> -----Original Message-----
> From: Noel O'Boyle [mailto:bao...@gm...]
> Sent: Tuesday, July 24, 2007 10:39 AM
> To: Christopher Rowley
> Cc: cclib-dev List; Adam Tenderholt
> Subject: Is there something you need from us?
>
> Hello Chris,
>
> Just wondering whether you're waiting for us to do something, or
> whether you need any help to get started?
>
> BTW, anyone going to the ACS in Boston? Me, at least.
>
> Regards,
>    Noel
>
>

Re: [cclib-devel] Morokuma EDA analysis

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

Sure, Morokuma decomposition would be great. In fact, I was looking
for this a couple of years ago during my PhD. I think that it's built
into GAMESS, but not in Gaussian, so I tried to run my calculation
with GAMESS but it failed to converge. And that was the end of that...

This does mean, at least, that we can compare our implementation with
an available one.

Noel

On 25/07/07, Karol Langner <kar...@kn...> wrote:
> >>> Hi,
> >>>
> >>> Has anyone considering implementing Ziegler-Morokuma energy
> >>> decomposition analysis into cclib? I don't know everything that is
> >>> involved in the calculation off hand, but I don't think it would
> >>> be an
> >>> enormous job considering that CDA is already implemented. It's
> >>> something
> >>> I would consider doing, once I'm done with the turbomole binding.
> >>>
> >>> Chris
> >>
> >> I would be very interested in this, but I don't share your enthusiasm
> >> about how easy it would be.
> >
> > I must admit I've never heard of this EDA. How does it differ from
> > CDA, and what exactly is involved? Do you have a link to a paper or
> > website?
> >
> > Adam
>
> I don't have the time to dig anything up right now - I can come back to it
> in a few days.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Morokuma EDA analysis

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

>>> Hi,
>>>
>>> Has anyone considering implementing Ziegler-Morokuma energy
>>> decomposition analysis into cclib? I don't know everything that is
>>> involved in the calculation off hand, but I don't think it would
>>> be an
>>> enormous job considering that CDA is already implemented. It's
>>> something
>>> I would consider doing, once I'm done with the turbomole binding.
>>>
>>> Chris
>>
>> I would be very interested in this, but I don't share your enthusiasm
>> about how easy it would be.
>
> I must admit I've never heard of this EDA. How does it differ from
> CDA, and what exactly is involved? Do you have a link to a paper or
> website?
>
> Adam

I don't have the time to dig anything up right now - I can come back to it
in a few days.

Re: [cclib-devel] Is there something you need from us?

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

> Sorry for the delay, I was busy with other work and the problem was a
> little more involved than I expected. I've committed a parser that  
> reads
> in coordinates and coefficients for closed shell species. It's not
> working with CDA yet, so there are a few bugs to work out. In any  
> case,
> the job is part done. Open shell species will take a little more time.

Delays are quite normal, at least for me, as I usually only work on  
cclib/PyMOlyze when research is going slowly or I have a major itch  
to scratch.

Do you know why your parser doesn't work with CDA? Is it exiting with  
an error, or are the numbers wrong?

> I've added a new script called merge_turbo to combine the various
> turbomole files into a single output file.

Excellent. I'm glad you've decided on a way to handle turbomole  
calculations. At some point, you should run the standard dvb  
calculations using turbomol and add these to the turbomole svn branch.

> On an unrelated note, I've written a python script that reads in
> Cartesian coordinates of a coordination complex and divides the atoms
> into fragments automatically for use with CDA. It's not strictly a  
> cclib
> tool but I'd just as soon include it here as anywhere else.

I don't really understand what you mean. Shouldn't you have to run  
three calculations (ie. A-B, A, and B) for CDA? And if so, I don't  
see how a script could help setup these calculations.

Adam

Re: [cclib-devel] Morokuma EDA analysis

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

>> Hi,
>>
>> Has anyone considering implementing Ziegler-Morokuma energy
>> decomposition analysis into cclib? I don't know everything that is
>> involved in the calculation off hand, but I don't think it would  
>> be an
>> enormous job considering that CDA is already implemented. It's  
>> something
>> I would consider doing, once I'm done with the turbomole binding.
>>
>> Chris
>
> I would be very interested in this, but I don't share your enthusiasm
> about how easy it would be.

I must admit I've never heard of this EDA. How does it differ from  
CDA, and what exactly is involved? Do you have a link to a paper or  
website?

Adam

Re: [cclib-devel] Morokuma EDA analysis

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

> Hi,
>
> Has anyone considering implementing Ziegler-Morokuma energy
> decomposition analysis into cclib? I don't know everything that is
> involved in the calculation off hand, but I don't think it would be an
> enormous job considering that CDA is already implemented. It's something
> I would consider doing, once I'm done with the turbomole binding.
>
> Chris

I would be very interested in this, but I don't share your enthusiasm
about how easy it would be.

Cheers,
Karol

[cclib-devel] Blue Obelisk meeting at the Fall ACS

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

I am reposting the following from Christoph Steinbeck on the
blue-obelisk-discuss mailing list (http://blueobelisk.org). Basically,
if you're interested in attending the Blue Obelisk get together, reply
to Chris on that list as soon as possible.

Dear all,

I would like to make a reservation for our Blue Obelisk meeting in
Boston. It'll be at ye olde union oyster house
(http://www.unionoysterhouse.com/) on Wednesday, August 22nd, 6 pm.

PLEASE LET ME KNOW ASAP IF YOU WANT TO JOIN!
(Sorry for shouting)

I have already noted the following people as participants:

Rich Apodaca
Noel O'Boyle
Sanford Dickert
Rajarshi Guha
Christoph Steinbeck

Cheers,

Chris

[cclib-devel] Morokuma EDA analysis

[Christopher R. <cro...@uo...>]

Hi,
 
Has anyone considering implementing Ziegler-Morokuma energy
decomposition analysis into cclib? I don't know everything that is
involved in the calculation off hand, but I don't think it would be an
enormous job considering that CDA is already implemented. It's something
I would consider doing, once I'm done with the turbomole binding.
 
Chris

Re: [cclib-devel] Is there something you need from us?

[Christopher R. <cro...@uo...>]

Hi all,

Sorry for the delay, I was busy with other work and the problem was a
little more involved than I expected. I've committed a parser that reads
in coordinates and coefficients for closed shell species. It's not
working with CDA yet, so there are a few bugs to work out. In any case,
the job is part done. Open shell species will take a little more time.

I've added a new script called merge_turbo to combine the various
turbomole files into a single output file.

On an unrelated note, I've written a python script that reads in
Cartesian coordinates of a coordination complex and divides the atoms
into fragments automatically for use with CDA. It's not strictly a cclib
tool but I'd just as soon include it here as anywhere else.

Chris

-----Original Message-----
From: Noel O'Boyle [mailto:bao...@gm...] 
Sent: Tuesday, July 24, 2007 10:39 AM
To: Christopher Rowley
Cc: cclib-dev List; Adam Tenderholt
Subject: Is there something you need from us?

Hello Chris,

Just wondering whether you're waiting for us to do something, or
whether you need any help to get started?

BTW, anyone going to the ACS in Boston? Me, at least.

Regards,
   Noel