cclib-devel Mailing List for cclib (Page 35)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello Chris,

Just wondering whether you're waiting for us to do something, or
whether you need any help to get started?

BTW, anyone going to the ACS in Boston? Me, at least.

Regards,
   Noel

Bugs item #1756794, was opened at 2007-07-19 13:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756794&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: GAMESS: Raman parsing fails

Initial Comment:
Reported by Charlie Bradshaw, but IP issues prevent me looking at the test file.

Dear Noel,

The attached .zip file contains a gamess log with runtype=raman on the
musk ambrette molecule.  GaussSum fails to open the log due to a
parsing error.  According to the documentation IR_raman.py should
handle this.  This log file also crashes Chemcraft, so it may be a
problem with the log.  There were a number of modes with *******
instead of activity where I changed the string of "*" to 0.0.

Best regards,

Charlie

Dr. Charles F. Bradshaw
The MITRE Corporation

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756794&group_id=161285

Bugs item #1756789, was opened at 2007-07-19 13:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756789&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gaussian: problem reading MO values

Initial Comment:
Reported by Jerome Kieffer; no test file due to IP issues.

Dear CCLib developpers,

I noticed a bug when reading a gaussian log file when the energy of the deepest orbital cannot fit in the formated 9 char .
Maybe this is due to the 2 iodines in this molecule (di-iodophenyl) or to the Dgauss DZVP basis set used.

Of course the bug occures by the python command :
float("**********"), in Logfile.parse.float(), line 188 of logfileparser.py

Here is an extract of the gaussian output.
 The electronic state is 1-A.
 Alpha  occ. eigenvalues -- ********************-176.38175-176.37760-165.76438
 Alpha  occ. eigenvalues -- -165.76230-165.76225-165.76023-165.75813-165.75807
 Alpha  occ. eigenvalues --  -35.82446 -35.82036 -31.33591 -31.33183 -31.33009

Kind regards.
--
Jérôme Kieffer (PhD)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756789&group_id=161285

I've done some more on this, it's now at
http://www.redbrick.dcu.ie/~noel/cclib/ccWeb.py with some discussion
on my blog at:
http://baoilleach.blogspot.com/2007/07/ccweb-lightweight-web-service-for.html

It would be nice to do a web page with a form where you can paste in
the contents of your log file, click SEND, and it will present the
results as a nicely formatted web page. It would also be useful for
asking Orca users, for example, to test out a parser that's in
development.

Regards,
   Noel

On 17/07/07, Noel O'Boyle <bao...@gm...> wrote:
> I've got a simple cclib-based webservice running. You can check it out
> by running something like the following script. It doesn't need
> simplejson, but if available, it will use it in preference to 'eval'
> (which can be a security risk).
>
> import urllib
> try:
>     import simplejson
> except:
>     simplejson = None
>
> data = urllib.urlencode({'logfile': open("dvb_sp.out").read()})
> f = urllib.urlopen("http://www.redbrick.dcu.ie/~noel/cclib/test.py", data)
> if simplejson:
>     result = simplejson.loads(f.read())
> else:
>     result = eval(f.read())
> print result.keys()
>
> Now you can use cclib even if it isn't installed on your own computer,
> or from a variety of different programming languages. I don't yet deal
> with errors correctly, so don't stress the script too much!
>
> Noel
>

>> (1) Moved cclibData from logfileparser.py to ../data.py, and
>> renamed to ccData
>> Rationale: this data is the core of the library. It doesn't really
>> below in any of cclib's submodules, so I moved it to the top level.
>
> This makes sense to me. We also still need to discuss how we're going
> to handle ccData and the various methods, but that probably needs a
> new thread.
Of course... I had no more time to work on the data/parser separation, and
I'm glad to see more pieces falling into place.

Karol

Bugs item #1756064, was opened at 2007-07-18 13:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756064&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gaussian parse error for #T

Initial Comment:
Christoph Steinbeck reported that a Gaussian file broke GaussSum. It seems that #T files don't include nbasis whereas the parser code assumes that this exists.

File attached, and we have permission from Christoph to make it public domain. (This is an NMR calculation)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756064&group_id=161285

Bugs item #1756059, was opened at 2007-07-18 13:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756059&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: GAMESS-UK mocoeffs or aooverlaps error

Initial Comment:
I've just noticed that there's a problem with the Mulliken analysis of GAMESS-UK files. There's either something wrong with the mocoeffs or the aooverlaps parsed from these.

Need to figure out the problem and add a unit test to ensure it doesn't reoccur.

Noel

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756059&group_id=161285

I've got a simple cclib-based webservice running. You can check it out
by running something like the following script. It doesn't need
simplejson, but if available, it will use it in preference to 'eval'
(which can be a security risk).

import urllib
try:
    import simplejson
except:
    simplejson = None

data = urllib.urlencode({'logfile': open("dvb_sp.out").read()})
f = urllib.urlopen("http://www.redbrick.dcu.ie/~noel/cclib/test.py", data)
if simplejson:
    result = simplejson.loads(f.read())
else:
    result = eval(f.read())
print result.keys()

Now you can use cclib even if it isn't installed on your own computer,
or from a variety of different programming languages. I don't yet deal
with errors correctly, so don't stress the script too much!

Noel

> (1) Moved cclibData from logfileparser.py to ../data.py, and  
> renamed to ccData
> Rationale: this data is the core of the library. It doesn't really
> below in any of cclib's submodules, so I moved it to the top level.

This makes sense to me. We also still need to discuss how we're going  
to handle ccData and the various methods, but that probably needs a  
new thread.

Adam

I did a bit of work on adding JSON support but it turned out I needed
to change a few things to get it to work. I also made some arbitary
decisions (see (1) below) which I'd like you guys to comment on.

First of all, JSON support is via simplejson. We could bundle this in
with cclib, or just expect users to install it if they wanted to use
this feature.

Here's the log message with some additional comments.

(1) Moved cclibData from logfileparser.py to ../data.py, and renamed to ccData
Rationale: this data is the core of the library. It doesn't really
below in any of cclib's submodules, so I moved it to the top level.
(2) Added methods to ccData: listify() and arrayify() to convert array
attributes to and from lists
Rationale: I think these will be useful in general, but they are
required for the JSON library, which doesn't handle arrays.
(3) Commented out __setattr__ magic, in favour of a call to arrayify()
in logfileparser.py
Rationale: this prevented listify() from working. As soon as I tried
to turn an array into a list, it automagically reverted it back to an
array.
(4) Added the writejson() method to ccData, which either returns a
JSON string, or writes it to a file
Rationale: well, this was the whole point

Notes:
(1) pickle now works, both for the arrayified ccData, and the listified one.
The pickled file is slightly smaller for the listified version, but
nothing major. We could add a writepickle() method. To be honest, I
think this would be overengineering.
(2) ccData._attrlist is duplicated by ccData._attrtypes.keys()
So...we should probably dump attrlist. Just something I noticed.

Regards,
   Noel

First of all, it's available at
http://www.orcaware.com/svn/wiki/Svnmerge.py (you might as well get
the trunk version).

Then read under "Development branches", and follow the instructions
there as this is exactly what you want to do.

What it boils down to, is that you should never use "svn merge"
yourself; you should always use "svnmerge.py" and it will just merge
everything that's available that hasn't already been merged.

I think you'll find it quite easy to use. Future versions of SVN are
likely to include this functionality natively.

Noel

On 12/07/07, Adam Tenderholt <a-t...@st...> wrote:
> svnmerge.py was mentioned awhile back for merging different branches.
> Noel, do you want to give some pointers on how to use this script?
> It'd be nice to know a quick and relatively easy way to merge the
> recent test and parser changes back into the orca branch I've created.
>
> Adam
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

svnmerge.py was mentioned awhile back for merging different branches.  
Noel, do you want to give some pointers on how to use this script?  
It'd be nice to know a quick and relatively easy way to merge the  
recent test and parser changes back into the orca branch I've created.

Adam

> Before you do anything, you should realise that this code is tightly
> linked to PyMOlyze, so  unless Adam agrees...

I agree that it makes sense to pass cclibData (or even attributes of  
cclibData) to the calculation methods instead of the parsers. Right  
now, I think it would be best to pass cclibData instead of attributes  
so that the interface for the methods remain as similar as possible.  
For instance: CSPA doesn't need overlaps, while most other  
populations analyses do.

Also, will the methods add the calculated attributes to the  
cclibData? The current implementations allow a FragmentAnalysis  
object to be passed directly to any of the population analysis  
methods, which is quite convenient for determining which fragment MOs  
contribute to the MOs of the entire molecule.

Adam

> I just created a sourceforge account for myself: cnrowley
OK - you've just been added to the cclib dev team. Welcome!

> I'll be programming on a Fedora Core 6 platform.
>
> I authored a couple of GPL programs years back, but I've never been part
> of a development team.
It's much more fun being part of a team. Seriously.

> I've never used subversion, other than using it to grab source trees. I
> used CVS years back, so expect it will just take me a few hours to read
> the manuals and get the hang of it.

Some docs you might want to read:
(1) Check out the links at
http://cclib.sourceforge.net/wiki/index.php/Development. You may want
to point your RSS reader to the CIA page, in particular.

(2) SVN is easier and nicer than CVS. You can view the structure of
our repository at:
   http://cclib.svn.sourceforge.net/viewvc/cclib/

You may want to checkout the trunk, as well as the turbomole branch:

svn checkout https://cclib.svn.sourceforge.net/svnroot/cclib/trunk cclibtrunk
svn checkout https://cclib.svn.sourceforge.net/svnroot/cclib/braches/turbomoleparser
turbomole

(3) The SVN book is:
http://svnbook.red-bean.com/

(4) A nice OS devel book is:
http://producingoss.com/

> I use python in my research, mostly for parsing but I do use it for some
> computation. My code can be a little sloppy, although I'll try to make
> an effort to keep anything I submit clean. Feel free to make criticisms
> of my code.

We try (in a general way) to keep to PEP 8 at:
   http://www.python.org/dev/peps/pep-0008/

There also some code I run from time to time that checks for PEP
8ness. But don't get bogged down in this. If you look at what's there
already in the other parsers you'll get the idea.

We're also interested in adding algorithms to cclib, so if you know a
nice one, feel free.

OK, I think that's enough for now. :-)

Noel

> Chris
>
> -----Original Message-----
> From: Noel O'Boyle [mailto:bao...@gm...]
> Sent: Thursday, July 12, 2007 8:40 AM
> To: Christopher Rowley
> Cc: cclib-dev List
> Subject: Re: [cclib-devel] Turbomole parser
>
> The important thing is now to get you coding. I've created a branch
> for the turbomoleparser called um, turbomoleparser or something. We
> can test out on this branch how to include multiple files, but I
> recommend that in the meanwhile you pick your favourite file and start
> working on that.
>
> It might help at this point if you can say what OS you are working on
> (I think we have one developer at the moment on Linux, one on Windows,
> one on Mac), and how familiar are you with the following:
>
> (1) Open source devel
> (2) Subversion
> (3) Python
>
> This will let us know how much we should explain things. Feel free of
> course to ask any questions, and don't worry about making mistakes.
>
> Oh yes, and don't forget to create a Sourceforge (SF) account and send
> me the name...
>
> Regards,
>    Noel
>
>
> On 11/07/07, Christopher Rowley <cro...@uo...> wrote:
> > I've attached a zip of the turbomole output files for the optimization
> > of ethene.
> >
> > I have a summary of the important files here:
> >
> > control - this is a ascii file that specifies the type of calculation
> to
> > run. It also contains keywords that specify the location of other
> files
> > related to the calculation
> > ie. $basis    file=basis
> >
> > basis - ascii file containing all the basis functions used in the
> > calculation
> > ie:
> > $basis
> > *
> > c def2-TZVPP
> > # c     (11s6p2d1f) / [5s3p2d1f]     {62111/411/11/1}
> > *
> >    6  s
> >   13575.349682      0.22245814352E-03
> >   2035.2333680      0.17232738252E-02
> >   463.22562359      0.89255715314E-02
> >   131.20019598      0.35727984502E-01
> >   42.853015891      0.11076259931
> >   15.584185766      0.24295627626
> >    2  s
> >  ...
> > $end
> >
> > energy - ascii file containing the final SCF energy for each
> > optimization step
> > $energy      SCF               SCFKIN            SCFPOT
> >      1   -78.62006391840    78.22049121937  -156.84055513777
> > ...
> >      5   -78.62016433199    78.17813647354  -156.79830080553
> > $end
> >
> > gradient - ascii file containing the final SCF energy, the norm of the
> > gradient, the cartesian coordinates,
> > and the gradient at each optimization step
> >
> > $grad          cartesian gradients
> >   cycle =      1    SCF energy =    -78.6200639184   |dE/dxyz| =
> > 0.007787
> >   -12.43305554870021      1.45676390273213      0.00000001455089
> c
> >   -11.46168130574795     -0.34900040894297     -0.00000002588925
> h
> >   -14.48255219706143      1.39416928077853     -0.00000005914843
> h
> >   -11.17787929057337      3.63195569944202     -0.00000000094486
> c
> >   -12.14925477129624      5.43772016116137     -0.00000002135391
> h
> >    -9.12838183435422      3.69454983309038     -0.00000005461309
> h
> >   0.37240190690901D-03  0.57948431095057D-03  0.38853271069288D-08
> >   -.18362345421673D-02  0.34133613968580D-02  -.97583915002572D-09
> >   0.38481666111819D-02  0.11765947797167D-03  -.22974479052215D-08
> >   -.37249153523038D-03  -.57960132610911D-03  0.12907959533087D-08
> >   0.18360651045835D-02  -.34131936211959D-02  -.29052983458520D-09
> >   -.38479075912553D-02  -.11771021861143D-03  -.16148640940085D-08
> > ...
> > $end
> >
> > mos - Contains the MO energies and coefficients in 4d20.14 format
> >
> > $scfmo    scfconv=6   format(4d20.14)
> > # SCF total energy is      -78.6201643320 a.u.
> > #
> >      1  a      eigenvalue=-.98998832838354D+01   nsaos=118
> >
> 0.33525257887995D+000.43483755824514D+000.29687028164704D-010.1443675670
> > 3553D-01
> >
> 0.52678143243858D-02-.10363028095958D-060.11827623499659D-03-.1226611495
> > 0504D-10
> >
> 0.13566446246138D-05-.13171691954860D-01-.21677290745517D-09-.4112147855
> > 9874D-06
> >
> -.28603744354330D-03-.85454212224573D-11-.14708011769907D-020.6148298791
> > 2470D-10
> >
> 0.20389102757828D-100.20796546607765D-060.72089304597414D-03-.3544240520
> > 8995D-02
> >
> 0.41175724483158D-090.55184920814757D-10-.79343053802777D-060.7001808373
> > 3727D-02
> >
> 0.36597788268211D-10-.49165972048646D-070.13379843496344D-02-.9468926087
> > 0386D-10
> >
> -.26197917829845D-100.85579464932607D-060.15672280349784D-020.2630723827
> > 4649D-04
> >
> -.17447811306186D-01-.16629360526852D-020.11032161215752D-02-.6181968637
> > 1091D-03
> >
> 0.14490807816497D-100.66606858738943D-02-.55586812728540D-020.3203660664
> > 0502D-10
> > ...
> >
> > For open shell systems, there are two separate files for the MO
> > coefficients, alpha and beta
> >
> > job.last - each optimization step writes output to a file job.x on the
> > details of the calculation,
> > such as SCF iteractions. Additional output, such as dipole moments, is
> > also written here. This is analogous to a log file like in other
> > programs.
> >
> > hessian - ascii file - for frequency analysis calculations, this file
> > contains the hessian (I'm not immediately sure what the format is)
> >
> > -----Original Message-----
> > From: Noel O'Boyle [mailto:bao...@gm...]
> > Sent: Wednesday, July 11, 2007 2:54 AM
> > To: Adam Tenderholt
> > Cc: Christopher Rowley; ccl...@li...
> > Subject: Re: [cclib-devel] Turbomole parser
> >
> > Hello Chris,
> >
> > Good to hear from you and welcome to cclib. We welcome all the help we
> > can get so there's really no question about approval. Our only
> > standard is that the code works before we release it, and we have a
> > number of tests that try to ensure this is the case.
> >
> > On 11/07/07, Adam Tenderholt <a-t...@st...> wrote:
> > > > Ok, I'll try to set aside some time do to it once there's
> approval.
> > I
> > > > have a project needs automated CDA analysis with turbomole, so I'd
> > be
> > > > looking get parser for the MO coefficients working first.
> > >
> > > I too generally focus on MO coeffs, so if you want help, let me
> know.
> > > One of the first steps you could take is to have a look at our basic
> > > test datafiles, and start running calculations with those.
> > > Specifically, you should run dvb_sp and dvb_un_sp. Both are
> > > calculations on di-vinylbenzene, and I believe you can find xyz
> > > coordinates in the input files of other calculations. The SP calc is
> > > a restricted single-point calc with no net charge and the UN_SP calc
> > > is an unrestricted single-point with a positive charge and a
> > > multiplicity of 2.
> > >
> > > > I took a look at the other parsers and I don't think it will be
> that
> > > > difficult to get turbomole working. The only significant problem
> is
> > > > that
> > > > turbomole doesn't put all its output in a single file. I generally
> > > > keep
> > > > a separate directory for each turbomole calculation. The simplest
> > > > way to
> > > > do it would be to pass the path of a directory containing the
> > > > output of
> > > > a turbomole job to the parser instead of the filename of the
> output
> > > > file.
> > > >
> > > > This would be inconsistent with all the other parsers, so it's a
> > > > little
> > > > unattractive. The other route I can see is to have a separate
> > > > utility to
> > > > merge the various turbomole output files into a single output file
> > > > that
> > > > could be read in by the parser.
> > >
> > > I'd suggest using cat to combine all of the files into one, although
> > > this probably isn't the best option for our windows-using friends.
> > > Perhaps we should handle zip or tar files (we already handle gz and
> > > bzip2, as I recall). Noel, Karol, any comments? I'm willing to help
> > > add any logfiles or code to a branch in the svn tree during the next
> > > few days, so if you have anything ready, let me know.
> >
> > Perhaps Chris, you could describe in detail the typical output from a
> > Turbomole calculation; that is, what files are created, what do they
> > contain (in general terms), are they ASCII files or binary. It might
> > make sense if you send to this list a .zip file of results of a small
> > example calculation.
> >
> > One possibility is that we have several parsers for several files. At
> > first this may seem messy, but we are moving towards separating the
> > parsers and the results, and it will be trivial for the user to add
> > the results together. But let's take a look at the actual output first
> > before we think about this too much.
> >
> > Some bookkeeping now. Can you create an account on SourceForge and
> > send me the name? I will need this to make you a developer.
> >
> > > Adam
> > >
> > >
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > -
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > cclib-devel mailing list
> > > ccl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > >
> >
> >
>

Don't forget to reply-all. :-)

---------- Forwarded message ----------
From: Christopher Rowley <cro...@uo...>
Date: 12-Jul-2007 16:18
Subject: RE: [cclib-devel] Turbomole parser
To: Noel O'Boyle <bao...@gm...>

Hi Noel,

I just created a sourceforge account for myself: cnrowley

I'll be programming on a Fedora Core 6 platform.

I authored a couple of GPL programs years back, but I've never been part
of a development team.

I've never used subversion, other than using it to grab source trees. I
used CVS years back, so expect it will just take me a few hours to read
the manuals and get the hang of it.

I use python in my research, mostly for parsing but I do use it for some
computation. My code can be a little sloppy, although I'll try to make
an effort to keep anything I submit clean. Feel free to make criticisms
of my code.

Chris

-----Original Message-----
From: Noel O'Boyle [mailto:bao...@gm...]
Sent: Thursday, July 12, 2007 8:40 AM
To: Christopher Rowley
Cc: cclib-dev List
Subject: Re: [cclib-devel] Turbomole parser

The important thing is now to get you coding. I've created a branch
for the turbomoleparser called um, turbomoleparser or something. We
can test out on this branch how to include multiple files, but I
recommend that in the meanwhile you pick your favourite file and start
working on that.

It might help at this point if you can say what OS you are working on
(I think we have one developer at the moment on Linux, one on Windows,
one on Mac), and how familiar are you with the following:

(1) Open source devel
(2) Subversion
(3) Python

This will let us know how much we should explain things. Feel free of
course to ask any questions, and don't worry about making mistakes.

Oh yes, and don't forget to create a Sourceforge (SF) account and send
me the name...

Regards,
   Noel

On 11/07/07, Christopher Rowley <cro...@uo...> wrote:
> I've attached a zip of the turbomole output files for the optimization
> of ethene.
>
> I have a summary of the important files here:
>
> control - this is a ascii file that specifies the type of calculation
to
> run. It also contains keywords that specify the location of other
files
> related to the calculation
> ie. $basis    file=basis
>
> basis - ascii file containing all the basis functions used in the
> calculation
> ie:
> $basis
> *
> c def2-TZVPP
> # c     (11s6p2d1f) / [5s3p2d1f]     {62111/411/11/1}
> *
>    6  s
>   13575.349682      0.22245814352E-03
>   2035.2333680      0.17232738252E-02
>   463.22562359      0.89255715314E-02
>   131.20019598      0.35727984502E-01
>   42.853015891      0.11076259931
>   15.584185766      0.24295627626
>    2  s
>  ...
> $end
>
> energy - ascii file containing the final SCF energy for each
> optimization step
> $energy      SCF               SCFKIN            SCFPOT
>      1   -78.62006391840    78.22049121937  -156.84055513777
> ...
>      5   -78.62016433199    78.17813647354  -156.79830080553
> $end
>
> gradient - ascii file containing the final SCF energy, the norm of the
> gradient, the cartesian coordinates,
> and the gradient at each optimization step
>
> $grad          cartesian gradients
>   cycle =      1    SCF energy =    -78.6200639184   |dE/dxyz| =
> 0.007787
>   -12.43305554870021      1.45676390273213      0.00000001455089
c
>   -11.46168130574795     -0.34900040894297     -0.00000002588925
h
>   -14.48255219706143      1.39416928077853     -0.00000005914843
h
>   -11.17787929057337      3.63195569944202     -0.00000000094486
c
>   -12.14925477129624      5.43772016116137     -0.00000002135391
h
>    -9.12838183435422      3.69454983309038     -0.00000005461309
h
>   0.37240190690901D-03  0.57948431095057D-03  0.38853271069288D-08
>   -.18362345421673D-02  0.34133613968580D-02  -.97583915002572D-09
>   0.38481666111819D-02  0.11765947797167D-03  -.22974479052215D-08
>   -.37249153523038D-03  -.57960132610911D-03  0.12907959533087D-08
>   0.18360651045835D-02  -.34131936211959D-02  -.29052983458520D-09
>   -.38479075912553D-02  -.11771021861143D-03  -.16148640940085D-08
> ...
> $end
>
> mos - Contains the MO energies and coefficients in 4d20.14 format
>
> $scfmo    scfconv=6   format(4d20.14)
> # SCF total energy is      -78.6201643320 a.u.
> #
>      1  a      eigenvalue=-.98998832838354D+01   nsaos=118
>
0.33525257887995D+000.43483755824514D+000.29687028164704D-010.1443675670
> 3553D-01
>
0.52678143243858D-02-.10363028095958D-060.11827623499659D-03-.1226611495
> 0504D-10
>
0.13566446246138D-05-.13171691954860D-01-.21677290745517D-09-.4112147855
> 9874D-06
>
-.28603744354330D-03-.85454212224573D-11-.14708011769907D-020.6148298791
> 2470D-10
>
0.20389102757828D-100.20796546607765D-060.72089304597414D-03-.3544240520
> 8995D-02
>
0.41175724483158D-090.55184920814757D-10-.79343053802777D-060.7001808373
> 3727D-02
>
0.36597788268211D-10-.49165972048646D-070.13379843496344D-02-.9468926087
> 0386D-10
>
-.26197917829845D-100.85579464932607D-060.15672280349784D-020.2630723827
> 4649D-04
>
-.17447811306186D-01-.16629360526852D-020.11032161215752D-02-.6181968637
> 1091D-03
>
0.14490807816497D-100.66606858738943D-02-.55586812728540D-020.3203660664
> 0502D-10
> ...
>
> For open shell systems, there are two separate files for the MO
> coefficients, alpha and beta
>
> job.last - each optimization step writes output to a file job.x on the
> details of the calculation,
> such as SCF iteractions. Additional output, such as dipole moments, is
> also written here. This is analogous to a log file like in other
> programs.
>
> hessian - ascii file - for frequency analysis calculations, this file
> contains the hessian (I'm not immediately sure what the format is)
>
> -----Original Message-----
> From: Noel O'Boyle [mailto:bao...@gm...]
> Sent: Wednesday, July 11, 2007 2:54 AM
> To: Adam Tenderholt
> Cc: Christopher Rowley; ccl...@li...
> Subject: Re: [cclib-devel] Turbomole parser
>
> Hello Chris,
>
> Good to hear from you and welcome to cclib. We welcome all the help we
> can get so there's really no question about approval. Our only
> standard is that the code works before we release it, and we have a
> number of tests that try to ensure this is the case.
>
> On 11/07/07, Adam Tenderholt <a-t...@st...> wrote:
> > > Ok, I'll try to set aside some time do to it once there's
approval.
> I
> > > have a project needs automated CDA analysis with turbomole, so I'd
> be
> > > looking get parser for the MO coefficients working first.
> >
> > I too generally focus on MO coeffs, so if you want help, let me
know.
> > One of the first steps you could take is to have a look at our basic
> > test datafiles, and start running calculations with those.
> > Specifically, you should run dvb_sp and dvb_un_sp. Both are
> > calculations on di-vinylbenzene, and I believe you can find xyz
> > coordinates in the input files of other calculations. The SP calc is
> > a restricted single-point calc with no net charge and the UN_SP calc
> > is an unrestricted single-point with a positive charge and a
> > multiplicity of 2.
> >
> > > I took a look at the other parsers and I don't think it will be
that
> > > difficult to get turbomole working. The only significant problem
is
> > > that
> > > turbomole doesn't put all its output in a single file. I generally
> > > keep
> > > a separate directory for each turbomole calculation. The simplest
> > > way to
> > > do it would be to pass the path of a directory containing the
> > > output of
> > > a turbomole job to the parser instead of the filename of the
output
> > > file.
> > >
> > > This would be inconsistent with all the other parsers, so it's a
> > > little
> > > unattractive. The other route I can see is to have a separate
> > > utility to
> > > merge the various turbomole output files into a single output file
> > > that
> > > could be read in by the parser.
> >
> > I'd suggest using cat to combine all of the files into one, although
> > this probably isn't the best option for our windows-using friends.
> > Perhaps we should handle zip or tar files (we already handle gz and
> > bzip2, as I recall). Noel, Karol, any comments? I'm willing to help
> > add any logfiles or code to a branch in the svn tree during the next
> > few days, so if you have anything ready, let me know.
>
> Perhaps Chris, you could describe in detail the typical output from a
> Turbomole calculation; that is, what files are created, what do they
> contain (in general terms), are they ASCII files or binary. It might
> make sense if you send to this list a .zip file of results of a small
> example calculation.
>
> One possibility is that we have several parsers for several files. At
> first this may seem messy, but we are moving towards separating the
> parsers and the results, and it will be trivial for the user to add
> the results together. But let's take a look at the actual output first
> before we think about this too much.
>
> Some bookkeeping now. Can you create an account on SourceForge and
> send me the name? I will need this to make you a developer.
>
> > Adam
> >
> >
> >
> >
> >
>
------------------------------------------------------------------------
> -
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
>
>

The important thing is now to get you coding. I've created a branch
for the turbomoleparser called um, turbomoleparser or something. We
can test out on this branch how to include multiple files, but I
recommend that in the meanwhile you pick your favourite file and start
working on that.

It might help at this point if you can say what OS you are working on
(I think we have one developer at the moment on Linux, one on Windows,
one on Mac), and how familiar are you with the following:

(1) Open source devel
(2) Subversion
(3) Python

This will let us know how much we should explain things. Feel free of
course to ask any questions, and don't worry about making mistakes.

Oh yes, and don't forget to create a Sourceforge (SF) account and send
me the name...

Regards,
   Noel

On 11/07/07, Christopher Rowley <cro...@uo...> wrote:
> I've attached a zip of the turbomole output files for the optimization
> of ethene.
>
> I have a summary of the important files here:
>
> control - this is a ascii file that specifies the type of calculation to
> run. It also contains keywords that specify the location of other files
> related to the calculation
> ie. $basis    file=basis
>
> basis - ascii file containing all the basis functions used in the
> calculation
> ie:
> $basis
> *
> c def2-TZVPP
> # c     (11s6p2d1f) / [5s3p2d1f]     {62111/411/11/1}
> *
>    6  s
>   13575.349682      0.22245814352E-03
>   2035.2333680      0.17232738252E-02
>   463.22562359      0.89255715314E-02
>   131.20019598      0.35727984502E-01
>   42.853015891      0.11076259931
>   15.584185766      0.24295627626
>    2  s
>  ...
> $end
>
> energy - ascii file containing the final SCF energy for each
> optimization step
> $energy      SCF               SCFKIN            SCFPOT
>      1   -78.62006391840    78.22049121937  -156.84055513777
> ...
>      5   -78.62016433199    78.17813647354  -156.79830080553
> $end
>
> gradient - ascii file containing the final SCF energy, the norm of the
> gradient, the cartesian coordinates,
> and the gradient at each optimization step
>
> $grad          cartesian gradients
>   cycle =      1    SCF energy =    -78.6200639184   |dE/dxyz| =
> 0.007787
>   -12.43305554870021      1.45676390273213      0.00000001455089      c
>   -11.46168130574795     -0.34900040894297     -0.00000002588925      h
>   -14.48255219706143      1.39416928077853     -0.00000005914843      h
>   -11.17787929057337      3.63195569944202     -0.00000000094486      c
>   -12.14925477129624      5.43772016116137     -0.00000002135391      h
>    -9.12838183435422      3.69454983309038     -0.00000005461309      h
>   0.37240190690901D-03  0.57948431095057D-03  0.38853271069288D-08
>   -.18362345421673D-02  0.34133613968580D-02  -.97583915002572D-09
>   0.38481666111819D-02  0.11765947797167D-03  -.22974479052215D-08
>   -.37249153523038D-03  -.57960132610911D-03  0.12907959533087D-08
>   0.18360651045835D-02  -.34131936211959D-02  -.29052983458520D-09
>   -.38479075912553D-02  -.11771021861143D-03  -.16148640940085D-08
> ...
> $end
>
> mos - Contains the MO energies and coefficients in 4d20.14 format
>
> $scfmo    scfconv=6   format(4d20.14)
> # SCF total energy is      -78.6201643320 a.u.
> #
>      1  a      eigenvalue=-.98998832838354D+01   nsaos=118
> 0.33525257887995D+000.43483755824514D+000.29687028164704D-010.1443675670
> 3553D-01
> 0.52678143243858D-02-.10363028095958D-060.11827623499659D-03-.1226611495
> 0504D-10
> 0.13566446246138D-05-.13171691954860D-01-.21677290745517D-09-.4112147855
> 9874D-06
> -.28603744354330D-03-.85454212224573D-11-.14708011769907D-020.6148298791
> 2470D-10
> 0.20389102757828D-100.20796546607765D-060.72089304597414D-03-.3544240520
> 8995D-02
> 0.41175724483158D-090.55184920814757D-10-.79343053802777D-060.7001808373
> 3727D-02
> 0.36597788268211D-10-.49165972048646D-070.13379843496344D-02-.9468926087
> 0386D-10
> -.26197917829845D-100.85579464932607D-060.15672280349784D-020.2630723827
> 4649D-04
> -.17447811306186D-01-.16629360526852D-020.11032161215752D-02-.6181968637
> 1091D-03
> 0.14490807816497D-100.66606858738943D-02-.55586812728540D-020.3203660664
> 0502D-10
> ...
>
> For open shell systems, there are two separate files for the MO
> coefficients, alpha and beta
>
> job.last - each optimization step writes output to a file job.x on the
> details of the calculation,
> such as SCF iteractions. Additional output, such as dipole moments, is
> also written here. This is analogous to a log file like in other
> programs.
>
> hessian - ascii file - for frequency analysis calculations, this file
> contains the hessian (I'm not immediately sure what the format is)
>
> -----Original Message-----
> From: Noel O'Boyle [mailto:bao...@gm...]
> Sent: Wednesday, July 11, 2007 2:54 AM
> To: Adam Tenderholt
> Cc: Christopher Rowley; ccl...@li...
> Subject: Re: [cclib-devel] Turbomole parser
>
> Hello Chris,
>
> Good to hear from you and welcome to cclib. We welcome all the help we
> can get so there's really no question about approval. Our only
> standard is that the code works before we release it, and we have a
> number of tests that try to ensure this is the case.
>
> On 11/07/07, Adam Tenderholt <a-t...@st...> wrote:
> > > Ok, I'll try to set aside some time do to it once there's approval.
> I
> > > have a project needs automated CDA analysis with turbomole, so I'd
> be
> > > looking get parser for the MO coefficients working first.
> >
> > I too generally focus on MO coeffs, so if you want help, let me know.
> > One of the first steps you could take is to have a look at our basic
> > test datafiles, and start running calculations with those.
> > Specifically, you should run dvb_sp and dvb_un_sp. Both are
> > calculations on di-vinylbenzene, and I believe you can find xyz
> > coordinates in the input files of other calculations. The SP calc is
> > a restricted single-point calc with no net charge and the UN_SP calc
> > is an unrestricted single-point with a positive charge and a
> > multiplicity of 2.
> >
> > > I took a look at the other parsers and I don't think it will be that
> > > difficult to get turbomole working. The only significant problem is
> > > that
> > > turbomole doesn't put all its output in a single file. I generally
> > > keep
> > > a separate directory for each turbomole calculation. The simplest
> > > way to
> > > do it would be to pass the path of a directory containing the
> > > output of
> > > a turbomole job to the parser instead of the filename of the output
> > > file.
> > >
> > > This would be inconsistent with all the other parsers, so it's a
> > > little
> > > unattractive. The other route I can see is to have a separate
> > > utility to
> > > merge the various turbomole output files into a single output file
> > > that
> > > could be read in by the parser.
> >
> > I'd suggest using cat to combine all of the files into one, although
> > this probably isn't the best option for our windows-using friends.
> > Perhaps we should handle zip or tar files (we already handle gz and
> > bzip2, as I recall). Noel, Karol, any comments? I'm willing to help
> > add any logfiles or code to a branch in the svn tree during the next
> > few days, so if you have anything ready, let me know.
>
> Perhaps Chris, you could describe in detail the typical output from a
> Turbomole calculation; that is, what files are created, what do they
> contain (in general terms), are they ASCII files or binary. It might
> make sense if you send to this list a .zip file of results of a small
> example calculation.
>
> One possibility is that we have several parsers for several files. At
> first this may seem messy, but we are moving towards separating the
> parsers and the results, and it will be trivial for the user to add
> the results together. But let's take a look at the actual output first
> before we think about this too much.
>
> Some bookkeeping now. Can you create an account on SourceForge and
> send me the name? I will need this to make you a developer.
>
> > Adam
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------
> -
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
>
>

At some point I'd like cclib to also parse the MO eigenvectors for correlated 
methods - natural orbitals from MP2 or CI, and optimized orbitals after MCSCF 
calcualtions. They all have the format of mocoeffs, with different values. 
I'd like to have your opinion - should these be parsed into the same 
attribute as the SCF MOs (mocoeffs) or into a new one (mpcoeffs?)?

-- 
written by Karol Langner
Thu Jul 12 11:40:45 EDT 2007

On Thursday 12 July 2007 05:11, Noel O'Boyle wrote:
> Before you do anything, you should realise that this code is tightly
> linked to PyMOlyze, so  unless Adam agrees...

Yes, of course, I try not to make any commits that change the current 
functionality without everyone's apporval.

-- 
written by Karol Langner
Thu Jul 12 11:39:33 EDT 2007

On 12/07/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 12 July 2007 04:47, Noel O'Boyle wrote:
> > On 12/07/07, Karol Langner <kar...@kn...> wrote:
> > > On Thursday 12 July 2007 04:19, Noel O'Boyle wrote:
> > > > > Concerning Calculation Methods in cclib: they need to accept
> > > > > cclibData objects now. And a comment/idea: since cclibData objects
> > > > > are to hold cclib data in general, perhaps they should also contain
> > > > > the results of methods (MPA, etc.). It annoys me a little that after
> > > > > doing a population analysis I have a two objects, both containing
> > > > > data that concern the same calculation! On the other hand, other
> > > > > methods need multiple cclibData objects (CDA). Maybe a good
> > > > > alternative is to provide functions for some methods that add the
> > > > > method results to the same cclibData object passed to them, instead
> > > > > of creating a new object. I'm not sure if that is clear... do you
> > > > > have any comments?
> > > >
> > > > I'm not so sure about this. Personally, after a population analysis I
> > > > don't want an object at all. I just want some data structures, e.g.
> > > > the charges on the atoms, and whatever else. Similarily, I don't think
> > > > algorithms should be called with cclibData objects. They should just
> > > > be fed with whatever information they need (explicit > implicit).
> > > > Otherwise, people who want to use these algorithms independently of
> > > > cclibData are going to have to jump through some hoops. My 2c.
> > >
> > > What I mean is that until now Logfile objects were passed to the methods.
> > > Now cclibData objects will be passed. By "I don't want an object at all"
> > > do you mean that you would like the methods to return list, arrays, or
> > > whatever, instead of setting them as attributes (currently to an the
> > > method class instance)?
> >
> > Exactly.
>
> I didn't think of that... and the idea appeals to me :) so I'm +1 on that.
> This can be done right away, since the methods need to be fixed due to the
> parser-data separation anyway.

Before you do anything, you should realise that this code is tightly
linked to PyMOlyze, so  unless Adam agrees...

> --
> written by Karol Langner
> Thu Jul 12 10:59:29 EDT 2007
>

On Thursday 12 July 2007 04:47, Noel O'Boyle wrote:
> On 12/07/07, Karol Langner <kar...@kn...> wrote:
> > On Thursday 12 July 2007 04:19, Noel O'Boyle wrote:
> > > > Concerning Calculation Methods in cclib: they need to accept
> > > > cclibData objects now. And a comment/idea: since cclibData objects
> > > > are to hold cclib data in general, perhaps they should also contain
> > > > the results of methods (MPA, etc.). It annoys me a little that after
> > > > doing a population analysis I have a two objects, both containing
> > > > data that concern the same calculation! On the other hand, other
> > > > methods need multiple cclibData objects (CDA). Maybe a good
> > > > alternative is to provide functions for some methods that add the
> > > > method results to the same cclibData object passed to them, instead
> > > > of creating a new object. I'm not sure if that is clear... do you
> > > > have any comments?
> > >
> > > I'm not so sure about this. Personally, after a population analysis I
> > > don't want an object at all. I just want some data structures, e.g.
> > > the charges on the atoms, and whatever else. Similarily, I don't think
> > > algorithms should be called with cclibData objects. They should just
> > > be fed with whatever information they need (explicit > implicit).
> > > Otherwise, people who want to use these algorithms independently of
> > > cclibData are going to have to jump through some hoops. My 2c.
> >
> > What I mean is that until now Logfile objects were passed to the methods.
> > Now cclibData objects will be passed. By "I don't want an object at all"
> > do you mean that you would like the methods to return list, arrays, or
> > whatever, instead of setting them as attributes (currently to an the
> > method class instance)?
>
> Exactly.

I didn't think of that... and the idea appeals to me :) so I'm +1 on that. 
This can be done right away, since the methods need to be fixed due to the 
parser-data separation anyway.

-- 
written by Karol Langner
Thu Jul 12 10:59:29 EDT 2007

On 12/07/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 12 July 2007 04:19, Noel O'Boyle wrote:
> > > Concerning Calculation Methods in cclib: they need to accept cclibData
> > > objects now. And a comment/idea: since cclibData objects are to hold
> > > cclib data in general, perhaps they should also contain the results of
> > > methods (MPA, etc.). It annoys me a little that after doing a population
> > > analysis I have a two objects, both containing data that concern the same
> > > calculation! On the other hand, other methods need multiple cclibData
> > > objects (CDA). Maybe a good alternative is to provide functions for some
> > > methods that add the method results to the same cclibData object passed
> > > to them, instead of creating a new object. I'm not sure if that is
> > > clear... do you have any comments?
> >
> > I'm not so sure about this. Personally, after a population analysis I
> > don't want an object at all. I just want some data structures, e.g.
> > the charges on the atoms, and whatever else. Similarily, I don't think
> > algorithms should be called with cclibData objects. They should just
> > be fed with whatever information they need (explicit > implicit).
> > Otherwise, people who want to use these algorithms independently of
> > cclibData are going to have to jump through some hoops. My 2c.
>
> What I mean is that until now Logfile objects were passed to the methods. Now
> cclibData objects will be passed. By "I don't want an object at all" do you
> mean that you would like the methods to return list, arrays, or whatever,
> instead of setting them as attributes (currently to an the method class
> instance)?

Exactly.

> --
> written by Karol Langner
> Thu Jul 12 10:26:27 EDT 2007
>

On Thursday 12 July 2007 04:19, Noel O'Boyle wrote:
> > Concerning Calculation Methods in cclib: they need to accept cclibData
> > objects now. And a comment/idea: since cclibData objects are to hold
> > cclib data in general, perhaps they should also contain the results of
> > methods (MPA, etc.). It annoys me a little that after doing a population
> > analysis I have a two objects, both containing data that concern the same
> > calculation! On the other hand, other methods need multiple cclibData
> > objects (CDA). Maybe a good alternative is to provide functions for some
> > methods that add the method results to the same cclibData object passed
> > to them, instead of creating a new object. I'm not sure if that is
> > clear... do you have any comments?
>
> I'm not so sure about this. Personally, after a population analysis I
> don't want an object at all. I just want some data structures, e.g.
> the charges on the atoms, and whatever else. Similarily, I don't think
> algorithms should be called with cclibData objects. They should just
> be fed with whatever information they need (explicit > implicit).
> Otherwise, people who want to use these algorithms independently of
> cclibData are going to have to jump through some hoops. My 2c.

What I mean is that until now Logfile objects were passed to the methods. Now 
cclibData objects will be passed. By "I don't want an object at all" do you 
mean that you would like the methods to return list, arrays, or whatever, 
instead of setting them as attributes (currently to an the method class 
instance)?

-- 
written by Karol Langner
Thu Jul 12 10:26:27 EDT 2007

On 12/07/07, Karol Langner <kar...@kn...> wrote:
> On Wednesday 11 July 2007 11:56, Noel O'Boyle wrote:
> > On 11/07/07, Adam Tenderholt <a-t...@st...> wrote:
> > > Can you (again) describe what changes will be necessary?
>
> There is a new class - cclibData (or whatever we rename it to). It contains
> the attribute lists and handles the checking of types in its own __setattr__
> method - and should do everything concerned with data after it is parsed
> instead of Logfile.
>
> The biggest change is that Logfile.parse() returns something, that is an
> instance of cclibData, which should hold the parsed attributes upen return.
> It is the biggest, because it changes the way cclib will be used. Now you
> need to write something like "data = ccopen(...).parse()" and data will hold
> the parsed data.
>
> Changes are presently contained to logfileparser.py to make things clear and
> simple. However, it might be better to accomodate them in the parsers
> themselves later (that is, in the extract method) - currently attributes are
> set to Logfile as before and moved to the new cclibData object after the
> actual parsing (look at the new code). I don't know if that will raise any
> problems, but it has the potential :)

I think it would be better to put it into the parsers. Otherwise the
code is misleading. That is, the subclasses set the attributes of the
LogfileParser, but the LogfileParser moves these attributes into a
cclibData instance. I agree though, that this is a very good first
step, and will allow us to deal with the changes incrementally.

> > > Will this happen in trunk, or in a separate branch?
> > > How is this going to affect parsers that are being developed in a
> > > different branch?
> > > How long do you expect this to take?
> >
> > I think Karol's email of the 9th of this month actually has the
> > changes as an attachment. I think they are pretty minimal.
> >
> > I would hope for it to be all done quick and nasty on the trunk within
> > a single day or so, and then merged to the branches, and then
> > completed for the parsers on the branches. We should start using
> > svnmerge.py for the branches to make it easy to keep track of what has
> > been merged, and in what direction.
>
> Done. I had to add a few more things to the file I sent before to get things
> working. Seems to be OK, test statistics are unchanged.
>
> Concerning Calculation Methods in cclib: they need to accept cclibData objects
> now. And a comment/idea: since cclibData objects are to hold cclib data in
> general, perhaps they should also contain the results of methods (MPA, etc.).
> It annoys me a little that after doing a population analysis I have a two
> objects, both containing data that concern the same calculation! On the other
> hand, other methods need multiple cclibData objects (CDA). Maybe a good
> alternative is to provide functions for some methods that add the method
> results to the same cclibData object passed to them, instead of creating a
> new object. I'm not sure if that is clear... do you have any comments?

I'm not so sure about this. Personally, after a population analysis I
don't want an object at all. I just want some data structures, e.g.
the charges on the atoms, and whatever else. Similarily, I don't think
algorithms should be called with cclibData objects. They should just
be fed with whatever information they need (explicit > implicit).
Otherwise, people who want to use these algorithms independently of
cclibData are going to have to jump through some hoops. My 2c.

> --
> written by Karol Langner
> Thu Jul 12 02:30:47 EDT 2007
>

On 12/07/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 12 July 2007 03:03, Karol Langner wrote:
> > The biggest change is that Logfile.parse() returns something, that is an
> > instance of cclibData, which should hold the parsed attributes upen return.
> > It is the biggest, because it changes the way cclib will be used. Now you
> > need to write something like "data = ccopen(...).parse()" and data will
> > hold the parsed data.
>
> Maybe a function like ccparse(arg) = ccopen(arg).parse() would make a good
> shortcut?

I feel like we're starting to overengineer here, and likely to confuse
users who just want a single way to parse files. We separated parse()
on purpose, so that people could have access to the settings before
parsing. If you feel that *this* is not necessary, I would be
interested in removing that.

> --
> written by Karol Langner
> Thu Jul 12 09:24:22 EDT 2007
>

On Thursday 12 July 2007 03:03, Karol Langner wrote:
> The biggest change is that Logfile.parse() returns something, that is an
> instance of cclibData, which should hold the parsed attributes upen return.
> It is the biggest, because it changes the way cclib will be used. Now you
> need to write something like "data = ccopen(...).parse()" and data will
> hold the parsed data.

Maybe a function like ccparse(arg) = ccopen(arg).parse() would make a good 
shortcut?

-- 
written by Karol Langner
Thu Jul 12 09:24:22 EDT 2007

2006	Jan	Feb	Mar (7)	Apr (30)	May (42)	Jun (24)	Jul (17)	Aug (11)	Sep (37)	Oct (39)	Nov (17)	Dec (10)
2007	Jan (64)	Feb (90)	Mar (89)	Apr (24)	May (23)	Jun (44)	Jul (74)	Aug (40)	Sep (32)	Oct (31)	Nov (27)	Dec
2008	Jan	Feb (7)	Mar (10)	Apr (7)	May (16)	Jun (4)	Jul (8)	Aug	Sep (13)	Oct (6)	Nov	Dec
2009	Jan (1)	Feb (9)	Mar (5)	Apr (6)	May (5)	Jun (13)	Jul (11)	Aug (17)	Sep (3)	Oct (11)	Nov (9)	Dec (15)
2010	Jan (14)	Feb (15)	Mar (10)	Apr (14)	May	Jun (10)	Jul	Aug (12)	Sep (4)	Oct (3)	Nov	Dec (3)
2011	Jan (20)	Feb (7)	Mar (22)	Apr (14)	May (2)	Jun	Jul (13)	Aug (4)	Sep (1)	Oct	Nov (6)	Dec (3)
2012	Jan (7)	Feb (5)	Mar (7)	Apr (23)	May	Jun	Jul (5)	Aug	Sep (2)	Oct (12)	Nov (13)	Dec (3)
2013	Jan (8)	Feb (17)	Mar (3)	Apr	May	Jun	Jul (2)	Aug (5)	Sep (6)	Oct (9)	Nov (5)	Dec (22)
2014	Jan (4)	Feb	Mar	Apr (2)	May	Jun (3)	Jul	Aug (15)	Sep (3)	Oct (1)	Nov (18)	Dec
2015	Jan	Feb	Mar (2)	Apr	May (1)	Jun (1)	Jul	Aug	Sep (7)	Oct	Nov (1)	Dec (1)
2016	Jan (1)	Feb (2)	Mar (3)	Apr (5)	May (3)	Jun (1)	Jul (3)	Aug (1)	Sep	Oct (3)	Nov (11)	Dec (12)
2017	Jan (4)	Feb (7)	Mar	Apr (5)	May (5)	Jun	Jul	Aug (5)	Sep (2)	Oct (3)	Nov (2)	Dec (1)
2018	Jan (1)	Feb (6)	Mar (17)	Apr (8)	May	Jun	Jul (2)	Aug (1)	Sep (1)	Oct	Nov (1)	Dec
2019	Jan (2)	Feb (5)	Mar (18)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb (1)	Mar (2)	Apr	May	Jun (1)	Jul	Aug	Sep	Oct (1)	Nov (1)	Dec
2021	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

cclib-devel Mailing List for cclib (Page 35)

cclib-devel — Developer's mailing list