cclib-devel — Developer's mailing list

[cclib-devel] Missing emails

[Noel O'B. <noe...@ma...>]

SF is currently rejecting mail from gmail accounts. They are supposedly l=
ooking
into this. Until then, I will need to send mail from this account.

I will forward to cclib some of the missing emails...

Regards,
   Noel

Re: [cclib-devel] adf and symmetry > C1

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

Hopefully fixed in SVN revision 356---initial tests of MPA gave  
expected results for handful of molecular orbitals.

Adam

On Sep 29, 2006, at 4:06 PM, Adam Tenderholt wrote:

> Mulliken/C-squared population analysess are broken for ADF files that
> have more symmetry than C1; presumably, this affects other methods.
> As far as I can tell, it's actually a problem with the parser because
> the mocoeffs matrix is block-diagonal as a result of stored symmetry
> elements. That is, the first n rows correspond to the first symmetry
> label with n elements instead of the usual first n rows corresponding
> to the n lowest molecular orbitals. This is with SVN revision number
> 354.
>
> NH3.adfout has been added to the data directory as an example case.
>
> Adam
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

[cclib-devel] adf and symmetry > C1

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

Mulliken/C-squared population analysess are broken for ADF files that  
have more symmetry than C1; presumably, this affects other methods.  
As far as I can tell, it's actually a problem with the parser because  
the mocoeffs matrix is block-diagonal as a result of stored symmetry  
elements. That is, the first n rows correspond to the first symmetry  
label with n elements instead of the usual first n rows corresponding  
to the n lowest molecular orbitals. This is with SVN revision number  
354.

NH3.adfout has been added to the data directory as an example case.

Adam

Re: [cclib-devel] jaguar files

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

> Am currently at conference (just presented cclib), so will just  
> give a brief answer. No mocoeffs! Yikes! Are you sure? I'm pretty  
> sure I tried to get the mocoeffs printed out.

I'm pretty sure there aren't mocoeffs. If there are, it's not labeled  
the same was as jaguar files I have.

How'd the poster on cclib go over?

> Do I still have access to Jaguar?? Hmmm...not officially; will  
> probably need to co-opt someone to help. Otherwise, I can certainyl  
> create the appropriate input file as the manual is on the web. Can  
> you wait until next week when I'll have a chance to look at what we  
> have?

It can wait until next week, and I still do have (indirect) access to  
Jaguar 6.0.

Adam

[cclib-devel] jaguar files

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

So I started looking at parsing Jaguar files today. None of the files  
I've looked at have any mocoeffs! Unless they are identified  
differently than what I'm used to---PyMOlyze looks for a line like  
"Occupied + virtual Orbitals- final wvfn". Noel, do you still have  
access to Jaguar? If not, I'll have to pester my labmate to run a few  
calcs for us and explain the parameters she uses.

Adam

Re: [cclib-devel] molpro parser

[<meh...@ch...>]

> There's a couple of other things I was wondering about: (I know this is
> being pedantic, but we want to get all of this straight from the start,
> before we have 6 parsers doing slightly different things)
> (1) Is mass-weighted better than the alternative (mass-unweighted or
> something)? I know we can compute one from the other (at least, I hope so!),
> but which one should we extract?

Mass-unweighted is generally prefered, (although in this case I parsed
the  weighted one, I will change this) the reason is that then one can
specify different masses and get frequencies and normal modes of for
example the deuteraded species.

> (2) What about geometry optimisations? Are we only going to extract the
> hessian from a frequency calculation?

Extracting the hessian from a geometry optimisation is in general
pointless (and not printed out in most cases) it is anyway an updated
one which is very dependent on the your procedure, what is more
important in my opinion, is to extract the gradient, also if possible
from a geometry optimisation, this is a lot of information about your
PES that should not be thrown away and could/is useful, at least in my
opinion.

> (3) What are the dimensions of the hessian? Can you discuss this some more

I have done a few updates 


Cheers,

Mehdi

Re: [cclib-devel] molpro parser

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

Sorry - I should have pointed you to the development pages on the wiki. The
"parsed data" you edited was information on the release. I've made the
necessary changes. The correct page is linked to from the "Development" link
in the side-bar on the wiki.

There's a couple of other things I was wondering about: (I know this is
being pedantic, but we want to get all of this straight from the start,
before we have 6 parsers doing slightly different things)
(1) Is mass-weighted better than the alternative (mass-unweighted or
something)? I know we can compute one from the other (at least, I hope so!),
but which one should we extract?
(2) What about geometry optimisations? Are we only going to extract the
hessian from a frequency calculation?
(3) What are the dimensions of the hessian? Can you discuss this some more
on
http://cclib.sourceforge.net/wiki/index.php?title=Hessian&action=edit

Regards,
  Noel

On 25/09/06, Noel O'Boyle <bao...@gm...> wrote:
>
>
> > Could you update the wiki with information on the hessian, so that we
> > can
> > > add it to the other parsers. We will also (at some point) need to
> > write a
> > > unit test (similar to testgbasis.py) for the hessian, so that all of
> > the
> > > parsers agree.
> >
> > For the hessian only the lower triangle part is stored so one would need
> > an LowerTriangleArrayToMatrix function i.e.:  [a11, a12, a22, a13,...,
> > ann] to
> > corresponding Matrix, so one can effectively work with. I will probably
> > put it in units.py (it is already written).
>
>
> It's up to you. I usually just fill in a full matrix as I read the data,
> e.g. data[i,j] = data[j,i] = myfloat
>
> For the Wiki I have to put for the hessian as array of rank 1, as it is
> > sometimes easier to work with.
>
>
> Wouldn't it be better as a rank 2 array. If you need to flatten it for
> convenience, you can just use myarray.flat().
>
> Mehdi
> >
> >
> > -------------------------------------------------------------------------
> > 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] adf parser

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

Can you upload to ccl...@gm... the problem log file you refer to
below, along with a line to say when it was fixed? I am currently putting
all of the log files onto the webspace (just to remind you all...these will
be publicly accessible), and will add to SVN a shell script to download any
new ones.


Commit by *atenderholt* :: r*343* /trunk/src/cclib/parser/adfparser.py:
 adfparser on Mo4mdt3-1_102.adfout: If scf doesn't converge "but result is
acceptable", the parser emits a warning and exits a loop; previously, the
parser got stuck in the loop skipping many attributes


On 23/09/06, Noel O'Boyle <bao...@gm...> wrote:
>
> Cool - when I get a chance I'll look into this. Maybe it's also a
> potential problem with the other SCF parsers.
>
> I think as a rule of thumb that all bug fixes should be included in the
> next release. Actually, it helps if you start the log message with "Bug fix"
> so it's quite clear which ones need to applied to the release branch. It's
> also useful when going through the log messages to create a changelog, as it
> makes it easy to separate new features from bug fixes and so on.
>
>  Looking at my own last few commits, it seems I don't even follow my own
> advice though :-)
>
>
> On 23/09/06, Adam Tenderholt < a-t...@st...> wrote:
> >
> > I just fixed a pretty critical (at least in my mind) bug in the ADF
> > parser. It would get stuck in a loop if the SCF didn't fully
> > converge, but gave acceptable results (according to text printed in
> > the logfile), causing numerous attributes to be skipped. I also added
> > a logger warning if EOF is reached while in that loop, which you can
> > remove if you think it is unnecessary.
> >
> > Hopefully this will make the 0.6 release.
> >
> > Adam
> >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
>
>

[cclib-devel] improved Overlap Population code

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

I just rewrote the OPA code. Previously, any overlap population on  
sizable molecules (say more than 60 basis functions) took FOREVER. I  
removed the loop over molecular orbitals and took advantage of a few  
Numeric features that allow addition and multiplication of entire  
arrays at once. OPA of a molecule with four fragments and 500+ basis  
functions now takes about 7 seconds, which is approximately 6 times  
faster than my old PyMOlyze c-module and possibly 50-100 times faster  
than the old OPA code (maybe a slight exaggeration, but I remember it  
being painfully slow compared to the old PyMOlyze).

Although I haven't extensively tested it, the handful of comparisons  
I've made against older versions give the same results for a few  
molecules. I recommend including it in the 0.6 release, unless you  
think there should be more robust testing.

Adam

Re: [cclib-devel] molpro parser

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

> > Could you update the wiki with information on the hessian, so that we
> can
> > add it to the other parsers. We will also (at some point) need to write
> a
> > unit test (similar to testgbasis.py) for the hessian, so that all of the
> > parsers agree.
>
> For the hessian only the lower triangle part is stored so one would need
> an LowerTriangleArrayToMatrix function i.e.:  [a11, a12, a22, a13,...,
> ann] to
> corresponding Matrix, so one can effectively work with. I will probably
> put it in units.py (it is already written).


It's up to you. I usually just fill in a full matrix as I read the data, e.g.
data[i,j] = data[j,i] = myfloat

For the Wiki I have to put for the hessian as array of rank 1, as it is
> sometimes easier to work with.


Wouldn't it be better as a rank 2 array. If you need to flatten it for
convenience, you can just use myarray.flat().

Mehdi
>
> -------------------------------------------------------------------------
> 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] molpro parser

[<meh...@ch...>]

On Mon, Sep 25, 2006 at 01:55:19PM +0100, Noel O'Boyle wrote:
> I've see you've just imported the Molpro parser and associated data. That's
> great.

I'm guilty

> I've added it to testGeoOpt. I'm about to change one thing: "au_to_cm-1"
> should be "hartree_to_cm-1", I think, to be consistent with the other
> conversions.

that's ok 


> Could you update the wiki with information on the hessian, so that we can
> add it to the other parsers. We will also (at some point) need to write a
> unit test (similar to testgbasis.py) for the hessian, so that all of the
> parsers agree.

For the hessian only the lower triangle part is stored so one would need
an LowerTriangleArrayToMatrix function i.e.:  [a11, a12, a22, a13,..., ann] to
corresponding Matrix, so one can effectively work with. I will probably
put it in units.py (it is already written).

For the Wiki I have to put for the hessian as array of rank 1, as it is
sometimes easier to work with.

Mehdi

[cclib-devel] Storage of real-life data files

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

According to sourceforge (
https://sourceforge.net/support/tracker.php?aid=1555268), our very large
data files should be stored in project web space. Once I get time (!!) I
will look into this. Presumably we will need a script to download these
files into our directory structure (e.g. using something like wget) from a
web accessible location, but that won't be rocket science.

I think this will simplify matters considerably.

Noel

Re: [cclib-devel] molpro parser

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

I've see you've just imported the Molpro parser and associated data. That's
great.

I've added it to testGeoOpt. I'm about to change one thing: "au_to_cm-1"
should be "hartree_to_cm-1", I think, to be consistent with the other
conversions.

Could you update the wiki with information on the hessian, so that we can
add it to the other parsers. We will also (at some point) need to write a
unit test (similar to testgbasis.py) for the hessian, so that all of the
parsers agree.

Regards,
  Noel


On 25/09/06, Noel O'Boyle <bao...@gm...> wrote:
>
>
> > > I'm not sure whether we want to keep the .molden files though. These
> > > files duplicate the information in the .log files, isn't this correct?
> >
> >
> > More or less, I don't know how familiar you are with Molpro but it is
> > almost a script language by itself which means that one have a lot of
> > control (I not advertising for them) to essentially do everything what
> > one would like to do with the data but on the other hand hides a lot of
> > info unless specified, making it thus difficult to parse, so dumping a
> > molden file is a way to check things, and harmless, untill they get too
> > big to be opened by Molden :-), which happens often as Molpro puts
> > almost everything you did'nt need in.
>
>
>
> I am not at all familiar with Molpro, but for all of the other programs we
> have a similar problem. You need to include various extra keywords to get
> the information written to the logfile. Please try to parse everything from
> the logfile. Whatever extra keywords are required should be entered on the
> wiki.
>
> In the same line of thought I wonder why nobody included the .dat files
> > for the Gamess-US jobs, they also could be parsed and more easily.
>
>
> Or the Gaussian checkpoint file...
>
> This is what cclib does; it parses the free-format output files. Typically
> more documentation is available for the free-format output files, more
> information is contained in them (although additional keywords may be
> required), and most people only retain these as they are smaller. I take
> your point, but this will require two parsers for every computational
> chemistry program. While this is not a bad idea, I would prefer to
> concentrate on getting more programs in cclib and writing more algorithms.
> You are welcome to write two parsers, but I would really like you to focus
> on the free-format output file as being the more useful (though more
> difficult).
>
> It could be that I have a bias towards the free-format output files as the
> formatted output files typically do not contain information on the progress
> of geometry optimisations or the convergence of the SCF. I find this
> information very useful for large systems to assess whether the system is
> likely to converge with the chosen convergence method (this is used by
> GaussSum).
>
> Regards,
>  Noel
>

Re: [cclib-devel] molpro parser

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

>
>
> > I'm not sure whether we want to keep the .molden files though. These
> > files duplicate the information in the .log files, isn't this correct?
>
> More or less, I don't know how familiar you are with Molpro but it is
> almost a script language by itself which means that one have a lot of
> control (I not advertising for them) to essentially do everything what
> one would like to do with the data but on the other hand hides a lot of
> info unless specified, making it thus difficult to parse, so dumping a
> molden file is a way to check things, and harmless, untill they get too
> big to be opened by Molden :-), which happens often as Molpro puts
> almost everything you did'nt need in.



I am not at all familiar with Molpro, but for all of the other programs we
have a similar problem. You need to include various extra keywords to get
the information written to the logfile. Please try to parse everything from
the logfile. Whatever extra keywords are required should be entered on the
wiki.

In the same line of thought I wonder why nobody included the .dat files
> for the Gamess-US jobs, they also could be parsed and more easily.


Or the Gaussian checkpoint file...

This is what cclib does; it parses the free-format output files. Typically
more documentation is available for the free-format output files, more
information is contained in them (although additional keywords may be
required), and most people only retain these as they are smaller. I take
your point, but this will require two parsers for every computational
chemistry program. While this is not a bad idea, I would prefer to
concentrate on getting more programs in cclib and writing more algorithms.
You are welcome to write two parsers, but I would really like you to focus
on the free-format output file as being the more useful (though more
difficult).

It could be that I have a bias towards the free-format output files as the
formatted output files typically do not contain information on the progress
of geometry optimisations or the convergence of the SCF. I find this
information very useful for large systems to assess whether the system is
likely to converge with the chosen convergence method (this is used by
GaussSum).

Regards,
 Noel

Re: [cclib-devel] molpro parser

[<meh...@ch...>]

Hi,

> Sorry for the delay in looking at your files.

I'm sorry too for not submitting yet, as did have much time to do that,
plus I had several problems making these tests examples.

> Can you get all of this onto subversion as soon as possible? This will
> make it easier for us to help you, and to get the tests set up and so
> on. Just do a 'svn add' for every file you want to upload, and then
> either do a single 'svn commit' for all of the files, or individual
> svn commits for every file. I can do it for you if you like, if you
> send me the latest copy of your code.

I hope to dot it myself still today but latter, as I finally managed to
get Molpro run the test job on divinyl-benzene.

> I'm not sure whether we want to keep the .molden files though. These
> files duplicate the information in the .log files, isn't this correct?

More or less, I don't know how familiar you are with Molpro but it is
almost a script language by itself which means that one have a lot of
control (I not advertising for them) to essentially do everything what
one would like to do with the data but on the other hand hides a lot of
info unless specified, making it thus difficult to parse, so dumping a
molden file is a way to check things, and harmless, untill they get too
big to be opened by Molden :-), which happens often as Molpro puts
almost everything you did'nt need in.

In the same line of thought I wonder why nobody included the .dat files
for the Gamess-US jobs, they also could be parsed and more easily.

Regards,

Mehdi

Re: [cclib-devel] molpro parser

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

Hello Mehdi,

Sorry for the delay in looking at your files. I didn't realise you had so
much done! It looks very good. Can you get all of this onto subversion as
soon as possible? This will make it easier for us to help you, and to get
the tests set up and so on. Just do a 'svn add' for every file you want to
upload, and then either do a single 'svn commit' for all of the files, or
individual svn commits for every file. I can do it for you if you like, if
you send me the latest copy of your code.

Once these are uploaded, I will modify the tests to include Molpro so that
we can work on making them all pass.

I'm not sure whether we want to keep the .molden files though. These files
duplicate the information in the .log files, isn't this correct?

Regards,
   Noel

On 14/09/06, Mehdi Bounouar <meh...@ch...> wrote:
>
> Hi,
>
> Before doing any major .... up with subversion I just send you the what
> I did for Molpro parser, also to have an opinion.
>
> I did not extend the tests but at least cclib
> is not broken :-)
>
> Mehdi
>
>
>

Re: [cclib-devel] adf parser

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

Cool - when I get a chance I'll look into this. Maybe it's also a potential
problem with the other SCF parsers.

I think as a rule of thumb that all bug fixes should be included in the next
release. Actually, it helps if you start the log message with "Bug fix" so
it's quite clear which ones need to applied to the release branch. It's also
useful when going through the log messages to create a changelog, as it
makes it easy to separate new features from bug fixes and so on.

 Looking at my own last few commits, it seems I don't even follow my own
advice though :-)


On 23/09/06, Adam Tenderholt <a-t...@st...> wrote:
>
> I just fixed a pretty critical (at least in my mind) bug in the ADF
> parser. It would get stuck in a loop if the SCF didn't fully
> converge, but gave acceptable results (according to text printed in
> the logfile), causing numerous attributes to be skipped. I also added
> a logger warning if EOF is reached while in that loop, which you can
> remove if you think it is unnecessary.
>
> Hopefully this will make the 0.6 release.
>
> Adam
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] adf parser

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

I just fixed a pretty critical (at least in my mind) bug in the ADF  
parser. It would get stuck in a loop if the SCF didn't fully  
converge, but gave acceptable results (according to text printed in  
the logfile), causing numerous attributes to be skipped. I also added  
a logger warning if EOF is reached while in that loop, which you can  
remove if you think it is unnecessary.

Hopefully this will make the 0.6 release.

Adam

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

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

> Ah, okay, in that case it'd be great if you could add it also to  
> regression.py, which has what I think is a nice framework for  
> specifying tests for individual files. If you could take a look at  
> it, see if you can figure it out, and ask me any questions.
>
> There's some instructions on the wiki at:
>     http://cclib.sourceforge.net/wiki/index.php/Tests
>

Done, although right now, it's just checking for the presence of  
atomnos and not that it has the correct size.

Adam

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

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

> Can you add a test for the SP unrestricted to ensure that atomnos  
> exists and has the right dimensions?

Done. Although right now, the unittest is using the dvb_un_sp_b.log  
file instead of dvb_un_sp.out which is the one missing the atomnos  
attribute. Should another group of tests be added (ie. Gaussian B),  
so that the parser is tested against both files?

> Regarding the release, I've overwhelmed with stuff at the moment,  
> but I hope to make a release at some point with the Changelog as we  
> discussed.

Completely understandable! Whenever it's released is fine by me...

Adam

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

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

You're right - input orientation should be used if nothing else is
available. The only thing to be careful is not to extract the same
information twice, e.g. for a single point calculation, there should only be
one geometry. After two steps in a geo-opt, there should be 3 geometries
(right? the starting, the 1st, the 2nd?). Also note that standard
orientation isn't available if you use 'NOSYM'.

Can you add a test for the SP unrestricted to ensure that atomnos exists and
has the right dimensions?

Regarding the release, I've overwhelmed with stuff at the moment, but I hope
to make a release at some point with the Changelog as we discussed.

On 19/09/06, Adam Tenderholt <a-t...@st...> wrote:
>
> I've been adapting PyMOlyze to work with cclib, and I've encountered
> a slight problem with the Gaussian test file dvb_un_sp.out. I was
> hoping to be able to pull out the names of atoms from that file/
> parser, but aonames isn't available after parse() is called. From
> what I can tell, the gaussian parser only looks for "Standard
> orientation" for geometry and atomnos info. Is there a reason "Input
> orientation" isn't used if other coordinate info isn't available?
>
> Adam
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Gaussian: standard versus input orientation

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

I've been adapting PyMOlyze to work with cclib, and I've encountered  
a slight problem with the Gaussian test file dvb_un_sp.out. I was  
hoping to be able to pull out the names of atoms from that file/ 
parser, but aonames isn't available after parse() is called. From  
what I can tell, the gaussian parser only looks for "Standard  
orientation" for geometry and atomnos info. Is there a reason "Input  
orientation" isn't used if other coordinate info isn't available?

Adam

Re: [cclib-devel] Ready for cclib 0.6?

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

> I'm ready to make a new release of cclib, version 0.6, let's say.  
> This weekend would be a good time for me to do it, so if anyone has  
> any comments, now's the time.
>
> This will be the changelog:
>
> Changes since cclib-0.5 :
>
> Features
>     * New parser: GAMESS-UK parser
>     * API addition: the .clean() method
>       The .clean() method of a parser clears all of the parsed
>       attributes. This is useful if you need to reparse during
>       the course of a calculation.
>     * Function rename: guesstype() has been renamed to ccopen()
>
> Bugfixes
>     * ccget: Passing multiple filenames now works on Windows too
>     * ADF parser: The following bugs have been fixed
>       Problem with parsing SFOs in certain log files
>       Handling of molecules with orbitals of E symmetry
>       Couldn't find the HOMO in log files from new versions of ADF
>     * Gaussian parser: The following bugs have been fixed
>       SCF values was not extracting the dEnergy value

Sounds like some serious improvements! :o)

> Also I need to add something about the new Qt Progress, if this is  
> ready to be included in the distribution (Adam?).

There are now two qt-based progress classes: QtProgress and  
Qt4Progress. They are mutually exclusive since both qt and PyQt4  
can't be loaded at the same time. I haven't extensively tested them,  
but they work fine for me.

To use them:

-----
from cclib.progress import QtProgress
progress=QtProgress("caption",parent_object)

parser=ccopen(filename, progress, logging.ERROR)
parser.parse()
-----

or

----
from cclib.progress import Qt4Progress
progress=Qt4Progress("caption",parent_object)

parser=ccopen(filename, progress, logging.ERROR)
parser.parse()
-----

Let me know if you need any more info...

Adam

[cclib-devel] Ready for cclib 0.6?

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

I'm ready to make a new release of cclib, version 0.6, let's say. This
weekend would be a good time for me to do it, so if anyone has any comments,
now's the time.

This will be the changelog:

Changes since cclib-0.5:

Features
    * New parser: GAMESS-UK parser
    * API addition: the .clean() method
      The .clean() method of a parser clears all of the parsed
      attributes. This is useful if you need to reparse during
      the course of a calculation.
    * Function rename: guesstype() has been renamed to ccopen()

Bugfixes
    * ccget: Passing multiple filenames now works on Windows too
    * ADF parser: The following bugs have been fixed
      Problem with parsing SFOs in certain log files
      Handling of molecules with orbitals of E symmetry
      Couldn't find the HOMO in log files from new versions of ADF
    * Gaussian parser: The following bugs have been fixed
      SCF values was not extracting the dEnergy value


Also I need to add something about the new Qt Progress, if this is ready to
be included in the distribution (Adam?).

Regards,
  Noel

Re: [cclib-devel] problem with utils.py revision 336

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

> I guess it's something that has a dependency on qt. It'll probably  
> need a protected 'import' statement, as in progress/__init__.py.  
> I'll look into it as soon as I have a chance. You can locally  
> switch to the earlier revision with something like 'svn update - 
> r335' which will allow you to continue for the moment

The current version of __init__.py *should* only load the qt-based  
modules if qt or PyQt4 has already been loaded. I have yet to test on  
a machine without qt/PyQt4.

As far as utils.py goes, I modified ccopen to allow optional progress  
classes and logging stuff to it in addition to the filename. I ran  
testall.py, and I didn't get any extra errors.

Adam