Re: [cclib-users] GaussSum/cclib once more

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

2009/11/24 Xaver Wurzenberger <xav...@we...>:
> Hi,
>> It can handle anything that *behaves* like a file. So you need to
>> convert your string to a StringIO.StringIO. I use this trick myself to
>> read strings.
>
> perfect, that's what I was looking for. BTW, it speeds up by just parsing e.
> g. one line instead of a whole log file in my case.
>
> Three more questions:
>
> - There's no information extracted about the "steps" needed to get SCF
> convergence, right? Gaussian seems to mix up the words steps and cycles. What
> I mean is not the number of geometry points=SCF energies but the numer of
> iterations made to get one SCF energy. Gaussian writes this in the log file
> as
>  SCF Done:  E(UB+HF-LYP) =  -1721.919     a.u. after   31 cycles
> (and I want the 31). Could this be included in a future release?

These values are available as the dimension of the arrays in
scfvalues: http://cclib.sourceforge.net/wiki/index.php/Scfvalues

> - What about having the SCF energy array also contain E/Hartree and E/kJ/mol
> as second and third column?

We store a single value in a defined unit. You can convert the values
using our handy converter (cclib.parser.utils.convertor or something).

> - What is the best way to tell from ccopen() which calculation type (Gaussian,
> GAMESS, ...) it recognized? There's no field for that, right?

To check whether object A is an instance of class B, use isinstance(A)
== B. B in this case would be gaussianparser.GaussianParser or so.

Hope this helps. BTW, could you cc cclib questions to our mailing list.

- Noel

> Thanks,
> Xaver
>
>
> Am Tuesday 24 November 2009 09:57:47 schrieben Sie:
>> Hell Xaver,
>>
>> 2009/11/23 Xaver Wurzenberger <xav...@we...>:
>> > Hi Noel,
>> >
>> > in case you don't remember me, I'm the guy who kept thinking about
>> > forking GaussSum in the spring this year and finally decided to just do
>> > his own thing ;-)
>> > I hope you're fine... you seem to, as I saw a pretty recent GaussSum
>> > version a few days ago. So your making-gausssum-rock-stable-project is
>> > moving foward! For me, it has been as with a lot of projects in my life,
>> > I start overly- motivated, oversize it all a little, and am out of power
>> > at 85% progress of the thing *g But this time, I'm gonna finish it and
>> > half a year later, I'm back at it. To my defense, I had to publish a
>> > (hopefully) big paper in the mean time, as an academic you'll know what I
>> > mean.
>>
>> Of course :-)
>>
>> > But enough chit-chat, I am of course writing to get a little help from
>> > you once more! I admit this light-heartedly, because I honestly belief
>> > that someday I'll repay by contributing to cclib or some other cc open
>> > source project.
>> > As for the former, I am once more thinking about using it. Since you're
>> > the first name on the cclib page, I think these questions are rightly
>> > adressed at you (sometimes my english is funny, I know ;-) ):
>> > Is - or will be - cclib able to parse
>> > a) simple text/strings or just files? Could I trick it by writing my
>> > snippet into a temp file?
>>
>> It can handle anything that *behaves* like a file. So you need to
>> convert your string to a StringIO.StringIO. I use this trick myself to
>> read strings.
>>
>> > b) for only specific data, say, SCF energies?
>> > What might be the pitfalls? Could small source code changes make it
>> > possible?
>>
>> This isn't possible. We go through the whole file once, and use "if"
>> statements to find matches. You could simply comment out many of the
>> "if" statements and see if it still works. In many cases it will. The
>> speed will improve somewhat.
>>
>> > Both is in the end intended to drastically reduce parsing time.
>>
>> I can't see how step (a) would speed anything up, but (b) will have
>> some effect.
>>
>> > BTW, does testall.py of cclib have to pass every test with OK? Because I
>> > got some fails and errors:
>> > ********* SUMMARY OF EVERYTHING **************
>> > TOTAL: 522      PASSED: 492     FAILED: 6       ERRORS: 3       SKIPPED:
>> > 21 Are these bugs, should I send them to the sourceforge tracker?
>>
>> They aren't really bugs, but I forget what they are. There's no need
>> to file them as bugs.
>>
>> > Regards,
>> > Xaver
>
>
>