cclib-devel — Developer's mailing list

Re: [cclib-devel] Separation of parsers and data

[Karol L. <kar...@kn...>]

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 :)

> > 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?

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

Re: [cclib-devel] Turbomole parser

[Christopher R. <cro...@uo...>]

I think this would make sense, but there are a couple of complications:
There is the option within turbomole to use non-standard filenames for
some of the output files, but I think it's ok to ignore this situation.
Also, turbomole could have as many as 9 files that need to be read, so
we'd have to pass the parser a large number of arguments.

In turbomole, the file names of the other files related to the
calculation are lines in the control file. In principle, the parser
could be passed the path of the control file, and then other files are
read as necessary based on it. 

The only option that wouldn't require modifications to cclib is to merge
the turbomole output files first and then run the parser on the whole
thing. At least for the time being, I'm inclined to use that.

-----Original Message-----
From: ccl...@li...
[mailto:ccl...@li...] On Behalf Of Karol
Langner
Sent: Wednesday, July 11, 2007 9:06 AM
To: ccl...@li...
Cc: Noel O'Boyle; Adam Tenderholt
Subject: Re: [cclib-devel] Turbomole parser

On Wednesday 11 July 2007 02:53, Noel O'Boyle wrote:
> > > 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.

A comment. There already is a 'support parsing multiple log files' point
on 
the wiki progress page, and this problem is not specific to Turbomole,
since 
both ADF and GAMESS have two or more output files. In terms of
programming 
this is not a big problem: pass more arguments to the parser, iterate
over 
them. There will be some logistical dangers, though. The order of the
files 
will matter and some information can be duplicated. In GAMESS, for
instance, 
the .dat file also contains MO coefficients but with higher precision
than 
the .out file, which is another advantage of doing this...

-- 
written by Karol Langner
Wed Jul 11 08:58:25 EDT 2007

------------------------------------------------------------------------
-
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

Re: [cclib-devel] Separation of parsers and data

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

On 11/07/07, Adam Tenderholt <a-t...@st...> wrote:
> > Following on the discussion on the list, are we all in favour of
> > making this separation go ahead?
> >
> > I am, and I'd like to see it happen as soon as possible, so that we
> > have time to get everything in shape before the next release.
>
> I'm mostly in favor, but as always, am a bit cautious. So I have a
> handful of questions:
>
> Can you (again) describe what changes will be necessary?
I think Karol's email of the 9th of this month actually has the
changes as an attachment. I think they are pretty minimal.

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

> Adam
>
>
>

Re: [cclib-devel] Separation of parsers and data

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

> Following on the discussion on the list, are we all in favour of
> making this separation go ahead?
>
> I am, and I'd like to see it happen as soon as possible, so that we
> have time to get everything in shape before the next release.

I'm mostly in favor, but as always, am a bit cautious. So I have a  
handful of questions:

Can you (again) describe what changes will be necessary?
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?

Adam

Re: [cclib-devel] Parsers / Parsed data (Was: Re: The summer)

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

On 10/07/07, Karol Langner <kar...@kn...> wrote:
> On Monday 09 July 2007 05:24, Noel O'Boyle wrote:
> > On 09/07/07, Karol Langner <kar...@kn...> wrote:
> > > Yes! This is something I mentioned some time ago, in a slightly different
> > > context. I tried pickling some time ago, and some parser attributes
> > > (logger, progress) were crashing it - with this kind of separation
> > > pickling would be possible without additional hacks. Also, I don't think
> > > the output from pickle is platform-independent, so I can't freely move it
> > > between the computers I do calculation on - here a text format is the
> > > safest.
> >
> > For the record, the output from Pickle *is* platform-independent (it's
> > actually just an ASCII file); the output from the faster cPickle is
> > *not* platform-independent (it's a binary file).
> Yes, I didn't look into that.
>
> > > Let's see if we are thinking along the same lines here. The parser would
> > > create a blank ParsedData object as an attribute in its parse() method,
> > > and possible return that object (return self.data)? So the syntax for
> > > using the
> > >
> > > parsers would need to change, to something like:
> > > >>> myparser = ccopen("....")
> > > >>> mydata = myparser.parse()
> > > >>> dir(mydata)
> > >
> > > ['aoname', 'natom', ....]
> > >
> > > >>> mydata is myparser.data
> > >
> > > True
> >
> > Exactly. Although I wouldn't called it ParsedData, as the information
> > didn't necessarily come from a parsing. Why not just call it something
> > like cclibData, or ccData (although we don't want to get confused with
> > Creative Commons)?
>
> OK... cclibData looks nice and is unique for sure. What information do you
> have in mind that would not come from a parsing? Output from the calculation
> methods?

It's just that the data is data; maybe we made it up; maybe I read it
from a file. You couldn't look at it, and say "hmmm...that there
data's been parsed from a file".

> --
> written by Karol Langner
> Mon Jul  9 21:31:36 EDT 2007
>

[cclib-devel] Separation of parsers and data

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

Following on the discussion on the list, are we all in favour of
making this separation go ahead?

I am, and I'd like to see it happen as soon as possible, so that we
have time to get everything in shape before the next release.

+1

Noel

Re: [cclib-devel] Suggestion regarding GAMESS test file changes

[Karol L. <kar...@kn...>]

On Wednesday 11 July 2007 05:07, Noel O'Boyle wrote:
> I've just been looking at r675 at:
> http://cclib.svn.sourceforge.net/viewvc/cclib?view=rev&revision=675
>
> I really don't think it's a good idea to replace test files. Otherwise
> we could regress. Just add the new one as _b instead. Or upload it to
> SF and add a test for it.

Added as a regression file.

-- 
written by Karol Langner
Wed Jul 11 12:11:31 EDT 2007

Re: [cclib-devel] broken tests?

[Karol L. <kar...@kn...>]

On Wednesday 11 July 2007 03:07, Noel O'Boyle wrote:
> Works for me in Python2.5.
>
> Fails for me in Python2.4 (with the same error as Adam found).
>
> We are currently supporting both of these platforms so it's probably a
> good idea to run all tests with Python2.4 in future.

Right... :) fixed.

-- 
written by Karol Langner
Wed Jul 11 11:08:10 EDT 2007

[cclib-devel] Suggestion regarding GAMESS test file changes

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

I've just been looking at r675 at:
http://cclib.svn.sourceforge.net/viewvc/cclib?view=rev&revision=675

I really don't think it's a good idea to replace test files. Otherwise
we could regress. Just add the new one as _b instead. Or upload it to
SF and add a test for it.

Noel

Re: [cclib-devel] Turbomole parser

[Karol L. <kar...@kn...>]

On Wednesday 11 July 2007 02:53, Noel O'Boyle wrote:
> > > 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.

A comment. There already is a 'support parsing multiple log files' point on 
the wiki progress page, and this problem is not specific to Turbomole, since 
both ADF and GAMESS have two or more output files. In terms of programming 
this is not a big problem: pass more arguments to the parser, iterate over 
them. There will be some logistical dangers, though. The order of the files 
will matter and some information can be duplicated. In GAMESS, for instance, 
the .dat file also contains MO coefficients but with higher precision than 
the .out file, which is another advantage of doing this...

-- 
written by Karol Langner
Wed Jul 11 08:58:25 EDT 2007

Re: [cclib-devel] broken tests?

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

Works for me in Python2.5.

Fails for me in Python2.4 (with the same error as Adam found).

We are currently supporting both of these platforms so it's probably a
good idea to run all tests with Python2.4 in future.

Noel

On 11/07/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 10 July 2007 21:03, Adam Tenderholt wrote:
> > The testall.py script appears to be broken in trunk, revision 680. It
> > complains about GaussianSPTest not having the _testMethodDoc
> > attribute. Any idea what's causing this?
>
> It doesn't break on my system... what are you on? Could you copy the output? I
> did submit rev681 yesterday, but it didn't concern the tests (although try
> updating your trunk first).
>
> --
> written by Karol Langner
> Wed Jul 11 08:42:26 EDT 2007
>
> -------------------------------------------------------------------------
> 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
>

Re: [cclib-devel] Turbomole parser

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

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
>

Re: [cclib-devel] broken tests?

[Karol L. <kar...@kn...>]

On Tuesday 10 July 2007 21:03, Adam Tenderholt wrote:
> The testall.py script appears to be broken in trunk, revision 680. It
> complains about GaussianSPTest not having the _testMethodDoc
> attribute. Any idea what's causing this?

It doesn't break on my system... what are you on? Could you copy the output? I 
did submit rev681 yesterday, but it didn't concern the tests (although try 
updating your trunk first).

-- 
written by Karol Langner
Wed Jul 11 08:42:26 EDT 2007

[cclib-devel] new parser: orca

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

For those of you who haven't been paying attention to the svn logs,  
I've started work on a new parser for the ORCA package. Currently, it  
supports all (most?) of the things I need for PyMOlyze, but it's  
missing a few things (scf convergence comes to mind) that GaussSum  
probably wants. I haven't added any tests because the testing  
framework seems to be broken. I've also updated the wiki developement  
parser page with what I have.

Is there anything that needs to be completed before it's considered  
for inclusion in the next cclib release? I'm hoping to get scf  
convegence and frequencies in the next day or so.

Adam

[cclib-devel] broken tests?

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

The testall.py script appears to be broken in trunk, revision 680. It  
complains about GaussianSPTest not having the _testMethodDoc  
attribute. Any idea what's causing this?

Adam

Re: [cclib-devel] Turbomole parser

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

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

Adam

Re: [cclib-devel] Turbomole parser

[Christopher R. <cro...@uo...>]

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

Chris

-----Original Message-----
From: Karol Langner [mailto:kar...@kn...] 
Sent: Monday, July 09, 2007 9:24 PM
To: ccl...@li...
Cc: Christopher Rowley
Subject: Re: [cclib-devel] Turbomole parser

On Monday 09 July 2007 14:24, Christopher Rowley wrote:
> Hi,
>
> I'm interested in using cclib with turbomole. Is there a parser in
> development? If not, I might have the time to write one and contribute
> it.
>
> Thanks,
> Christopher Rowley
> Ph.D Candidate
> Department of Chemistry
> University of Ottawa

Hi Chris!

 No, there is not Turbomole parser in development presently. You are
surely 
welcome to work on one and contribute, although you need to wait for
Noel 
O'Boyle's reply to your post as he is the main developer here. From my
part, 
I can help a bit with it and generate test files, but not before
mid-August 
when I get back to work.

Cheers,
Karol

-- 
written by Karol Langner
Mon Jul  9 21:21:16 EDT 2007

Re: [cclib-devel] Parsers / Parsed data (Was: Re: The summer)

[Karol L. <kar...@kn...>]

On Monday 09 July 2007 05:24, Noel O'Boyle wrote:
> On 09/07/07, Karol Langner <kar...@kn...> wrote:
> > Yes! This is something I mentioned some time ago, in a slightly different
> > context. I tried pickling some time ago, and some parser attributes
> > (logger, progress) were crashing it - with this kind of separation
> > pickling would be possible without additional hacks. Also, I don't think
> > the output from pickle is platform-independent, so I can't freely move it
> > between the computers I do calculation on - here a text format is the
> > safest.
>
> For the record, the output from Pickle *is* platform-independent (it's
> actually just an ASCII file); the output from the faster cPickle is
> *not* platform-independent (it's a binary file).
Yes, I didn't look into that.

> > Let's see if we are thinking along the same lines here. The parser would
> > create a blank ParsedData object as an attribute in its parse() method,
> > and possible return that object (return self.data)? So the syntax for
> > using the
> >
> > parsers would need to change, to something like:
> > >>> myparser = ccopen("....")
> > >>> mydata = myparser.parse()
> > >>> dir(mydata)
> >
> > ['aoname', 'natom', ....]
> >
> > >>> mydata is myparser.data
> >
> > True
>
> Exactly. Although I wouldn't called it ParsedData, as the information
> didn't necessarily come from a parsing. Why not just call it something
> like cclibData, or ccData (although we don't want to get confused with
> Creative Commons)?

OK... cclibData looks nice and is unique for sure. What information do you 
have in mind that would not come from a parsing? Output from the calculation 
methods?

-- 
written by Karol Langner
Mon Jul  9 21:31:36 EDT 2007

Re: [cclib-devel] Molpro

[Karol L. <kar...@kn...>]

On Monday 09 July 2007 05:09, Noel O'Boyle wrote:
> OK - go for it! I hope to do more cclib development in the near
> future, now that I've gotten GaussSum using the SVN trunk of cclib.
OK, done. A number of tests still don't pass, but the overall situation is 
quite good. I might not get around to fixing all of them before I get back 
mid-august, however.

> On 09/07/07, Karol Langner <kar...@kn...> wrote:
> > On Tuesday 12 June 2007 12:23, Noel O'Boyle wrote:
> > > Looking at the boxes not ticked on the "development parsed data", I
> > > would say it needs some more work - for example, it's currently not
> > > usable by GaussSum or PyMOlyze. If you can create the input files, I
> > > can do some of this.
> >
> > Since this post I've added alot of code to the Molpro parser (see
> > http://cclib.sourceforge.net/wiki/index.php/Development_parsed_data for
> > details), and most of the needed test files. So maybe it is time now to
> > move it to the trunk and get it synched with the other tests?
> >
> > --
> > written by Karol Langner
> > Mon Jul  9 09:47:24 EDT 2007

-- 
written by Karol Langner
Mon Jul  9 21:26:56 EDT 2007

Re: [cclib-devel] Turbomole parser

[Karol L. <kar...@kn...>]

On Monday 09 July 2007 14:24, Christopher Rowley wrote:
> Hi,
>
> I'm interested in using cclib with turbomole. Is there a parser in
> development? If not, I might have the time to write one and contribute
> it.
>
> Thanks,
> Christopher Rowley
> Ph.D Candidate
> Department of Chemistry
> University of Ottawa

Hi Chris!

 No, there is not Turbomole parser in development presently. You are surely 
welcome to work on one and contribute, although you need to wait for Noel 
O'Boyle's reply to your post as he is the main developer here. From my part, 
I can help a bit with it and generate test files, but not before mid-August 
when I get back to work.

Cheers,
Karol

-- 
written by Karol Langner
Mon Jul  9 21:21:16 EDT 2007

[cclib-devel] Turbomole parser

[Christopher R. <cro...@uo...>]

Hi,
 
I'm interested in using cclib with turbomole. Is there a parser in
development? If not, I might have the time to write one and contribute
it.
 
Thanks,
Christopher Rowley
Ph.D Candidate
Department of Chemistry
University of Ottawa
 

Re: [cclib-devel] Parsers / Parsed data (Was: Re: The summer)

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

On 09/07/07, Karol Langner <kar...@kn...> wrote:
> On Monday 25 June 2007 07:15, Noel O'Boyle wrote:
> > Actually, this makes me realise that we need to separate the parser
> > from the parsed data. Yikes! I think I always knew that this was a
> > possibility, but I never really thought about reading in data. The
> > parsers will need to create an instance of CalculationResults or
> > something, whose attributes will be aonames, etc. One of the
> > additional benefits of this, is that the data can simply be pickled to
> > a file, which is what you (Karol) should be using for your own scripts
> > for communicating between Python programs (see 'pickle' in the
> > standard library).
> >
> > Noel
>
> Yes! This is something I mentioned some time ago, in a slightly different
> context. I tried pickling some time ago, and some parser attributes (logger,
> progress) were crashing it - with this kind of separation pickling would be
> possible without additional hacks. Also, I don't think the output from pickle
> is platform-independent, so I can't freely move it between the computers I do
> calculation on - here a text format is the safest.

For the record, the output from Pickle *is* platform-independent (it's
actually just an ASCII file); the output from the faster cPickle is
*not* platform-independent (it's a binary file).

> Let's see if we are thinking along the same lines here. The parser would
> create a blank ParsedData object as an attribute in its parse() method, and
> possible return that object (return self.data)? So the syntax for using the
> parsers would need to change, to something like:
>
> >>> myparser = ccopen("....")
> >>> mydata = myparser.parse()
> >>> dir(mydata)
> ['aoname', 'natom', ....]
> >>> mydata is myparser.data
> True

Exactly. Although I wouldn't called it ParsedData, as the information
didn't necessarily come from a parsing. Why not just call it something
like cclibData, or ccData (although we don't want to get confused with
Creative Commons)?

> It strikes me that this does not require many changes in the code! It does
> imply, however, a general change in the way the parser is used. The
> ParsedData class can then a method for dumping to json or whatever. I wonder
> if there is a way to do this without changing the present syntax for parsing.
>
> Cheers,
> Karol
>
> --
> written by Karol Langner
> Mon Jul  9 09:28:32 EDT 2007
>

Re: [cclib-devel] Molpro

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

OK - go for it! I hope to do more cclib development in the near
future, now that I've gotten GaussSum using the SVN trunk of cclib.

Noel

On 09/07/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 12 June 2007 12:23, Noel O'Boyle wrote:
> > Looking at the boxes not ticked on the "development parsed data", I
> > would say it needs some more work - for example, it's currently not
> > usable by GaussSum or PyMOlyze. If you can create the input files, I
> > can do some of this.
>
> Since this post I've added alot of code to the Molpro parser (see
> http://cclib.sourceforge.net/wiki/index.php/Development_parsed_data for
> details), and most of the needed test files. So maybe it is time now to move
> it to the trunk and get it synched with the other tests?
>
> --
> written by Karol Langner
> Mon Jul  9 09:47:24 EDT 2007
>

Re: [cclib-devel] Parsers / Parsed data (Was: Re: The summer)

[Karol L. <kar...@kn...>]

Here is a quick illustration of the few changes that need to be made to the 
logfileparser file to separate the parser from the parsed data. In the 
attched file the ParserData object is an attribute of Logfile, but it doesn't 
have to be (if it is passed to extract() or extract() returns the values to 
set, but this requires a couple of more changes.

Cheers,
Karol

-- 
written by Karol Langner
Mon Jul  9 10:05:48 EDT 2007

[cclib-devel] Parsers / Parsed data (Was: Re: The summer)

[Karol L. <kar...@kn...>]

On Monday 25 June 2007 07:15, Noel O'Boyle wrote:
> Actually, this makes me realise that we need to separate the parser
> from the parsed data. Yikes! I think I always knew that this was a
> possibility, but I never really thought about reading in data. The
> parsers will need to create an instance of CalculationResults or
> something, whose attributes will be aonames, etc. One of the
> additional benefits of this, is that the data can simply be pickled to
> a file, which is what you (Karol) should be using for your own scripts
> for communicating between Python programs (see 'pickle' in the
> standard library).
>
> Noel

Yes! This is something I mentioned some time ago, in a slightly different
context. I tried pickling some time ago, and some parser attributes (logger,
progress) were crashing it - with this kind of separation pickling would be
possible without additional hacks. Also, I don't think the output from pickle
is platform-independent, so I can't freely move it between the computers I do
calculation on - here a text format is the safest.

Let's see if we are thinking along the same lines here. The parser would
create a blank ParsedData object as an attribute in its parse() method, and
possible return that object (return self.data)? So the syntax for using the

parsers would need to change, to something like:
>>> myparser = ccopen("....")
>>> mydata = myparser.parse()
>>> dir(mydata)

['aoname', 'natom', ....]

>>> mydata is myparser.data

True

It strikes me that this does not require many changes in the code! It does
imply, however, a general change in the way the parser is used. The
ParsedData class can then a method for dumping to json or whatever. I wonder
if there is a way to do this without changing the present syntax for parsing.

Cheers,
Karol

--
written by Karol Langner
Mon Jul  9 09:28:32 EDT 2007