Menu
▾
▴
cclib-devel
|
From: Noel O'B. <bao...@gm...> - 2007-01-24 11:34:42
|
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 |
|
From: Karol L. <kar...@kn...> - 2007-01-24 14:33:01
|
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 |
|
From: Noel O'B. <bao...@gm...> - 2007-01-24 14:48:33
|
> 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
>
|
|
From: Noel O'B. <bao...@gm...> - 2007-01-24 15:57:18
|
> 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 |
|
From: Karol L. <kar...@kn...> - 2007-01-24 21:12:44
|
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 |
|
From: Karol L. <kar...@kn...> - 2007-01-24 22:12:22
|
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
|
|
From: Noel O'B. <bao...@gm...> - 2007-01-25 08:09:49
|
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
>
|
|
From: Noel O'B. <bao...@gm...> - 2007-01-25 08:17:05
|
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 > |
|
From: Karol L. <kar...@kn...> - 2007-01-25 15:29:48
|
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 |
|
From: Karol L. <kar...@kn...> - 2007-01-25 16:24:32
|
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 |
|
From: Noel O'B. <bao...@gm...> - 2007-01-25 16:30:46
|
> 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 ... |
|
From: Karol L. <kar...@kn...> - 2007-01-25 17:04:02
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X