cclib-devel — Developer's mailing list

Re: [cclib-devel] Fwd: Refactoring

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

On Tuesday 27 of February 2007 15:34, Noel O'Boyle wrote:
> On 26/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > With this in mind, could we just base the release on trunk (i.e. I'll
> > > merge all of the change to release), and then I'll remove any items in
> > > development (e.g. ccenergies).
> >
> > That sounds reasonable.
>
> OK, done.

Out of curiousity, did something happen here that caused some tests in testMP 
to fail? I noticed that a few lines of code were gone (readded them today).

> The only tests left to pass are those involving coreelectrons (because
> of tests I've added today basically). We need
>
> (1) a test file for GAMESS-US and/or PC-GAMESS, and then code for it
> (2) code for GAMESS-UK
> (3) bug fix for ADF (I presume it's a bug)

So this is all done, I think. Any other coding bits you need help with?

Karol

-- 
written by Karol Langner
Thu Mar  1 22:50:06 CET 2007

Re: [cclib-devel] mpenergies tests

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

On Thursday 01 of March 2007 15:41, Noel O'Boyle wrote:
> I've added three failing tests for PCGAMESS mpenergies to the test
> suite. (I promise not to add any more breaking tests to the testsuite
> after this.)
>
> Since you've taken the lead on mpenergies, I'll leave this to you
> Karol if you have the time. If not please let me know.
>
> Noel

I'll take care of this later today or tommorow.

-- 
written by Karol Langner
Thu Mar  1 16:44:07 CET 2007

[cclib-devel] mpenergies tests

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

I've added three failing tests for PCGAMESS mpenergies to the test
suite. (I promise not to add any more breaking tests to the testsuite
after this.)

Since you've taken the lead on mpenergies, I'll leave this to you
Karol if you have the time. If not please let me know.

Noel

Re: [cclib-devel] License for Jaguar and release schedule

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

On 01/03/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 01 of March 2007 11:19, Noel O'Boyle wrote:
> > Hello all,
> >
> > Schrodinger have been good enough to grant cclib a temporary license
> > for Jaguar for 12 months, at the end of which period we will need to
> > provide a report of cclib support for Jaguar. Due to time constraints
> > (I will be away for long periods over the next two months), I still
> > think we should get cclib 0.7 out the door and look to 0.8 for full
> > Jaguar support.
> >
> > In short, I still aim to make a release of 0.7b this weekend...hope
> > this is okay with everyone.
> >
> > Noel
>
> This is good news - how will this license be used and by whom?
Let's discuss this off list....

> I just commited the coreelectrons test for GAMESS-US to svn. I will be
> available over the weekend to help out with the release.
Great. BTW, I'd appreciate if you could make clear in log comments
(e.g. r559) whether this revision is to be included in the release or
not. It will make things easier for me when merging to the release
branch.

> Karol
>
> --
> written by Karol Langner
> Thu Mar  1 12:44:04 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
>

Re: [cclib-devel] License for Jaguar and release schedule

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

On Thursday 01 of March 2007 11:19, Noel O'Boyle wrote:
> Hello all,
>
> Schrodinger have been good enough to grant cclib a temporary license
> for Jaguar for 12 months, at the end of which period we will need to
> provide a report of cclib support for Jaguar. Due to time constraints
> (I will be away for long periods over the next two months), I still
> think we should get cclib 0.7 out the door and look to 0.8 for full
> Jaguar support.
>
> In short, I still aim to make a release of 0.7b this weekend...hope
> this is okay with everyone.
>
> Noel

This is good news - how will this license be used and by whom?

I just commited the coreelectrons test for GAMESS-US to svn. I will be 
available over the weekend to help out with the release.

Karol

-- 
written by Karol Langner
Thu Mar  1 12:44:04 CET 2007

[cclib-devel] License for Jaguar and release schedule

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

Hello all,

Schrodinger have been good enough to grant cclib a temporary license
for Jaguar for 12 months, at the end of which period we will need to
provide a report of cclib support for Jaguar. Due to time constraints
(I will be away for long periods over the next two months), I still
think we should get cclib 0.7 out the door and look to 0.8 for full
Jaguar support.

In short, I still aim to make a release of 0.7b this weekend...hope
this is okay with everyone.

Noel

[cclib-devel] multiple input files

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

Dear all,

 While working with some new programs recently (CPMD, for example, which would 
be really cool to support :D), it occurred to me that using multiple input 
files in cclib is missing. Alot of programs put output in more than one file, 
and the various files can contain information useful for cclib. So reading 
from multiple files is a feature that should definitely be implemented (in a 
smart way, of course) in the future.

Cheers,
Karol

-- 
written by Karol Langner
Wed Feb 28 08:10:31 CET 2007

[cclib-devel] Input file for GAMESS

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

Hello Karol,

Can you make an input file for GAMESS coreelectrons? It's doing my head in.

Noel

[cclib-devel] GAMESS-UK coreelectrons

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

I'm going to do GAMESS-UK coreelectrons...

[cclib-devel] Fwd: Refactoring

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

---------- Forwarded message ----------
From: Noel O'Boyle <bao...@gm...>
Date: 27-Feb-2007 14:34
Subject: Re: [cclib-devel] Refactoring
To: Adam Tenderholt <a-t...@st...>


On 26/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > With this in mind, could we just base the release on trunk (i.e. I'll
> > merge all of the change to release), and then I'll remove any items in
> > development (e.g. ccenergies).
>
> That sounds reasonable.
OK, done.

> Are all the regression tests passing with the
> trunk version?

The only tests left to pass are those involving coreelectrons (because
of tests I've added today basically). We need

(1) a test file for GAMESS-US and/or PC-GAMESS, and then code for it
(2) code for GAMESS-UK
(3) bug fix for ADF (I presume it's a bug)

To be practical, I think I'll have to make a release of cclib 0.7b
this weekend, or it'll be put off for too long. When I come back I'll
make the final release.

Noel

Re: [cclib-devel] Refactoring

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

> With this in mind, could we just base the release on trunk (i.e. I'll
> merge all of the change to release), and then I'll remove any items in
> development (e.g. ccenergies).

That sounds reasonable. Are all the regression tests passing with the  
trunk version?

Adam

Re: [cclib-devel] Refactoring

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

I'm going to make a U-turn now. I'm slowly realising that even with
the magic help of svnmerge.py, it will not be possible to cleanly
merge trunk to the release branch (or at least without a lot of effort
hand fixing conflicts and so on), and leave out the refactoring
changes soon after 479.

With this in mind, could we just base the release on trunk (i.e. I'll
merge all of the change to release), and then I'll remove any items in
development (e.g. ccenergies).

Noel

On 09/02/07, Noel O'Boyle <bao...@gm...> wrote:
> cclib 0.7 release branch created based on trunk revision 479.
> Development should still occur on the trunk (or the parser refactoring
> branch). I'll look after merging stable changes to the release branch
> every so often.
>
> Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> final Jaguar tests.
>
> Noel
>
> On 02/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > Sounds like this is starting to turn into a major refactoring, and I'm
> > > a bit wary of having this on the trunk, especially as it will be
> > > experimental for the first while. Can you put this on a branch instead
> > > and just test with a single parser for the moment?
> >
> > Karol, it does sound like you are doing some interesting work, but I
> > agree with Noel that this should be developed someplace other than
> > where our current changes are. Especially since my most recent
> > version of PyMOlyze uses trunk as that's where the CDA and
> > FragmentAnalysis code is.
> >
> > What are the current features we are hoping to have in cclib 0.7? If
> > there aren't going to be many changes (esp to parsers), I think it
> > makes sense to merge trunk (from before the refactoring) into a
> > cclib-0.7 branch. If we decide we like the refactoring changes, we
> > can merge those into cclib-0.7 once its stable. What do y'all think?
> >
> > Adam
> >
> >
> >
>

[cclib-devel] More moving towards release

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

Some more thoughts:
(1) Let's not let Jaguar hold up our release date.
(2) The only coding left to do (right??) is coreelectrons for a couple
of parsers (see the development wiki). I've uploaded some test files.
Please email this list before you start writing a coreelectrons parser
so that we don't duplicate the effort. When this is done, we'll
release.
(3) Adam, could you add some text to the Changelog regarding new
methods being added in cclib 0.7? I think this might be easier for
you.
(4) To manage merging to the release branch, I'm using svnmerge.py
from http://www.orcaware.com/svn/wiki/Svnmerge.py, so I'd appreciate
if you didn't merge things by hand to the release branch, but rather
left it to me or used svnmerge.
(5) We typically release a beta first; and then a week or two later,
the final release. For the record I'll be away from 7th to 17th March
(St. Patrick's Day, woo hoo).

Noel

Re: [cclib-devel] PyVib2

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

On 25/02/07, Maxim Fedorovsky <Max...@un...> wrote:
> Noel O'Boyle schrieb:
> > On 24/02/07, Maxim Fedorovsky <Max...@un...> wrote:
> >>        Dear developers of cclib,
> >>
> >>     I have started a Python project, called PyVib2
> >> http://pyvib2.sourceforge.net/ , which probably could be interesting for
> >> you.
> >
> > Indeed it is. Very impressive, although I must admit that I wasn't
> > able to open any files due to an error with VTK on Windows (see end of
> > message for the text, but I think that this error has nothing to do
> > with pyvib2).
> >
> > However, I can see it's a very useful program. As I said to you in an
> > earlier email, we would be very interested in integrating cclib and
> > pyvib2. From our point of view, this would basically involve
> > extracting some extra information from the output files of the
> > different programs with your guidance.
> Thank you) I think we could make some work together in order to avoid
> the double overhead :)

That would be great.

> However, if I understood it correctly, you want to provide the user with
> an universal suite of parsers for extracting a big set of properties
> from the main computational packages. Our primary goal is to facilitate
> the interpretation of results.
Yes, exactly.

> As you have probably seen, we are working
> mainly with Gaussian and DALTON. I'am planning to spend time in
> programming new parsers (e.g. for Turbomole and ADF) if it would help
> the user to use the functionalities of PyVib2 and if someone would
> *really* need it.
We don't currently support DALTON or Turbomole (simply because we
don't have access to these programs), but we do have parsers for ADF,
Gaussian, GAMESS, GAMESS-UK and (soon) Jaguar. We also have parsers
for Molpro and Molcas at various stages of development.

In the short term, we are likely to be busy as we are close to a new
release, but after that we can start adding whatever new attributes
you are interested in.

> > By the way, some nice features
> > of cclib that you may not be aware of are automatic detection of the
> > appropriate parser for a particular file, and the ability to handle
> > .gz, .tar, .zip, and .bz2 files.
> >
> > What do you think?
> You mean that cclib looks inside a file to determine its type ? It is
> nice.
Exactly, it makes things a lot easier when using cclib in applications
as the user doesn't have to choose the name of the program, or rely on
extensions.

> > couldn't load library "vtkRenderingPythonTkWidgets.dll": this library
> > or a dependent library could not be found in library path
> >
> > VTK don't provide a binary with the Python interface, so I got it from:
> >    http://mayavi.sourceforge.net/dwnld/vtk/win32/
> >
>
> Unfortunately, the installation of VTK under Windows is not so painless
> as under Linux :( I have compiled VTK from the source with Microsoft
> Visual Studio 6.0. Under a Debian-based Linux "apt-get install
> python-vtk" would do the job perfectly.
Yes, I used to have Debian too. Maybe I can install it with VMWare or
something. Would it be possible for you to use py2exe to create a
massive binary for Windows users?

Regards,
   Noel

Re: [cclib-devel] PyVib2

[Maxim F. <Max...@un...>]

Noel O'Boyle schrieb:
> On 24/02/07, Maxim Fedorovsky <Max...@un...> wrote:
>>        Dear developers of cclib,
>>
>>     I have started a Python project, called PyVib2
>> http://pyvib2.sourceforge.net/ , which probably could be interesting for
>> you.
>
> Indeed it is. Very impressive, although I must admit that I wasn't
> able to open any files due to an error with VTK on Windows (see end of
> message for the text, but I think that this error has nothing to do
> with pyvib2).
>
> However, I can see it's a very useful program. As I said to you in an
> earlier email, we would be very interested in integrating cclib and
> pyvib2. From our point of view, this would basically involve
> extracting some extra information from the output files of the
> different programs with your guidance.
Thank you) I think we could make some work together in order to avoid 
the double overhead :)

However, if I understood it correctly, you want to provide the user with 
an universal suite of parsers for extracting a big set of properties 
from the main computational packages. Our primary goal is to facilitate 
the interpretation of results. As you have probably seen, we are working 
mainly with Gaussian and DALTON. I'am planning to spend time in 
programming new parsers (e.g. for Turbomole and ADF) if it would help 
the user to use the functionalities of PyVib2 and if someone would 
*really* need it.

> By the way, some nice features
> of cclib that you may not be aware of are automatic detection of the
> appropriate parser for a particular file, and the ability to handle
> .gz, .tar, .zip, and .bz2 files.
>
> What do you think?
You mean that cclib looks inside a file to determine its type ? It is 
nice. My simple pyviblib.io.parsers.ParserFactory.create_parser() just 
analyzes the extension.

> couldn't load library "vtkRenderingPythonTkWidgets.dll": this library
> or a dependent library could not be found in library path
>
> VTK don't provide a binary with the Python interface, so I got it from:
>    http://mayavi.sourceforge.net/dwnld/vtk/win32/
>

Unfortunately, the installation of VTK under Windows is not so painless 
as under Linux :( I have compiled VTK from the source with Microsoft 
Visual Studio 6.0. Under a Debian-based Linux "apt-get install 
python-vtk" would do the job perfectly.


With best regards,
Maxim Fedorovsky.

Re: [cclib-devel] PyVib2

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

On 24/02/07, Maxim Fedorovsky <Max...@un...> wrote:
>        Dear developers of cclib,
>
>     I have started a Python project, called PyVib2
> http://pyvib2.sourceforge.net/ , which probably could be interesting for
> you.

Indeed it is. Very impressive, although I must admit that I wasn't
able to open any files due to an error with VTK on Windows (see end of
message for the text, but I think that this error has nothing to do
with pyvib2).

However, I can see it's a very useful program. As I said to you in an
earlier email, we would be very interested in integrating cclib and
pyvib2. From our point of view, this would basically involve
extracting some extra information from the output files of the
different programs with your guidance. By the way, some nice features
of cclib that you may not be aware of are automatic detection of the
appropriate parser for a particular file, and the ability to handle
.gz, .tar, .zip, and .bz2 files.

What do you think?

Regards,
    Noel

Error message follows:
>>>>>>>>>>>>>>>>>>>>>>>>>>
couldn't load library "vtkRenderingPythonTkWidgets.dll": this library
or a dependent library could not be found in library path

Traceback :
  File "C:\Python24\Lib\site-packages\pyviblib\gui\main.py", line 378,
in __open_file
    self.__append_molecule(mol, parser)
  File "C:\Python24\Lib\site-packages\pyviblib\gui\main.py", line 285,
in __append_molecule
    check_command=self.__update_GUI)
  File "C:\Python24\Lib\site-packages\pyviblib\gui\widgets.py", line
6013, in __init__
    BaseWidget.__init__(self, **kw)
  File "C:\Python24\Lib\site-packages\pyviblib\gui\widgets.py", line
127, in __init__
    self._constructGUI()
  File "C:\Python24\Lib\site-packages\pyviblib\gui\widgets.py", line
6043, in _constructGUI
    self._varsdict['renderWidget'] = MoleculeRenderWidget(self, **kw)
  File "C:\Python24\Lib\site-packages\pyviblib\gui\widgets.py", line
324, in __init__
    vtktkrw.vtkTkRenderWidget.__init__(self, master,
  File "C:\Python24\lib\site-packages\vtk_python\vtk\tk\vtkTkRenderWidget.py",
line 84, in __init__
    vtkLoadPythonTkWidgets(master.tk)
  File "C:\Python24\lib\site-packages\vtk_python\vtk\tk\vtkLoadPythonTkWidgets.py",
line 63, in vtkLoadPythonTkWidgets
    interp.call('load', filename)

VTK don't provide a binary with the Python interface, so I got it from:
    http://mayavi.sourceforge.net/dwnld/vtk/win32/

[cclib-devel] PyVib2

[Maxim F. <Max...@un...>]

       Dear developers of cclib,

    I have started a Python project, called PyVib2 
http://pyvib2.sourceforge.net/ , which probably could be interesting for 
you.

   
    With best regards,
    Maxim Fedorovsky.

[cclib-devel] Fwd: Cclib parsing problems

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

---------- Forwarded message ----------
From: Noel O'Boyle <bao...@gm...>
Date: 23-Feb-2007 15:52
Subject: Re: Cclib parsing problems
To: "Bradshaw, Charles F." <cbr...@mi...>


Yes, this is another problem. And thanks again for reporting it.

We haven't trained cclib on a file with imaginary frequencies. Here's
a workaround for you, replace the 'I' on line 7405 of your log file
with a space. We need to fix this at our end though.

I would like to use your log file as a test file for cclib, to ensure
that this problem is fixed. Are you willing to donate your log file
into the public domain? Be clear what this means - it will be freely
available for downloading from the cclib website
(http://www.sf.net/projects/cclib) and you will not be able to change
your mind afterwards.

Regards,
    Noel

On 23/02/07, Bradshaw, Charles F. <cbr...@mi...> wrote:
>  Noel,
>
> The attached GAMESS log of a Hessian run fails to parse.
>
> Best regards,
>
> Charlie
>
>
> Dr. Charles F. Bradshaw
> The MITRE Corporation
> MS T630
> 7515 Colshire Drive
> McLean, VA 22102-7508
> W - 703-983-5847
> C - 703-932-5427
> Fax - 703-983-6989
>
>

Re: [cclib-devel] Fwd: Things to do before release

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

>> What remains to do before release:
>> (1) Documentation (volume.py...Noel)
>> (2) Jaguar mpenergies for water at MP2/3/4/5...no need for all the
>> orbitals and overlap matrices
>> (3) coreelectron tests and parsing (may need test files)
>> (4) Change testcda.py into unittest format
>>
>> Anything else?
>>
>> Noel
>
> *(2) If we get some test files for Jaguar MP runs, I'll add the  
> parsing code.
> I added a note on the wiki about moenergies.

As near as I can tell, Jaguar 6.0 only does MP2 (and it's a custom  
modification they call local MP2) and not MP3/4/5. I'm also not  
overly familiar with Jaguar and those in my group who actually use  
Jaguar only do DFT, so I think those in my group should be a last  
resort. Perhaps we should see if a more experienced volunteer, say on  
ccl.net, would be willing to run these calcs for us?

Adam

Re: [cclib-devel] Coreelectrons

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

> Well, that'd be great. Could you leave out the population analysis
> section to keep things small.

Done. It's got a double-zeta basis set on all atoms, with a frozen  
core (3d) on the Mo. I briefly looked through the PRINT/EPRINT  
options, and removed what I thought was possible. It parses, although  
I don't know how accurate it is.

Adam

Re: [cclib-devel] Coreelectrons

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

On 22/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > It's probably not possible to standardise the pseudopotential used
> > across all programs, but I think that we can at least use the same
> > molecule. Adam has already uploaded MoOCl4 for Gaussian, and Mo for
> > ADF. I'd prefer to go with MoOCl4 in general as it has at least 1 atom
> > with no pseudopotential, and at least 2 atoms with different
> > coreelectrons. I don't know if there's any need to recreate another
> > one for ADF, although it might be a good idea.
>
> I actually just ran MoOCl4 for my research using ADF. It's using a
> triple zeta with polarization, so if that's ok with you, I can upload
> those files today. If not, I can rerun them with a smaller basis set
> if you want.

Well, that'd be great. Could you leave out the population analysis
section to keep things small.

> > I note that the Gaussian file is LanL2 for Mo and Cl, and the ADF file
> > seems to magically have a frozen core (can you confirm this Adam, as
> > there doesn't seem to be any keywords for frozen core in the input
> > file?). I'm going to try to create something similar for GAMESS. BTW,
> > I don't think there's any need for the overlap matrix and
> > coefficients...I think we are testing these sufficiently already.
>
> Without turning on relativistic effects, ADF only has basis functions
> with a frozen core for Mo, although I don't know if it chose the
> basis set with the 3d or 4p in the core. Also, I should point out in
> case you aren't aware: ADF doesn't use gaussian-type orbitals, but
> rather Slater-type orbitals.
OK, just to check.

> Adam
>
>

Re: [cclib-devel] Coreelectrons

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

> It's probably not possible to standardise the pseudopotential used
> across all programs, but I think that we can at least use the same
> molecule. Adam has already uploaded MoOCl4 for Gaussian, and Mo for
> ADF. I'd prefer to go with MoOCl4 in general as it has at least 1 atom
> with no pseudopotential, and at least 2 atoms with different
> coreelectrons. I don't know if there's any need to recreate another
> one for ADF, although it might be a good idea.

I actually just ran MoOCl4 for my research using ADF. It's using a  
triple zeta with polarization, so if that's ok with you, I can upload  
those files today. If not, I can rerun them with a smaller basis set  
if you want.

> I note that the Gaussian file is LanL2 for Mo and Cl, and the ADF file
> seems to magically have a frozen core (can you confirm this Adam, as
> there doesn't seem to be any keywords for frozen core in the input
> file?). I'm going to try to create something similar for GAMESS. BTW,
> I don't think there's any need for the overlap matrix and
> coefficients...I think we are testing these sufficiently already.

Without turning on relativistic effects, ADF only has basis functions  
with a frozen core for Mo, although I don't know if it chose the  
basis set with the 3d or 4p in the core. Also, I should point out in  
case you aren't aware: ADF doesn't use gaussian-type orbitals, but  
rather Slater-type orbitals.

Adam

[cclib-devel] Coreelectrons

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

I've just been creating some coreelectrons tests, but I see that we do
need some more test files.

It's probably not possible to standardise the pseudopotential used
across all programs, but I think that we can at least use the same
molecule. Adam has already uploaded MoOCl4 for Gaussian, and Mo for
ADF. I'd prefer to go with MoOCl4 in general as it has at least 1 atom
with no pseudopotential, and at least 2 atoms with different
coreelectrons. I don't know if there's any need to recreate another
one for ADF, although it might be a good idea.

I note that the Gaussian file is LanL2 for Mo and Cl, and the ADF file
seems to magically have a frozen core (can you confirm this Adam, as
there doesn't seem to be any keywords for frozen core in the input
file?). I'm going to try to create something similar for GAMESS. BTW,
I don't think there's any need for the overlap matrix and
coefficients...I think we are testing these sufficiently already.

Regards,
   Noel

Re: [cclib-devel] Fwd: Things to do before release

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

On Thursday 22 of February 2007 08:52, Noel O'Boyle wrote:
> What remains to do before release:
> (1) Documentation (volume.py...Noel)
> (2) Jaguar mpenergies for water at MP2/3/4/5...no need for all the
> orbitals and overlap matrices
> (3) coreelectron tests and parsing (may need test files)
> (4) Change testcda.py into unittest format
>
> Anything else?
>
> Noel

*(2) If we get some test files for Jaguar MP runs, I'll add the parsing code. 
I added a note on the wiki about moenergies.

-- 
written by Karol Langner
Thu Feb 22 13:05:25 CET 2007

[cclib-devel] Coupled Cluster energies

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

Just wanted to let you know, that to further enlarge the repertoire of 
correlated energies in cclib, I started working on Coupled Cluster runs. I 
will first deal with GAMESS and Gaussian, but in the long run I would 
appreciate if someone could also upload CC test files for Jaguar and 
GAMESS-UK, which I don't have access to.

Cheers,
Karol

-- 
written by Karol Langner
Thu Feb 22 13:01:40 CET 2007