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: Pavel S. <pav...@gm...> - 2011-05-10 19:59:51
|
The latest version of cclib (svn).
Gaussian 09 Single point output file works just fine, but same file from
g03 doesn't.
I console i see
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/qmforge/qmforge.py",
line 250, in fileOpen
self.open(str(filename))
File "/usr/local/lib/python2.7/dist-packages/qmforge/qmforge.py",
line 150, in open
data = parser.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/gaussianparser.py",
line 933, in extract
temp.append(float(part[j:j+10]))
ValueError: could not convert string to float: (B2)--O
If i change "(B2)--O" to "O" the it works too.
Unfortunately, molecule very big, so i can't do this for all orbitals :).
Best wishes,
PS.
--
Pavlo V. Solntsev
pavlo.solntsev at gmail.com
|
|
From: Karol M. L. <kar...@gm...> - 2011-04-13 09:53:13
|
Aye. On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote: > Aye. > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <bao...@gm...> wrote: > > All in favour say "aye". Aye. > > > > On 12 April 2011 10:03, Karol M. Langner <kar...@gm...> wrote: > >> Noel, > >> > >> While working on packaging cclib I got this comment from Michael Bank. Is there > >> any reason not to change the license to the current one "or later"? > >> > >> - Karol > >> > >> ----- Forwarded message from Michael Banck <mb...@de...> ----- > >> > >> ... > >> > >> ** As an aside, you might want to contact the upstream authors to > >> relicense to "LGPL v2.1 or later", or else they might run into > >> license incompatibilites further down the road (at least Noel should > >> be aware of that, as OpenBabel keeps suffering from that) > >> > >> ... > >> > >> ----- End forwarded message ----- > >> > >> -- > >> written by Karol M. Langner > >> Tue Apr 12 11:00:31 CEST 2011 > >> > > > > ------------------------------------------------------------------------------ > > Forrester Wave Report - Recovery time is now measured in hours and minutes > > not days. Key insights are discussed in the 2010 Forrester Wave Report as > > part of an in-depth evaluation of disaster recovery service providers. > > Forrester found the best-in-class provider in terms of services and vision. > > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > > _______________________________________________ > > cclib-devel mailing list > > ccl...@li... > > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > -- written by Karol Langner Wed Apr 13 11:52:52 CEST 2011 |
|
From: Adam T. <ate...@gm...> - 2011-04-12 22:57:07
|
Aye. On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <bao...@gm...> wrote: > All in favour say "aye". Aye. > > On 12 April 2011 10:03, Karol M. Langner <kar...@gm...> wrote: >> Noel, >> >> While working on packaging cclib I got this comment from Michael Bank. Is there >> any reason not to change the license to the current one "or later"? >> >> - Karol >> >> ----- Forwarded message from Michael Banck <mb...@de...> ----- >> >> ... >> >> ** As an aside, you might want to contact the upstream authors to >> relicense to "LGPL v2.1 or later", or else they might run into >> license incompatibilites further down the road (at least Noel should >> be aware of that, as OpenBabel keeps suffering from that) >> >> ... >> >> ----- End forwarded message ----- >> >> -- >> written by Karol M. Langner >> Tue Apr 12 11:00:31 CEST 2011 >> > > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Noel O'B. <bao...@gm...> - 2011-04-12 09:26:14
|
All in favour say "aye". Aye. On 12 April 2011 10:03, Karol M. Langner <kar...@gm...> wrote: > Noel, > > While working on packaging cclib I got this comment from Michael Bank. Is there > any reason not to change the license to the current one "or later"? > > - Karol > > ----- Forwarded message from Michael Banck <mb...@de...> ----- > > ... > > ** As an aside, you might want to contact the upstream authors to > relicense to "LGPL v2.1 or later", or else they might run into > license incompatibilites further down the road (at least Noel should > be aware of that, as OpenBabel keeps suffering from that) > > ... > > ----- End forwarded message ----- > > -- > written by Karol M. Langner > Tue Apr 12 11:00:31 CEST 2011 > |
|
From: Karol M. L. <kar...@gm...> - 2011-04-12 09:03:31
|
Noel, While working on packaging cclib I got this comment from Michael Bank. Is there any reason not to change the license to the current one "or later"? - Karol ----- Forwarded message from Michael Banck <mb...@de...> ----- ... ** As an aside, you might want to contact the upstream authors to relicense to "LGPL v2.1 or later", or else they might run into license incompatibilites further down the road (at least Noel should be aware of that, as OpenBabel keeps suffering from that) ... ----- End forwarded message ----- -- written by Karol M. Langner Tue Apr 12 11:00:31 CEST 2011 |
|
From: Adam T. <ate...@gm...> - 2011-04-07 16:50:30
|
Hi Xaver, Thanks for those contributions. I've added them to SVN trunk/data/GAMESS in a basicGAMESS2010 subdirectory. Adam On Apr 7, 2011, at 5:09 AM, Xaver W. wrote: > Hi Adam, > > attached find new GAMESS test files. GAMESS does not use a version number but a > date, so I called it "gamess2010-10-01" indicating version "01. Oct 2010" > (which is the current version). > Mind that the frequency and tddft calcs seem to break the parser, I hope this > is not a mistake of mine but on the parser side. > Of course I submit all testfiles I send you to the public domain. > > Regards, > Xaver > > > > > Am Freitag 01 April 2011, 22:45:21 schrieben Sie: >> Hi Xaver, >> >> You can either email me the files directly or put them in a zip file on >> some website and send me the link. And cclib tries to support as many >> versions of a package, so if you have ORCA 2.8 files, we'll add those >> alongside our ORCA 2.6 files. >> >> Thanks, >> >> Adam >> >> On Apr 1, 2011, at 2:16 AM, Xaver W. wrote: >>> Hi Adam, >>> >>> well I'm using ORCA 2.8 here where sto-3g seems implemented. As we're on >>> that, what is the cclib policy about different "backend" versions? It >>> wouldn't be too much work to prepare 2.8 test files as well, if that >>> helps. >>> >>> Whats especially nice about NWChem is that it is open-source (in contrast >>> to nearly anything else except MPQC)... And no, I don't expect a >>> full-blown parser within days ;-) , I just thought you might like to >>> have them in your sleeve for the future. >>> Where should I send the test files? To you, the cclib list, some >>> sourceforge tracker...? >>> >>> Regards, >>> Xaver >>> >>> Am Donnerstag 31 März 2011, 19:59:36 schrieb Adam Tenderholt: >>>> Hi Xaver, >>>> >>>> Thanks for contacting us about the ORCA bug. I'm the one who started >>>> that parser (I think), and if I remember correctly, and based on the >>>> 2.6.x manual, STO-3G isn't defined; 3-21G is the next improvement. >>>> >>>> As far as the NWChem files, I would be interested in the test files. >>>> It's not a package I'm using at the moment, but I've thought about >>>> trying it out for the constrained (?) DFT methodology. I can't >>>> guarantee that there will be a rigorous parser in the near future, but >>>> I could probably hack together basic support once I can find a few >>>> hours to focus on that. >>>> >>>> Thanks again, >>>> >>>> Adam >>>> >>>> On Mar 28, 2011, at 7:46 AM, Xaver W. wrote: >>>>> Hi, >>>>> >>>>> I'm currently testing the open-source quantum chemistry application >>>>> NWChem (http://www.nwchem-sw.org). As I'm trying stuff anyway, I could >>>>> prepare cclib regression test files with it in case you want to >>>>> eventually support NWChem. Are you interested? >>>>> >>>>> Oh, and one more thing: In your wiki I read that test files should be >>>>> "b3lyp/sto-3g". It seems however that the current ORCA test files were >>>>> made with 3-21G (see e.g. >>>>> http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/data/ORCA/basicORCA >>>>> 2. 6/dvb_gopt.inp?revision=937&view=markup ). Have I misunderstood >>>>> something? >>>>> >>>>> Regards, >>>>> Xaver >>>>> >>>>> >>>>> ----------------------------------------------------------------------- >>>>> -- ----- Enable your software for Intel(R) Active Management Technology >>>>> to meet the growing manageability and security demands of your >>>>> customers. Businesses are taking advantage of Intel(R) vPro (TM) >>>>> technology - will your software be a part of the solution? Download >>>>> the Intel(R) Manageability Checker today! >>>>> http://p.sf.net/sfu/intel-dev2devmar >>>>> _______________________________________________ >>>>> cclib-devel mailing list >>>>> ccl...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel > > <dvb_cclib-tests_gamess2010-10-01.7z> |
|
From: Adam T. <ate...@gm...> - 2011-04-04 16:45:43
|
Hi Xaver, Thanks for the files. I've added them to an appropriate subdirectory in SVN trunk. My versions of ccget and ccopen (turbomole branch) don't open them, although calling the ORCA parser directly works for the few files I tested. Adam On Apr 4, 2011, at 8:32 AM, Xaver W. wrote: > Hi, > > attached find the testfiles for ORCA 2.8. I used slightly different parameters > than the ones in the 2.6 testfiles wherever I found it appropriate (esp. > "UseSym" keyword) Also, I just used an unoptimized GaussView input structure > and the sto-3g basis. None seems to break the 1.0.1 parser. > I didn't send a copy of this email to the cclib mailing list because it has a > 80 (?) kilobytes limit - tell me if I should send it there still, with or > without attachments. > > Regards, > Xaver > > > > Am Freitag 01 April 2011, 22:45:21 schrieben Sie: >> Hi Xaver, >> >> You can either email me the files directly or put them in a zip file on >> some website and send me the link. And cclib tries to support as many >> versions of a package, so if you have ORCA 2.8 files, we'll add those >> alongside our ORCA 2.6 files. >> >> Thanks, >> >> Adam >> >> On Apr 1, 2011, at 2:16 AM, Xaver W. wrote: >>> Hi Adam, >>> >>> well I'm using ORCA 2.8 here where sto-3g seems implemented. As we're on >>> that, what is the cclib policy about different "backend" versions? It >>> wouldn't be too much work to prepare 2.8 test files as well, if that >>> helps. >>> >>> Whats especially nice about NWChem is that it is open-source (in contrast >>> to nearly anything else except MPQC)... And no, I don't expect a >>> full-blown parser within days ;-) , I just thought you might like to >>> have them in your sleeve for the future. >>> Where should I send the test files? To you, the cclib list, some >>> sourceforge tracker...? >>> >>> Regards, >>> Xaver >>> >>> Am Donnerstag 31 März 2011, 19:59:36 schrieb Adam Tenderholt: >>>> Hi Xaver, >>>> >>>> Thanks for contacting us about the ORCA bug. I'm the one who started >>>> that parser (I think), and if I remember correctly, and based on the >>>> 2.6.x manual, STO-3G isn't defined; 3-21G is the next improvement. >>>> >>>> As far as the NWChem files, I would be interested in the test files. >>>> It's not a package I'm using at the moment, but I've thought about >>>> trying it out for the constrained (?) DFT methodology. I can't >>>> guarantee that there will be a rigorous parser in the near future, but >>>> I could probably hack together basic support once I can find a few >>>> hours to focus on that. >>>> >>>> Thanks again, >>>> >>>> Adam >>>> >>>> On Mar 28, 2011, at 7:46 AM, Xaver W. wrote: >>>>> Hi, >>>>> >>>>> I'm currently testing the open-source quantum chemistry application >>>>> NWChem (http://www.nwchem-sw.org). As I'm trying stuff anyway, I could >>>>> prepare cclib regression test files with it in case you want to >>>>> eventually support NWChem. Are you interested? >>>>> >>>>> Oh, and one more thing: In your wiki I read that test files should be >>>>> "b3lyp/sto-3g". It seems however that the current ORCA test files were >>>>> made with 3-21G (see e.g. >>>>> http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/data/ORCA/basicORCA >>>>> 2. 6/dvb_gopt.inp?revision=937&view=markup ). Have I misunderstood >>>>> something? >>>>> >>>>> Regards, >>>>> Xaver >>>>> >>>>> >>>>> ----------------------------------------------------------------------- >>>>> -- ----- Enable your software for Intel(R) Active Management Technology >>>>> to meet the growing manageability and security demands of your >>>>> customers. Businesses are taking advantage of Intel(R) vPro (TM) >>>>> technology - will your software be a part of the solution? Download >>>>> the Intel(R) Manageability Checker today! >>>>> http://p.sf.net/sfu/intel-dev2devmar >>>>> _______________________________________________ >>>>> cclib-devel mailing list >>>>> ccl...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel > > <dvb_cclib-tests_orca28.7z> |
|
From: Benjamin S. <bs...@un...> - 2011-04-03 21:54:04
|
Hi all, Finally got the basis set parser working at a beginning level. I was having issues with instance vs. class variables and this get/setattr business (this OO stuff takes some getting used to...). Some current limitations: - How basis sets are attached to a particular atom. Right now they are simply associated by element, so if there are different basis sets on atoms of the same element it wont catch that. - Obviously, this only works with ORCA right now. I'll work on a G03 parser soon (and ADF one of these days, but I'll need to add some sort of STO vs. GTO identifier), if anyone can send me a G09 output file with basis set information that would be great. - Documentation is spotty to say the least. Attached are: patches for orcaparser.py and data.py basis.py which contains the classes for the basis set handling a simple ORCA output file (me.out) Parsing the me.out will give the basisset attribute. The data structure is a bit complicated, any thoughts on simplifying it will be greatly appreciated (I looked through avogadro a bit, the organization here is somewhat similar). Here are some examples for navigating basisset. Example 1: the gaussian primitives for the second shell of the carbon atom (2nd atom). Primitives are listed as (coefficient, exponent). In [2]: data.basisset.atoms[1][1].shells[3].primitives Out[2]: [(0.056888332, 9.4680970621), (0.3129405934, 2.0103545142), (0.7606501651, 0.5477100471)] Example 2: angular momentum type (p) of the above shell. In [3]: data.basisset.atoms[1][1].shells[3].angular_momentum Out[3]: 'p' Example 3: element of atom 2. In [4]: data.basisset.atoms[1][0] Out[4]: 'C' Best, Ben Stein |
|
From: Noel O'B. <bao...@gm...> - 2011-04-03 21:18:15
|
On 3 April 2011 20:20, Karol M. Langner <kar...@gm...> wrote: > On Sat, Apr 02, 2011 at 06:47:42PM +0100, Noel O'Boyle wrote: >> regression.py now passes on the Python 3 branch. The biggest change is >> use of "next(inputfile)" instead of "inputfile.next()", and integer >> division (if desired) needs to be specified explicitly with "//". >> >> How do you guys feel about transitioning over to this branch in the >> next few months? Py3 came out in Dec 2008, and we are going to have to >> make the move at some point. I don't really want to have to maintain >> two releases of cclib, so let me know what you think. >> >> - Noel >> >> On 1 April 2011 13:35, Noel O'Boyle <bao...@gm...> wrote: >> > Now that numpy has been ported to Py3, I've created a branch for >> > Python 3. I would anticipate that a release of cclib in 12 months time >> > would be based on Python 3. >> > >> > - Noel > > I'm for it. I don't think we heavily rely on any obsolete elements > of the language. The minor things (like the ones you mention) will > still work for 2.6 and later, so we can bump up the suggested > dependencies in the INSTALL file. We can also try to import > from __future__ to support older versions. The differences are a bit greater than I implied maybe (e.g. all the import statements have changed). It won't be possible to run the Python 3 branch with a version of Python 2 (or not without a lot of work). - Noel |
|
From: Xaver W. <xav...@we...> - 2011-04-03 20:34:22
|
Hi, glad to be of help. The 5 standard cclib tests of NWChem 6.0 are in the attached file (hope you can handle 7zip). For every test there is an input (.nw) and an output (.out) file - I think the rest is self-explanatory. As for the ORCA 2.8 test files, I hope to be able to prepare them in the next days and send them to you too. Regards, Xaver Am 01.04.2011 22:45, schrieb Adam Tenderholt: > Hi Xaver, > > You can either email me the files directly or put them in a zip file on some website and send me the link. And cclib tries to support as many versions of a package, so if you have ORCA 2.8 files, we'll add those alongside our ORCA 2.6 files. > > Thanks, > > Adam > > On Apr 1, 2011, at 2:16 AM, Xaver W. wrote: > >> Hi Adam, >> >> well I'm using ORCA 2.8 here where sto-3g seems implemented. As we're on that, >> what is the cclib policy about different "backend" versions? It wouldn't be too >> much work to prepare 2.8 test files as well, if that helps. >> >> Whats especially nice about NWChem is that it is open-source (in contrast to >> nearly anything else except MPQC)... And no, I don't expect a full-blown >> parser within days ;-) , I just thought you might like to have them in your >> sleeve for the future. >> Where should I send the test files? To you, the cclib list, some sourceforge >> tracker...? >> >> Regards, >> Xaver >> >> >> >> Am Donnerstag 31 März 2011, 19:59:36 schrieb Adam Tenderholt: >>> Hi Xaver, >>> >>> Thanks for contacting us about the ORCA bug. I'm the one who started that >>> parser (I think), and if I remember correctly, and based on the 2.6.x >>> manual, STO-3G isn't defined; 3-21G is the next improvement. >>> >>> As far as the NWChem files, I would be interested in the test files. It's >>> not a package I'm using at the moment, but I've thought about trying it >>> out for the constrained (?) DFT methodology. I can't guarantee that there >>> will be a rigorous parser in the near future, but I could probably hack >>> together basic support once I can find a few hours to focus on that. >>> >>> Thanks again, >>> >>> Adam >>> >>> On Mar 28, 2011, at 7:46 AM, Xaver W. wrote: >>>> Hi, >>>> >>>> I'm currently testing the open-source quantum chemistry application >>>> NWChem (http://www.nwchem-sw.org). As I'm trying stuff anyway, I could >>>> prepare cclib regression test files with it in case you want to >>>> eventually support NWChem. Are you interested? >>>> >>>> Oh, and one more thing: In your wiki I read that test files should be >>>> "b3lyp/sto-3g". It seems however that the current ORCA test files were >>>> made with 3-21G (see e.g. >>>> http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/data/ORCA/basicORCA2. >>>> 6/dvb_gopt.inp?revision=937&view=markup ). Have I misunderstood >>>> something? >>>> >>>> Regards, >>>> Xaver >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> ----- Enable your software for Intel(R) Active Management Technology to >>>> meet the growing manageability and security demands of your customers. >>>> Businesses are taking advantage of Intel(R) vPro (TM) technology - will >>>> your software be a part of the solution? Download the Intel(R) >>>> Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar >>>> _______________________________________________ >>>> cclib-devel mailing list >>>> ccl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol M. L. <kar...@gm...> - 2011-04-03 19:20:52
|
On Sat, Apr 02, 2011 at 06:47:42PM +0100, Noel O'Boyle wrote: > regression.py now passes on the Python 3 branch. The biggest change is > use of "next(inputfile)" instead of "inputfile.next()", and integer > division (if desired) needs to be specified explicitly with "//". > > How do you guys feel about transitioning over to this branch in the > next few months? Py3 came out in Dec 2008, and we are going to have to > make the move at some point. I don't really want to have to maintain > two releases of cclib, so let me know what you think. > > - Noel > > On 1 April 2011 13:35, Noel O'Boyle <bao...@gm...> wrote: > > Now that numpy has been ported to Py3, I've created a branch for > > Python 3. I would anticipate that a release of cclib in 12 months time > > would be based on Python 3. > > > > - Noel I'm for it. I don't think we heavily rely on any obsolete elements of the language. The minor things (like the ones you mention) will still work for 2.6 and later, so we can bump up the suggested dependencies in the INSTALL file. We can also try to import from __future__ to support older versions. - Karol -- written by Karol Langner Sun Apr 3 21:11:14 CEST 2011 |
|
From: Noel O'B. <bao...@gm...> - 2011-04-02 17:47:48
|
regression.py now passes on the Python 3 branch. The biggest change is use of "next(inputfile)" instead of "inputfile.next()", and integer division (if desired) needs to be specified explicitly with "//". How do you guys feel about transitioning over to this branch in the next few months? Py3 came out in Dec 2008, and we are going to have to make the move at some point. I don't really want to have to maintain two releases of cclib, so let me know what you think. - Noel On 1 April 2011 13:35, Noel O'Boyle <bao...@gm...> wrote: > Now that numpy has been ported to Py3, I've created a branch for > Python 3. I would anticipate that a release of cclib in 12 months time > would be based on Python 3. > > - Noel > |
|
From: Adam T. <ate...@gm...> - 2011-04-01 20:45:32
|
Hi Xaver, You can either email me the files directly or put them in a zip file on some website and send me the link. And cclib tries to support as many versions of a package, so if you have ORCA 2.8 files, we'll add those alongside our ORCA 2.6 files. Thanks, Adam On Apr 1, 2011, at 2:16 AM, Xaver W. wrote: > Hi Adam, > > well I'm using ORCA 2.8 here where sto-3g seems implemented. As we're on that, > what is the cclib policy about different "backend" versions? It wouldn't be too > much work to prepare 2.8 test files as well, if that helps. > > Whats especially nice about NWChem is that it is open-source (in contrast to > nearly anything else except MPQC)... And no, I don't expect a full-blown > parser within days ;-) , I just thought you might like to have them in your > sleeve for the future. > Where should I send the test files? To you, the cclib list, some sourceforge > tracker...? > > Regards, > Xaver > > > > Am Donnerstag 31 März 2011, 19:59:36 schrieb Adam Tenderholt: >> Hi Xaver, >> >> Thanks for contacting us about the ORCA bug. I'm the one who started that >> parser (I think), and if I remember correctly, and based on the 2.6.x >> manual, STO-3G isn't defined; 3-21G is the next improvement. >> >> As far as the NWChem files, I would be interested in the test files. It's >> not a package I'm using at the moment, but I've thought about trying it >> out for the constrained (?) DFT methodology. I can't guarantee that there >> will be a rigorous parser in the near future, but I could probably hack >> together basic support once I can find a few hours to focus on that. >> >> Thanks again, >> >> Adam >> >> On Mar 28, 2011, at 7:46 AM, Xaver W. wrote: >>> Hi, >>> >>> I'm currently testing the open-source quantum chemistry application >>> NWChem (http://www.nwchem-sw.org). As I'm trying stuff anyway, I could >>> prepare cclib regression test files with it in case you want to >>> eventually support NWChem. Are you interested? >>> >>> Oh, and one more thing: In your wiki I read that test files should be >>> "b3lyp/sto-3g". It seems however that the current ORCA test files were >>> made with 3-21G (see e.g. >>> http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/data/ORCA/basicORCA2. >>> 6/dvb_gopt.inp?revision=937&view=markup ). Have I misunderstood >>> something? >>> >>> Regards, >>> Xaver >>> >>> >>> ------------------------------------------------------------------------- >>> ----- Enable your software for Intel(R) Active Management Technology to >>> meet the growing manageability and security demands of your customers. >>> Businesses are taking advantage of Intel(R) vPro (TM) technology - will >>> your software be a part of the solution? Download the Intel(R) >>> Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar >>> _______________________________________________ >>> cclib-devel mailing list >>> ccl...@li... >>> https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Noel O'B. <bao...@gm...> - 2011-04-01 12:35:33
|
Now that numpy has been ported to Py3, I've created a branch for Python 3. I would anticipate that a release of cclib in 12 months time would be based on Python 3. - Noel |
|
From: Xaver W. <xav...@we...> - 2011-04-01 09:17:00
|
Hi Adam, well I'm using ORCA 2.8 here where sto-3g seems implemented. As we're on that, what is the cclib policy about different "backend" versions? It wouldn't be too much work to prepare 2.8 test files as well, if that helps. Whats especially nice about NWChem is that it is open-source (in contrast to nearly anything else except MPQC)... And no, I don't expect a full-blown parser within days ;-) , I just thought you might like to have them in your sleeve for the future. Where should I send the test files? To you, the cclib list, some sourceforge tracker...? Regards, Xaver Am Donnerstag 31 März 2011, 19:59:36 schrieb Adam Tenderholt: > Hi Xaver, > > Thanks for contacting us about the ORCA bug. I'm the one who started that > parser (I think), and if I remember correctly, and based on the 2.6.x > manual, STO-3G isn't defined; 3-21G is the next improvement. > > As far as the NWChem files, I would be interested in the test files. It's > not a package I'm using at the moment, but I've thought about trying it > out for the constrained (?) DFT methodology. I can't guarantee that there > will be a rigorous parser in the near future, but I could probably hack > together basic support once I can find a few hours to focus on that. > > Thanks again, > > Adam > > On Mar 28, 2011, at 7:46 AM, Xaver W. wrote: > > Hi, > > > > I'm currently testing the open-source quantum chemistry application > > NWChem (http://www.nwchem-sw.org). As I'm trying stuff anyway, I could > > prepare cclib regression test files with it in case you want to > > eventually support NWChem. Are you interested? > > > > Oh, and one more thing: In your wiki I read that test files should be > > "b3lyp/sto-3g". It seems however that the current ORCA test files were > > made with 3-21G (see e.g. > > http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/data/ORCA/basicORCA2. > > 6/dvb_gopt.inp?revision=937&view=markup ). Have I misunderstood > > something? > > > > Regards, > > Xaver > > > > > > ------------------------------------------------------------------------- > > ----- Enable your software for Intel(R) Active Management Technology to > > meet the growing manageability and security demands of your customers. > > Businesses are taking advantage of Intel(R) vPro (TM) technology - will > > your software be a part of the solution? Download the Intel(R) > > Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar > > _______________________________________________ > > cclib-devel mailing list > > ccl...@li... > > https://lists.sourceforge.net/lists/listinfo/cclib-devel |
|
From: Adam T. <ate...@gm...> - 2011-03-31 18:00:01
|
Hi Xaver, Thanks for contacting us about the ORCA bug. I'm the one who started that parser (I think), and if I remember correctly, and based on the 2.6.x manual, STO-3G isn't defined; 3-21G is the next improvement. As far as the NWChem files, I would be interested in the test files. It's not a package I'm using at the moment, but I've thought about trying it out for the constrained (?) DFT methodology. I can't guarantee that there will be a rigorous parser in the near future, but I could probably hack together basic support once I can find a few hours to focus on that. Thanks again, Adam On Mar 28, 2011, at 7:46 AM, Xaver W. wrote: > Hi, > > I'm currently testing the open-source quantum chemistry application NWChem > (http://www.nwchem-sw.org). As I'm trying stuff anyway, I could prepare cclib > regression test files with it in case you want to eventually support NWChem. > Are you interested? > > Oh, and one more thing: In your wiki I read that test files should be > "b3lyp/sto-3g". It seems however that the current ORCA test files were made > with 3-21G (see e.g. > http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/data/ORCA/basicORCA2.6/dvb_gopt.inp?revision=937&view=markup > ). Have I misunderstood something? > > Regards, > Xaver > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel |
|
From: Xaver W. <xav...@we...> - 2011-03-28 14:46:21
|
Hi, I'm currently testing the open-source quantum chemistry application NWChem (http://www.nwchem-sw.org). As I'm trying stuff anyway, I could prepare cclib regression test files with it in case you want to eventually support NWChem. Are you interested? Oh, and one more thing: In your wiki I read that test files should be "b3lyp/sto-3g". It seems however that the current ORCA test files were made with 3-21G (see e.g. http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/data/ORCA/basicORCA2.6/dvb_gopt.inp?revision=937&view=markup ). Have I misunderstood something? Regards, Xaver |
|
From: Karol M. L. <kar...@gm...> - 2011-03-28 10:47:58
|
Dear Xaver, Looks like an easy one to fix. But could you provide us with a log file that recreates this bug, in the Public Domain? Cheers, Karol On Mon, Mar 28, 2011 at 12:38:11PM +0200, Xaver W. wrote: > Hi, > in case of dummy atoms, orcaparser can't read the atoms. Consider: > > >>> cclibdata = cfile.parse() > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "cclib/parser/logfileparser.py", line 221, in parse > self.extract(inputfile, line) > File "cclib/parser/orcaparser.py", line 196, in extract > atomnos.append(self.table.number[broken[0]]) > KeyError: '-' > > I think the lines which orcaparser is trying to read are (sth like): > > 138 --------------------------------- > 139 CARTESIAN COORDINATES (ANGSTROEM) > 140 --------------------------------- > 141 Fe 0.000000 0.000000 0.000660 > 142 O -0.592830 1.741600 -0.806850 > 143 O 0.592830 -1.741600 -0.806850 > 144 C 0.000000 2.934410 -0.176690 > 145 C 0.000000 -2.934410 -0.176690 > 146 H -0.018170 3.765540 -0.884740 > 147 H 0.018170 -3.765540 -0.884740 > 148 C 1.428890 2.563280 0.175900 > 149 C -1.428890 -2.563280 0.175900 > 150 H 2.069080 2.492180 -0.707270 > 151 H -2.069080 -2.492180 -0.707270 > 152 O 1.366300 1.233000 0.806640 > 153 O -1.366300 -1.233000 0.806640 > 154 H -0.593730 3.184280 0.706460 > 155 H 0.593730 -3.184280 0.706460 > 156 H 1.849370 3.280780 0.883620 > 157 H -1.849370 -3.280780 0.883620 > 158 H -1.264360 1.976320 -1.465620 > 159 H 1.264360 -1.976320 -1.465620 > 160 H 2.067340 1.111470 1.465270 > 161 H -2.067340 -1.111470 1.465270 > 162 - 0.408688 1.481601 0.017975 > 163 - -0.442210 -1.472899 0.045583 > > (line numbers by "vi", ignore) > > The two last lines are the coordinates of two dummy atoms. They turn up as > "DA" in the input, but apparently as " - " in the coordinate blocks of the > output. > > Drop me a line if you need more info. > > Regards, > Xaver W. > (for ccwatcher.sourceforge.net) > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel -- written by Karol M. Langner Mon Mar 28 12:46:01 CEST 2011 |
|
From: Xaver W. <xav...@we...> - 2011-03-28 10:38:17
|
Hi,
in case of dummy atoms, orcaparser can't read the atoms. Consider:
>>> cclibdata = cfile.parse()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "cclib/parser/logfileparser.py", line 221, in parse
self.extract(inputfile, line)
File "cclib/parser/orcaparser.py", line 196, in extract
atomnos.append(self.table.number[broken[0]])
KeyError: '-'
I think the lines which orcaparser is trying to read are (sth like):
138 ---------------------------------
139 CARTESIAN COORDINATES (ANGSTROEM)
140 ---------------------------------
141 Fe 0.000000 0.000000 0.000660
142 O -0.592830 1.741600 -0.806850
143 O 0.592830 -1.741600 -0.806850
144 C 0.000000 2.934410 -0.176690
145 C 0.000000 -2.934410 -0.176690
146 H -0.018170 3.765540 -0.884740
147 H 0.018170 -3.765540 -0.884740
148 C 1.428890 2.563280 0.175900
149 C -1.428890 -2.563280 0.175900
150 H 2.069080 2.492180 -0.707270
151 H -2.069080 -2.492180 -0.707270
152 O 1.366300 1.233000 0.806640
153 O -1.366300 -1.233000 0.806640
154 H -0.593730 3.184280 0.706460
155 H 0.593730 -3.184280 0.706460
156 H 1.849370 3.280780 0.883620
157 H -1.849370 -3.280780 0.883620
158 H -1.264360 1.976320 -1.465620
159 H 1.264360 -1.976320 -1.465620
160 H 2.067340 1.111470 1.465270
161 H -2.067340 -1.111470 1.465270
162 - 0.408688 1.481601 0.017975
163 - -0.442210 -1.472899 0.045583
(line numbers by "vi", ignore)
The two last lines are the coordinates of two dummy atoms. They turn up as
"DA" in the input, but apparently as " - " in the coordinate blocks of the
output.
Drop me a line if you need more info.
Regards,
Xaver W.
(for ccwatcher.sourceforge.net)
|
|
From: Noel O'B. <bao...@gm...> - 2011-03-26 17:01:18
|
If you really want, but can you check that it installs correctly from a source distribution made after running manifest.py? - Noel On 26 March 2011 16:45, Karol M. Langner <kar...@gm...> wrote: > Noel, > > I think it would be more reasonable to NOT install them in setup.py > by default. I can take it upon myself to change this by adding an > option. Is --install-tests is OK? > > On Sat, Mar 26, 2011 at 04:01:36PM +0000, Noel O'Boyle wrote: >> There's no need for them to be packaged certainly. But I see no real >> problem with installing them (and everytime I try to change the >> installer, I break something!). >> >> - Noel >> >> On 26 March 2011 15:33, Karol M. Langner <kar...@gm...> wrote: >> > Dear cclibers, >> > >> > While working towards the cclib debian packages, a question came up >> > concerning whether the unittests should be packaged or not. Basically, >> > the user does not need them, right? If not, then I suppose we should >> > also not be installing them by default. >> > >> > What do you think? >> > >> > - Karol > > -- > written by Karol Langner > Sat Mar 26 17:43:07 CET 2011 > |
|
From: Karol M. L. <kar...@gm...> - 2011-03-26 16:45:55
|
Noel, I think it would be more reasonable to NOT install them in setup.py by default. I can take it upon myself to change this by adding an option. Is --install-tests is OK? On Sat, Mar 26, 2011 at 04:01:36PM +0000, Noel O'Boyle wrote: > There's no need for them to be packaged certainly. But I see no real > problem with installing them (and everytime I try to change the > installer, I break something!). > > - Noel > > On 26 March 2011 15:33, Karol M. Langner <kar...@gm...> wrote: > > Dear cclibers, > > > > While working towards the cclib debian packages, a question came up > > concerning whether the unittests should be packaged or not. Basically, > > the user does not need them, right? If not, then I suppose we should > > also not be installing them by default. > > > > What do you think? > > > > - Karol -- written by Karol Langner Sat Mar 26 17:43:07 CET 2011 |
|
From: Karol M. L. <kar...@gm...> - 2011-03-26 16:38:16
|
On Thu, Feb 10, 2011 at 11:02:32AM +0000, Noel O'Boyle wrote: > Unfortunately, the SF wiki > puts a huge banner at the top of the page, which is really annoying. Why? :) It really looks silly. I created a ticket for hiding it. We will see if it can be changed... -- written by Karol Langner Sat Mar 26 17:10:38 CET 2011 |
|
From: Noel O'B. <bao...@gm...> - 2011-03-26 16:01:42
|
There's no need for them to be packaged certainly. But I see no real problem with installing them (and everytime I try to change the installer, I break something!). - Noel On 26 March 2011 15:33, Karol M. Langner <kar...@gm...> wrote: > Dear cclibers, > > While working towards the cclib debian packages, a question came up > concerning whether the unittests should be packaged or not. Basically, > the user does not need them, right? If not, then I suppose we should > also not be installing them by default. > > What do you think? > > - Karol > > -- > written by Karol Langner > Sat Mar 26 16:30:18 CET 2011 > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol M. L. <kar...@gm...> - 2011-03-26 15:33:25
|
Dear cclibers, While working towards the cclib debian packages, a question came up concerning whether the unittests should be packaged or not. Basically, the user does not need them, right? If not, then I suppose we should also not be installing them by default. What do you think? - Karol -- written by Karol Langner Sat Mar 26 16:30:18 CET 2011 |
|
From: Karol M. L. <kar...@gm...> - 2011-03-21 09:59:55
|
On Mon, Mar 21, 2011 at 09:50:51AM +0000, Noel O'Boyle wrote: > Hi all, > > Following an email by John Simmie to CCL.net, I've added support to > extract the "X matrix of Anharmonic Constants (cm-1)" from a > FREQ=ANHARM job in Gaussian. I'm not quite sure what to call it, but > for the moment it's "vibanharms". I think there are also anharmonic > frequencies, so maybe it should instead be "vibanharmconsts". > > - Noel Hi, Isn't the frequency used in the anharmonic term the same as the harmonic? Anyway, I would propose vibaconst. - Karol -- written by Karol M. Langner Mon Mar 21 10:53:49 CET 2011 |
17 messages has been excluded from this view by a project administrator.
