cclib-devel — Developer's mailing list

Re: [cclib-devel] three things

[Noel O'B. <no...@ca...>]

On Thu, 2006-04-06 at 08:58 -0700, Adam Tenderholt wrote:
> > It looks like there are three distinct types of orbitals now: atomic
> > orbitals, basis set orbitals, and molecular orbitals. Molecular orbitals
> > are composed of linear combinations of basis set orbitals, which are
> > composed of linear combinations of atomic orbitals (is this correct?).
> > For Gaussian, basis set orbitals are equal to the atomic orbitals.
> 
> Molecular orbitals are linear combinations of basis set orbitals.
> Gaussian uses atomic orbitals as the basis set orbitals. ADF uses either
> atomic orbitals (no symmetry) or symmetry adapted linear combinations
> (SALCs) of atomic orbitals for its basis set.
> 
> > Is there any need to store basis set orbitals in an attribute? So long
> > as the ADF parser creates a mocoeffs matrix which describes the MOs in
> > terms of the AOs (and not the basis set orbitals) I think we don't need
> > the basis set orbitals. 
> 
> The problem is that ADF stores mocoeffs in terms of the basis set
> orbitals (it calls them CFOs, or something like that). It then breaks up
> these orbitals by symmetry, and prints their corresponding mocoeffs matrix.

I guess my question is, is it possible to translate the mocoeffs matrix
from being based on the Symmetry Adapted Linear Combinations (or
whatever) to being based on the original atomic orbitals. Isn't this
what we need to do to make it possible to do our population analyses?
We're not interested in how much 1/sqrt(2) (C1s + C2s) contributes to a
particular molecular orbital, but in how much C1s contributes.

> > Regarding the aonames, to be honest, I forget why I wanted to extract
> > aonames in the first place. In short, I think we should forget about
> > aonames (I'll remove it from the relevant places if you agree), and
> > concentrate on getting mocoeff the same between different programs.
> 
> I'd like the aonames because it's key to how PyMOlyze works. It reads
> the list of aonames, and lets the user specify fragments in terms of
> those. For instance, I usually create the following fragments: Mo d, Mo
> s/p, S, O, C/H. Occasionally, I split up the sulfur orbitals into p and
> s/d fragments.

OK - that's fine. If they're useful we'll extract them. Regarding the
format of the name, "Mo 2p", etc. seems fine.

> Adam
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] three things

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

> I've been thinking some more about this and now I think that we should
> avoid Classes altogether, as this has been our method until now (e.g.
> for molecular orbitals we have symmetries and coefficients as separate
> attributes, for vibrations, we have raman intensity, and symmetry as
> separate items, etc.). We can uses atomcoords, atomnos, atomXXXX, etc.
> Or reduce 'atom' to 'at', or just 'a'.

Sounds reasonable.

> For the moment, I propose atomcoords (as we already have atomnos). If
> you agree, we can add this to our specification (in the docstring of
> logfileparser.py).

So atomcoords will be a list of array[2] (with dimensions natom x 3)?
The list will be length 1 for single point calcs, and however long for
geometry optimizations?

Adam

Re: [cclib-devel] Handling of symmetry

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

> I think this would be good. I assumed that there wasn't any symmetry
> present but now I see that there is. There's no need to delete the old
> file (the more the merrier), just call one _a and the other _b and make
> some comments in the svn log, or in the metadata.

Ok. My parents are visiting me this week, so I can't make any promises
about getting it this week. Early next week for sure.

Re: [cclib-devel] three things

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

> It looks like there are three distinct types of orbitals now: atomic
> orbitals, basis set orbitals, and molecular orbitals. Molecular orbitals
> are composed of linear combinations of basis set orbitals, which are
> composed of linear combinations of atomic orbitals (is this correct?).
> For Gaussian, basis set orbitals are equal to the atomic orbitals.

Molecular orbitals are linear combinations of basis set orbitals.
Gaussian uses atomic orbitals as the basis set orbitals. ADF uses either
atomic orbitals (no symmetry) or symmetry adapted linear combinations
(SALCs) of atomic orbitals for its basis set.

> Is there any need to store basis set orbitals in an attribute? So long
> as the ADF parser creates a mocoeffs matrix which describes the MOs in
> terms of the AOs (and not the basis set orbitals) I think we don't need
> the basis set orbitals. 

The problem is that ADF stores mocoeffs in terms of the basis set
orbitals (it calls them CFOs, or something like that). It then breaks up
these orbitals by symmetry, and prints their corresponding mocoeffs matrix.

> Regarding the aonames, to be honest, I forget why I wanted to extract
> aonames in the first place. In short, I think we should forget about
> aonames (I'll remove it from the relevant places if you agree), and
> concentrate on getting mocoeff the same between different programs.

I'd like the aonames because it's key to how PyMOlyze works. It reads
the list of aonames, and lets the user specify fragments in terms of
those. For instance, I usually create the following fragments: Mo d, Mo
s/p, S, O, C/H. Occasionally, I split up the sulfur orbitals into p and
s/d fragments.

Adam

Re: [cclib-devel] three things

[Noel O'B. <no...@ca...>]

On Thu, 2006-03-30 at 17:04 -0800, Adam Tenderholt wrote:

> 2) In looking at the Gaussian parser, I wasn't able to find a variable for 
> storing each structure found for a gaussian calculation. What do you think 
> about adding a class for Atoms (name or number, x, y, z in either angs or 
> bohr), a class for Molecules (either a list of Atoms, or more complicated 
> with dictionaries?), and geoms[ ] and geomcoords[ ] in the parser classes?

I've been thinking some more about this and now I think that we should
avoid Classes altogether, as this has been our method until now (e.g.
for molecular orbitals we have symmetries and coefficients as separate
attributes, for vibrations, we have raman intensity, and symmetry as
separate items, etc.). We can uses atomcoords, atomnos, atomXXXX, etc.
Or reduce 'atom' to 'at', or just 'a'.

For the moment, I propose atomcoords (as we already have atomnos). If
you agree, we can add this to our specification (in the docstring of
logfileparser.py).

Regards,
 Noel

Re: [cclib-devel] Handling of symmetry

[Noel O'B. <no...@ca...>]

On Wed, 2006-04-05 at 14:08 -0800, Adam Tenderholt wrote:
> > I think the lowercase u/g is a good idea, but I'm not convinced about
> > the period. How about "Bu", etc? Isn't this the standard notation?
> 
> I agree.

Okay - we'll do this. I'll put specifications like this on the wiki from
now on once we have agreed.

> > Remember that there are possibly two special cases that
> > our program should also handle without problems: no symmetry (all A, I
> > guess), and really high symmetry (e.g. Td). For the first case, the
> > unrestricted calculation should have no symmetry. Might be worthwhile
> > running an optimisation of methane for the second (if you also think it
> > might be a problem).
> 
> I think we should handle as much as possible like you say. Should I rerun the 
> dvb unrestricted calculation in ADF with nosymmetry? 

I think this would be good. I assumed that there wasn't any symmetry
present but now I see that there is. There's no need to delete the old
file (the more the merrier), just call one _a and the other _b and make
some comments in the svn log, or in the metadata.

> Also, have we decided what to do about aonames for high symmetry calculations 
> in ADF?

See other email.

> Adam
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] three things

[Noel O'B. <no...@ca...>]

On Thu, 2006-03-30 at 17:04 -0800, Adam Tenderholt wrote:
> 1) I've been working on the ADF parser, however I ran into a problem with 
> reading "aonames". Basically, if there is any symmetry (and nosymmetry isn't 
> specified for the ADF calc), it uses linear combinations of orbitals on 
> different atoms for the atomic basis. As an example, look for the SFOs 
> section on line 1371 of dvb_sp.adfout. SFO 1Ag is constant (C1_1S + C4_1S), 
> where constant is 1/sqrt(2). I can think of two solutions. First, parse it as 
> it is so aonames become something like 1/2 C1_1S + C4_1S. My problem with 
> this is handling more complicated cases with 3+ atoms might lead to more 
> difficult coefficients. Second, ignore it and make sure cclib users know that 
> if they want to do anything with aonames, they need to specify nosymmetry in 
> the ADF calc.

It looks like there are three distinct types of orbitals now: atomic
orbitals, basis set orbitals, and molecular orbitals. Molecular orbitals
are composed of linear combinations of basis set orbitals, which are
composed of linear combinations of atomic orbitals (is this correct?).
For Gaussian, basis set orbitals are equal to the atomic orbitals.

Is there any need to store basis set orbitals in an attribute? So long
as the ADF parser creates a mocoeffs matrix which describes the MOs in
terms of the AOs (and not the basis set orbitals) I think we don't need
the basis set orbitals. 

Regarding the aonames, to be honest, I forget why I wanted to extract
aonames in the first place. In short, I think we should forget about
aonames (I'll remove it from the relevant places if you agree), and
concentrate on getting mocoeff the same between different programs.

> 2) In looking at the Gaussian parser, I wasn't able to find a variable for 
> storing each structure found for a gaussian calculation. What do you think 
> about adding a class for Atoms (name or number, x, y, z in either angs or 
> bohr), a class for Molecules (either a list of Atoms, or more complicated 
> with dictionaries?), and geoms[ ] and geomcoords[ ] in the parser classes?
> 
> 3) What if certain calculations don't implement the same parameters for 
> geotargets/geovalues and scftargets/scfvalues? Look at the differences 
> between the ADF and Gaussian calculations. Is there going to be a variable to 
> keep track of the names for each parameter? Or maybe a set of pre-defined 
> dictionaries (e.g. MaxForce:[ ], RMS Force:[ ], Energy:[ ], dEnergy:[ ], 
> etc.) should be used instead to keep some consistency across each type of 
> calculation?
> 
> Adam
> 
> P.S. Noel, I hope you enjoyed your travels...
> 

Re: [cclib-devel] Handling of symmetry

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

> I think the lowercase u/g is a good idea, but I'm not convinced about
> the period. How about "Bu", etc? Isn't this the standard notation?

I agree.

> Remember that there are possibly two special cases that
> our program should also handle without problems: no symmetry (all A, I
> guess), and really high symmetry (e.g. Td). For the first case, the
> unrestricted calculation should have no symmetry. Might be worthwhile
> running an optimisation of methane for the second (if you also think it
> might be a problem).

I think we should handle as much as possible like you say. Should I rerun the 
dvb unrestricted calculation in ADF with nosymmetry? 

Also, have we decided what to do about aonames for high symmetry calculations 
in ADF?

Adam

[cclib-devel] Wiki for cclib

[Noel O'B. <no...@ca...>]

What do you think of using MediaWiki for the web pages? It's a bit lazy
but it'll make documentation so much easier to write.

If you agree, I'll follow the instructions here:
http://meta.wikimedia.org/wiki/Running_MediaWiki_on_Sourceforge.net

A colleague of mine has agreed to run the Jaguar jobs.

P.S. I will look at your question regarding aonames tomorrow.

Regards,
 Noel

[cclib-devel] Metadata for calculations

[Noel O'B. <no...@ca...>]

Andrew,

Could we also include in the metadata for calculations the machine it
was run on, e.g. Pentium 4.

Regards,
 Noel

[cclib-devel] Handling of symmetry

[Noel O'B. <no...@ca...>]

We need to standardise the handling of symmetry labels between programs:

Gaussian
[['BU', 'AG', 'BU', 'AG', 'AG', 'BU', 'BU', 'AG', 'BU', 'AG', 'AG',
'BU', 'AG', 'BU', 'BU', 'AG', 'AG', 'BU', 'AG', 'AG', 'BU', 'BU', 'BU',
'AG', 'BU', 'BU', 'AG', 'AU', 'BU', 'AG', 'AG', 'BG', 'AU', 'BG', 'BG',
'AU', 'AU', 'BG', 'AU', 'BG', 'AG', 'BU', 'AG', 'BU', 'BU', 'AG', 'BU',
'AG', 'BU', 'AG', 'AG', 'BU', 'AG', 'BU', 'BU', 'AG', 'AG', 'BU', 'AG',
'BU']]
GAMESS
[['BU', 'AG', 'BU', 'AG', 'BU', 'AG', 'BU', 'AG', 'BU', 'AG', 'AG',
'BU', 'AG', 'BU', 'BU', 'AG', 'AG', 'BU', 'AG', 'AG', 'BU', 'BU', 'BU',
'AG', 'BU', 'AG', 'BU', 'AU', 'BU', 'AG', 'AG', 'BG', 'AU', 'BG', 'BG',
'AU', 'AU', 'BG', 'AU', 'BG', 'AG', 'BU', 'BU', 'AG', 'AG', 'BU', 'BU',
'AG', 'BU', 'AG', 'AG', 'BU', 'AG', 'BU', 'BU', 'AG', 'AG', 'BU', 'AG',
'BU']]
ADF
[['B.u', 'A.g', 'B.u', 'A.g', 'B.u', 'A.g', 'B.u', 'A.g', 'B.u', 'A.g',
'A.g', 'B.u', 'A.g', 'B.u', 'B.u', 'A.g', 'A.g', 'B.u', 'A.g', 'A.g',
'B.u', 'B.u', 'B.u', 'A.g', 'B.u', 'B.u', 'A.g', 'A.u', 'B.u', 'A.g',
'A.g', 'B.g', 'A.u', 'B.g', 'B.g', 'A.u', 'A.u', 'B.g', 'A.u', 'B.g',
'A.g', 'B.u', 'B.u', 'A.g', 'A.g', 'B.u', 'B.u', 'A.g', 'B.u', 'A.g',
'A.g', 'B.u', 'A.g', 'B.u', 'B.u', 'A.g', 'A.g', 'B.u', 'A.g', 'B.u']]

I think the lowercase u/g is a good idea, but I'm not convinced about
the period. How about "Bu", etc? Isn't this the standard notation? What
do you think? Remember that there are possibly two special cases that
our program should also handle without problems: no symmetry (all A, I
guess), and really high symmetry (e.g. Td). For the first case, the
unrestricted calculation should have no symmetry. Might be worthwhile
running an optimisation of methane for the second (if you also think it
might be a problem).

Regards,
 Noel

Re: [cclib-devel] three things

[Noel O'B. <no...@ca...>]

On Thu, 2006-03-30 at 17:04 -0800, Adam Tenderholt wrote:
> 1) I've been working on the ADF parser, however I ran into a problem with 
> reading "aonames". Basically, if there is any symmetry (and nosymmetry isn't 
> specified for the ADF calc), it uses linear combinations of orbitals on 
> different atoms for the atomic basis. As an example, look for the SFOs 
> section on line 1371 of dvb_sp.adfout. SFO 1Ag is constant (C1_1S + C4_1S), 
> where constant is 1/sqrt(2). I can think of two solutions. First, parse it as 
> it is so aonames become something like 1/2 C1_1S + C4_1S. My problem with 
> this is handling more complicated cases with 3+ atoms might lead to more 
> difficult coefficients. Second, ignore it and make sure cclib users know that 
> if they want to do anything with aonames, they need to specify nosymmetry in 
> the ADF calc.

I'll think some more about this - I gotta go and give a short talk now.

> 2) In looking at the Gaussian parser, I wasn't able to find a variable for 
> storing each structure found for a gaussian calculation. What do you think 
> about adding a class for Atoms (name or number, x, y, z in either angs or 
> bohr), a class for Molecules (either a list of Atoms, or more complicated 
> with dictionaries?), and geoms[ ] and geomcoords[ ] in the parser classes?

Yes - you're right - this is missing. My own feelings are:
(1) Angstroms are nicer
(2) I prefer Atom.coords = (1.0,1.1,2.2) rather than
Atom.x,Atom.y,Atom.z.
(3) Do we need a class for Molecules? Can we instead just use a list of
Atoms? (just to keep things simple - can you think of any advantages to
having a class?)
(4) Why not atoms[] in the parser class (which will be a list of Atoms)?
The atoms will not only have geometry, but names/numbers as well, and
atomic orbitals also maybe.

> 3) What if certain calculations don't implement the same parameters for 
> geotargets/geovalues and scftargets/scfvalues? Look at the differences 
> between the ADF and Gaussian calculations. Is there going to be a variable to 
> keep track of the names for each parameter? Or maybe a set of pre-defined 
> dictionaries (e.g. MaxForce:[ ], RMS Force:[ ], Energy:[ ], dEnergy:[ ], 
> etc.) should be used instead to keep some consistency across each type of 
> calculation?

The same differences exist between the Gaussian and the GAMESS parsers.
At the moment, I don't assume that scftarget[0] in the Gaussian parser
refers to the same thing as scftarget[0] in the GAMESS parser. This may
feel inconsistent, but the information you get by dividing the
corresponding scfvalue by its scftarget is independent of the nature of
that data. I understand what you're saying, but I think that this
information is being extracted in the context of a comparison to the
target value, and is of no interest in itself (in general). Where it is
of interest, it should be present as a parsed attribute of the class.

For the moment, why don't we create a text file in a docs folder (I'll
start it) with a table giving the scf and geo targets from the various
programs. We can fill this in with information from the various parsers
and use it to create a dictionary if we think this is useful.

BTW, people here use Jaguar, so I'll work on that next.

I've started writing unit tests. Run and look at "test/testall.py" for
more info. Ideally, whenever we make a change to a parser, we should
make sure that are the tests are passed. Also ideally, we regard a
parser as complete once it passes all the tests. However, at the moment,
there are only 4 tests, which obviously don't test all that much,
although it does highlight an error in the gamess parser. I'll continue
to add more tests to this, and you may find it useful also to add
specific tests for the ADF parser.

Noel

> Adam
> 
> P.S. Noel, I hope you enjoyed your travels...

Oh yeah, San Fran/Stanford was really interesting. We went to see
redwoods in Muir Wood(?) the following day and went wine tasting in
Nappa Valley too.

Atlanta Georgia wasn't much fun, but it turned out to be a really
interesting conference (for me). Didn't get to see your boss talking but
I did see his name in the program.

[cclib-devel] three things

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

1) I've been working on the ADF parser, however I ran into a problem with 
reading "aonames". Basically, if there is any symmetry (and nosymmetry isn't 
specified for the ADF calc), it uses linear combinations of orbitals on 
different atoms for the atomic basis. As an example, look for the SFOs 
section on line 1371 of dvb_sp.adfout. SFO 1Ag is constant (C1_1S + C4_1S), 
where constant is 1/sqrt(2). I can think of two solutions. First, parse it as 
it is so aonames become something like 1/2 C1_1S + C4_1S. My problem with 
this is handling more complicated cases with 3+ atoms might lead to more 
difficult coefficients. Second, ignore it and make sure cclib users know that 
if they want to do anything with aonames, they need to specify nosymmetry in 
the ADF calc.

2) In looking at the Gaussian parser, I wasn't able to find a variable for 
storing each structure found for a gaussian calculation. What do you think 
about adding a class for Atoms (name or number, x, y, z in either angs or 
bohr), a class for Molecules (either a list of Atoms, or more complicated 
with dictionaries?), and geoms[ ] and geomcoords[ ] in the parser classes?

3) What if certain calculations don't implement the same parameters for 
geotargets/geovalues and scftargets/scfvalues? Look at the differences 
between the ADF and Gaussian calculations. Is there going to be a variable to 
keep track of the names for each parameter? Or maybe a set of pre-defined 
dictionaries (e.g. MaxForce:[ ], RMS Force:[ ], Energy:[ ], dEnergy:[ ], 
etc.) should be used instead to keep some consistency across each type of 
calculation?

Adam

P.S. Noel, I hope you enjoyed your travels...

-- 
Want a web browser that is fully customizable? 

Go to http://www.mozilla.org/products/firefox/

to download the newest version of Firefox and 
its available extentions.

Re: [cclib-devel] progress support

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

> Got it. Works fine, although doesn't play well with the logger, but you
> can turn the logger off or get it to write to a file.

Yeah. This is done with calling G03 with a third argument of logging.ERROR or 
such.

> I don't know where the slow step is. I've added a call to random so that
> it only calls it every so many steps, but there isn't a massive
> improvement.

I also added optional arguments to parse so that you can specify how "fine" or 
"course" you want the update to be. The first option is the fine argument, 
which is used for checks against random() inside "slow" parts like parsing 
overlap and coefficients. The second option is the course argument, which is 
used for checks that aren't "slow".

> Not really. I think this is the price you pay. A bit like Heisenberg's
> uncertainty principle - by observing the progress you change it. :-) If
> we could identify more clearly the slow step - for example, is it the
> call to tell()? - then we could think about how to improve it. I tried
> various things to speed up the textprogress, but they only made a minor
> difference.

I agree that it is probably the price we pay. I've tried numerous things to 
speed it up, but nothing seems to be too significant. I think I'd rather know 
the progress and add on (at most) a few seconds, and of course, it's 
ultimately up to the developer using cclib.

> BTW, you may be interested in:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/299207
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/168639

I didn't exactly take their work, but I did figure out how to make the text 
progress work like is expected. I haven't finished every part of it, but it 
should still be useful. Of course, the text progress is more an example for 
people to follow. I just wanted to establish the API used for any progress 
classes. Basically two functions need to be implemented:

1) initialize, which expects nsteps and text
2) update, which expects step and text

I've also added a few test files for ADF, although I haven't started working 
on the parser. Such a daunting task!

Adam

Re: [cclib-devel] progress support

[Noel O'B. <no...@ca...>]

On Thu, 2006-03-09 at 12:03 -0800, Adam Tenderholt wrote:
> So I added an example progress class called TextProgress which basically 
> prints out bars saying how much progress has been made, and made necessary 
> changes to G03 parser to allow use of this class.
> 
> If you want to use it, first create an instance, and pass that instance to the 
> G03 class along with the filename:
> 
> progress=TextProgress()
> p=G03(filename,progress)
> p.parse()

Got it. Works fine, although doesn't play well with the logger, but you
can turn the logger off or get it to write to a file.

> I changed the __init__ function of G03 to accept any amount of arguments, and 
> pass that onto the baseclass. See the SVN diffs for more details. This allows 
> the user of cclib to not specify a parser and continue as before.
Yes, and seems to be just as fast if you don't specify a progress.

> Unfortunately, not all of this message is good news. Calling G03 with a 
> TextParser adds a 20-25% overhead: 4 seconds becomes 5ish, 21 seconds becomes 
> more like 26, etc. I think the problem is that it calls the 
> progress.update(step) far too frequently.
I don't know where the slow step is. I've added a call to random so that
it only calls it every so many steps, but there isn't a massive
improvement.

>  It may make more sense to identify 
> the slower parts of the parsing class, and only add progress.update there, 
> but I don't know for sure.
> 
> Any ideas on how to improve this?
Not really. I think this is the price you pay. A bit like Heisenberg's
uncertainty principle - by observing the progress you change it. :-) If
we could identify more clearly the slow step - for example, is it the
call to tell()? - then we could think about how to improve it. I tried
various things to speed up the textprogress, but they only made a minor
difference.

BTW, you may be interested in:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/299207
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/168639

Regards,
 Noel

[cclib-devel] progress support

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

So I added an example progress class called TextProgress which basically 
prints out bars saying how much progress has been made, and made necessary 
changes to G03 parser to allow use of this class.

If you want to use it, first create an instance, and pass that instance to the 
G03 class along with the filename:

progress=TextProgress()
p=G03(filename,progress)
p.parse()

I changed the __init__ function of G03 to accept any amount of arguments, and 
pass that onto the baseclass. See the SVN diffs for more details. This allows 
the user of cclib to not specify a parser and continue as before.

Unfortunately, not all of this message is good news. Calling G03 with a 
TextParser adds a 20-25% overhead: 4 seconds becomes 5ish, 21 seconds becomes 
more like 26, etc. I think the problem is that it calls the 
progress.update(step) far too frequently. It may make more sense to identify 
the slower parts of the parsing class, and only add progress.update there, 
but I don't know for sure.

Any ideas on how to improve this?

Adam



-- 
Want a web browser that is fully customizable? 

Go to http://www.mozilla.org/products/firefox/

to download the newest version of Firefox and 
its available extentions.

Re: [cclib-devel] Getting the ball rolling

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

> cclib is now self-parsing!

Excellent. Did you upload utils.py, or is that not required?

> OK, not quite, but it does parse your test file now. The necessary magic
> is:
> $ python setup.py install (as root, although there are alternatives)
>
> >>> from cclib.parser import G03
> >>> p = G03("Mo4OSibdt2-sp.log")
> >>> p.parse()
>
> Things to do:
> (1) Change variable names
> (2) Change variable types
> (3) Move logging code into Logfile superclass
> (4) Code for progress bars/indicators
> (5) Write parsers for other programs.
>
> I will do 1-->3 for the Gaussian parser. I will put the names we agreed
> on into the docstring for the Logfile class, and we can take that as our
> guide.

I will work on 4, and learn how to parse ADF and Jaguar files (some of 5). 
Also, is it possible to make it so each parser has its own file? I feel like 
that would make the code more maintanable, but I don't know how easily it can 
be done to keep syntax like we have.

> Let's start sharing test files, and putting a few onto sourceforge too.
> It might be good to run the same few calculations on the same molecule
> using lots of different software. It would be good to submit these test
> files to the OpenBabel repository too. I'm reasonably familiar with the
> Python unit test framework, and so will cobble together some tests once
> we have a few files.

Is there an upper limit for filesize for test files? I think most of my single 
point Gaussian files are 50-100 MB, but I could probably find a few smaller 
ones if necessary. 

> For our first release, 0.1, 0.5 or whatever, let's aim towards getting
> functional parsers.
>
> Oh yeah, BTW, I think I've set up the SVN to send the commit comments to
> the cclib-svn mailing list. You might want to subscribe to this to keep
> uptodate. I'm not yet sure if I've set it up properly though.
>
> What do you think?

I think this is a good start. I'll play with it when I get the chance. :o)

Adam

[cclib-devel] Getting the ball rolling

[Noel O'B. <no...@ca...>]

cclib is now self-parsing!

OK, not quite, but it does parse your test file now. The necessary magic
is:
$ python setup.py install (as root, although there are alternatives)

>>> from cclib.parser import G03
>>> p = G03("Mo4OSibdt2-sp.log")
>>> p.parse()

Things to do:
(1) Change variable names
(2) Change variable types
(3) Move logging code into Logfile superclass
(4) Code for progress bars/indicators
(5) Write parsers for other programs.

I will do 1-->3 for the Gaussian parser. I will put the names we agreed
on into the docstring for the Logfile class, and we can take that as our
guide.

Let's start sharing test files, and putting a few onto sourceforge too.
It might be good to run the same few calculations on the same molecule
using lots of different software. It would be good to submit these test
files to the OpenBabel repository too. I'm reasonably familiar with the
Python unit test framework, and so will cobble together some tests once
we have a few files.

For our first release, 0.1, 0.5 or whatever, let's aim towards getting
functional parsers.

Oh yeah, BTW, I think I've set up the SVN to send the commit comments to
the cclib-svn mailing list. You might want to subscribe to this to keep
uptodate. I'm not yet sure if I've set it up properly though.

What do you think?

Regards,
 Noel

[cclib-devel] First message

[Noel O'B. <no...@ca...>]

Hello everyone,

This is a test message to make sure that everything is set up correctly.

Regards,
 Noel