Re: [cclib-devel] molpro parser

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

I've see you've just imported the Molpro parser and associated data. That's
great.

I've added it to testGeoOpt. I'm about to change one thing: "au_to_cm-1"
should be "hartree_to_cm-1", I think, to be consistent with the other
conversions.

Could you update the wiki with information on the hessian, so that we can
add it to the other parsers. We will also (at some point) need to write a
unit test (similar to testgbasis.py) for the hessian, so that all of the
parsers agree.

Regards,
  Noel


On 25/09/06, Noel O'Boyle <bao...@gm...> wrote:
>
>
> > > I'm not sure whether we want to keep the .molden files though. These
> > > files duplicate the information in the .log files, isn't this correct?
> >
> >
> > More or less, I don't know how familiar you are with Molpro but it is
> > almost a script language by itself which means that one have a lot of
> > control (I not advertising for them) to essentially do everything what
> > one would like to do with the data but on the other hand hides a lot of
> > info unless specified, making it thus difficult to parse, so dumping a
> > molden file is a way to check things, and harmless, untill they get too
> > big to be opened by Molden :-), which happens often as Molpro puts
> > almost everything you did'nt need in.
>
>
>
> I am not at all familiar with Molpro, but for all of the other programs we
> have a similar problem. You need to include various extra keywords to get
> the information written to the logfile. Please try to parse everything from
> the logfile. Whatever extra keywords are required should be entered on the
> wiki.
>
> In the same line of thought I wonder why nobody included the .dat files
> > for the Gamess-US jobs, they also could be parsed and more easily.
>
>
> Or the Gaussian checkpoint file...
>
> This is what cclib does; it parses the free-format output files. Typically
> more documentation is available for the free-format output files, more
> information is contained in them (although additional keywords may be
> required), and most people only retain these as they are smaller. I take
> your point, but this will require two parsers for every computational
> chemistry program. While this is not a bad idea, I would prefer to
> concentrate on getting more programs in cclib and writing more algorithms.
> You are welcome to write two parsers, but I would really like you to focus
> on the free-format output file as being the more useful (though more
> difficult).
>
> It could be that I have a bias towards the free-format output files as the
> formatted output files typically do not contain information on the progress
> of geometry optimisations or the convergence of the SCF. I find this
> information very useful for large systems to assess whether the system is
> likely to converge with the chosen convergence method (this is used by
> GaussSum).
>
> Regards,
>  Noel
>