cclib-devel — Developer's mailing list

Re: [cclib-devel] Numeric --> numpy

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

I agree that we should move to numpy soon as Numeric is old. Are  
there major differences between the two? Hopefully the conversion  
won't be too difficult or time consuming...

Adam

On Jan 25, 2007, at 7:24 AM, Karol Langner wrote:

> On Thursday 25 of January 2007 13:17, Noel O'Boyle wrote:
>> Hello all,
>>
>> We're going to have to start thinking about transitioning to numpy at
>> some point this year. Numeric is not available for Python 2.5 on
>> Windows, for example, and there is a big push for users to move to
>> numpy.
>>
>> How are things on Gentoo at this stage?
>>
>> Regards,
>>   Noel
>
> I was actually going to ask about this soon, and will certainly  
> help when the
> time comes if I'm not loaded with work. I guess you're thinking  
> about making
> the transition quickly?
>
> Karol
>
> -- 
> written by Karol Langner
> Thu Jan 25 16:23:06 CET 2007
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] MP2 calculations

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

On Thursday 25 of January 2007 17:30, you wrote:
> > I used eactlty the same output as you did in the g03 test, and the
> > energies agree within 10^-7 hartree. Do you mean that the log file I
> > uploaded for the water MP2 job in GAMESS is big?
>
> Apologies - I got confused...I saw a reference to aniline in an
> earlier email, and ...

That was just a calculation I was testing something on yesterday at work, to 
illustrate an optimization.

-- 
written by Karol Langner
Thu Jan 25 18:02:13 CET 2007

Re: [cclib-devel] MP2 calculations

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

> I used eactlty the same output as you did in the g03 test, and the energies
> agree within 10^-7 hartree. Do you mean that the log file I uploaded for the
> water MP2 job in GAMESS is big?

Apologies - I got confused...I saw a reference to aniline in an
earlier email, and ...

Re: [cclib-devel] MP2 calculations

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

On Thursday 25 of January 2007 09:09, Noel O'Boyle wrote:
> Can you write this up on the wiki? I'll edit it there (e.g. we use
> Arrays instead of lists), and then we can formalise what we've
> decided, see whether we're all happy and then implement it for
> everything.

Just wrote a page about it and added the entry to the parsed data page - take 
a look. I notice the wiki page works painfully slow at times.

By the way, I noticed the shape of mpenergies didn't fit in with the other 
attributes with rank > 1, so I switched it, as described on the wiki.

> Regarding log files, try to keep them as small as possible and
> consistent between different programs (to make life easier).

I used eactlty the same output as you did in the g03 test, and the energies 
agree within 10^-7 hartree. Do you mean that the log file I uploaded for the 
water MP2 job in GAMESS is big?

Karol

-- 
written by Karol Langner
Thu Jan 25 16:35:46 CET 2007

Re: [cclib-devel] MP2 calculations

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

On Thursday 25 of January 2007 09:17, you wrote:
> It's absolutely worthwhile. If there's one thing I've learnt through
> working on GaussSum, is that you need example files. Otherwise, you
> just *think* it works for MP2; now, we're certain, and we'll still be
> certain in a year's time. And we need to have the same certainty for
> each of the other programs. Also, in a future version of Gaussian, the
> MP5 output could be different, but we still want it to work for users
> of the current version.
>
> In other words, tests keep us sane in a world of multiple versions of
> multiple packages. :-)

Of course you're right. It actially turned out that the line with the MP2 
energies is different when MP3/MP4/MP5 is done (covered by the code I added).

Karol

-- 
written by Karol Langner
Thu Jan 25 16:27:20 CET 2007

Re: [cclib-devel] Numeric --> numpy

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

On Thursday 25 of January 2007 13:17, Noel O'Boyle wrote:
> Hello all,
>
> We're going to have to start thinking about transitioning to numpy at
> some point this year. Numeric is not available for Python 2.5 on
> Windows, for example, and there is a big push for users to move to
> numpy.
>
> How are things on Gentoo at this stage?
>
> Regards,
>   Noel

I was actually going to ask about this soon, and will certainly help when the 
time comes if I'm not loaded with work. I guess you're thinking about making 
the transition quickly?

Karol

-- 
written by Karol Langner
Thu Jan 25 16:23:06 CET 2007

[cclib-devel] Numeric --> numpy

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

Hello all,

We're going to have to start thinking about transitioning to numpy at
some point this year. Numeric is not available for Python 2.5 on
Windows, for example, and there is a big push for users to move to
numpy.

How are things on Gentoo at this stage?

Regards,
  Noel

Re: [cclib-devel] MP2 calculations

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

It's absolutely worthwhile. If there's one thing I've learnt through
working on GaussSum, is that you need example files. Otherwise, you
just *think* it works for MP2; now, we're certain, and we'll still be
certain in a year's time. And we need to have the same certainty for
each of the other programs. Also, in a future version of Gaussian, the
MP5 output could be different, but we still want it to work for users
of the current version.

In other words, tests keep us sane in a world of multiple versions of
multiple packages. :-)

> Is it worthwhile to have all four runs? After all, the MP5 logfile has output
> from the MP2, MP3, and MP4 as well.
>
> Karol
>
> --
> written by Karol Langner
> Wed Jan 24 22:10:20 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] MP2 calculations

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

Can you write this up on the wiki? I'll edit it there (e.g. we use
Arrays instead of lists), and then we can formalise what we've
decided, see whether we're all happy and then implement it for
everything.

Regarding log files, try to keep them as small as possible and
consistent between different programs (to make life easier).

Noel

On 24/01/07, Karol Langner <kar...@kn...> wrote:
> I just uploaded an MP2 logfile for GAMESS (doesn't do any higher corrections
> yet), with the same input as Noel used for the Gaussian MP2-MP5 tests.
>
> To minimize the number of attributes, I changed mp2energies to mpenergies,
> which now a list of lists, where mpenergies[0] are the MP2 energies,
> mpenergies[1] are the MP3 energies, and so forth. If this seems excessive,
> there's no problem in trimming it to one list, on the other hand it contains
> all the MP levels in natural order, without the need for additional
> attributes.
>
> As for MP4 energies, the Gaussian parser now uses the one with the most
> substitutions (SDTQ by default, but can be lower).
>
> Just to illustrate:
>
> 1. The GAMESS-US MP2 test
> >>> g = cclib.parser.GAMESS("water_mp2.out")
> >>> g.parse()
> (.....)
> [GAMESS water_mp2.out INFO] Creating attribute mpenergies[]
> (.....)
> >>> g.mpenergies
> [[-2040.9170996066973]]
>
> 2. The Gaussian MP5 test
> >>> g = cclib.parser.Gaussian("water_mp5.log")
> >>> g.parse()
> (.....)
> [Gaussian water_mp5.log INFO] Creating attribute mpenergies[]
> (.....)
> >>> g.mpenergies
> [[-2040.9170997465096], [-2041.2033310633337], [-2041.2922339997131],
> [-2041.3222993585564]]
>
> 3. An example MP2 optimization logfile
> >>> g = cclib.parser.Gaussian("aniline.mp2.g03.log")
> >>> g.parse()
> (.....)
> [Gaussian aniline.mp2.g03.log INFO] Creating attribute mpenergies[]
> (.....)
> >>> g.mpenergies
> [[-7801.7598674464125, -7801.8351490188224, -7801.8374080673448,
> -7801.8381336209577, -7801.8382029085296]]
>
> I hope this is all OK,
> Karol
>
> --
> written by Karol Langner
> Wed Jan 24 23:00:14 CET 2007
>

Re: [cclib-devel] MP2 calculations

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

I just uploaded an MP2 logfile for GAMESS (doesn't do any higher corrections 
yet), with the same input as Noel used for the Gaussian MP2-MP5 tests.

To minimize the number of attributes, I changed mp2energies to mpenergies, 
which now a list of lists, where mpenergies[0] are the MP2 energies, 
mpenergies[1] are the MP3 energies, and so forth. If this seems excessive, 
there's no problem in trimming it to one list, on the other hand it contains 
all the MP levels in natural order, without the need for additional 
attributes.

As for MP4 energies, the Gaussian parser now uses the one with the most 
substitutions (SDTQ by default, but can be lower).

Just to illustrate:

1. The GAMESS-US MP2 test
>>> g = cclib.parser.GAMESS("water_mp2.out")
>>> g.parse()
(.....)
[GAMESS water_mp2.out INFO] Creating attribute mpenergies[]
(.....)
>>> g.mpenergies
[[-2040.9170996066973]]

2. The Gaussian MP5 test
>>> g = cclib.parser.Gaussian("water_mp5.log")
>>> g.parse()
(.....)
[Gaussian water_mp5.log INFO] Creating attribute mpenergies[]
(.....)
>>> g.mpenergies
[[-2040.9170997465096], [-2041.2033310633337], [-2041.2922339997131], 
[-2041.3222993585564]]

3. An example MP2 optimization logfile
>>> g = cclib.parser.Gaussian("aniline.mp2.g03.log")
>>> g.parse()
(.....)
[Gaussian aniline.mp2.g03.log INFO] Creating attribute mpenergies[]
(.....)
>>> g.mpenergies
[[-7801.7598674464125, -7801.8351490188224, -7801.8374080673448, 
-7801.8381336209577, -7801.8382029085296]]

I hope this is all OK,
Karol

-- 
written by Karol Langner
Wed Jan 24 23:00:14 CET 2007

Re: [cclib-devel] MP2 calculations

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

On Wednesday 24 of January 2007 12:34, Noel O'Boyle wrote:
> Dear all,
>
> I'm about to upload 8 files for Gaussian: water_MPx.com/log, where x is
> 2,3,4,5.
>
> Each MP3 file also contains information on MP2 results. Each MP4 file,
> also contains info on MP2 and MP3 results, and so on.
>
> As Karol has already done, MP2 info is indicted by the word EUMP2. MP3
> info is indicated by the word EUMP3.
>
> MP4 calcs can be at various levels - I suggest we just extract the
> figure for the highest level. The log file contains something like:
>
> MP4(T)=     -.55601167D-04
> E3=         -.10847902D-01      EUMP3=         -.75014575395D+02
> E4(DQ)=     -.32068082D-02      UMP4(DQ)=      -.75017782203D+02
> E4(SDQ)=    -.33238377D-02      UMP4(SDQ)=     -.75017899233D+02
> E4(SDTQ)=   -.33794389D-02      UMP4(SDTQ)=    -.75017954834D+02
>
> In this case, we would extract the UMP4(SDTQ) figure. In general, we
> just extract the final figure in this block (which may alternatively
> be UMP4(DQ) or UMP4(SDQ)).
>
> MP5 calculations are simpler...we just extract the figure from:
>
> DEMP5 =  -0.11048812312D-02 MP5 =  -0.75017172926D+02
>
> How does this sound? We can stick the appropriate values into
> mp2energies, etc. as proposed by Karol. The only drawback is that a
> user who wants the most accurate figure will need to check for the
> presence/absence of mp5energies, mp4energies, etc.
>
> Regards,
>     Noel

Is it worthwhile to have all four runs? After all, the MP5 logfile has output 
from the MP2, MP3, and MP4 as well.

Karol

-- 
written by Karol Langner
Wed Jan 24 22:10:20 CET 2007

Re: [cclib-devel] cclib mission statement (was Re: MP2 calculations)

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

On 24/01/07, Karol Langner <kar...@kn...> wrote:
> On Wednesday 24 of January 2007 20:13, Noel O'Boyle wrote:
> > > Well said - maybe "The overall goal of cclib is to extract information
> > > useful for algorithms, or visualisation, and to do this equally for 'all'
> > > comp chem packages." should go on the main wiki page :)
> >
> > Good point. :-)
>
> Just added.

I don't think what I just said is a very good description of what
cclib is about, but it's a start. I think I've something a bit more
comprehensive somewhere...I'll dig it up.

Re: [cclib-devel] cclib mission statement (was Re: MP2 calculations)

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

On Wednesday 24 of January 2007 20:53, Karol Langner wrote:
> > I really wouldn't be too enthusiastic about this. In fact, the more I
> > think about it, the less I like it. But leaving that aside for the
> > moment, what do think users would do with this information after it's
> > extracted? Are you thinking about automated input file generation
> > somehow?
>
> No, I wasn't thinking about auto input generation, just that 'scfenergies'
> can be ambigious, since it doesn't tell you whether the calculation was HF
> or DFT (for example). The more I think about parsing input options, the
> more I dislike the idea, too. Maybe an attribute called 'scftype' would be
> usefull, though?

To comment on myself, 'scftype' is not a good idea for this, since what I had 
in mind was not the "type" of SCF, of course. Just thinking out loud again.

-- 
written by Karol Langner
Wed Jan 24 21:00:47 CET 2007

Re: [cclib-devel] cclib mission statement (was Re: MP2 calculations)

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

On Wednesday 24 of January 2007 20:13, Noel O'Boyle wrote:
> > Well said - maybe "The overall goal of cclib is to extract information
> > useful for algorithms, or visualisation, and to do this equally for 'all'
> > comp chem packages." should go on the main wiki page :)
>
> Good point. :-)

Just added.

> > As far as options go, I was thinking about just reading the input option
> >  lines from programs into a string attribute ("options" or so).
>
> I really wouldn't be too enthusiastic about this. In fact, the more I
> think about it, the less I like it. But leaving that aside for the
> moment, what do think users would do with this information after it's
> extracted? Are you thinking about automated input file generation
> somehow?

No, I wasn't thinking about auto input generation, just that 'scfenergies' can 
be ambigious, since it doesn't tell you whether the calculation was HF or DFT 
(for example). The more I think about parsing input options, the more I 
dislike the idea, too. Maybe an attribute called 'scftype' would be usefull, 
though?

-- 
written by Karol Langner
Wed Jan 24 20:43:19 CET 2007

Re: [cclib-devel] cclib mission statement (was Re: MP2 calculations)

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

> Well said - maybe "The overall goal of cclib is to extract information useful
> for algorithms, or visualisation, and to do this equally for 'all' comp chem
> packages." should go on the main wiki page :)

Good point. :-)

> As far as options go, I was thinking about just reading the input option
>  lines from programs into a string attribute ("options" or so).

I really wouldn't be too enthusiastic about this. In fact, the more I
think about it, the less I like it. But leaving that aside for the
moment, what do think users would do with this information after it's
extracted? Are you thinking about automated input file generation
somehow?

> > I presented some of the reasons for cclib at a conference a few months
> > ago. Check out:
> >    http://cclib.sourceforge.net/wiki/index.php/Complife06
>
> Looks nice :)
>
> Karol
>
> --
> written by Karol Langner
> Wed Jan 24 19:15:57 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Fwd: Re: MP2 calculations

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

On Wednesday 24 of January 2007 16:57, you wrote:
> The overall goal of cclib is not to extract every piece of information
> from a log file, but to extract information useful for algorithms, or
> visualisation, and to do this equally for 'all' comp chem packages. We
> want to make it easy for others to implement comp chem algorithms that
> take the overlap matrix, do some matrix, and output the 'atoms in
> molecules' charges, for example.

Well said - maybe "The overall goal of cclib is to extract information useful
for algorithms, or visualisation, and to do this equally for 'all' comp chem
packages." should go on the main wiki page :)

As far as options go, I was thinking about just reading the input option
 lines from programs into a string attribute ("options" or so).

> I presented some of the reasons for cclib at a conference a few months
> ago. Check out:
>    http://cclib.sourceforge.net/wiki/index.php/Complife06

Looks nice :)

Karol

-- 
written by Karol Langner
Wed Jan 24 19:15:57 CET 2007

[cclib-devel] Fwd: Re: Units in energies revisited

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

On Wednesday 24 of January 2007 15:50, you wrote:
> I guess it's to be consistent with the moenergies. Most of the units
> chosen have been experimental units, rather than atomic units.

So I updated the units in the LogFile docstring and added units for vibirs
 and vibramas, as my first commit. I took the km/m for IR intensities and
 A^4/Da for Raman intensities from what was written in Gaussian/GAMESS
 output.

Karol

-- 
written by Karol Langner
Wed Jan 24 19:03:55 CET 2007

Re: [cclib-devel] MP2 calculations

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

> This leads me to another question. In the current implementation, if a user
> has a parsed cclib object, and sees the scfenergies attribute, how does he
> know whether these energies are from Hartree-Fock, DFT, or AM1/PM3
> calculations? In other words, to what extent are the calculation options
> parsed, so that they can be taken from a LogFile object?

The calculation options are not parsed at all.

The overall goal of cclib is not to extract every piece of information
from a log file, but to extract information useful for algorithms, or
visualisation, and to do this equally for 'all' comp chem packages. We
want to make it easy for others to implement comp chem algorithms that
take the overlap matrix, do some matrix, and output the 'atoms in
molecules' charges, for example.

I presented some of the reasons for cclib at a conference a few months
ago. Check out:
   http://cclib.sourceforge.net/wiki/index.php/Complife06

Noel

Re: [cclib-devel] Correlated electronic energies

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

On Wednesday 24 of January 2007 15:50, Noel O'Boyle wrote:
> Are people interested in more than one energy figure, though? Wouldn't
> they usually just want the most accurate figure.

Usually I guess so, unless someone is studying various levels of theory.

-- 
written by Karol Langner
Wed Jan 24 16:08:23 CET 2007

Re: [cclib-devel] Units in energies revisited

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

OK, i have no problem with that.

On Wednesday 24 of January 2007 15:50, Noel O'Boyle wrote:
> I guess it's to be consistent with the moenergies. Most of the units
> chosen have been experimental units, rather than atomic units.
>
> On 24/01/07, Karol Langner <kar...@kn...> wrote:
> > Dear all,
> >
> >  I wanted to come back to the issue of units in the molecular energies
> > parsed by cclib. Is there a reason why scfenergies are converted to eV
> > from hartrees?
> >
> > Karol

-- 
written by Karol Langner
Wed Jan 24 15:58:10 CET 2007

Re: [cclib-devel] Correlated electronic energies

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

Are people interested in more than one energy figure, though? Wouldn't
they usually just want the most accurate figure.

Re: [cclib-devel] Units in energies revisited

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

I guess it's to be consistent with the moenergies. Most of the units
chosen have been experimental units, rather than atomic units.

On 24/01/07, Karol Langner <kar...@kn...> wrote:
> Dear all,
>
>  I wanted to come back to the issue of units in the molecular energies parsed
> by cclib. Is there a reason why scfenergies are converted to eV from
> hartrees?
>
> Karol
>
> --
> written by Karol Langner
> Wed Jan 24 15:41:19 CET 2007
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] MP2 calculations

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

> This is a situation, where having a general "energies" (or "molenergies" or
> "totalenergies")  dictionary attribute would be useful - it could hold HF,
> MP2, MP3, and other energies. The attribute "scfenergies" could be kept as a
> reference to energies["SCF"], though. There are a bunch of other energies
> that could be contained here in the future, too, correlated energies (coupled
> cluster), or from parametrized hamiltonians (AM1, ...).
>
> Even if a general attribute like this turned out clumsy for the user, I think
> it could be usefull in other parts of cclib code. I'm just not sure if a
> dictionary is the best way to go?

Let's try what we think is a reasonable approach, and then, if we have
problems adapting this to deal with other programs, etc., we can
change it. Note, though, that we will need to have resolved these
questions before these attributes will be included in a public
release.

Regarding dictionaries, if it helps, you should realise that object
attributes such as "mylogfile.homos" are actually implemented as
dictionaries. It's just that the syntax is different, and you use
hasattr(mylogfile, "homos") instead of mydict.has_key("homos"). So the
user has the same problems in either case trying to find out whether
there is an MP2 energy present or not. The only advantage in using a
dictionary is that, as you say, all of the energies are in the same
place, so that the user can test to see if more than a single energy
is present, for example: len(totalenergies)>0?

BTW, I think that we currently extract AM1/PM3 energies (at least for
Gaussian) and put them into scfenergies. It might be useful to have a
'bestenergies' attribute which points to the highest quality energies
present.

> Karol
>
> --
> written by Karol Langner
> Wed Jan 24 15:18:43 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Units in energies revisited

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

Dear all,

 I wanted to come back to the issue of units in the molecular energies parsed 
by cclib. Is there a reason why scfenergies are converted to eV from 
hartrees?

Karol

-- 
written by Karol Langner
Wed Jan 24 15:41:19 CET 2007

Re: [cclib-devel] MP2 calculations

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

On Wednesday 24 of January 2007 12:34, Noel O'Boyle wrote:
> Dear all,
>
> I'm about to upload 8 files for Gaussian: water_MPx.com/log, where x is
> 2,3,4,5.
>
> Each MP3 file also contains information on MP2 results. Each MP4 file,
> also contains info on MP2 and MP3 results, and so on.
>
> As Karol has already done, MP2 info is indicted by the word EUMP2. MP3
> info is indicated by the word EUMP3.
>
> MP4 calcs can be at various levels - I suggest we just extract the
> figure for the highest level. The log file contains something like:
>
> MP4(T)=     -.55601167D-04
> E3=         -.10847902D-01      EUMP3=         -.75014575395D+02
> E4(DQ)=     -.32068082D-02      UMP4(DQ)=      -.75017782203D+02
> E4(SDQ)=    -.33238377D-02      UMP4(SDQ)=     -.75017899233D+02
> E4(SDTQ)=   -.33794389D-02      UMP4(SDTQ)=    -.75017954834D+02
>
> In this case, we would extract the UMP4(SDTQ) figure. In general, we
> just extract the final figure in this block (which may alternatively
> be UMP4(DQ) or UMP4(SDQ)).
>
> MP5 calculations are simpler...we just extract the figure from:
>
> DEMP5 =  -0.11048812312D-02 MP5 =  -0.75017172926D+02
>
> How does this sound? We can stick the appropriate values into
> mp2energies, etc. as proposed by Karol. The only drawback is that a
> user who wants the most accurate figure will need to check for the
> presence/absence of mp5energies, mp4energies, etc.
>
> Regards,
>     Noel

This is a situation, where having a general "energies" (or "molenergies" or 
"totalenergies")  dictionary attribute would be useful - it could hold HF, 
MP2, MP3, and other energies. The attribute "scfenergies" could be kept as a 
reference to energies["SCF"], though. There are a bunch of other energies 
that could be contained here in the future, too, correlated energies (coupled 
cluster), or from parametrized hamiltonians (AM1, ...).

Even if a general attribute like this turned out clumsy for the user, I think 
it could be usefull in other parts of cclib code. I'm just not sure if a 
dictionary is the best way to go?

Karol

-- 
written by Karol Langner
Wed Jan 24 15:18:43 CET 2007