cclib-devel — Developer's mailing list

[cclib-devel] frequency displacements?

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

Do we have any plans on parsing the displacement vectors for  
frequency, IR, or Raman calculations? I've recently added some pretty  
interesting stuff to PyMOlyze, and adding support to visualize the  
motions at each frequency would probably be quite simple if this  
information were in cclib.

Adam

Re: [cclib-devel] nmo proposal

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

I hate reverting stuff, but it's not until you try something out that
you know for sure whether it's a good idea or not. If I was a real SVN
guru, I should be able to think 10 revisions ahead (like those chess
masters). :-)

Have a nice holiday. I'll try and get some of this stuff sorted out
over the next while.

Noel

On 22/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > In your original email below, you say that Jaguar doesn't always have
> > the same number of alpha orbitals as beta orbitals. I think you mean
> > that it doesn't print information on the same number of alpha orbitals
> > as beta orbitals. Just like GAMESS-UK, then, I think - they actually
> > have the same number of alpha and beta orbitals, but just the
> > information on them isn't there (this is speculation, but it is
> > certainly true for other programs).
>
> You are correct: in Jaguar, there are always the same number of alpha
> orbitals as beta orbitals. However, it doesn't always print the same
> number, esp if the ipvert=X option is enabled. In this case, it only
> prints X virtual orbitals which means that if homos[0] != homos[1]
> we'll get a different amount of information for the alpha orbitals
> compared to the beta orbitals.
>
> > If what I say is true, then I don't think it helps to redefine nmo as
> > the orbitals for which there is information in the log file. Instead,
> > we should just relax the constraint that len(moenergies)==nmo, and
> > that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs
> > on which we have M.O. energies, and len(mocoeffs) is the number of MOs
> > for which we have mocoeffs. For unrestricted calcs, we should perhaps
> > move to a list of rank 2 arrays for mocoeffs, which can be of
> > different sizes depending on how orbitals are described in the log
> > file: mocoeff = [ alphamocoeffs, betamocoeffs ].
>
> I would definitely support mocoeffs being a list of rank 2 arrays to
> address the fact that alphamocoeffs and betamocoeffs could be
> different sizes. I think it also means that we should change
> moenergies to reflect something similar (list of rank 1 arrays).
>
> > Overall, what I'm trying to say, is that we are ending up redefining
> > nmo to give a value which we can already find by looking at
> > len(moenergies) or len(mocoeffs). And now that we realise that for
> > GAMESS-UK these values are not always equal to each other, it makes
> > less sense than ever.
>
> I agree with you here. My original suggestion was made because
> alphamocoeffs and betamocoeffs would be different sizes, so i figured
> it was just easier to make the mocoeffs matrix as large as nbasis x
> nbasis, and adjust nmo so that we know which coefficients are "real".
>
> > We've both done some work on this already, but I'm worried that we're
> > following red herrings. I think we can solve the Jaguar problem
> > without doing this. Would the modifications I suggest be sufficient to
> > handle Jaguar files?
>
> In summary, yes, I think we can revert nmo back to it's original
> definition if we change the definition of mocoeffs and moenergies as
> outlined above. Since your the SVN guru, will you revert the nmo
> changes back?
>
> Adam
>
> P.S. I'm on holiday for the next few days without internet.
>
>

Re: [cclib-devel] nmo proposal

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

> In your original email below, you say that Jaguar doesn't always have
> the same number of alpha orbitals as beta orbitals. I think you mean
> that it doesn't print information on the same number of alpha orbitals
> as beta orbitals. Just like GAMESS-UK, then, I think - they actually
> have the same number of alpha and beta orbitals, but just the
> information on them isn't there (this is speculation, but it is
> certainly true for other programs).

You are correct: in Jaguar, there are always the same number of alpha  
orbitals as beta orbitals. However, it doesn't always print the same  
number, esp if the ipvert=X option is enabled. In this case, it only  
prints X virtual orbitals which means that if homos[0] != homos[1]  
we'll get a different amount of information for the alpha orbitals  
compared to the beta orbitals.

> If what I say is true, then I don't think it helps to redefine nmo as
> the orbitals for which there is information in the log file. Instead,
> we should just relax the constraint that len(moenergies)==nmo, and
> that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs
> on which we have M.O. energies, and len(mocoeffs) is the number of MOs
> for which we have mocoeffs. For unrestricted calcs, we should perhaps
> move to a list of rank 2 arrays for mocoeffs, which can be of
> different sizes depending on how orbitals are described in the log
> file: mocoeff = [ alphamocoeffs, betamocoeffs ].

I would definitely support mocoeffs being a list of rank 2 arrays to  
address the fact that alphamocoeffs and betamocoeffs could be  
different sizes. I think it also means that we should change  
moenergies to reflect something similar (list of rank 1 arrays).

> Overall, what I'm trying to say, is that we are ending up redefining
> nmo to give a value which we can already find by looking at
> len(moenergies) or len(mocoeffs). And now that we realise that for
> GAMESS-UK these values are not always equal to each other, it makes
> less sense than ever.

I agree with you here. My original suggestion was made because  
alphamocoeffs and betamocoeffs would be different sizes, so i figured  
it was just easier to make the mocoeffs matrix as large as nbasis x  
nbasis, and adjust nmo so that we know which coefficients are "real".

> We've both done some work on this already, but I'm worried that we're
> following red herrings. I think we can solve the Jaguar problem
> without doing this. Would the modifications I suggest be sufficient to
> handle Jaguar files?

In summary, yes, I think we can revert nmo back to it's original  
definition if we change the definition of mocoeffs and moenergies as  
outlined above. Since your the SVN guru, will you revert the nmo  
changes back?

Adam

P.S. I'm on holiday for the next few days without internet.

Re: [cclib-devel] nmo proposal

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

Adam,

I've been thinking about this a bit more and I feel that we've moved
too far from the original problem, especially now that it's becoming
less and less clear what the value of nmo should be in particular
cases.

In your original email below, you say that Jaguar doesn't always have
the same number of alpha orbitals as beta orbitals. I think you mean
that it doesn't print information on the same number of alpha orbitals
as beta orbitals. Just like GAMESS-UK, then, I think - they actually
have the same number of alpha and beta orbitals, but just the
information on them isn't there (this is speculation, but it is
certainly true for other programs).

If what I say is true, then I don't think it helps to redefine nmo as
the orbitals for which there is information in the log file. Instead,
we should just relax the constraint that len(moenergies)==nmo, and
that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs
on which we have M.O. energies, and len(mocoeffs) is the number of MOs
for which we have mocoeffs. For unrestricted calcs, we should perhaps
move to a list of rank 2 arrays for mocoeffs, which can be of
different sizes depending on how orbitals are described in the log
file: mocoeff = [ alphamocoeffs, betamocoeffs ].

Overall, what I'm trying to say, is that we are ending up redefining
nmo to give a value which we can already find by looking at
len(moenergies) or len(mocoeffs). And now that we realise that for
GAMESS-UK these values are not always equal to each other, it makes
less sense than ever.

We've both done some work on this already, but I'm worried that we're
following red herrings. I think we can solve the Jaguar problem
without doing this. Would the modifications I suggest be sufficient to
handle Jaguar files?

Noel

On 24/10/06, Adam Tenderholt <a-t...@st...> wrote:
> Some quantum chemistry programs (eg. Jaguar) don't always have the
> same number of alpha orbitals as beta orbitals. Therefore, I propose
> that we change nmo from an integer to a list of integers like
> mocoeffs currently is. This would also mean in these cases, mocoeffs
> should have dimension (1 or 2, nbasis, nbasis) as nmo should always
> be less than or equal to nbasis. Comments?
>
> If this change is agreed upon, then I say we implement this after the
> 0.6 release so as to keep merging bugfix changes easy; alternatively,
> we could create a 0.8 trunk where these changes can be made.
> (Speaking of which, is there a timeframe for the 0.6 release? The ADF
> errors have been fixed as near as I can tell so regression.py passes
> all of the tests and only errors on the one ADF file which is missing
> MO info.)
>
> Adam
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Sorry

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

It seems to be working for csjacky (the user who reported the bug)
now. I've created a new release, which is now up on SF (includes two
bug fixes to gaussian parser). I'll update the other distribution
sites today or tomorrow.

Noel

On 21/11/06, Noel O'Boyle <bao...@gm...> wrote:
> Yes - I've caught the Jaguar one now too. All unit tests and
> regression tests now pass (the latter also needed editing to remove a
> reference to Jaguar). I can't believe I missed all of this.
>
> I will send a prerelease to the user as you suggest. But I need to
> take some more time to update the Changelog, as I think I merged
> another bug fix for G03 since 0.6.
>
> The new openlogfile() command uses the extension of the log file to
> determine whether it is a .zip, .bz, .gz or none of the above. I'm not
> sure why the code failed though...even if a filename is passed which
> doesn't have an extension it should still work.
>
> What does this give on your system?
> >>> import os.path
> >>> os.path.splitext("base.ext")
> ('base', '.ext')
> >>> os.path.splitext("base")
> ('base', '')
> >>> "base.ext".rfind(".")
> 4
> >>> "base".rfind(".")
> -1
>
> Was there something strange about the filename you used?
>
> It says "AttributeError: rfind" in your message below. This implies
> that a string was not passed to splitext (I've just been looking at
> the source code...it's only a four line function or so), since all
> strings should have the .rfind() method. How did you call this method?
>
> Noel
>
> On 21/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > > Looks like I messed up making the 0.6 release...I forgot to remove two
> > > references to the molproparser.
> >
> > Did you get the references to jaguarparser as well? I ran into that
> > problem when I removed cclib and tried reinstalling 0.6.
> >
> > Also, I'm having problems with trunk. Looks like it has to do with
> > utils.py and your new extension framework for detecting zipped files,
> > although I'm not positive since ccget seems to be working just fine.
> >
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/site-packages/pymolyze/pymolyze.py", line 128, in open
> >      parser=ccopen(filename,progress,logging.ERROR)
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/site-packages/cclib/parser/utils.py", line 50, in ccopen
> >      inputfile = openlogfile(filename)
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/site-packages/cclib/parser/utils.py", line 29, in openlogfile
> >      extension = os.path.splitext(filename)[1]
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/posixpath.py", line 92, in splitext
> >      i = p.rfind('.')
> > AttributeError: rfind
> >
> > > Of course, it worked for me because molparser.py *is* present on my
> > > system -- I need to uninstall old versions of cclib in future before
> > > trusting that they're fixed. I'd like to get the fix out as soon as
> > > possible, but I'm running short on time today, and I know that I won't
> > > have much time tomorrow. As well as this, I want to make *sure* this
> > > time that everything is fine, so I'm not going to rush out a version.
> >
> > Sounds good to me, although you probably should push a pre-released
> > version to the user who reported this bug as soon as possible so that
> > he can continue working with cclib---I'm guessing this is a
> > relatively minor problem.
> >
> > Adam
> >
> >
> >
>

Re: [cclib-devel] Sorry

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

Yes - I've caught the Jaguar one now too. All unit tests and
regression tests now pass (the latter also needed editing to remove a
reference to Jaguar). I can't believe I missed all of this.

I will send a prerelease to the user as you suggest. But I need to
take some more time to update the Changelog, as I think I merged
another bug fix for G03 since 0.6.

The new openlogfile() command uses the extension of the log file to
determine whether it is a .zip, .bz, .gz or none of the above. I'm not
sure why the code failed though...even if a filename is passed which
doesn't have an extension it should still work.

What does this give on your system?
>>> import os.path
>>> os.path.splitext("base.ext")
('base', '.ext')
>>> os.path.splitext("base")
('base', '')
>>> "base.ext".rfind(".")
4
>>> "base".rfind(".")
-1

Was there something strange about the filename you used?

It says "AttributeError: rfind" in your message below. This implies
that a string was not passed to splitext (I've just been looking at
the source code...it's only a four line function or so), since all
strings should have the .rfind() method. How did you call this method?

Noel

On 21/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > Looks like I messed up making the 0.6 release...I forgot to remove two
> > references to the molproparser.
>
> Did you get the references to jaguarparser as well? I ran into that
> problem when I removed cclib and tried reinstalling 0.6.
>
> Also, I'm having problems with trunk. Looks like it has to do with
> utils.py and your new extension framework for detecting zipped files,
> although I'm not positive since ccget seems to be working just fine.
>
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/pymolyze/pymolyze.py", line 128, in open
>      parser=ccopen(filename,progress,logging.ERROR)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib/parser/utils.py", line 50, in ccopen
>      inputfile = openlogfile(filename)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib/parser/utils.py", line 29, in openlogfile
>      extension = os.path.splitext(filename)[1]
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/posixpath.py", line 92, in splitext
>      i = p.rfind('.')
> AttributeError: rfind
>
> > Of course, it worked for me because molparser.py *is* present on my
> > system -- I need to uninstall old versions of cclib in future before
> > trusting that they're fixed. I'd like to get the fix out as soon as
> > possible, but I'm running short on time today, and I know that I won't
> > have much time tomorrow. As well as this, I want to make *sure* this
> > time that everything is fine, so I'm not going to rush out a version.
>
> Sounds good to me, although you probably should push a pre-released
> version to the user who reported this bug as soon as possible so that
> he can continue working with cclib---I'm guessing this is a
> relatively minor problem.
>
> Adam
>
>
>

Re: [cclib-devel] nmo woes

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

I just realized I completely misread the email you sent. This is a  
tough call because we really shouldn't say nmo is [60,60] because we  
don't have all that info for the mocoeffs but there are more  
information about moenergies and mosyms above [40,39]. My feeling is  
that nmo should correspond to the number that maximizes information  
(ie. in this case, [40,39]) and that we put a note on the wiki that  
there may be information up to nbasis, but we can't guarantee it's  
existence or accuracy.

Adam

On Nov 19, 2006, at 10:41 AM, Noel O'Boyle wrote:

> Hello Adam,
>
> I'm a bit unsure about what to do with the GAMESS-UK nmo's.
>
> For the unrestricted calculation (for example), there are 60 MOs, and
> there are moenergies and mosyms for all sixty alpha and beta.
>
> However, mocoeffs are only available for the 40 lowest alpha MOs, and
> the 39 lowest beta MOs (that is, by default it provides information on
> the occupied MOs and the 5 lowest unoccupied MOs).
>
> So, is nmo [60,60] or [40,39]? The current definition of nmo doesn't
> make this clear, so we'd better decide one way or another and refine
> the definition.
>
> Regards,
>  Noel

Re: [cclib-devel] nmo woes

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

Hey Noel,

> So, is nmo [60,60] or [40,39]? The current definition of nmo doesn't
> make this clear, so we'd better decide one way or another and refine
> the definition.

In this case, nmo should be [40,39] since there are 40 alpha and 39  
beta orbitals. This will allow us to iterate over all of the orbital  
coefficients as follows:

for spin in range(2):

	for i in range(len(nmo[spin]):
		
		for j in range(nbasis):

			print "The coefficient of the %i basis function to the %ith  
molecular orbital of spin %i is %6.3f\"%(j, i, spin, mocoeffs[spin,i,j])


(Apologies for weird word-wrapping that may happen.)

Remember that mocoeffs should be size (1 or 2, nbasis, nbasis) and  
initially filled with zeros. Hope this helps,

Adam

	
>
> Regards,
>   Noel
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

[cclib-devel] nmo woes

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

Hello Adam,

I'm a bit unsure about what to do with the GAMESS-UK nmo's.

For the unrestricted calculation (for example), there are 60 MOs, and
there are moenergies and mosyms for all sixty alpha and beta.

However, mocoeffs are only available for the 40 lowest alpha MOs, and
the 39 lowest beta MOs (that is, by default it provides information on
the occupied MOs and the 5 lowest unoccupied MOs).

So, is nmo [60,60] or [40,39]? The current definition of nmo doesn't
make this clear, so we'd better decide one way or another and refine
the definition.

Regards,
  Noel

[cclib-devel] cclib used by PyMOlyze

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

Hi Adam,

I've just seen that you've released the first version of PyMOlyze that
uses cclib. Congrats!

I've also noticed that cclib, GaussSum and PyMOlyze are all in a row
in the top 10 chemistry projects on sourceforge (or were yesterday).
This is a real case of open source cooperation and promotion of
interoperability leading to benefits above and beyond what we would
have had working on our own in parallel (buzzword alert: "synergy").
We all benefit from the same bug fixes in cclib. As well as that,
other users and programmers benefit in having access to the parsers
and algorithms that we use ourselves.

Three cheers for PyMOlyze, GaussSum and of course, cclib. :-)

Noel

[cclib-devel] Bug with no sym z-matrix Gaussian file

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

I've just uploaded a small test file (water defined by a z-matrix with
keyword NOSYM) for the r400 bugfix, but it fails to parse on the
current HEAD due to some coreelectrons code looking for natom, which
isn't defined (but should be).

I'm checking in a regression.py with the failing test.

Noel

Re: [cclib-devel] nmo proposal

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

On 31/10/06, Adam Tenderholt <a-t...@st...> wrote:
> >> Some quantum chemistry programs (eg. Jaguar) don't always have the
> >> same number of alpha orbitals as beta orbitals. Therefore, I propose
> >> that we change nmo from an integer to a list of integers like
> >> mocoeffs currently is. This would also mean in these cases, mocoeffs
> >> should have dimension (1 or 2, nbasis, nbasis) as nmo should always
> >> be less than or equal to nbasis. Comments?
> >
> > Sounds good, except that mocoeffs is *not* currently a list of
> > integers. It's a rank 3 array.
>
> Right. Which is why the size of the mocoeffs array should have
> dimension (1 or 2, nbasis, nbasis). Anything not assigned would be
> zero, and it's up to the user of cclib to decide what elements are
> valid based on nmo and nbasis (and spin). I think it's a safe
> assumption that the orbitals we know about run from zero to nmo (even
> in the one ADF case, I think mocoeffs was correct).
>
> > So, how many attributes will we need to change?:
> > (1) nmo
>
> Change this to a list. In most cases we've seen, nmo[0] == nmo[1] but
> we're making this change to address the case when nmo[0] != nmo[1].

> > (2) mocoeffs
>
> See above.
>
> > (3) moenergies
>
> This should probably be a rank two array with size (1 or 2, nbasis)
> with unassigned elements 99999 like we did with the one ADF file.
>
> > (4) mosyms (maybe, it's fine as it is though)
>
> My guess is for most cases this is fine, although we may want to
> consider size (1 or 2, nbasis) and unassigned elements get A symmetry.
>
> > So we need to...
> > (1) update the wiki
> > (2) update the unit tests/regression tests
> > (3) add any extra tests we need to make sure we're obeying the wiki
> > (4) change the code (let's just work off the HEAD revision).
>
> Sounds good.
>
> > And the best part is that I'll even do some of this myself, as I'll
> > start to have a bit more free time after next Monday (yippee!).

OK - thanks for explaining this in depth - I actually had the wrong
idea. I thought we were going to split everything into two separate
arrays for alpha and beta, e.g. moenergies[0] and moenergies[1] which
would be of lengths nmo[0] and nmo[1] respectively (and similarly for
mocoeffs, mosyms and so on).

I'm happy to make the changes you suggest; I'll start by making some
changes to the wiki which you might doublecheck. I'll put the new
information on the attribute pages under a subheading like
"Development version" or "cclib 0.7" or something, to avoid confusing
users.

BTW, I've merged the zip branch to the HEAD and compressed the
regression files on the web server. See r402.

Regards,
   Noel

Re: [cclib-devel] nmo proposal

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

>> Some quantum chemistry programs (eg. Jaguar) don't always have the
>> same number of alpha orbitals as beta orbitals. Therefore, I propose
>> that we change nmo from an integer to a list of integers like
>> mocoeffs currently is. This would also mean in these cases, mocoeffs
>> should have dimension (1 or 2, nbasis, nbasis) as nmo should always
>> be less than or equal to nbasis. Comments?
>
> Sounds good, except that mocoeffs is *not* currently a list of
> integers. It's a rank 3 array.

Right. Which is why the size of the mocoeffs array should have  
dimension (1 or 2, nbasis, nbasis). Anything not assigned would be  
zero, and it's up to the user of cclib to decide what elements are  
valid based on nmo and nbasis (and spin). I think it's a safe  
assumption that the orbitals we know about run from zero to nmo (even  
in the one ADF case, I think mocoeffs was correct).

> So, how many attributes will we need to change?:
> (1) nmo

Change this to a list. In most cases we've seen, nmo[0] == nmo[1] but  
we're making this change to address the case when nmo[0] != nmo[1].

> (2) mocoeffs

See above.

> (3) moenergies

This should probably be a rank two array with size (1 or 2, nbasis)  
with unassigned elements 99999 like we did with the one ADF file.

> (4) mosyms (maybe, it's fine as it is though)

My guess is for most cases this is fine, although we may want to  
consider size (1 or 2, nbasis) and unassigned elements get A symmetry.

> So we need to...
> (1) update the wiki
> (2) update the unit tests/regression tests
> (3) add any extra tests we need to make sure we're obeying the wiki
> (4) change the code (let's just work off the HEAD revision).

Sounds good.

> And the best part is that I'll even do some of this myself, as I'll
> start to have a bit more free time after next Monday (yippee!).

:o)

Adam

Re: [cclib-devel] nmo proposal

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

OK Adam, let's do it. I suppose it is a bit of a hack to fill empty
MOs with zeros.

> Some quantum chemistry programs (eg. Jaguar) don't always have the
> same number of alpha orbitals as beta orbitals. Therefore, I propose
> that we change nmo from an integer to a list of integers like
> mocoeffs currently is. This would also mean in these cases, mocoeffs
> should have dimension (1 or 2, nbasis, nbasis) as nmo should always
> be less than or equal to nbasis. Comments?

Sounds good, except that mocoeffs is *not* currently a list of
integers. It's a rank 3 array.

So, how many attributes will we need to change?:
(1) nmo
(2) mocoeffs
(3) moenergies
(4) mosyms (maybe, it's fine as it is though)

So we need to...
(1) update the wiki
(2) update the unit tests/regression tests
(3) add any extra tests we need to make sure we're obeying the wiki
(4) change the code (let's just work off the HEAD revision).

And the best part is that I'll even do some of this myself, as I'll
start to have a bit more free time after next Monday (yippee!).

Noel

[cclib-devel] ANN: cclib 0.6 released

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

cclib 0.6 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.

Compared to cclib 0.5, the main changes are:
    * addition of a GAMESS-UK parser
    * Overlap Population analysis now much faster
    * renamed guesstype to ccopen
    * Several bug fixes for the ADF and Gaussian parsers
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

[cclib-devel] cclib 0.6 uploaded

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

cclib 0.6 has been tagged and uploaded. I've included that final
bugfix of yours relating to the SCF convergence. I got very confused
this morning as I didn't update my local tree, and ended up fixing the
same bug as you did, only to realise that it had already been done.
:-P

Anyway, I'll do the publicity tomorrow (cclib mailing lists,
freshmeat, pypi, gamess-uk forum, possibly CCL), but feel free to
update the download links on the wiki - it should be on all of the
sourceforge mirrors now.

Will this be the version that sets the computational chemistry world
alight? We'll soon find out...:-)

   Noel

Re: [cclib-devel] nmo proposal

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

> I've made the changes. If the file is missing any MO info, it fills
> moenergies with 99999 and mosyms with 'A'. It now passes the
> regression test, although I haven't fully checked whether mocoeffs
> are accurate. Let me know if there is anything else we should do.

Great. I'll start the merge. Might be good to double check the user
docs on the wiki to see whether there's anything that needs updating.
I think the only API addition is the .clean() method. Also, you want
want to add some names to THANKS.

Just a note to say that I've been playing about with .zip, .bz2, .gz
support for output files on a branch that I'll merge *after* the
release. It seems to be working without any problems and all using
standard Python libraries, but we can verify this later.

Noel

Re: [cclib-devel] nmo proposal

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

> I would be reluctant to change things so much. I have had similar
> issues with GAMESS-UK, and AFAIK there is a switch that can be passed
> to Jaguar to make it print out all of the alpha and beta orbitals. Let
> us come back to this a little later.

I agree with coming back to this a bit later. The reason I bring it  
up now is one of my colleagues often only prints 15 or so virtual  
orbitals because of space reasons---she claims it causes Jaguar to  
crash, but I don't entirely believe her. This creates a problem  
because she often deals with S=2 or S=5/2 systems, so there will be  
an unequal number of alpha and beta orbitals. Let's postpone thinking  
about this for now, but I do think it is a (hopefully minor) change  
we should think about.

> Indeed, I have to say "well done", Adam. You've put a lot of work into
> squashing these bugs and I think we can count on fairly good coverage
> of 'log file space', now. The timeframe is as soon as we figure out
> what to do about the final error on the ADF file. Check out my email
> of 12th Oct reproduced here:

I feel like I've just been catching up for the all the coding I  
didn't  do during the summer while you were working on the GAMESS  
parsers. :o)

> """
> There is now only a single error in regression.py, which is the
> problem 1 below. Can we avoid getting a parse error in this case by
> refusing to create moenergies, or by filling MOs 1-25 with moenergies
> of 9999 (i.e. to indicate a problem). I think that users should be
> able to get the energies of the homo and lumo even though there is a
> problem with the rest of them. What do you think?
> """

I've made the changes. If the file is missing any MO info, it fills  
moenergies with 99999 and mosyms with 'A'. It now passes the  
regression test, although I haven't fully checked whether mocoeffs  
are accurate. Let me know if there is anything else we should do.

Adam

Re: [cclib-devel] nmo proposal

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

On 24/10/06, Adam Tenderholt <a-t...@st...> wrote:
> Some quantum chemistry programs (eg. Jaguar) don't always have the
> same number of alpha orbitals as beta orbitals. Therefore, I propose
> that we change nmo from an integer to a list of integers like
> mocoeffs currently is. This would also mean in these cases, mocoeffs
> should have dimension (1 or 2, nbasis, nbasis) as nmo should always
> be less than or equal to nbasis. Comments?

> If this change is agreed upon, then I say we implement this after the
> 0.6 release so as to keep merging bugfix changes easy; alternatively,
> we could create a 0.8 trunk where these changes can be made.

I would be reluctant to change things so much. I have had similar
issues with GAMESS-UK, and AFAIK there is a switch that can be passed
to Jaguar to make it print out all of the alpha and beta orbitals. Let
us come back to this a little later.


> (Speaking of which, is there a timeframe for the 0.6 release? The ADF
> errors have been fixed as near as I can tell so regression.py passes
> all of the tests and only errors on the one ADF file which is missing
> MO info.)

Indeed, I have to say "well done", Adam. You've put a lot of work into
squashing these bugs and I think we can count on fairly good coverage
of 'log file space', now. The timeframe is as soon as we figure out
what to do about the final error on the ADF file. Check out my email
of 12th Oct reproduced here:
"""
There is now only a single error in regression.py, which is the
problem 1 below. Can we avoid getting a parse error in this case by
refusing to create moenergies, or by filling MOs 1-25 with moenergies
of 9999 (i.e. to indicate a problem). I think that users should be
able to get the energies of the homo and lumo even though there is a
problem with the rest of them. What do you think?
"""

Once we sort this out (whatever way), I will make the final release.

Noel

[cclib-devel] nmo proposal

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

Some quantum chemistry programs (eg. Jaguar) don't always have the  
same number of alpha orbitals as beta orbitals. Therefore, I propose  
that we change nmo from an integer to a list of integers like  
mocoeffs currently is. This would also mean in these cases, mocoeffs  
should have dimension (1 or 2, nbasis, nbasis) as nmo should always  
be less than or equal to nbasis. Comments?

If this change is agreed upon, then I say we implement this after the  
0.6 release so as to keep merging bugfix changes easy; alternatively,  
we could create a 0.8 trunk where these changes can be made.  
(Speaking of which, is there a timeframe for the 0.6 release? The ADF  
errors have been fixed as near as I can tell so regression.py passes  
all of the tests and only errors on the one ADF file which is missing  
MO info.)

Adam

Re: [cclib-devel] Another bug

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

> I should feel good that all possible bugs are being ironed out of the
> parsers, but...:-)

I'm glad that we are finding new bugs and fixing them, but I'd be  
much happier if they didn't exist in the first place!! :-P Oh well.

> In tidying up the interaction between regression.py and
> regressionfiles.txt, I found that some of the regression files were
> not being detected, so I added them (regression.py now gives a warning
> if some files are missing, so it won't be possible to make this
> mistake in future). However, one of the new ADF files, Os3.out, gives
> a parsing error:
>
>     aolist = range(len(self.moenergies[spin]))
> AttributeError: 'ADF' object has no attribute 'moenergies'

I believe this has now been fixed in the SVN repository.

Adam

[cclib-devel] Another bug

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

Hello Adam,

I should feel good that all possible bugs are being ironed out of the
parsers, but...:-)

In tidying up the interaction between regression.py and
regressionfiles.txt, I found that some of the regression files were
not being detected, so I added them (regression.py now gives a warning
if some files are missing, so it won't be possible to make this
mistake in future). However, one of the new ADF files, Os3.out, gives
a parsing error:

    aolist = range(len(self.moenergies[spin]))
AttributeError: 'ADF' object has no attribute 'moenergies'

Regards,
   Noel

Re: [cclib-devel] Major ADF bug -- homos

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

Have added the file. Run wget.sh in the data directory to update your
data files.

Was the problem with the web stuff something to do with permissions?
Let me know if it's something that we should fix.

On 22/10/06, Adam Tenderholt <a-t...@st...> wrote:
> A colleague of mine has found a pretty major ADF bug involving the
> homos. I'm having trouble adding the file so I'll forward it to Noel.
>
> Adam
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Major ADF bug -- homos

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

A colleague of mine has found a pretty major ADF bug involving the  
homos. I'm having trouble adding the file so I'll forward it to Noel.

Adam

Re: [cclib-devel] Gaussian: standard versus input orientation

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

I've updated regression.py with a slightly more, um, useful docstring.
:-) Funny thing is, I got very confused because the docstring of the
following unittest seemed almost identical, apart from the
Irishisms...:-)

def testGaussian_basicGaussian03_dvb_un_sp_out(logfile):
    """
    This file had no atomcoords at all at all, due to only having an Input
    Orientation section and no Standard Orientation.
    """
    assert len(logfile.atomnos) == 20
    assert logfile.atomcoords.shape == (1,20,3)

def testGaussian_Gaussian03_Mo4OSibdt2_opt_log(logfile):
    """
    This file had no atomcoords as it did not contain any
    "Input orientation" sections, only "Standard orientation" sections
    """
    assert hasattr(logfile,"atomcoords")


On 11/10/06, Adam Tenderholt <a-t...@st...> wrote:
> Added a fix so that input orientation is used if standard orientation
> isn't found. Info's in the svn log. Also, updated regression.py so
> that it checks for the right dimensions of atomcoords.
>
> Adam
>
>