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