Menu
▾
▴
cclib-devel — Developer's mailing list
This list is closed, nobody may subscribe to it.
| 2006 |
Jan
|
Feb
|
Mar
(7) |
Apr
(30) |
May
(42) |
Jun
(24) |
Jul
(17) |
Aug
(11) |
Sep
(37) |
Oct
(39) |
Nov
(17) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(64) |
Feb
(90) |
Mar
(89) |
Apr
(24) |
May
(23) |
Jun
(44) |
Jul
(74) |
Aug
(40) |
Sep
(32) |
Oct
(31) |
Nov
(27) |
Dec
|
| 2008 |
Jan
|
Feb
(7) |
Mar
(10) |
Apr
(7) |
May
(16) |
Jun
(4) |
Jul
(8) |
Aug
|
Sep
(13) |
Oct
(6) |
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
(9) |
Mar
(5) |
Apr
(6) |
May
(5) |
Jun
(13) |
Jul
(11) |
Aug
(17) |
Sep
(3) |
Oct
(11) |
Nov
(9) |
Dec
(15) |
| 2010 |
Jan
(14) |
Feb
(15) |
Mar
(10) |
Apr
(14) |
May
|
Jun
(10) |
Jul
|
Aug
(12) |
Sep
(4) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2011 |
Jan
(20) |
Feb
(7) |
Mar
(22) |
Apr
(14) |
May
(2) |
Jun
|
Jul
(13) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(6) |
Dec
(3) |
| 2012 |
Jan
(7) |
Feb
(5) |
Mar
(7) |
Apr
(23) |
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(12) |
Nov
(13) |
Dec
(3) |
| 2013 |
Jan
(8) |
Feb
(17) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(6) |
Oct
(9) |
Nov
(5) |
Dec
(22) |
| 2014 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(3) |
Jul
|
Aug
(15) |
Sep
(3) |
Oct
(1) |
Nov
(18) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(3) |
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
(11) |
Dec
(12) |
| 2017 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(5) |
May
(5) |
Jun
|
Jul
|
Aug
(5) |
Sep
(2) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2018 |
Jan
(1) |
Feb
(6) |
Mar
(17) |
Apr
(8) |
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
(2) |
Feb
(5) |
Mar
(18) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Clyde F. <cly...@gm...> - 2013-11-07 10:23:43
|
Hi,
In the latest revision python 2.x compatibility is broken by line 496 in
regression.py:
print(" %s..." % fname, end=" ")
2.x compatibility can be reinstated by adding the import:
from __future__ import print_function
Clyde
|
|
From: Karol M. L. <kar...@gm...> - 2013-10-31 02:10:49
|
Great to see this fixed! - Karol On Oct 30 2013, Noel O'Boyle wrote: > Thanks Clyde. Fixed in dev version as follows: > http://sourceforge.net/p/cclib/code/1064/tree//trunk/src/cclib/parser/gaussianparser.py?diff=50d38e5fe88f3d233d970f93:1063 > > The problem was that IRC calculations must put the frequency number, > i.e. 1, 2, 3, etc. in a different column (off-by-one). Don't ask me > why. > > - Noel > > On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote: > > Hi, > > > > Enclosed is a log file that causes problems extracting frequencies, in > > particular of the 11 frequencies recorded in the log file only 10 and 11 are > > extracted. > > > > I think the problem is due to the following lines of code: > > > > # The line with indices > > if line[1:15].strip() == "" and > > line[15:22].strip().isdigit(): > > freqbase = int(line[15:22]) > > if freqbase == 1 and hasattr(self, 'vibfreqs'): > > # This is a reparse of this information > > removeold = True > > > > and > > > > if removeold: # This is a reparse, so throw away the old > > info > > if hasattr(self, "vibsyms"): > > # We have already parsed the vibsyms so don't > > throw away! > > self.vibsyms = > > self.vibsyms[-len(line[15:].split()):] > > if hasattr(self, "vibirs"): > > self.vibirs = [] > > if hasattr(self, 'vibfreqs'): > > self.vibfreqs = [] > > if hasattr(self, 'vibramans'): > > self.vibramans = [] > > if hasattr(self, 'vibdisps'): > > self.vibdisps = [] > > removeold = False > > > > Which mean once the 10th frequency is reached all frequencies are deleted > > and parsing begins again. > > > > In my local copy I've changed the line: > > > > freqbase = int(line[15:22]) > > > > to > > > > freqbase = int(line.split()[0]) > > > > which I think covers the case the code is intended to cover. > > > > Cheers > > > > Clyde > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > > from > > the latest Intel processors and coprocessors. See abstracts and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > _______________________________________________ > > cclib-devel mailing list > > ccl...@li... > > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel -- written by Karol M. Langner Wed Oct 30 22:10:24 EDT 2013 |
|
From: Noel O'B. <bao...@gm...> - 2013-10-30 21:57:14
|
Thanks Clyde. Fixed in dev version as follows: http://sourceforge.net/p/cclib/code/1064/tree//trunk/src/cclib/parser/gaussianparser.py?diff=50d38e5fe88f3d233d970f93:1063 The problem was that IRC calculations must put the frequency number, i.e. 1, 2, 3, etc. in a different column (off-by-one). Don't ask me why. - Noel On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote: > Hi, > > Enclosed is a log file that causes problems extracting frequencies, in > particular of the 11 frequencies recorded in the log file only 10 and 11 are > extracted. > > I think the problem is due to the following lines of code: > > # The line with indices > if line[1:15].strip() == "" and > line[15:22].strip().isdigit(): > freqbase = int(line[15:22]) > if freqbase == 1 and hasattr(self, 'vibfreqs'): > # This is a reparse of this information > removeold = True > > and > > if removeold: # This is a reparse, so throw away the old > info > if hasattr(self, "vibsyms"): > # We have already parsed the vibsyms so don't > throw away! > self.vibsyms = > self.vibsyms[-len(line[15:].split()):] > if hasattr(self, "vibirs"): > self.vibirs = [] > if hasattr(self, 'vibfreqs'): > self.vibfreqs = [] > if hasattr(self, 'vibramans'): > self.vibramans = [] > if hasattr(self, 'vibdisps'): > self.vibdisps = [] > removeold = False > > Which mean once the 10th frequency is reached all frequencies are deleted > and parsing begins again. > > In my local copy I've changed the line: > > freqbase = int(line[15:22]) > > to > > freqbase = int(line.split()[0]) > > which I think covers the case the code is intended to cover. > > Cheers > > Clyde > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Noel O'B. <bao...@gm...> - 2013-10-27 16:40:50
|
Hi Clyde, Sorry - it's taken me a while to come back to this. Unfortunately you have removed too much of the header. We rely on the phrase "Gaussian, Inc." in the header to identify Gaussian files automatically. Could you just make the minimal changes required or replace filenames and usernames with generic filenames and usernames. - Noel On 7 October 2013 12:37, Clyde Fare <cly...@gm...> wrote: > Hi Noel, here's a version (just removed the header) I'm happy for you to put > into the public domain. > > Cheers > > Clyde > > > > > On 6 October 2013 11:15, Noel O'Boyle <bao...@gm...> wrote: >> >> Thanks for this Clyde. Are you happy to place this log file in the >> public domain? >> >> - Noel >> >> On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote: >> > Hi, >> > >> > Enclosed is a log file that causes problems extracting frequencies, in >> > particular of the 11 frequencies recorded in the log file only 10 and 11 >> > are >> > extracted. >> > >> > I think the problem is due to the following lines of code: >> > >> > # The line with indices >> > if line[1:15].strip() == "" and >> > line[15:22].strip().isdigit(): >> > freqbase = int(line[15:22]) >> > if freqbase == 1 and hasattr(self, 'vibfreqs'): >> > # This is a reparse of this information >> > removeold = True >> > >> > and >> > >> > if removeold: # This is a reparse, so throw away the >> > old >> > info >> > if hasattr(self, "vibsyms"): >> > # We have already parsed the vibsyms so >> > don't >> > throw away! >> > self.vibsyms = >> > self.vibsyms[-len(line[15:].split()):] >> > if hasattr(self, "vibirs"): >> > self.vibirs = [] >> > if hasattr(self, 'vibfreqs'): >> > self.vibfreqs = [] >> > if hasattr(self, 'vibramans'): >> > self.vibramans = [] >> > if hasattr(self, 'vibdisps'): >> > self.vibdisps = [] >> > removeold = False >> > >> > Which mean once the 10th frequency is reached all frequencies are >> > deleted >> > and parsing begins again. >> > >> > In my local copy I've changed the line: >> > >> > freqbase = int(line[15:22]) >> > >> > to >> > >> > freqbase = int(line.split()[0]) >> > >> > which I think covers the case the code is intended to cover. >> > >> > Cheers >> > >> > Clyde >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > October Webinars: Code for Performance >> > Free Intel webinars can help you accelerate application performance. >> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> > from >> > the latest Intel processors and coprocessors. See abstracts and register >> > > >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > cclib-devel mailing list >> > ccl...@li... >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > > |
|
From: Noel O'B. <bao...@gm...> - 2013-10-27 13:03:36
|
Hi Benjamin, I've just checked and it works for me with the current development code. I suggest you try the latest version. If that doesn't work, then you will either have to wait for the next release or use the development code yourself. These last options requires Python 3. - Noel On 23 October 2013 23:19, benjamin sanchez lengeling <bea...@gm...> wrote: > Yes I am willing to place it into public domain. > > > On Fri, Oct 18, 2013 at 2:00 AM, Noel O'Boyle <bao...@gm...> wrote: >> >> Hello Benjamin, >> >> We only fix bugs for public domain log files. Are you happy to place >> this log file in the public domain? >> >> Regards, >> Noel >> >> On 14 October 2013 23:35, benjamin sanchez lengeling >> <bea...@gm...> wrote: >> > hi all, >> > script and ouput is provided. >> > CClib not working :( >> > >> > Exits with error: >> > " >> > File "CheckGeometry.py", line 17, in <module> >> > data = myfile.parse() >> > File >> > "/usr/local/lib/python2.7/dist-packages/cclib/parser/logfileparser.py", >> > line >> > 221, in parse >> > self.extract(inputfile, line) >> > File >> > "/usr/local/lib/python2.7/dist-packages/cclib/parser/gamessparser.py", >> > line >> > 676, in extract >> > assert line == blank >> > AssertionError >> > >> > " >> > >> > >> > ------------------------------------------------------------------------------ >> > October Webinars: Code for Performance >> > Free Intel webinars can help you accelerate application performance. >> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> > from >> > the latest Intel processors and coprocessors. See abstracts and register >> > > >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > cclib-devel mailing list >> > ccl...@li... >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > > |
|
From: Noel O'B. <bao...@gm...> - 2013-10-18 09:00:48
|
Hello Benjamin, We only fix bugs for public domain log files. Are you happy to place this log file in the public domain? Regards, Noel On 14 October 2013 23:35, benjamin sanchez lengeling <bea...@gm...> wrote: > hi all, > script and ouput is provided. > CClib not working :( > > Exits with error: > " > File "CheckGeometry.py", line 17, in <module> > data = myfile.parse() > File > "/usr/local/lib/python2.7/dist-packages/cclib/parser/logfileparser.py", line > 221, in parse > self.extract(inputfile, line) > File > "/usr/local/lib/python2.7/dist-packages/cclib/parser/gamessparser.py", line > 676, in extract > assert line == blank > AssertionError > > " > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol M. L. <kar...@gm...> - 2013-10-07 11:53:01
|
Well, anything >=7.0 would be OK, I guess. If it's newer than 7.0, it would be best to rerun our whole test suite and update the files. The main thing would be to add population analysis (at least Mulliken), which the Manual says can be chosen in the Method section. - Karol On Sep 27 2013, Adam Tenderholt wrote: > Turns out my former lab does actually have access to Jaguar. I don't know > which version though. Are there any specific calculations I should try to > have run? > > > > On Mon, Sep 23, 2013 at 4:01 PM, Adam Tenderholt <ate...@gm...>wrote: > > > I also don't have access to Jaguar, and my former lab no longer licenses > > it. So I guess we have a few options: don't provide support, ask > > Schroedinger for a complimentary license, or seek out potential > > collaborators (i.e. ccl.net). Thoughts? > > > > > > On Mon, Sep 23, 2013 at 8:51 AM, Noel O'Boyle <bao...@gm...>wrote: > > > >> I no longer have access to any of these I'm afraid... > >> > >> On 19 September 2013 05:18, Karol M. Langner <kar...@gm...> > >> wrote: > >> > I looked at the atomcharges code, and fixed the GAMESS-US parser a bit. > >> > > >> > One more thing, though. Our current Jaguar and Molpro log files for > >> unit testing do not contain any partial charges, so there is nothing to > >> test at this point. I could update the Molpro files, but does anyone have > >> access to Jaguar now? > >> > > >> > - Karol > >> > > >> > On Sep 18 2013, Karol M. Langner wrote: > >> >> Yeah, forwarding to the dev list. > >> >> > >> >> So... any thoughts for/against these candidates: > >> >> 1. aopop > >> >> 2. aopops > >> >> 3. aopopulation > >> >> 4. aopopulations > >> >> 5. populations > >> >> > >> >> I think I prefer the first one, for its brevity. > >> >> > >> >> Cheers, > >> >> Karol > >> >> > >> >> On Sep 18 2013, Adam Tenderholt wrote: > >> >> > Hi Karol, > >> >> > > >> >> > Thanks for taking care of this. I forgot that an atomcharges > >> attribute was > >> >> > added. As far as aopop or aopopuations, perhaps that discussion > >> should be > >> >> > moved to cclib-devel? > >> >> > > >> >> > Adam > >> >> > > >> >> > > >> >> > > >> >> > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner > >> >> > <kar...@gm...>wrote: > >> >> > > >> >> > > Hi, > >> >> > > > >> >> > > Some time ago we actually created the 'atomcharges' attribute: > >> >> > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges > >> >> > > (see that page for the data description) > >> >> > > > >> >> > > So I went ahead and extended that to NPA charges and just commited > >> >> > > code that parses them for Gaussian09. And the newest trunk code > >> >> > > should parse the output file you sent, Fedor. > >> >> > > > >> >> > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it > >> >> > > should not be hard and this would be a good time to do it. > >> >> > > > >> >> > > As far as populations go, I believe we would need to create a new > >> attribute > >> >> > > for that, since it doesn't fit anywhere else. It should probably > >> also > >> >> > > be a dictionary. > >> >> > > > >> >> > > To keep with our current naming scheme, how about 'aopop' or > >> >> > > 'aopopulation'? > >> >> > > > >> >> > > Cheers, > >> >> > > Karol > >> >> > > > >> >> > > On Sep 13 2013, Fedor Zhuravlev wrote: > >> >> > > > Hi Adam and Karol, > >> >> > > > > >> >> > > > Frontier Molecular Orbitals: This is exactly what I was looking > >> for > >> >> > > folks, thanks! > >> >> > > > > >> >> > > > For the NPA analysis: I have included 3 log files from g09, > >> Jaguar 7 > >> >> > > and Turbomole 6.1, all containing the output from the NPA > >> calculations (at > >> >> > > the end of the file, they look very similar). The values of > >> interest could > >> >> > > be the Natural Charge and Natural Electron Population. Those would > >> be nice > >> >> > > to extract. > >> >> > > > > >> >> > > > Fedor > >> >> > > > > >> >> > > > From: Adam Tenderholt [mailto:ate...@gm...] > >> >> > > > Sent: 12 September 2013 18:08 > >> >> > > > To: Fedor Zhuravlev > >> >> > > > Cc: Karol M. Langner; ccl...@li... > >> >> > > > Subject: Re: [cclib-users] FMO properties > >> >> > > > > >> >> > > > Hi Fedor, > >> >> > > > > >> >> > > > Getting the energies of the HOMO and LUMO is pretty > >> straight-forward: > >> >> > > > > >> >> > > > from cclib.parser import ccopen > >> >> > > > > >> >> > > > parser = ccopen(logfile) > >> >> > > > data = parser.parser() > >> >> > > > homo = data.homos[0] # assuming spin-restricted > >> >> > > > lumo = homo + 1 > >> >> > > > > >> >> > > > homo_energy = data.moenergies[0][homo] > >> >> > > > lumo_energy = data.moenergies[0][lumo] > >> >> > > > > >> >> > > > As far as parsing population analyses, Noel, Karol, and I will > >> have to > >> >> > > discuss the potential implementation details. Do you have a > >> favorite QM > >> >> > > package? > >> >> > > > > >> >> > > > Adam > >> >> > > > > >> >> > > > > >> >> > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt... > >> <mailto: > >> >> > > fe...@dt...>> wrote: > >> >> > > > Hi Karol and Adam, > >> >> > > > > >> >> > > > Thanks much for the prompt reply. I was looking for the energies > >> of HOMO > >> >> > > and LUMO. From there, using the Koopman's theorem one gets the > >> ionization > >> >> > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP); > >> LUMO-HOMO is > >> >> > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity > >> (JACS, > >> >> > > 1999, 121, 1922). 4 very useful, easily chemically interpretable > >> chemical > >> >> > > descriptors for the price of two frontier MO! Would be very nice > >> to have! > >> >> > > > > >> >> > > > As for the natural population analysis the QM code would > >> normally do it > >> >> > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just > >> the > >> >> > > question of proper parsing the data. Most people would normally be > >> >> > > interested in the natural charge and natural population. > >> >> > > > > >> >> > > > That was my wish list for Christmas :) > >> >> > > > > >> >> > > > Fedor Zhuravlev > >> >> > > > Senior Researcher > >> >> > > > DTU Nutech > >> >> > > > Technical University of Denmark > >> >> > > > Center for Nuclear Technologies > >> >> > > > Hevesy Laboratory > >> >> > > > DTU Risø Campus > >> >> > > > > >> >> > > > Frederiksborgvej 399 Building 202 > >> >> > > > Building 202 > >> >> > > > 4000 Roskilde > >> >> > > > fe...@dt...<mailto:fe...@dt...> > >> >> > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk> > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > -----Original Message----- > >> >> > > > From: Karol M. Langner [mailto:kar...@gm...<mailto: > >> >> > > kar...@gm...>] > >> >> > > > Sent: 12 September 2013 00:31 > >> >> > > > To: Adam Tenderholt > >> >> > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto: > >> >> > > ccl...@li...> > >> >> > > > Subject: Re: [cclib-users] FMO properties > >> >> > > > > >> >> > > > I assumed fragment energies in the fragment molecular orbital > >> method in > >> >> > > GAMESS-US... > >> >> > > > > >> >> > > > On Sep 11 2013, Adam Tenderholt wrote: > >> >> > > > > Hi Fedor, > >> >> > > > > > >> >> > > > > I wanted to follow up on Karol's email. I'm not familiar with > >> the > >> >> > > > > details of NPA, and I briefly looked up the > >> Reed/Weinstock/Weinhold > >> >> > > > > paper. Adding it as a method in cclib is likely possible, but > >> it would > >> >> > > > > probably take several hours to fully understand the algorithm, > >> and > >> >> > > > > then implement and test it. This does interest me, although > >> I'm not > >> >> > > > > sure when I could get around to it. > >> >> > > > > > >> >> > > > > Also, what exactly do you mean by FMO energies? To me, FMO > >> could stand > >> >> > > > > for either fragment molecular orbitals or frontier molecular > >> orbitals. > >> >> > > > > Do you have a concrete example? > >> >> > > > > > >> >> > > > > Adam > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner > >> >> > > > > <kar...@gm...<mailto:kar...@gm... > >> >>wrote: > >> >> > > > > > >> >> > > > > > On Sep 11 2013, Fedor Zhuravlev wrote: > >> >> > > > > > > Dear cclib development team, > >> >> > > > > > > > >> >> > > > > > > Just had a first look at cclib and here's my questions: > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > 1. Is there a single-liner to get FMO energies only? > >> >> > > > > > > > >> >> > > > > > > 2. What about natural population analysis? > >> >> > > > > > > > >> >> > > > > > > Thanks much, > >> >> > > > > > > > >> >> > > > > > > Fedor > >> >> > > > > > > >> >> > > > > > Hi Fedor, > >> >> > > > > > > >> >> > > > > > Nice to hear from you. I've used cclib to parse FMO output > >> from > >> >> > > > > > GAMESS-US in the past, but it involved a quick custom hack, > >> which I > >> >> > > > > > still may have somewhere I guess (I did this outside of > >> version > >> >> > > > > > control). However, this was some years ago, and I think the > >> format > >> >> > > > > > has changed significantly since then. > >> >> > > > > > > >> >> > > > > > As far as population analyses are concerned, we do not parse > >> them, > >> >> > > > > > although there was a discussion about that in the past. We > >> have > >> >> > > > > > implemented several population analysis algorithms alongside > >> cclib, > >> >> > > though: > >> >> > > > > > > >> http://cclib.sourceforge.net/wiki/index.php/Calculation_methods > >> >> > > > > > ... although NAO is not among them. If you're thinking about > >> the > >> >> > > > > > original approach published by Reed/Weinstock/Weinhold, I > >> think it's > >> >> > > > > > a modification of Lowdin's orthoganolization, which we do. > >> So you > >> >> > > > > > could try to extend it to get what you want. Maybe Noel or > >> Adam has > >> >> > > more thoughts about this? > >> >> > > > > > > >> >> > > > > > If you want something specific parsed, you will generally > >> need to > >> >> > > > > > provide us with an example output file that we can use for > >> testing. > >> >> > > > > > > >> >> > > > > > Cheers, > >> >> > > > > > Karol > >> >> > > > > > > >> >> > > > > > -- > >> >> > > > > > written by Karol M. Langner > >> >> > > > > > Wed Sep 11 10:51:11 EDT 2013 > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> -------------------------------------------------------------------- > >> >> > > > > > ---------- How ServiceNow helps IT people transform IT > >> departments: > >> >> > > > > > 1. Consolidate legacy IT systems to a single system of > >> record for IT > >> >> > > > > > 2. Standardize and globalize service processes across IT 3. > >> >> > > > > > Implement zero-touch automation to replace manual, redundant > >> tasks > >> >> > > > > > > >> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg > >> >> > > > > > .clktrk _______________________________________________ > >> >> > > > > > cclib-users mailing list > >> >> > > > > > ccl...@li...<mailto: > >> >> > > ccl...@li...> > >> >> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users > >> >> > > > > > > >> >> > > > > >> >> > > > -- > >> >> > > > written by Karol M. Langner > >> >> > > > Wed Sep 11 18:30:58 EDT 2013 > >> >> > > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > -- > >> >> > > written by Karol M. Langner > >> >> > > Wed Sep 18 18:11:05 EDT 2013 > >> >> > > > >> >> > >> >> -- > >> >> written by Karol M. Langner > >> >> Wed Sep 18 22:29:09 EDT 2013 > >> > > >> > -- > >> > written by Karol M. Langner > >> > Thu Sep 19 00:14:43 EDT 2013 > >> > > >> > > >> ------------------------------------------------------------------------------ > >> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > >> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > >> SharePoint > >> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > >> includes > >> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > >> > > >> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > >> > _______________________________________________ > >> > cclib-devel mailing list > >> > ccl...@li... > >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel > >> > > > > -- written by Karol M. Langner Mon Oct 7 07:47:56 EDT 2013 |
|
From: Noel O'B. <bao...@gm...> - 2013-10-06 10:16:02
|
Thanks for this Clyde. Are you happy to place this log file in the public domain? - Noel On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote: > Hi, > > Enclosed is a log file that causes problems extracting frequencies, in > particular of the 11 frequencies recorded in the log file only 10 and 11 are > extracted. > > I think the problem is due to the following lines of code: > > # The line with indices > if line[1:15].strip() == "" and > line[15:22].strip().isdigit(): > freqbase = int(line[15:22]) > if freqbase == 1 and hasattr(self, 'vibfreqs'): > # This is a reparse of this information > removeold = True > > and > > if removeold: # This is a reparse, so throw away the old > info > if hasattr(self, "vibsyms"): > # We have already parsed the vibsyms so don't > throw away! > self.vibsyms = > self.vibsyms[-len(line[15:].split()):] > if hasattr(self, "vibirs"): > self.vibirs = [] > if hasattr(self, 'vibfreqs'): > self.vibfreqs = [] > if hasattr(self, 'vibramans'): > self.vibramans = [] > if hasattr(self, 'vibdisps'): > self.vibdisps = [] > removeold = False > > Which mean once the 10th frequency is reached all frequencies are deleted > and parsing begins again. > > In my local copy I've changed the line: > > freqbase = int(line[15:22]) > > to > > freqbase = int(line.split()[0]) > > which I think covers the case the code is intended to cover. > > Cheers > > Clyde > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <ate...@gm...> - 2013-09-27 20:42:11
|
Turns out my former lab does actually have access to Jaguar. I don't know which version though. Are there any specific calculations I should try to have run? On Mon, Sep 23, 2013 at 4:01 PM, Adam Tenderholt <ate...@gm...>wrote: > I also don't have access to Jaguar, and my former lab no longer licenses > it. So I guess we have a few options: don't provide support, ask > Schroedinger for a complimentary license, or seek out potential > collaborators (i.e. ccl.net). Thoughts? > > > On Mon, Sep 23, 2013 at 8:51 AM, Noel O'Boyle <bao...@gm...>wrote: > >> I no longer have access to any of these I'm afraid... >> >> On 19 September 2013 05:18, Karol M. Langner <kar...@gm...> >> wrote: >> > I looked at the atomcharges code, and fixed the GAMESS-US parser a bit. >> > >> > One more thing, though. Our current Jaguar and Molpro log files for >> unit testing do not contain any partial charges, so there is nothing to >> test at this point. I could update the Molpro files, but does anyone have >> access to Jaguar now? >> > >> > - Karol >> > >> > On Sep 18 2013, Karol M. Langner wrote: >> >> Yeah, forwarding to the dev list. >> >> >> >> So... any thoughts for/against these candidates: >> >> 1. aopop >> >> 2. aopops >> >> 3. aopopulation >> >> 4. aopopulations >> >> 5. populations >> >> >> >> I think I prefer the first one, for its brevity. >> >> >> >> Cheers, >> >> Karol >> >> >> >> On Sep 18 2013, Adam Tenderholt wrote: >> >> > Hi Karol, >> >> > >> >> > Thanks for taking care of this. I forgot that an atomcharges >> attribute was >> >> > added. As far as aopop or aopopuations, perhaps that discussion >> should be >> >> > moved to cclib-devel? >> >> > >> >> > Adam >> >> > >> >> > >> >> > >> >> > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner >> >> > <kar...@gm...>wrote: >> >> > >> >> > > Hi, >> >> > > >> >> > > Some time ago we actually created the 'atomcharges' attribute: >> >> > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges >> >> > > (see that page for the data description) >> >> > > >> >> > > So I went ahead and extended that to NPA charges and just commited >> >> > > code that parses them for Gaussian09. And the newest trunk code >> >> > > should parse the output file you sent, Fedor. >> >> > > >> >> > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it >> >> > > should not be hard and this would be a good time to do it. >> >> > > >> >> > > As far as populations go, I believe we would need to create a new >> attribute >> >> > > for that, since it doesn't fit anywhere else. It should probably >> also >> >> > > be a dictionary. >> >> > > >> >> > > To keep with our current naming scheme, how about 'aopop' or >> >> > > 'aopopulation'? >> >> > > >> >> > > Cheers, >> >> > > Karol >> >> > > >> >> > > On Sep 13 2013, Fedor Zhuravlev wrote: >> >> > > > Hi Adam and Karol, >> >> > > > >> >> > > > Frontier Molecular Orbitals: This is exactly what I was looking >> for >> >> > > folks, thanks! >> >> > > > >> >> > > > For the NPA analysis: I have included 3 log files from g09, >> Jaguar 7 >> >> > > and Turbomole 6.1, all containing the output from the NPA >> calculations (at >> >> > > the end of the file, they look very similar). The values of >> interest could >> >> > > be the Natural Charge and Natural Electron Population. Those would >> be nice >> >> > > to extract. >> >> > > > >> >> > > > Fedor >> >> > > > >> >> > > > From: Adam Tenderholt [mailto:ate...@gm...] >> >> > > > Sent: 12 September 2013 18:08 >> >> > > > To: Fedor Zhuravlev >> >> > > > Cc: Karol M. Langner; ccl...@li... >> >> > > > Subject: Re: [cclib-users] FMO properties >> >> > > > >> >> > > > Hi Fedor, >> >> > > > >> >> > > > Getting the energies of the HOMO and LUMO is pretty >> straight-forward: >> >> > > > >> >> > > > from cclib.parser import ccopen >> >> > > > >> >> > > > parser = ccopen(logfile) >> >> > > > data = parser.parser() >> >> > > > homo = data.homos[0] # assuming spin-restricted >> >> > > > lumo = homo + 1 >> >> > > > >> >> > > > homo_energy = data.moenergies[0][homo] >> >> > > > lumo_energy = data.moenergies[0][lumo] >> >> > > > >> >> > > > As far as parsing population analyses, Noel, Karol, and I will >> have to >> >> > > discuss the potential implementation details. Do you have a >> favorite QM >> >> > > package? >> >> > > > >> >> > > > Adam >> >> > > > >> >> > > > >> >> > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt... >> <mailto: >> >> > > fe...@dt...>> wrote: >> >> > > > Hi Karol and Adam, >> >> > > > >> >> > > > Thanks much for the prompt reply. I was looking for the energies >> of HOMO >> >> > > and LUMO. From there, using the Koopman's theorem one gets the >> ionization >> >> > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP); >> LUMO-HOMO is >> >> > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity >> (JACS, >> >> > > 1999, 121, 1922). 4 very useful, easily chemically interpretable >> chemical >> >> > > descriptors for the price of two frontier MO! Would be very nice >> to have! >> >> > > > >> >> > > > As for the natural population analysis the QM code would >> normally do it >> >> > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just >> the >> >> > > question of proper parsing the data. Most people would normally be >> >> > > interested in the natural charge and natural population. >> >> > > > >> >> > > > That was my wish list for Christmas :) >> >> > > > >> >> > > > Fedor Zhuravlev >> >> > > > Senior Researcher >> >> > > > DTU Nutech >> >> > > > Technical University of Denmark >> >> > > > Center for Nuclear Technologies >> >> > > > Hevesy Laboratory >> >> > > > DTU Risø Campus >> >> > > > >> >> > > > Frederiksborgvej 399 Building 202 >> >> > > > Building 202 >> >> > > > 4000 Roskilde >> >> > > > fe...@dt...<mailto:fe...@dt...> >> >> > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk> >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > -----Original Message----- >> >> > > > From: Karol M. Langner [mailto:kar...@gm...<mailto: >> >> > > kar...@gm...>] >> >> > > > Sent: 12 September 2013 00:31 >> >> > > > To: Adam Tenderholt >> >> > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto: >> >> > > ccl...@li...> >> >> > > > Subject: Re: [cclib-users] FMO properties >> >> > > > >> >> > > > I assumed fragment energies in the fragment molecular orbital >> method in >> >> > > GAMESS-US... >> >> > > > >> >> > > > On Sep 11 2013, Adam Tenderholt wrote: >> >> > > > > Hi Fedor, >> >> > > > > >> >> > > > > I wanted to follow up on Karol's email. I'm not familiar with >> the >> >> > > > > details of NPA, and I briefly looked up the >> Reed/Weinstock/Weinhold >> >> > > > > paper. Adding it as a method in cclib is likely possible, but >> it would >> >> > > > > probably take several hours to fully understand the algorithm, >> and >> >> > > > > then implement and test it. This does interest me, although >> I'm not >> >> > > > > sure when I could get around to it. >> >> > > > > >> >> > > > > Also, what exactly do you mean by FMO energies? To me, FMO >> could stand >> >> > > > > for either fragment molecular orbitals or frontier molecular >> orbitals. >> >> > > > > Do you have a concrete example? >> >> > > > > >> >> > > > > Adam >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner >> >> > > > > <kar...@gm...<mailto:kar...@gm... >> >>wrote: >> >> > > > > >> >> > > > > > On Sep 11 2013, Fedor Zhuravlev wrote: >> >> > > > > > > Dear cclib development team, >> >> > > > > > > >> >> > > > > > > Just had a first look at cclib and here's my questions: >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > 1. Is there a single-liner to get FMO energies only? >> >> > > > > > > >> >> > > > > > > 2. What about natural population analysis? >> >> > > > > > > >> >> > > > > > > Thanks much, >> >> > > > > > > >> >> > > > > > > Fedor >> >> > > > > > >> >> > > > > > Hi Fedor, >> >> > > > > > >> >> > > > > > Nice to hear from you. I've used cclib to parse FMO output >> from >> >> > > > > > GAMESS-US in the past, but it involved a quick custom hack, >> which I >> >> > > > > > still may have somewhere I guess (I did this outside of >> version >> >> > > > > > control). However, this was some years ago, and I think the >> format >> >> > > > > > has changed significantly since then. >> >> > > > > > >> >> > > > > > As far as population analyses are concerned, we do not parse >> them, >> >> > > > > > although there was a discussion about that in the past. We >> have >> >> > > > > > implemented several population analysis algorithms alongside >> cclib, >> >> > > though: >> >> > > > > > >> http://cclib.sourceforge.net/wiki/index.php/Calculation_methods >> >> > > > > > ... although NAO is not among them. If you're thinking about >> the >> >> > > > > > original approach published by Reed/Weinstock/Weinhold, I >> think it's >> >> > > > > > a modification of Lowdin's orthoganolization, which we do. >> So you >> >> > > > > > could try to extend it to get what you want. Maybe Noel or >> Adam has >> >> > > more thoughts about this? >> >> > > > > > >> >> > > > > > If you want something specific parsed, you will generally >> need to >> >> > > > > > provide us with an example output file that we can use for >> testing. >> >> > > > > > >> >> > > > > > Cheers, >> >> > > > > > Karol >> >> > > > > > >> >> > > > > > -- >> >> > > > > > written by Karol M. Langner >> >> > > > > > Wed Sep 11 10:51:11 EDT 2013 >> >> > > > > > >> >> > > > > > >> >> > > > > > >> -------------------------------------------------------------------- >> >> > > > > > ---------- How ServiceNow helps IT people transform IT >> departments: >> >> > > > > > 1. Consolidate legacy IT systems to a single system of >> record for IT >> >> > > > > > 2. Standardize and globalize service processes across IT 3. >> >> > > > > > Implement zero-touch automation to replace manual, redundant >> tasks >> >> > > > > > >> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg >> >> > > > > > .clktrk _______________________________________________ >> >> > > > > > cclib-users mailing list >> >> > > > > > ccl...@li...<mailto: >> >> > > ccl...@li...> >> >> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users >> >> > > > > > >> >> > > > >> >> > > > -- >> >> > > > written by Karol M. Langner >> >> > > > Wed Sep 11 18:30:58 EDT 2013 >> >> > > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > -- >> >> > > written by Karol M. Langner >> >> > > Wed Sep 18 18:11:05 EDT 2013 >> >> > > >> >> >> >> -- >> >> written by Karol M. Langner >> >> Wed Sep 18 22:29:09 EDT 2013 >> > >> > -- >> > written by Karol M. Langner >> > Thu Sep 19 00:14:43 EDT 2013 >> > >> > >> ------------------------------------------------------------------------------ >> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, >> SharePoint >> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack >> includes >> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > cclib-devel mailing list >> > ccl...@li... >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > |
|
From: Adam T. <ate...@gm...> - 2013-09-23 23:02:08
|
I also don't have access to Jaguar, and my former lab no longer licenses it. So I guess we have a few options: don't provide support, ask Schroedinger for a complimentary license, or seek out potential collaborators (i.e. ccl.net). Thoughts? On Mon, Sep 23, 2013 at 8:51 AM, Noel O'Boyle <bao...@gm...> wrote: > I no longer have access to any of these I'm afraid... > > On 19 September 2013 05:18, Karol M. Langner <kar...@gm...> > wrote: > > I looked at the atomcharges code, and fixed the GAMESS-US parser a bit. > > > > One more thing, though. Our current Jaguar and Molpro log files for unit > testing do not contain any partial charges, so there is nothing to test at > this point. I could update the Molpro files, but does anyone have access to > Jaguar now? > > > > - Karol > > > > On Sep 18 2013, Karol M. Langner wrote: > >> Yeah, forwarding to the dev list. > >> > >> So... any thoughts for/against these candidates: > >> 1. aopop > >> 2. aopops > >> 3. aopopulation > >> 4. aopopulations > >> 5. populations > >> > >> I think I prefer the first one, for its brevity. > >> > >> Cheers, > >> Karol > >> > >> On Sep 18 2013, Adam Tenderholt wrote: > >> > Hi Karol, > >> > > >> > Thanks for taking care of this. I forgot that an atomcharges > attribute was > >> > added. As far as aopop or aopopuations, perhaps that discussion > should be > >> > moved to cclib-devel? > >> > > >> > Adam > >> > > >> > > >> > > >> > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner > >> > <kar...@gm...>wrote: > >> > > >> > > Hi, > >> > > > >> > > Some time ago we actually created the 'atomcharges' attribute: > >> > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges > >> > > (see that page for the data description) > >> > > > >> > > So I went ahead and extended that to NPA charges and just commited > >> > > code that parses them for Gaussian09. And the newest trunk code > >> > > should parse the output file you sent, Fedor. > >> > > > >> > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it > >> > > should not be hard and this would be a good time to do it. > >> > > > >> > > As far as populations go, I believe we would need to create a new > attribute > >> > > for that, since it doesn't fit anywhere else. It should probably > also > >> > > be a dictionary. > >> > > > >> > > To keep with our current naming scheme, how about 'aopop' or > >> > > 'aopopulation'? > >> > > > >> > > Cheers, > >> > > Karol > >> > > > >> > > On Sep 13 2013, Fedor Zhuravlev wrote: > >> > > > Hi Adam and Karol, > >> > > > > >> > > > Frontier Molecular Orbitals: This is exactly what I was looking > for > >> > > folks, thanks! > >> > > > > >> > > > For the NPA analysis: I have included 3 log files from g09, > Jaguar 7 > >> > > and Turbomole 6.1, all containing the output from the NPA > calculations (at > >> > > the end of the file, they look very similar). The values of > interest could > >> > > be the Natural Charge and Natural Electron Population. Those would > be nice > >> > > to extract. > >> > > > > >> > > > Fedor > >> > > > > >> > > > From: Adam Tenderholt [mailto:ate...@gm...] > >> > > > Sent: 12 September 2013 18:08 > >> > > > To: Fedor Zhuravlev > >> > > > Cc: Karol M. Langner; ccl...@li... > >> > > > Subject: Re: [cclib-users] FMO properties > >> > > > > >> > > > Hi Fedor, > >> > > > > >> > > > Getting the energies of the HOMO and LUMO is pretty > straight-forward: > >> > > > > >> > > > from cclib.parser import ccopen > >> > > > > >> > > > parser = ccopen(logfile) > >> > > > data = parser.parser() > >> > > > homo = data.homos[0] # assuming spin-restricted > >> > > > lumo = homo + 1 > >> > > > > >> > > > homo_energy = data.moenergies[0][homo] > >> > > > lumo_energy = data.moenergies[0][lumo] > >> > > > > >> > > > As far as parsing population analyses, Noel, Karol, and I will > have to > >> > > discuss the potential implementation details. Do you have a > favorite QM > >> > > package? > >> > > > > >> > > > Adam > >> > > > > >> > > > > >> > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt... > <mailto: > >> > > fe...@dt...>> wrote: > >> > > > Hi Karol and Adam, > >> > > > > >> > > > Thanks much for the prompt reply. I was looking for the energies > of HOMO > >> > > and LUMO. From there, using the Koopman's theorem one gets the > ionization > >> > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP); > LUMO-HOMO is > >> > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity > (JACS, > >> > > 1999, 121, 1922). 4 very useful, easily chemically interpretable > chemical > >> > > descriptors for the price of two frontier MO! Would be very nice > to have! > >> > > > > >> > > > As for the natural population analysis the QM code would normally > do it > >> > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just the > >> > > question of proper parsing the data. Most people would normally be > >> > > interested in the natural charge and natural population. > >> > > > > >> > > > That was my wish list for Christmas :) > >> > > > > >> > > > Fedor Zhuravlev > >> > > > Senior Researcher > >> > > > DTU Nutech > >> > > > Technical University of Denmark > >> > > > Center for Nuclear Technologies > >> > > > Hevesy Laboratory > >> > > > DTU Risø Campus > >> > > > > >> > > > Frederiksborgvej 399 Building 202 > >> > > > Building 202 > >> > > > 4000 Roskilde > >> > > > fe...@dt...<mailto:fe...@dt...> > >> > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk> > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > -----Original Message----- > >> > > > From: Karol M. Langner [mailto:kar...@gm...<mailto: > >> > > kar...@gm...>] > >> > > > Sent: 12 September 2013 00:31 > >> > > > To: Adam Tenderholt > >> > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto: > >> > > ccl...@li...> > >> > > > Subject: Re: [cclib-users] FMO properties > >> > > > > >> > > > I assumed fragment energies in the fragment molecular orbital > method in > >> > > GAMESS-US... > >> > > > > >> > > > On Sep 11 2013, Adam Tenderholt wrote: > >> > > > > Hi Fedor, > >> > > > > > >> > > > > I wanted to follow up on Karol's email. I'm not familiar with > the > >> > > > > details of NPA, and I briefly looked up the > Reed/Weinstock/Weinhold > >> > > > > paper. Adding it as a method in cclib is likely possible, but > it would > >> > > > > probably take several hours to fully understand the algorithm, > and > >> > > > > then implement and test it. This does interest me, although I'm > not > >> > > > > sure when I could get around to it. > >> > > > > > >> > > > > Also, what exactly do you mean by FMO energies? To me, FMO > could stand > >> > > > > for either fragment molecular orbitals or frontier molecular > orbitals. > >> > > > > Do you have a concrete example? > >> > > > > > >> > > > > Adam > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner > >> > > > > <kar...@gm...<mailto:kar...@gm...>>wrote: > >> > > > > > >> > > > > > On Sep 11 2013, Fedor Zhuravlev wrote: > >> > > > > > > Dear cclib development team, > >> > > > > > > > >> > > > > > > Just had a first look at cclib and here's my questions: > >> > > > > > > > >> > > > > > > > >> > > > > > > 1. Is there a single-liner to get FMO energies only? > >> > > > > > > > >> > > > > > > 2. What about natural population analysis? > >> > > > > > > > >> > > > > > > Thanks much, > >> > > > > > > > >> > > > > > > Fedor > >> > > > > > > >> > > > > > Hi Fedor, > >> > > > > > > >> > > > > > Nice to hear from you. I've used cclib to parse FMO output > from > >> > > > > > GAMESS-US in the past, but it involved a quick custom hack, > which I > >> > > > > > still may have somewhere I guess (I did this outside of > version > >> > > > > > control). However, this was some years ago, and I think the > format > >> > > > > > has changed significantly since then. > >> > > > > > > >> > > > > > As far as population analyses are concerned, we do not parse > them, > >> > > > > > although there was a discussion about that in the past. We > have > >> > > > > > implemented several population analysis algorithms alongside > cclib, > >> > > though: > >> > > > > > > http://cclib.sourceforge.net/wiki/index.php/Calculation_methods > >> > > > > > ... although NAO is not among them. If you're thinking about > the > >> > > > > > original approach published by Reed/Weinstock/Weinhold, I > think it's > >> > > > > > a modification of Lowdin's orthoganolization, which we do. So > you > >> > > > > > could try to extend it to get what you want. Maybe Noel or > Adam has > >> > > more thoughts about this? > >> > > > > > > >> > > > > > If you want something specific parsed, you will generally > need to > >> > > > > > provide us with an example output file that we can use for > testing. > >> > > > > > > >> > > > > > Cheers, > >> > > > > > Karol > >> > > > > > > >> > > > > > -- > >> > > > > > written by Karol M. Langner > >> > > > > > Wed Sep 11 10:51:11 EDT 2013 > >> > > > > > > >> > > > > > > >> > > > > > > -------------------------------------------------------------------- > >> > > > > > ---------- How ServiceNow helps IT people transform IT > departments: > >> > > > > > 1. Consolidate legacy IT systems to a single system of record > for IT > >> > > > > > 2. Standardize and globalize service processes across IT 3. > >> > > > > > Implement zero-touch automation to replace manual, redundant > tasks > >> > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg > >> > > > > > .clktrk _______________________________________________ > >> > > > > > cclib-users mailing list > >> > > > > > ccl...@li...<mailto: > >> > > ccl...@li...> > >> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users > >> > > > > > > >> > > > > >> > > > -- > >> > > > written by Karol M. Langner > >> > > > Wed Sep 11 18:30:58 EDT 2013 > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > -- > >> > > written by Karol M. Langner > >> > > Wed Sep 18 18:11:05 EDT 2013 > >> > > > >> > >> -- > >> written by Karol M. Langner > >> Wed Sep 18 22:29:09 EDT 2013 > > > > -- > > written by Karol M. Langner > > Thu Sep 19 00:14:43 EDT 2013 > > > > > ------------------------------------------------------------------------------ > > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > > > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > > _______________________________________________ > > cclib-devel mailing list > > ccl...@li... > > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Noel O'B. <bao...@gm...> - 2013-09-23 15:51:57
|
I no longer have access to any of these I'm afraid... On 19 September 2013 05:18, Karol M. Langner <kar...@gm...> wrote: > I looked at the atomcharges code, and fixed the GAMESS-US parser a bit. > > One more thing, though. Our current Jaguar and Molpro log files for unit testing do not contain any partial charges, so there is nothing to test at this point. I could update the Molpro files, but does anyone have access to Jaguar now? > > - Karol > > On Sep 18 2013, Karol M. Langner wrote: >> Yeah, forwarding to the dev list. >> >> So... any thoughts for/against these candidates: >> 1. aopop >> 2. aopops >> 3. aopopulation >> 4. aopopulations >> 5. populations >> >> I think I prefer the first one, for its brevity. >> >> Cheers, >> Karol >> >> On Sep 18 2013, Adam Tenderholt wrote: >> > Hi Karol, >> > >> > Thanks for taking care of this. I forgot that an atomcharges attribute was >> > added. As far as aopop or aopopuations, perhaps that discussion should be >> > moved to cclib-devel? >> > >> > Adam >> > >> > >> > >> > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner >> > <kar...@gm...>wrote: >> > >> > > Hi, >> > > >> > > Some time ago we actually created the 'atomcharges' attribute: >> > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges >> > > (see that page for the data description) >> > > >> > > So I went ahead and extended that to NPA charges and just commited >> > > code that parses them for Gaussian09. And the newest trunk code >> > > should parse the output file you sent, Fedor. >> > > >> > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it >> > > should not be hard and this would be a good time to do it. >> > > >> > > As far as populations go, I believe we would need to create a new attribute >> > > for that, since it doesn't fit anywhere else. It should probably also >> > > be a dictionary. >> > > >> > > To keep with our current naming scheme, how about 'aopop' or >> > > 'aopopulation'? >> > > >> > > Cheers, >> > > Karol >> > > >> > > On Sep 13 2013, Fedor Zhuravlev wrote: >> > > > Hi Adam and Karol, >> > > > >> > > > Frontier Molecular Orbitals: This is exactly what I was looking for >> > > folks, thanks! >> > > > >> > > > For the NPA analysis: I have included 3 log files from g09, Jaguar 7 >> > > and Turbomole 6.1, all containing the output from the NPA calculations (at >> > > the end of the file, they look very similar). The values of interest could >> > > be the Natural Charge and Natural Electron Population. Those would be nice >> > > to extract. >> > > > >> > > > Fedor >> > > > >> > > > From: Adam Tenderholt [mailto:ate...@gm...] >> > > > Sent: 12 September 2013 18:08 >> > > > To: Fedor Zhuravlev >> > > > Cc: Karol M. Langner; ccl...@li... >> > > > Subject: Re: [cclib-users] FMO properties >> > > > >> > > > Hi Fedor, >> > > > >> > > > Getting the energies of the HOMO and LUMO is pretty straight-forward: >> > > > >> > > > from cclib.parser import ccopen >> > > > >> > > > parser = ccopen(logfile) >> > > > data = parser.parser() >> > > > homo = data.homos[0] # assuming spin-restricted >> > > > lumo = homo + 1 >> > > > >> > > > homo_energy = data.moenergies[0][homo] >> > > > lumo_energy = data.moenergies[0][lumo] >> > > > >> > > > As far as parsing population analyses, Noel, Karol, and I will have to >> > > discuss the potential implementation details. Do you have a favorite QM >> > > package? >> > > > >> > > > Adam >> > > > >> > > > >> > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt...<mailto: >> > > fe...@dt...>> wrote: >> > > > Hi Karol and Adam, >> > > > >> > > > Thanks much for the prompt reply. I was looking for the energies of HOMO >> > > and LUMO. From there, using the Koopman's theorem one gets the ionization >> > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP); LUMO-HOMO is >> > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity (JACS, >> > > 1999, 121, 1922). 4 very useful, easily chemically interpretable chemical >> > > descriptors for the price of two frontier MO! Would be very nice to have! >> > > > >> > > > As for the natural population analysis the QM code would normally do it >> > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just the >> > > question of proper parsing the data. Most people would normally be >> > > interested in the natural charge and natural population. >> > > > >> > > > That was my wish list for Christmas :) >> > > > >> > > > Fedor Zhuravlev >> > > > Senior Researcher >> > > > DTU Nutech >> > > > Technical University of Denmark >> > > > Center for Nuclear Technologies >> > > > Hevesy Laboratory >> > > > DTU Risø Campus >> > > > >> > > > Frederiksborgvej 399 Building 202 >> > > > Building 202 >> > > > 4000 Roskilde >> > > > fe...@dt...<mailto:fe...@dt...> >> > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk> >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > -----Original Message----- >> > > > From: Karol M. Langner [mailto:kar...@gm...<mailto: >> > > kar...@gm...>] >> > > > Sent: 12 September 2013 00:31 >> > > > To: Adam Tenderholt >> > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto: >> > > ccl...@li...> >> > > > Subject: Re: [cclib-users] FMO properties >> > > > >> > > > I assumed fragment energies in the fragment molecular orbital method in >> > > GAMESS-US... >> > > > >> > > > On Sep 11 2013, Adam Tenderholt wrote: >> > > > > Hi Fedor, >> > > > > >> > > > > I wanted to follow up on Karol's email. I'm not familiar with the >> > > > > details of NPA, and I briefly looked up the Reed/Weinstock/Weinhold >> > > > > paper. Adding it as a method in cclib is likely possible, but it would >> > > > > probably take several hours to fully understand the algorithm, and >> > > > > then implement and test it. This does interest me, although I'm not >> > > > > sure when I could get around to it. >> > > > > >> > > > > Also, what exactly do you mean by FMO energies? To me, FMO could stand >> > > > > for either fragment molecular orbitals or frontier molecular orbitals. >> > > > > Do you have a concrete example? >> > > > > >> > > > > Adam >> > > > > >> > > > > >> > > > > >> > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner >> > > > > <kar...@gm...<mailto:kar...@gm...>>wrote: >> > > > > >> > > > > > On Sep 11 2013, Fedor Zhuravlev wrote: >> > > > > > > Dear cclib development team, >> > > > > > > >> > > > > > > Just had a first look at cclib and here's my questions: >> > > > > > > >> > > > > > > >> > > > > > > 1. Is there a single-liner to get FMO energies only? >> > > > > > > >> > > > > > > 2. What about natural population analysis? >> > > > > > > >> > > > > > > Thanks much, >> > > > > > > >> > > > > > > Fedor >> > > > > > >> > > > > > Hi Fedor, >> > > > > > >> > > > > > Nice to hear from you. I've used cclib to parse FMO output from >> > > > > > GAMESS-US in the past, but it involved a quick custom hack, which I >> > > > > > still may have somewhere I guess (I did this outside of version >> > > > > > control). However, this was some years ago, and I think the format >> > > > > > has changed significantly since then. >> > > > > > >> > > > > > As far as population analyses are concerned, we do not parse them, >> > > > > > although there was a discussion about that in the past. We have >> > > > > > implemented several population analysis algorithms alongside cclib, >> > > though: >> > > > > > http://cclib.sourceforge.net/wiki/index.php/Calculation_methods >> > > > > > ... although NAO is not among them. If you're thinking about the >> > > > > > original approach published by Reed/Weinstock/Weinhold, I think it's >> > > > > > a modification of Lowdin's orthoganolization, which we do. So you >> > > > > > could try to extend it to get what you want. Maybe Noel or Adam has >> > > more thoughts about this? >> > > > > > >> > > > > > If you want something specific parsed, you will generally need to >> > > > > > provide us with an example output file that we can use for testing. >> > > > > > >> > > > > > Cheers, >> > > > > > Karol >> > > > > > >> > > > > > -- >> > > > > > written by Karol M. Langner >> > > > > > Wed Sep 11 10:51:11 EDT 2013 >> > > > > > >> > > > > > >> > > > > > -------------------------------------------------------------------- >> > > > > > ---------- How ServiceNow helps IT people transform IT departments: >> > > > > > 1. Consolidate legacy IT systems to a single system of record for IT >> > > > > > 2. Standardize and globalize service processes across IT 3. >> > > > > > Implement zero-touch automation to replace manual, redundant tasks >> > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg >> > > > > > .clktrk _______________________________________________ >> > > > > > cclib-users mailing list >> > > > > > ccl...@li...<mailto: >> > > ccl...@li...> >> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users >> > > > > > >> > > > >> > > > -- >> > > > written by Karol M. Langner >> > > > Wed Sep 11 18:30:58 EDT 2013 >> > > > >> > > >> > > >> > > >> > > >> > > >> > > -- >> > > written by Karol M. Langner >> > > Wed Sep 18 18:11:05 EDT 2013 >> > > >> >> -- >> written by Karol M. Langner >> Wed Sep 18 22:29:09 EDT 2013 > > -- > written by Karol M. Langner > Thu Sep 19 00:14:43 EDT 2013 > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel |
|
From: Adam T. <ate...@gm...> - 2013-09-19 16:09:07
|
My thoughts on the attribute name: 1) It should be plural since it contains more than one value. This matches the rest of cclib (e.g. aonames, atomnos, atomcoords, etc.) 2) Since it's atomic-orbital level, it should probably contain ao to distinguish it from atom populations, which are also (sometimes) available to parse if we decide to support that in the future. 3) We already sometimes abbreviate attributes (e.g. vibsyms, vibfreqs, mocoeffs), so there's precedent. Based on these, my vote would be aopops. Adam On Wed, Sep 18, 2013 at 7:30 PM, Karol M. Langner <kar...@gm...>wrote: > Yeah, forwarding to the dev list. > > So... any thoughts for/against these candidates: > 1. aopop > 2. aopops > 3. aopopulation > 4. aopopulations > 5. populations > > I think I prefer the first one, for its brevity. > > Cheers, > Karol > > On Sep 18 2013, Adam Tenderholt wrote: > > Hi Karol, > > > > Thanks for taking care of this. I forgot that an atomcharges attribute > was > > added. As far as aopop or aopopuations, perhaps that discussion should be > > moved to cclib-devel? > > > > Adam > > > > > > > > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner > > <kar...@gm...>wrote: > > > > > Hi, > > > > > > Some time ago we actually created the 'atomcharges' attribute: > > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges > > > (see that page for the data description) > > > > > > So I went ahead and extended that to NPA charges and just commited > > > code that parses them for Gaussian09. And the newest trunk code > > > should parse the output file you sent, Fedor. > > > > > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it > > > should not be hard and this would be a good time to do it. > > > > > > As far as populations go, I believe we would need to create a new > attribute > > > for that, since it doesn't fit anywhere else. It should probably also > > > be a dictionary. > > > > > > To keep with our current naming scheme, how about 'aopop' or > > > 'aopopulation'? > > > > > > Cheers, > > > Karol > > > > > > On Sep 13 2013, Fedor Zhuravlev wrote: > > > > Hi Adam and Karol, > > > > > > > > Frontier Molecular Orbitals: This is exactly what I was looking for > > > folks, thanks! > > > > > > > > For the NPA analysis: I have included 3 log files from g09, Jaguar 7 > > > and Turbomole 6.1, all containing the output from the NPA calculations > (at > > > the end of the file, they look very similar). The values of interest > could > > > be the Natural Charge and Natural Electron Population. Those would be > nice > > > to extract. > > > > > > > > Fedor > > > > > > > > From: Adam Tenderholt [mailto:ate...@gm...] > > > > Sent: 12 September 2013 18:08 > > > > To: Fedor Zhuravlev > > > > Cc: Karol M. Langner; ccl...@li... > > > > Subject: Re: [cclib-users] FMO properties > > > > > > > > Hi Fedor, > > > > > > > > Getting the energies of the HOMO and LUMO is pretty straight-forward: > > > > > > > > from cclib.parser import ccopen > > > > > > > > parser = ccopen(logfile) > > > > data = parser.parser() > > > > homo = data.homos[0] # assuming spin-restricted > > > > lumo = homo + 1 > > > > > > > > homo_energy = data.moenergies[0][homo] > > > > lumo_energy = data.moenergies[0][lumo] > > > > > > > > As far as parsing population analyses, Noel, Karol, and I will have > to > > > discuss the potential implementation details. Do you have a favorite QM > > > package? > > > > > > > > Adam > > > > > > > > > > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt... > <mailto: > > > fe...@dt...>> wrote: > > > > Hi Karol and Adam, > > > > > > > > Thanks much for the prompt reply. I was looking for the energies of > HOMO > > > and LUMO. From there, using the Koopman's theorem one gets the > ionization > > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP); > LUMO-HOMO is > > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity (JACS, > > > 1999, 121, 1922). 4 very useful, easily chemically interpretable > chemical > > > descriptors for the price of two frontier MO! Would be very nice to > have! > > > > > > > > As for the natural population analysis the QM code would normally do > it > > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just the > > > question of proper parsing the data. Most people would normally be > > > interested in the natural charge and natural population. > > > > > > > > That was my wish list for Christmas :) > > > > > > > > Fedor Zhuravlev > > > > Senior Researcher > > > > DTU Nutech > > > > Technical University of Denmark > > > > Center for Nuclear Technologies > > > > Hevesy Laboratory > > > > DTU Risø Campus > > > > > > > > Frederiksborgvej 399 Building 202 > > > > Building 202 > > > > 4000 Roskilde > > > > fe...@dt...<mailto:fe...@dt...> > > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Karol M. Langner [mailto:kar...@gm...<mailto: > > > kar...@gm...>] > > > > Sent: 12 September 2013 00:31 > > > > To: Adam Tenderholt > > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto: > > > ccl...@li...> > > > > Subject: Re: [cclib-users] FMO properties > > > > > > > > I assumed fragment energies in the fragment molecular orbital method > in > > > GAMESS-US... > > > > > > > > On Sep 11 2013, Adam Tenderholt wrote: > > > > > Hi Fedor, > > > > > > > > > > I wanted to follow up on Karol's email. I'm not familiar with the > > > > > details of NPA, and I briefly looked up the Reed/Weinstock/Weinhold > > > > > paper. Adding it as a method in cclib is likely possible, but it > would > > > > > probably take several hours to fully understand the algorithm, and > > > > > then implement and test it. This does interest me, although I'm not > > > > > sure when I could get around to it. > > > > > > > > > > Also, what exactly do you mean by FMO energies? To me, FMO could > stand > > > > > for either fragment molecular orbitals or frontier molecular > orbitals. > > > > > Do you have a concrete example? > > > > > > > > > > Adam > > > > > > > > > > > > > > > > > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner > > > > > <kar...@gm...<mailto:kar...@gm...>>wrote: > > > > > > > > > > > On Sep 11 2013, Fedor Zhuravlev wrote: > > > > > > > Dear cclib development team, > > > > > > > > > > > > > > Just had a first look at cclib and here's my questions: > > > > > > > > > > > > > > > > > > > > > 1. Is there a single-liner to get FMO energies only? > > > > > > > > > > > > > > 2. What about natural population analysis? > > > > > > > > > > > > > > Thanks much, > > > > > > > > > > > > > > Fedor > > > > > > > > > > > > Hi Fedor, > > > > > > > > > > > > Nice to hear from you. I've used cclib to parse FMO output from > > > > > > GAMESS-US in the past, but it involved a quick custom hack, > which I > > > > > > still may have somewhere I guess (I did this outside of version > > > > > > control). However, this was some years ago, and I think the > format > > > > > > has changed significantly since then. > > > > > > > > > > > > As far as population analyses are concerned, we do not parse > them, > > > > > > although there was a discussion about that in the past. We have > > > > > > implemented several population analysis algorithms alongside > cclib, > > > though: > > > > > > http://cclib.sourceforge.net/wiki/index.php/Calculation_methods > > > > > > ... although NAO is not among them. If you're thinking about the > > > > > > original approach published by Reed/Weinstock/Weinhold, I think > it's > > > > > > a modification of Lowdin's orthoganolization, which we do. So you > > > > > > could try to extend it to get what you want. Maybe Noel or Adam > has > > > more thoughts about this? > > > > > > > > > > > > If you want something specific parsed, you will generally need to > > > > > > provide us with an example output file that we can use for > testing. > > > > > > > > > > > > Cheers, > > > > > > Karol > > > > > > > > > > > > -- > > > > > > written by Karol M. Langner > > > > > > Wed Sep 11 10:51:11 EDT 2013 > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > ---------- How ServiceNow helps IT people transform IT > departments: > > > > > > 1. Consolidate legacy IT systems to a single system of record > for IT > > > > > > 2. Standardize and globalize service processes across IT 3. > > > > > > Implement zero-touch automation to replace manual, redundant > tasks > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg > > > > > > .clktrk _______________________________________________ > > > > > > cclib-users mailing list > > > > > > ccl...@li...<mailto: > > > ccl...@li...> > > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users > > > > > > > > > > > > > > -- > > > > written by Karol M. Langner > > > > Wed Sep 11 18:30:58 EDT 2013 > > > > > > > > > > > > > > > > > > > > > > -- > > > written by Karol M. Langner > > > Wed Sep 18 18:11:05 EDT 2013 > > > > > -- > written by Karol M. Langner > Wed Sep 18 22:29:09 EDT 2013 > |
|
From: Karol M. L. <kar...@gm...> - 2013-09-19 04:18:41
|
I looked at the atomcharges code, and fixed the GAMESS-US parser a bit. One more thing, though. Our current Jaguar and Molpro log files for unit testing do not contain any partial charges, so there is nothing to test at this point. I could update the Molpro files, but does anyone have access to Jaguar now? - Karol On Sep 18 2013, Karol M. Langner wrote: > Yeah, forwarding to the dev list. > > So... any thoughts for/against these candidates: > 1. aopop > 2. aopops > 3. aopopulation > 4. aopopulations > 5. populations > > I think I prefer the first one, for its brevity. > > Cheers, > Karol > > On Sep 18 2013, Adam Tenderholt wrote: > > Hi Karol, > > > > Thanks for taking care of this. I forgot that an atomcharges attribute was > > added. As far as aopop or aopopuations, perhaps that discussion should be > > moved to cclib-devel? > > > > Adam > > > > > > > > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner > > <kar...@gm...>wrote: > > > > > Hi, > > > > > > Some time ago we actually created the 'atomcharges' attribute: > > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges > > > (see that page for the data description) > > > > > > So I went ahead and extended that to NPA charges and just commited > > > code that parses them for Gaussian09. And the newest trunk code > > > should parse the output file you sent, Fedor. > > > > > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it > > > should not be hard and this would be a good time to do it. > > > > > > As far as populations go, I believe we would need to create a new attribute > > > for that, since it doesn't fit anywhere else. It should probably also > > > be a dictionary. > > > > > > To keep with our current naming scheme, how about 'aopop' or > > > 'aopopulation'? > > > > > > Cheers, > > > Karol > > > > > > On Sep 13 2013, Fedor Zhuravlev wrote: > > > > Hi Adam and Karol, > > > > > > > > Frontier Molecular Orbitals: This is exactly what I was looking for > > > folks, thanks! > > > > > > > > For the NPA analysis: I have included 3 log files from g09, Jaguar 7 > > > and Turbomole 6.1, all containing the output from the NPA calculations (at > > > the end of the file, they look very similar). The values of interest could > > > be the Natural Charge and Natural Electron Population. Those would be nice > > > to extract. > > > > > > > > Fedor > > > > > > > > From: Adam Tenderholt [mailto:ate...@gm...] > > > > Sent: 12 September 2013 18:08 > > > > To: Fedor Zhuravlev > > > > Cc: Karol M. Langner; ccl...@li... > > > > Subject: Re: [cclib-users] FMO properties > > > > > > > > Hi Fedor, > > > > > > > > Getting the energies of the HOMO and LUMO is pretty straight-forward: > > > > > > > > from cclib.parser import ccopen > > > > > > > > parser = ccopen(logfile) > > > > data = parser.parser() > > > > homo = data.homos[0] # assuming spin-restricted > > > > lumo = homo + 1 > > > > > > > > homo_energy = data.moenergies[0][homo] > > > > lumo_energy = data.moenergies[0][lumo] > > > > > > > > As far as parsing population analyses, Noel, Karol, and I will have to > > > discuss the potential implementation details. Do you have a favorite QM > > > package? > > > > > > > > Adam > > > > > > > > > > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt...<mailto: > > > fe...@dt...>> wrote: > > > > Hi Karol and Adam, > > > > > > > > Thanks much for the prompt reply. I was looking for the energies of HOMO > > > and LUMO. From there, using the Koopman's theorem one gets the ionization > > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP); LUMO-HOMO is > > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity (JACS, > > > 1999, 121, 1922). 4 very useful, easily chemically interpretable chemical > > > descriptors for the price of two frontier MO! Would be very nice to have! > > > > > > > > As for the natural population analysis the QM code would normally do it > > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just the > > > question of proper parsing the data. Most people would normally be > > > interested in the natural charge and natural population. > > > > > > > > That was my wish list for Christmas :) > > > > > > > > Fedor Zhuravlev > > > > Senior Researcher > > > > DTU Nutech > > > > Technical University of Denmark > > > > Center for Nuclear Technologies > > > > Hevesy Laboratory > > > > DTU Risø Campus > > > > > > > > Frederiksborgvej 399 Building 202 > > > > Building 202 > > > > 4000 Roskilde > > > > fe...@dt...<mailto:fe...@dt...> > > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Karol M. Langner [mailto:kar...@gm...<mailto: > > > kar...@gm...>] > > > > Sent: 12 September 2013 00:31 > > > > To: Adam Tenderholt > > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto: > > > ccl...@li...> > > > > Subject: Re: [cclib-users] FMO properties > > > > > > > > I assumed fragment energies in the fragment molecular orbital method in > > > GAMESS-US... > > > > > > > > On Sep 11 2013, Adam Tenderholt wrote: > > > > > Hi Fedor, > > > > > > > > > > I wanted to follow up on Karol's email. I'm not familiar with the > > > > > details of NPA, and I briefly looked up the Reed/Weinstock/Weinhold > > > > > paper. Adding it as a method in cclib is likely possible, but it would > > > > > probably take several hours to fully understand the algorithm, and > > > > > then implement and test it. This does interest me, although I'm not > > > > > sure when I could get around to it. > > > > > > > > > > Also, what exactly do you mean by FMO energies? To me, FMO could stand > > > > > for either fragment molecular orbitals or frontier molecular orbitals. > > > > > Do you have a concrete example? > > > > > > > > > > Adam > > > > > > > > > > > > > > > > > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner > > > > > <kar...@gm...<mailto:kar...@gm...>>wrote: > > > > > > > > > > > On Sep 11 2013, Fedor Zhuravlev wrote: > > > > > > > Dear cclib development team, > > > > > > > > > > > > > > Just had a first look at cclib and here's my questions: > > > > > > > > > > > > > > > > > > > > > 1. Is there a single-liner to get FMO energies only? > > > > > > > > > > > > > > 2. What about natural population analysis? > > > > > > > > > > > > > > Thanks much, > > > > > > > > > > > > > > Fedor > > > > > > > > > > > > Hi Fedor, > > > > > > > > > > > > Nice to hear from you. I've used cclib to parse FMO output from > > > > > > GAMESS-US in the past, but it involved a quick custom hack, which I > > > > > > still may have somewhere I guess (I did this outside of version > > > > > > control). However, this was some years ago, and I think the format > > > > > > has changed significantly since then. > > > > > > > > > > > > As far as population analyses are concerned, we do not parse them, > > > > > > although there was a discussion about that in the past. We have > > > > > > implemented several population analysis algorithms alongside cclib, > > > though: > > > > > > http://cclib.sourceforge.net/wiki/index.php/Calculation_methods > > > > > > ... although NAO is not among them. If you're thinking about the > > > > > > original approach published by Reed/Weinstock/Weinhold, I think it's > > > > > > a modification of Lowdin's orthoganolization, which we do. So you > > > > > > could try to extend it to get what you want. Maybe Noel or Adam has > > > more thoughts about this? > > > > > > > > > > > > If you want something specific parsed, you will generally need to > > > > > > provide us with an example output file that we can use for testing. > > > > > > > > > > > > Cheers, > > > > > > Karol > > > > > > > > > > > > -- > > > > > > written by Karol M. Langner > > > > > > Wed Sep 11 10:51:11 EDT 2013 > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > ---------- How ServiceNow helps IT people transform IT departments: > > > > > > 1. Consolidate legacy IT systems to a single system of record for IT > > > > > > 2. Standardize and globalize service processes across IT 3. > > > > > > Implement zero-touch automation to replace manual, redundant tasks > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg > > > > > > .clktrk _______________________________________________ > > > > > > cclib-users mailing list > > > > > > ccl...@li...<mailto: > > > ccl...@li...> > > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users > > > > > > > > > > > > > > -- > > > > written by Karol M. Langner > > > > Wed Sep 11 18:30:58 EDT 2013 > > > > > > > > > > > > > > > > > > > > > > -- > > > written by Karol M. Langner > > > Wed Sep 18 18:11:05 EDT 2013 > > > > > -- > written by Karol M. Langner > Wed Sep 18 22:29:09 EDT 2013 -- written by Karol M. Langner Thu Sep 19 00:14:43 EDT 2013 |
|
From: Karol M. L. <kar...@gm...> - 2013-09-19 02:30:50
|
Yeah, forwarding to the dev list. So... any thoughts for/against these candidates: 1. aopop 2. aopops 3. aopopulation 4. aopopulations 5. populations I think I prefer the first one, for its brevity. Cheers, Karol On Sep 18 2013, Adam Tenderholt wrote: > Hi Karol, > > Thanks for taking care of this. I forgot that an atomcharges attribute was > added. As far as aopop or aopopuations, perhaps that discussion should be > moved to cclib-devel? > > Adam > > > > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner > <kar...@gm...>wrote: > > > Hi, > > > > Some time ago we actually created the 'atomcharges' attribute: > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges > > (see that page for the data description) > > > > So I went ahead and extended that to NPA charges and just commited > > code that parses them for Gaussian09. And the newest trunk code > > should parse the output file you sent, Fedor. > > > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it > > should not be hard and this would be a good time to do it. > > > > As far as populations go, I believe we would need to create a new attribute > > for that, since it doesn't fit anywhere else. It should probably also > > be a dictionary. > > > > To keep with our current naming scheme, how about 'aopop' or > > 'aopopulation'? > > > > Cheers, > > Karol > > > > On Sep 13 2013, Fedor Zhuravlev wrote: > > > Hi Adam and Karol, > > > > > > Frontier Molecular Orbitals: This is exactly what I was looking for > > folks, thanks! > > > > > > For the NPA analysis: I have included 3 log files from g09, Jaguar 7 > > and Turbomole 6.1, all containing the output from the NPA calculations (at > > the end of the file, they look very similar). The values of interest could > > be the Natural Charge and Natural Electron Population. Those would be nice > > to extract. > > > > > > Fedor > > > > > > From: Adam Tenderholt [mailto:ate...@gm...] > > > Sent: 12 September 2013 18:08 > > > To: Fedor Zhuravlev > > > Cc: Karol M. Langner; ccl...@li... > > > Subject: Re: [cclib-users] FMO properties > > > > > > Hi Fedor, > > > > > > Getting the energies of the HOMO and LUMO is pretty straight-forward: > > > > > > from cclib.parser import ccopen > > > > > > parser = ccopen(logfile) > > > data = parser.parser() > > > homo = data.homos[0] # assuming spin-restricted > > > lumo = homo + 1 > > > > > > homo_energy = data.moenergies[0][homo] > > > lumo_energy = data.moenergies[0][lumo] > > > > > > As far as parsing population analyses, Noel, Karol, and I will have to > > discuss the potential implementation details. Do you have a favorite QM > > package? > > > > > > Adam > > > > > > > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt...<mailto: > > fe...@dt...>> wrote: > > > Hi Karol and Adam, > > > > > > Thanks much for the prompt reply. I was looking for the energies of HOMO > > and LUMO. From there, using the Koopman's theorem one gets the ionization > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP); LUMO-HOMO is > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity (JACS, > > 1999, 121, 1922). 4 very useful, easily chemically interpretable chemical > > descriptors for the price of two frontier MO! Would be very nice to have! > > > > > > As for the natural population analysis the QM code would normally do it > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just the > > question of proper parsing the data. Most people would normally be > > interested in the natural charge and natural population. > > > > > > That was my wish list for Christmas :) > > > > > > Fedor Zhuravlev > > > Senior Researcher > > > DTU Nutech > > > Technical University of Denmark > > > Center for Nuclear Technologies > > > Hevesy Laboratory > > > DTU Risø Campus > > > > > > Frederiksborgvej 399 Building 202 > > > Building 202 > > > 4000 Roskilde > > > fe...@dt...<mailto:fe...@dt...> > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk> > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Karol M. Langner [mailto:kar...@gm...<mailto: > > kar...@gm...>] > > > Sent: 12 September 2013 00:31 > > > To: Adam Tenderholt > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto: > > ccl...@li...> > > > Subject: Re: [cclib-users] FMO properties > > > > > > I assumed fragment energies in the fragment molecular orbital method in > > GAMESS-US... > > > > > > On Sep 11 2013, Adam Tenderholt wrote: > > > > Hi Fedor, > > > > > > > > I wanted to follow up on Karol's email. I'm not familiar with the > > > > details of NPA, and I briefly looked up the Reed/Weinstock/Weinhold > > > > paper. Adding it as a method in cclib is likely possible, but it would > > > > probably take several hours to fully understand the algorithm, and > > > > then implement and test it. This does interest me, although I'm not > > > > sure when I could get around to it. > > > > > > > > Also, what exactly do you mean by FMO energies? To me, FMO could stand > > > > for either fragment molecular orbitals or frontier molecular orbitals. > > > > Do you have a concrete example? > > > > > > > > Adam > > > > > > > > > > > > > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner > > > > <kar...@gm...<mailto:kar...@gm...>>wrote: > > > > > > > > > On Sep 11 2013, Fedor Zhuravlev wrote: > > > > > > Dear cclib development team, > > > > > > > > > > > > Just had a first look at cclib and here's my questions: > > > > > > > > > > > > > > > > > > 1. Is there a single-liner to get FMO energies only? > > > > > > > > > > > > 2. What about natural population analysis? > > > > > > > > > > > > Thanks much, > > > > > > > > > > > > Fedor > > > > > > > > > > Hi Fedor, > > > > > > > > > > Nice to hear from you. I've used cclib to parse FMO output from > > > > > GAMESS-US in the past, but it involved a quick custom hack, which I > > > > > still may have somewhere I guess (I did this outside of version > > > > > control). However, this was some years ago, and I think the format > > > > > has changed significantly since then. > > > > > > > > > > As far as population analyses are concerned, we do not parse them, > > > > > although there was a discussion about that in the past. We have > > > > > implemented several population analysis algorithms alongside cclib, > > though: > > > > > http://cclib.sourceforge.net/wiki/index.php/Calculation_methods > > > > > ... although NAO is not among them. If you're thinking about the > > > > > original approach published by Reed/Weinstock/Weinhold, I think it's > > > > > a modification of Lowdin's orthoganolization, which we do. So you > > > > > could try to extend it to get what you want. Maybe Noel or Adam has > > more thoughts about this? > > > > > > > > > > If you want something specific parsed, you will generally need to > > > > > provide us with an example output file that we can use for testing. > > > > > > > > > > Cheers, > > > > > Karol > > > > > > > > > > -- > > > > > written by Karol M. Langner > > > > > Wed Sep 11 10:51:11 EDT 2013 > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > ---------- How ServiceNow helps IT people transform IT departments: > > > > > 1. Consolidate legacy IT systems to a single system of record for IT > > > > > 2. Standardize and globalize service processes across IT 3. > > > > > Implement zero-touch automation to replace manual, redundant tasks > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg > > > > > .clktrk _______________________________________________ > > > > > cclib-users mailing list > > > > > ccl...@li...<mailto: > > ccl...@li...> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users > > > > > > > > > > > -- > > > written by Karol M. Langner > > > Wed Sep 11 18:30:58 EDT 2013 > > > > > > > > > > > > > > > -- > > written by Karol M. Langner > > Wed Sep 18 18:11:05 EDT 2013 > > -- written by Karol M. Langner Wed Sep 18 22:29:09 EDT 2013 |
|
From: Karol M. L. <kar...@gm...> - 2013-08-11 20:30:23
|
So, are we compatible with python3 now? - Karol On Aug 10 2013, Noel O'Boyle wrote: > Great. I guess you're right - there's no reason to keep it now, and it > can just cause confusion. Do you want to go ahead and delete it? > > - Noel > > > > On 9 August 2013 21:15, Adam Tenderholt <ate...@gm...> wrote: > > Since it was a fairly straight-forward merge and I had a bit of spare time, > > I went ahead and merged python3 into trunk just now. Is there any reason to > > keep the python3 branch? > > > > > > > > On Fri, Aug 9, 2013 at 1:29 AM, Noel O'Boyle <bao...@gm...> wrote: > >> > >> My bad. Those few recent commits on Python3 should have been made on > >> trunk. I'll merge them. > >> > >> - Noel > >> > >> On 8 August 2013 23:41, Adam Tenderholt <ate...@gm...> wrote: > >> > Quick question: Is there a reason to develop in the python3 branch > >> > instead > >> > of trunk? > >> > > >> > It looks like trunk is ~5 commits behind branches/python3. > >> > > >> > Adam > >> > > >> > > >> > > >> > ------------------------------------------------------------------------------ > >> > Get 100% visibility into Java/.NET code with AppDynamics Lite! > >> > It's a free troubleshooting tool designed for production. > >> > Get down to code-level detail for bottlenecks, with <2% overhead. > >> > Download for free and get started troubleshooting in minutes. > >> > > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > >> > _______________________________________________ > >> > cclib-devel mailing list > >> > ccl...@li... > >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel > >> > > > > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel -- written by Karol M. Langner Sun Aug 11 16:29:41 EDT 2013 |
|
From: Noel O'B. <bao...@gm...> - 2013-08-10 10:35:03
|
Great. I guess you're right - there's no reason to keep it now, and it can just cause confusion. Do you want to go ahead and delete it? - Noel On 9 August 2013 21:15, Adam Tenderholt <ate...@gm...> wrote: > Since it was a fairly straight-forward merge and I had a bit of spare time, > I went ahead and merged python3 into trunk just now. Is there any reason to > keep the python3 branch? > > > > On Fri, Aug 9, 2013 at 1:29 AM, Noel O'Boyle <bao...@gm...> wrote: >> >> My bad. Those few recent commits on Python3 should have been made on >> trunk. I'll merge them. >> >> - Noel >> >> On 8 August 2013 23:41, Adam Tenderholt <ate...@gm...> wrote: >> > Quick question: Is there a reason to develop in the python3 branch >> > instead >> > of trunk? >> > >> > It looks like trunk is ~5 commits behind branches/python3. >> > >> > Adam >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Get 100% visibility into Java/.NET code with AppDynamics Lite! >> > It's a free troubleshooting tool designed for production. >> > Get down to code-level detail for bottlenecks, with <2% overhead. >> > Download for free and get started troubleshooting in minutes. >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > cclib-devel mailing list >> > ccl...@li... >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > > |
|
From: Adam T. <ate...@gm...> - 2013-08-09 20:16:17
|
Since it was a fairly straight-forward merge and I had a bit of spare time, I went ahead and merged python3 into trunk just now. Is there any reason to keep the python3 branch? On Fri, Aug 9, 2013 at 1:29 AM, Noel O'Boyle <bao...@gm...> wrote: > My bad. Those few recent commits on Python3 should have been made on > trunk. I'll merge them. > > - Noel > > On 8 August 2013 23:41, Adam Tenderholt <ate...@gm...> wrote: > > Quick question: Is there a reason to develop in the python3 branch > instead > > of trunk? > > > > It looks like trunk is ~5 commits behind branches/python3. > > > > Adam > > > > > > > ------------------------------------------------------------------------------ > > Get 100% visibility into Java/.NET code with AppDynamics Lite! > > It's a free troubleshooting tool designed for production. > > Get down to code-level detail for bottlenecks, with <2% overhead. > > Download for free and get started troubleshooting in minutes. > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > _______________________________________________ > > cclib-devel mailing list > > ccl...@li... > > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > > |
|
From: Noel O'B. <bao...@gm...> - 2013-08-09 08:29:38
|
My bad. Those few recent commits on Python3 should have been made on trunk. I'll merge them. - Noel On 8 August 2013 23:41, Adam Tenderholt <ate...@gm...> wrote: > Quick question: Is there a reason to develop in the python3 branch instead > of trunk? > > It looks like trunk is ~5 commits behind branches/python3. > > Adam > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <ate...@gm...> - 2013-08-08 22:41:38
|
Quick question: Is there a reason to develop in the python3 branch instead of trunk? It looks like trunk is ~5 commits behind branches/python3. Adam |
|
From: Noel O'B. <bao...@gm...> - 2013-07-28 09:26:58
|
Sorry - I see that I said I'd do this but clearly never did.
Regarding (2) first, sure separate functions are fine and probably a
good idea in general.
Regarding (1), I have in mind that the next release will be based on
Python 3. So definitely make sure that your fixes go on the Py3
branch. My own feeling is maintaining two branches at the same time is
too much work - our resources are best spent on a single Python.
However, if one of you wants to merge fixes back to the Python2 branch
feel free to do it. (BTW, I still have to port GaussSum too and
similiarly it'll happen in the next few months.)
- Noel
On 27 July 2013 20:42, Adam Tenderholt <ate...@gm...> wrote:
> A user of QMForge just alerted me to this problem, and I didn't see an
> obvious fix in SVN. Before I started to work on it, I wanted to check-in and
> ask a few things.
>
> 1) Will there be a minor bug fix release for cclib 1.1 (python2), or are we
> only supporting fixes to the python3 branches now? If we make a change in
> one branch, how difficult is it to merge that to another branch given the
> python differences? Is it better to make two separate fixes? (QMForge is
> still on python2, but I plan on moving to python3 in the coming months.)
>
> 2) Any thoughts on the best approach? Right now, there is a large commented
> block detailing the format with the main parser code being if/elif
> statements inside a while loop. A second commented block can be added
> detailing the other format along with the associated parser code. Since this
> would likely lead to somewhat messier code, there could instead be two new
> functions (parse_scf_condensed_format and parse_scf_expanded_format) with
> format commented at the beginning of the function. I'm leaning towards the
> latter since our extract functions are becoming quite large (over 500 LOC
> for Orcaparser and 1000 LOC for Gaussian!!), and perhaps we should consider
> creating functions for individual attributes.
>
> Adam
>
>
>
> On Mon, Feb 25, 2013 at 3:24 PM, Karol M. Langner <kar...@gm...>
> wrote:
>>
>> I agree, and I'll leave this one to you guys. Have you checked if perhaps
>> this is caused by a change between ORCA versions? I'm not really up-to-date
>> on it's output.
>>
>> Karol
>>
>> On Feb 25 2013, Noel O'Boyle wrote:
>> > I'm all for parsing it. Since this is fairly GaussSum-specific I'm
>> > happy to do it if you can make sure these files are public domain. In
>> > the meanwhile, you can point out to the user that he can comment out
>> > the offending code.
>> >
>> > On 25 February 2013 17:31, Adam Tenderholt <ate...@gm...>
>> > wrote:
>> > > CC: dev list
>> > >
>> > > Any thoughts on this? Should we try to parse the alternate SCF
>> > > convergence
>> > > info, or just change the code so it doesn't raise an exception?
>> > >
>> > > Adam
>> > >
>> > > On Mon, Feb 25, 2013 at 3:14 AM, msmqbm <ms...@ci...> wrote:
>> > >>
>> > >> Dear Adam,
>> > >>
>> > >> Thanks for your message. The reason for that strange output is the
>> > >> NormalPrint keyword, it has nothing to do with the MRCI (you can
>> > >> delete that
>> > >> part). Here I attach an output with a DFT calculation and a
>> > >> normalPrint
>> > >> keyword, so that you can see the source of the problem.
>> > >> It's ok if you make this input or output public.
>> > >>
>> > >> It would be nice that, even if the parser cannot read the whole file,
>> > >> it
>> > >> didn't raise an exception, so that one could get at least the
>> > >> geometry, the
>> > >> number of atoms or the information it has read so far.
>> > >>
>> > >> Cheers,
>> > >>
>> > >>
>> > >> On 02/25/2013 01:24 AM, Adam Tenderholt wrote:
>> > >>
>> > >> Hi Melchor,
>> > >>
>> > >> Sorry for the delay. I've finally looked into your parse error. The
>> > >> problem is the output from the SCF convergence. For instance, it your
>> > >> file,
>> > >> it is:
>> > >>
>> > >> --------------
>> > >> SCF ITERATIONS
>> > >> --------------
>> > >> *** Starting incremental Fock matrix formation ***
>> > >>
>> > >> ----------------------------
>> > >> ! ITERATION 0 !
>> > >> ----------------------------
>> > >> Total Energy : -377.995940441385 Eh
>> > >> Energy Change : -377.995940441385 Eh
>> > >> MAX-DP : 0.104636203272
>> > >> RMS-DP : 0.004511416837
>> > >> Actual Damping : 0.7000
>> > >> Actual Level Shift : 0.2500 Eh
>> > >> Int. Num. El. : 43.99928165 (UP= 21.99964083 DN=
>> > >> 21.99964083)
>> > >> Exchange : -34.30375363
>> > >> Correlation : -2.02696332
>> > >>
>> > >>
>> > >> ----------------------------
>> > >> ! ITERATION 1 !
>> > >> ----------------------------
>> > >> Total Energy : -378.158637308210 Eh
>> > >> Energy Change : -0.162696866825 Eh
>> > >> MAX-DP : 0.056981704567
>> > >> RMS-DP : 0.002392614971
>> > >> Actual Damping : 0.7000
>> > >> Actual Level Shift : 0.2500 Eh
>> > >> Int. Num. El. : 43.99902992 (UP= 21.99951496 DN=
>> > >> 21.99951496)
>> > >> Exchange : -34.01830967
>> > >> Correlation : -2.01718102
>> > >>
>> > >> However, cclib is expecting the following:
>> > >>
>> > >> --------------
>> > >> SCF ITERATIONS
>> > >> --------------
>> > >> ITER Energy Delta-E Max-DP RMS-DP
>> > >> [F,P]
>> > >> Damp
>> > >> *** Starting incremental Fock matrix formation ***
>> > >> 0 -381.9867779344 0.000000000000 0.05707535 0.00425410
>> > >> 0.0807540
>> > >> 0.7000
>> > >> 1 -382.0079986969 -0.021220762511 0.02895905 0.00220039
>> > >> 0.0411442
>> > >> 0.7000
>> > >>
>> > >> I tried to make sense of your input file, but I don't have any
>> > >> experience
>> > >> with MRCI calculations with ORCA. Do you know if there was some
>> > >> option that
>> > >> caused the SCF convergence to be printed differently? Or is this how
>> > >> the
>> > >> convergence for all MRCI calculations is printed?
>> > >>
>> > >> Also, are you willing to place your logfile in the public domain? We
>> > >> would
>> > >> like to include it with our other regression files.
>> > >>
>> > >> Thanks,
>> > >>
>> > >> Adam
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Thu, Feb 21, 2013 at 1:48 AM, msmqbm <ms...@ci...> wrote:
>> > >>>
>> > >>> Dear cclib developers,
>> > >>> When trying to parse an Orca 2.9.0 output file I get the following
>> > >>> error:
>> > >>>
>> > >>> >>> import cclib
>> > >>> >>> f1= cclib.parser.ORCA("DAT6600.out")
>> > >>> >>> data1= f1.parse()
>> > >>> [ORCA DAT6600.out INFO] Creating attribute atomcoords[]
>> > >>> [ORCA DAT6600.out INFO] Creating attribute atomnos[]
>> > >>> [ORCA DAT6600.out INFO] Creating attribute natom: 9
>> > >>> [ORCA DAT6600.out INFO] Creating attribute nbasis: 90
>> > >>> [ORCA DAT6600.out INFO] Creating attribute charge: 0
>> > >>> [ORCA DAT6600.out INFO] Creating attribute mult: 1
>> > >>> [ORCA DAT6600.out INFO] Creating attribute scfvalues[]
>> > >>> Traceback (most recent call last):
>> > >>> File "<stdin>", line 1, in <module>
>> > >>> File
>> > >>> "/usr/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
>> > >>> line 221, in parse
>> > >>> self.extract(inputfile, line)
>> > >>> File
>> > >>> "/usr/lib/python2.7/dist-packages/cclib/parser/orcaparser.py",
>> > >>> line 90, in extract
>> > >>> assert line[1] == "Energy"
>> > >>> AssertionError
>> > >>>
>> > >>> I'm using cclib version 1.1 (the latest one). I attach the file
>> > >>> DAT6600.out.
>> > >>>
>> > >>> Is there a solution to this?
>> > >>>
>> > >>> Thanks in advance,
>> > >>>
>> > >>> --
>> > >>> Melchor Sánchez
>> > >>> PhD candidate
>> > >>> Institute of Advanced Chemistry of Catalonia
>> > >>> http://www.iqac.csic.es/qteor
>> > >>> IQAC - CSIC
>> > >>> Tel. +34 934006100 ext: 1307
>> > >>> Jordi Girona 18-26
>> > >>> 08034 Barcelona (Spain)
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> ------------------------------------------------------------------------------
>> > >>> Everyone hates slow websites. So do we.
>> > >>> Make your web apps faster with AppDynamics
>> > >>> Download AppDynamics Lite for free today:
>> > >>> http://p.sf.net/sfu/appdyn_d2d_feb
>> > >>> _______________________________________________
>> > >>> cclib-users mailing list
>> > >>> ccl...@li...
>> > >>> https://lists.sourceforge.net/lists/listinfo/cclib-users
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Melchor Sánchez
>> > >> PhD candidate
>> > >> Institute of Advanced Chemistry of Catalonia
>> > >> http://www.iqac.csic.es/qteor
>> > >> IQAC - CSIC
>> > >> Tel. +34 934006100 ext: 1307
>> > >> Jordi Girona 18-26
>> > >> 08034 Barcelona (Spain)
>> > >
>> > >
>> > >
>> > >
>> > > ------------------------------------------------------------------------------
>> > > Everyone hates slow websites. So do we.
>> > > Make your web apps faster with AppDynamics
>> > > Download AppDynamics Lite for free today:
>> > > http://p.sf.net/sfu/appdyn_d2d_feb
>> > > _______________________________________________
>> > > cclib-devel mailing list
>> > > ccl...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> > >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Everyone hates slow websites. So do we.
>> > Make your web apps faster with AppDynamics
>> > Download AppDynamics Lite for free today:
>> > http://p.sf.net/sfu/appdyn_d2d_feb
>> > _______________________________________________
>> > cclib-devel mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>> --
>> written by Karol M. Langner
>> Tue Feb 26 00:22:12 CET 2013
>
>
|
|
From: Adam T. <ate...@gm...> - 2013-07-27 19:42:41
|
A user of QMForge just alerted me to this problem, and I didn't see an
obvious fix in SVN. Before I started to work on it, I wanted to check-in
and ask a few things.
1) Will there be a minor bug fix release for cclib 1.1 (python2), or are we
only supporting fixes to the python3 branches now? If we make a change in
one branch, how difficult is it to merge that to another branch given the
python differences? Is it better to make two separate fixes? (QMForge is
still on python2, but I plan on moving to python3 in the coming months.)
2) Any thoughts on the best approach? Right now, there is a large commented
block detailing the format with the main parser code being if/elif
statements inside a while loop. A second commented block can be added
detailing the other format along with the associated parser code. Since
this would likely lead to somewhat messier code, there could instead be two
new functions (parse_scf_condensed_format and parse_scf_expanded_format)
with format commented at the beginning of the function. I'm leaning towards
the latter since our extract functions are becoming quite large (over 500
LOC for Orcaparser and 1000 LOC for Gaussian!!), and perhaps we should
consider creating functions for individual attributes.
Adam
On Mon, Feb 25, 2013 at 3:24 PM, Karol M. Langner
<kar...@gm...>wrote:
> I agree, and I'll leave this one to you guys. Have you checked if perhaps
> this is caused by a change between ORCA versions? I'm not really up-to-date
> on it's output.
>
> Karol
>
> On Feb 25 2013, Noel O'Boyle wrote:
> > I'm all for parsing it. Since this is fairly GaussSum-specific I'm
> > happy to do it if you can make sure these files are public domain. In
> > the meanwhile, you can point out to the user that he can comment out
> > the offending code.
> >
> > On 25 February 2013 17:31, Adam Tenderholt <ate...@gm...>
> wrote:
> > > CC: dev list
> > >
> > > Any thoughts on this? Should we try to parse the alternate SCF
> convergence
> > > info, or just change the code so it doesn't raise an exception?
> > >
> > > Adam
> > >
> > > On Mon, Feb 25, 2013 at 3:14 AM, msmqbm <ms...@ci...> wrote:
> > >>
> > >> Dear Adam,
> > >>
> > >> Thanks for your message. The reason for that strange output is the
> > >> NormalPrint keyword, it has nothing to do with the MRCI (you can
> delete that
> > >> part). Here I attach an output with a DFT calculation and a
> normalPrint
> > >> keyword, so that you can see the source of the problem.
> > >> It's ok if you make this input or output public.
> > >>
> > >> It would be nice that, even if the parser cannot read the whole file,
> it
> > >> didn't raise an exception, so that one could get at least the
> geometry, the
> > >> number of atoms or the information it has read so far.
> > >>
> > >> Cheers,
> > >>
> > >>
> > >> On 02/25/2013 01:24 AM, Adam Tenderholt wrote:
> > >>
> > >> Hi Melchor,
> > >>
> > >> Sorry for the delay. I've finally looked into your parse error. The
> > >> problem is the output from the SCF convergence. For instance, it your
> file,
> > >> it is:
> > >>
> > >> --------------
> > >> SCF ITERATIONS
> > >> --------------
> > >> *** Starting incremental Fock matrix formation ***
> > >>
> > >> ----------------------------
> > >> ! ITERATION 0 !
> > >> ----------------------------
> > >> Total Energy : -377.995940441385 Eh
> > >> Energy Change : -377.995940441385 Eh
> > >> MAX-DP : 0.104636203272
> > >> RMS-DP : 0.004511416837
> > >> Actual Damping : 0.7000
> > >> Actual Level Shift : 0.2500 Eh
> > >> Int. Num. El. : 43.99928165 (UP= 21.99964083 DN=
> > >> 21.99964083)
> > >> Exchange : -34.30375363
> > >> Correlation : -2.02696332
> > >>
> > >>
> > >> ----------------------------
> > >> ! ITERATION 1 !
> > >> ----------------------------
> > >> Total Energy : -378.158637308210 Eh
> > >> Energy Change : -0.162696866825 Eh
> > >> MAX-DP : 0.056981704567
> > >> RMS-DP : 0.002392614971
> > >> Actual Damping : 0.7000
> > >> Actual Level Shift : 0.2500 Eh
> > >> Int. Num. El. : 43.99902992 (UP= 21.99951496 DN=
> > >> 21.99951496)
> > >> Exchange : -34.01830967
> > >> Correlation : -2.01718102
> > >>
> > >> However, cclib is expecting the following:
> > >>
> > >> --------------
> > >> SCF ITERATIONS
> > >> --------------
> > >> ITER Energy Delta-E Max-DP RMS-DP [F,P]
> > >> Damp
> > >> *** Starting incremental Fock matrix formation ***
> > >> 0 -381.9867779344 0.000000000000 0.05707535 0.00425410
> 0.0807540
> > >> 0.7000
> > >> 1 -382.0079986969 -0.021220762511 0.02895905 0.00220039
> 0.0411442
> > >> 0.7000
> > >>
> > >> I tried to make sense of your input file, but I don't have any
> experience
> > >> with MRCI calculations with ORCA. Do you know if there was some
> option that
> > >> caused the SCF convergence to be printed differently? Or is this how
> the
> > >> convergence for all MRCI calculations is printed?
> > >>
> > >> Also, are you willing to place your logfile in the public domain? We
> would
> > >> like to include it with our other regression files.
> > >>
> > >> Thanks,
> > >>
> > >> Adam
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Feb 21, 2013 at 1:48 AM, msmqbm <ms...@ci...> wrote:
> > >>>
> > >>> Dear cclib developers,
> > >>> When trying to parse an Orca 2.9.0 output file I get the following
> error:
> > >>>
> > >>> >>> import cclib
> > >>> >>> f1= cclib.parser.ORCA("DAT6600.out")
> > >>> >>> data1= f1.parse()
> > >>> [ORCA DAT6600.out INFO] Creating attribute atomcoords[]
> > >>> [ORCA DAT6600.out INFO] Creating attribute atomnos[]
> > >>> [ORCA DAT6600.out INFO] Creating attribute natom: 9
> > >>> [ORCA DAT6600.out INFO] Creating attribute nbasis: 90
> > >>> [ORCA DAT6600.out INFO] Creating attribute charge: 0
> > >>> [ORCA DAT6600.out INFO] Creating attribute mult: 1
> > >>> [ORCA DAT6600.out INFO] Creating attribute scfvalues[]
> > >>> Traceback (most recent call last):
> > >>> File "<stdin>", line 1, in <module>
> > >>> File
> "/usr/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
> > >>> line 221, in parse
> > >>> self.extract(inputfile, line)
> > >>> File "/usr/lib/python2.7/dist-packages/cclib/parser/orcaparser.py",
> > >>> line 90, in extract
> > >>> assert line[1] == "Energy"
> > >>> AssertionError
> > >>>
> > >>> I'm using cclib version 1.1 (the latest one). I attach the file
> > >>> DAT6600.out.
> > >>>
> > >>> Is there a solution to this?
> > >>>
> > >>> Thanks in advance,
> > >>>
> > >>> --
> > >>> Melchor Sánchez
> > >>> PhD candidate
> > >>> Institute of Advanced Chemistry of Catalonia
> > >>> http://www.iqac.csic.es/qteor
> > >>> IQAC - CSIC
> > >>> Tel. +34 934006100 ext: 1307
> > >>> Jordi Girona 18-26
> > >>> 08034 Barcelona (Spain)
> > >>>
> > >>>
> > >>>
> > >>>
> ------------------------------------------------------------------------------
> > >>> Everyone hates slow websites. So do we.
> > >>> Make your web apps faster with AppDynamics
> > >>> Download AppDynamics Lite for free today:
> > >>> http://p.sf.net/sfu/appdyn_d2d_feb
> > >>> _______________________________________________
> > >>> cclib-users mailing list
> > >>> ccl...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/cclib-users
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Melchor Sánchez
> > >> PhD candidate
> > >> Institute of Advanced Chemistry of Catalonia
> > >> http://www.iqac.csic.es/qteor
> > >> IQAC - CSIC
> > >> Tel. +34 934006100 ext: 1307
> > >> Jordi Girona 18-26
> > >> 08034 Barcelona (Spain)
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Everyone hates slow websites. So do we.
> > > Make your web apps faster with AppDynamics
> > > Download AppDynamics Lite for free today:
> > > http://p.sf.net/sfu/appdyn_d2d_feb
> > > _______________________________________________
> > > cclib-devel mailing list
> > > ccl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_feb
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
> --
> written by Karol M. Langner
> Tue Feb 26 00:22:12 CET 2013
>
|
|
From: Noel O'B. <bao...@gm...> - 2013-03-01 09:00:48
|
No, it isn't. That's why we've had to wait so long. But it's time for Py3; Py3 came out in Dec 2008 and according to https://wiki.ubuntu.com/Python/3, Ubuntu 14.04 will ship only with Py3. - Noel On 1 March 2013 08:13, Karol M. Langner <kar...@gm...> wrote: > Is the trunk still compatible with python2? > > On Feb 28 2013, Noel O'Boyle wrote: >> Trunk is now Python3. The old Python2 trunk is at branches/python2, >> but please don't commit anything there. >> >> The tests pass as before...at least the regression tests. There may >> well be errors though so keep an eye out for anything fishy. >> >> - Noel >> >> On 28 February 2013 16:16, Noel O'Boyle <bao...@gm...> wrote: >> > No - on the Python 3 branch. Almost there. >> > >> > When done, I'll copy the existing trunk to a Python2 branch, and copy >> > Python3 to trunk. >> > >> > - Noel >> > >> > On 28 February 2013 15:58, Karol M. Langner <kar...@gm...> wrote: >> >> Are you working in trunk? >> >> >> >> On Feb 27 2013, Noel O'Boyle wrote: >> >>> Hi there, >> >>> >> >>> Just to let you guys know that I'm currently working my way through >> >>> the parsers for the Python 3 port. It's taking longer than I expected >> >>> but I hope to have it done by next week. >> >>> >> >>> - Noel >> >>> >> >>> ------------------------------------------------------------------------------ >> >>> Everyone hates slow websites. So do we. >> >>> Make your web apps faster with AppDynamics >> >>> Download AppDynamics Lite for free today: >> >>> http://p.sf.net/sfu/appdyn_d2d_feb >> >>> _______________________________________________ >> >>> cclib-devel mailing list >> >>> ccl...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> >> >> >> -- >> >> written by Karol M. Langner >> >> Thu Feb 28 16:58:29 CET 2013 > > -- > written by Karol M. Langner > Fri Mar 1 09:13:24 CET 2013 |
|
From: Karol M. L. <kar...@gm...> - 2013-03-01 08:14:53
|
Is the trunk still compatible with python2? On Feb 28 2013, Noel O'Boyle wrote: > Trunk is now Python3. The old Python2 trunk is at branches/python2, > but please don't commit anything there. > > The tests pass as before...at least the regression tests. There may > well be errors though so keep an eye out for anything fishy. > > - Noel > > On 28 February 2013 16:16, Noel O'Boyle <bao...@gm...> wrote: > > No - on the Python 3 branch. Almost there. > > > > When done, I'll copy the existing trunk to a Python2 branch, and copy > > Python3 to trunk. > > > > - Noel > > > > On 28 February 2013 15:58, Karol M. Langner <kar...@gm...> wrote: > >> Are you working in trunk? > >> > >> On Feb 27 2013, Noel O'Boyle wrote: > >>> Hi there, > >>> > >>> Just to let you guys know that I'm currently working my way through > >>> the parsers for the Python 3 port. It's taking longer than I expected > >>> but I hope to have it done by next week. > >>> > >>> - Noel > >>> > >>> ------------------------------------------------------------------------------ > >>> Everyone hates slow websites. So do we. > >>> Make your web apps faster with AppDynamics > >>> Download AppDynamics Lite for free today: > >>> http://p.sf.net/sfu/appdyn_d2d_feb > >>> _______________________________________________ > >>> cclib-devel mailing list > >>> ccl...@li... > >>> https://lists.sourceforge.net/lists/listinfo/cclib-devel > >> > >> -- > >> written by Karol M. Langner > >> Thu Feb 28 16:58:29 CET 2013 -- written by Karol M. Langner Fri Mar 1 09:13:24 CET 2013 |
|
From: Karol M. L. <kar...@gm...> - 2013-03-01 00:44:44
|
Are you working in trunk? On Feb 27 2013, Noel O'Boyle wrote: > Hi there, > > Just to let you guys know that I'm currently working my way through > the parsers for the Python 3 port. It's taking longer than I expected > but I hope to have it done by next week. > > - Noel > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel -- written by Karol M. Langner Thu Feb 28 16:58:29 CET 2013 |
|
From: Noel O'B. <bao...@gm...> - 2013-02-28 22:27:13
|
Trunk is now Python3. The old Python2 trunk is at branches/python2, but please don't commit anything there. The tests pass as before...at least the regression tests. There may well be errors though so keep an eye out for anything fishy. - Noel On 28 February 2013 16:16, Noel O'Boyle <bao...@gm...> wrote: > No - on the Python 3 branch. Almost there. > > When done, I'll copy the existing trunk to a Python2 branch, and copy > Python3 to trunk. > > - Noel > > On 28 February 2013 15:58, Karol M. Langner <kar...@gm...> wrote: >> Are you working in trunk? >> >> On Feb 27 2013, Noel O'Boyle wrote: >>> Hi there, >>> >>> Just to let you guys know that I'm currently working my way through >>> the parsers for the Python 3 port. It's taking longer than I expected >>> but I hope to have it done by next week. >>> >>> - Noel >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> _______________________________________________ >>> cclib-devel mailing list >>> ccl...@li... >>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> >> -- >> written by Karol M. Langner >> Thu Feb 28 16:58:29 CET 2013 |
17 messages has been excluded from this view by a project administrator.
