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: Noel O'B. <bao...@gm...> - 2011-01-18 11:26:09
|
The two failures are long term historic failures - they basically map out the limit of what cclib can be expected to do. What I really should do is keep a historic record of SVN revisions versus the regressions. I'll put that on my list of things to do! - Noel On 18 January 2011 10:22, Karol M. Langner <kar...@gm...> wrote: > Hi, > > On Tuesday 18 January 2011 04:20:45 Adam Tenderholt wrote: >> Also, I'm getting regression errors for Gaussian98/test_Cu2.log.gz and >> GAMESS-US/zolm_dft3a.log.zip and a ccopen failure for ORCA2.8/co.out. This >> appears to be the case for my trunk install too. > > I also get errors with the first two. However, ORCA2.8/co.out should parse > correctly with my latest commit. Are you sure you've updated your local copy? > >> The testall.py script >> (Turbomole branch) gives the following: >> >> ********* SUMMARY PER PACKAGE **************** >> Total Passed Failed Errors Skipped >> ADF2007.01 53 51 0 0 2 >> GAMESS-UK 58 58 0 0 0 >> GAMESS-US 76 73 1 0 2 >> Gaussian03 95 92 0 0 3 >> Jaguar7.0 55 48 0 0 7 >> Molpro2006 63 59 0 0 4 >> ORCA2.6 54 46 5 1 2 >> PCGAMESS 75 74 0 0 1 >> Turbomole 37 18 0 19 0 > > This is the same I get using trunk, besides the Turbomole line of course. > >> Lots of errors with Turbomole. Clearly I have work to do. ;-) Any idea >> about the Orca and GAMESS-US problems? > > I would love to work on the turbomole parser, however for the near future you > are on your own :) > > As far as ORCA is concerned, four fails and the error are connected to > vibration attributes, which are very low on my "priority list". The fifth > fail happens for scftargets when parsing the geometry optimization test, > which I think will be easy to fix. > > The fail for GAMESS-US is connected to etsecs not summing up to 1. I don't > know what to do with that, however, at the moment. > > Best, > Karol > > -- > written by Karol M. Langner > Tue Jan 18 11:22:27 CET 2011 > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
From: Karol M. L. <kar...@gm...> - 2011-01-18 10:19:42
|
Hi, On Tuesday 18 January 2011 04:20:45 Adam Tenderholt wrote: > Also, I'm getting regression errors for Gaussian98/test_Cu2.log.gz and > GAMESS-US/zolm_dft3a.log.zip and a ccopen failure for ORCA2.8/co.out. This > appears to be the case for my trunk install too. I also get errors with the first two. However, ORCA2.8/co.out should parse correctly with my latest commit. Are you sure you've updated your local copy? > The testall.py script > (Turbomole branch) gives the following: > > ********* SUMMARY PER PACKAGE **************** > Total Passed Failed Errors Skipped > ADF2007.01 53 51 0 0 2 > GAMESS-UK 58 58 0 0 0 > GAMESS-US 76 73 1 0 2 > Gaussian03 95 92 0 0 3 > Jaguar7.0 55 48 0 0 7 > Molpro2006 63 59 0 0 4 > ORCA2.6 54 46 5 1 2 > PCGAMESS 75 74 0 0 1 > Turbomole 37 18 0 19 0 This is the same I get using trunk, besides the Turbomole line of course. > Lots of errors with Turbomole. Clearly I have work to do. ;-) Any idea > about the Orca and GAMESS-US problems? I would love to work on the turbomole parser, however for the near future you are on your own :) As far as ORCA is concerned, four fails and the error are connected to vibration attributes, which are very low on my "priority list". The fifth fail happens for scftargets when parsing the geometry optimization test, which I think will be easy to fix. The fail for GAMESS-US is connected to etsecs not summing up to 1. I don't know what to do with that, however, at the moment. Best, Karol -- written by Karol M. Langner Tue Jan 18 11:22:27 CET 2011 |
From: Adam T. <ate...@gm...> - 2011-01-18 03:20:43
|
Karol (and others), Thanks for the heads-up. I've just merged changes from trunk back into the turbomole parser branch. Also, I'm getting regression errors for Gaussian98/test_Cu2.log.gz and GAMESS-US/zolm_dft3a.log.zip and a ccopen failure for ORCA2.8/co.out. This appears to be the case for my trunk install too. The testall.py script (Turbomole branch) gives the following: ********* SUMMARY PER PACKAGE **************** Total Passed Failed Errors Skipped ADF2007.01 53 51 0 0 2 GAMESS-UK 58 58 0 0 0 GAMESS-US 76 73 1 0 2 Gaussian03 95 92 0 0 3 Jaguar7.0 55 48 0 0 7 Molpro2006 63 59 0 0 4 ORCA2.6 54 46 5 1 2 PCGAMESS 75 74 0 0 1 Turbomole 37 18 0 19 0 -- Lots of errors with Turbomole. Clearly I have work to do. ;-) Any idea about the Orca and GAMESS-US problems? Adam > This is something I never did last year after this discussion, so I've > finished it now. I merged your vibmasses parser for ADF into trunk, renaming > the attribute to atommasses. > > For the Gaussian parser, I think my solution is more general than the one I > saw in the Turbomole parser (relies on thermochemistry being printed), and > the values contain more digits. Maybe you would like to merge it into there. > > - Karol > > -- > written by Karol M. Langner > Mon Jan 10 15:42:20 CET 2011 |
From: Adam T. <ate...@gm...> - 2011-01-17 18:36:55
|
Hey Ben (and everyone else), It's great that you're thinking about undertaking such an interesting addition to cclib. It's definitely something that I wanted to get around to working on, but I've just been plenty busy with research and such. Anyhow, I have a couple of thoughts about your approach. You should try to put the basis sets in a format that makes it easy to eventually convert to the densities that may be of some interest. Can this be done with matrix operations in numpy? There's also the promise of OpenCL. This might not help in the short-term since I don't think that there are drivers that take advantage of GPUs (my laptop for instance can only work with the CPU), but it seems like a good long-term approach. One of my former colleagues has written a Mac application that renders orbitals from Gaussian calculations on the fly. I don't really know what his plans are for his program, but I don't think he plans on developing it commercially. If you're interested, I can see what he thinks and put you two in contact. Adam On Sun, Jan 16, 2011 at 12:10 PM, Benjamin Stein <bs...@un...> wrote: > Hello, and I hope everyones holidays were nice and relaxing! > > I've been thinking about improving the basis set handling in cclib which, as I'm sure everyone knows, looks to be a bit of an undertaking. My eventual goal is to have the handling robust enough to provide methods to generate cube (or whichever format) files of orbitals, densities, etc. > > Personally, my motivation (aside from learning how basis sets are handled in various packages) is to play around with orbital transformations, and being able to plot them would be beyond useful. In addition, this would open up doors to possibly visualizing time-dependent results (such as density differences and transition densities). > > I'm attacking the problem using a bottom up sort of approach, by working out how to store the basis set information at the primitive gaussian (or slater, I'm trying to be agnostic) level. So far I've sketched out a few simple classes (bear with me, I'm new to this OO stuff). > > > Some thoughts: > > Have each atom possess a list of shells. Each shell is composed of primitive functions, each with a contraction coefficient and exponent. This part seems easy-ish; I think I've figured out the parsing of ORCA's basis set output. I haven't looked at Gaussian in a while, but I remember it being reasonable. As long as a package has an option to print out the basis set in some sort of sane format, we should be OK. > > A tricky bit is how to handle the 2l+1 m_l components of each shell. None of the packages I've looked at so far have documented the m_l ordering. We can always ask the developers if need be, and I think I've figured it out for ORCA by looking at the output. > > > I've attached some code I put together (I haven't tested any of it, just thinking out loud), but I'm not sure if attachments work on the mailing list. If not I'll just pop it up on dropbox or something. > > Best, > Ben > > > > Benjamin Stein > University of New Mexico > > > > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > |
From: Benjamin S. <bs...@un...> - 2011-01-16 20:10:28
|
Hello, and I hope everyones holidays were nice and relaxing! I've been thinking about improving the basis set handling in cclib which, as I'm sure everyone knows, looks to be a bit of an undertaking. My eventual goal is to have the handling robust enough to provide methods to generate cube (or whichever format) files of orbitals, densities, etc. Personally, my motivation (aside from learning how basis sets are handled in various packages) is to play around with orbital transformations, and being able to plot them would be beyond useful. In addition, this would open up doors to possibly visualizing time-dependent results (such as density differences and transition densities). I'm attacking the problem using a bottom up sort of approach, by working out how to store the basis set information at the primitive gaussian (or slater, I'm trying to be agnostic) level. So far I've sketched out a few simple classes (bear with me, I'm new to this OO stuff). Some thoughts: Have each atom possess a list of shells. Each shell is composed of primitive functions, each with a contraction coefficient and exponent. This part seems easy-ish; I think I've figured out the parsing of ORCA's basis set output. I haven't looked at Gaussian in a while, but I remember it being reasonable. As long as a package has an option to print out the basis set in some sort of sane format, we should be OK. A tricky bit is how to handle the 2l+1 m_l components of each shell. None of the packages I've looked at so far have documented the m_l ordering. We can always ask the developers if need be, and I think I've figured it out for ORCA by looking at the output. I've attached some code I put together (I haven't tested any of it, just thinking out loud), but I'm not sure if attachments work on the mailing list. If not I'll just pop it up on dropbox or something. Best, Ben Benjamin Stein University of New Mexico |
From: Karol M. L. <kar...@gm...> - 2011-01-10 14:39:42
|
On Friday 09 April 2010 19:39:11 Adam Tenderholt wrote: > >>> Any thoughts on keeping them as vibmasses or should we call them > >>> atomicmasses? > >> > >> It sounds like atommasses (like atomnos) would make most sense. > > > > OK, I can do this in the trunk later today. Adam, you'll have to sync the > > branches you develop. > > Karol, do you just want to merge the changes I made for the Gaussian and > ADF parsers (turbomol branch) into trunk before you start working on them? > You'll have the rename them from vibmasses to atomicmasses. Adam, This is something I never did last year after this discussion, so I've finished it now. I merged your vibmasses parser for ADF into trunk, renaming the attribute to atommasses. For the Gaussian parser, I think my solution is more general than the one I saw in the Turbomole parser (relies on thermochemistry being printed), and the values contain more digits. Maybe you would like to merge it into there. - Karol -- written by Karol M. Langner Mon Jan 10 15:42:20 CET 2011 |
From: Benjamin S. <BS...@un...> - 2011-01-07 18:15:05
|
Hello, and thanks the for warm welcome, everyone! Cclib has been a great help to me so far, and I hope to contribute more yet. Like I mentioned to Karol I have a couple of things I'd like to see about implementing, but I'll have to come to everyone here for lots of help. Cclib is the first project I've been involved in that wasn't just me hacking together some ugly code! Thanks again and all the best, Ben |
From: Adam T. <ate...@gm...> - 2011-01-07 18:04:29
|
Indeed, welcome. :-) I started the ORCA parser back when I was a grad student, but only implemented what I occasionally needed for my research. I've since started a postdoc and rarely use ORCA now, so I'm glad that you've found it useful and are interested in contributing to cclib. Adam On Jan 7, 2011, at 2:23 AM, Noel O'Boyle wrote: > Welcome to the club. > > - Noel > > On 6 January 2011 22:13, Karol M. Langner <kar...@gm...> wrote: >> I'd like to introduce Ben Stein (stei7766 on SF), who joined the cclib >> dev team today. He already contributed one useful patch to the ORCA >> parser, and we hope to see more of that in the future! >> >> Cheers, >> Karol >> >> -- >> written by Karol Langner >> Thu Jan 6 23:13:34 CET 2011 >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel |
From: Noel O'B. <bao...@gm...> - 2011-01-07 10:23:47
|
Welcome to the club. - Noel On 6 January 2011 22:13, Karol M. Langner <kar...@gm...> wrote: > I'd like to introduce Ben Stein (stei7766 on SF), who joined the cclib > dev team today. He already contributed one useful patch to the ORCA > parser, and we hope to see more of that in the future! > > Cheers, > Karol > > -- > written by Karol Langner > Thu Jan 6 23:13:34 CET 2011 > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
From: Karol M. L. <kar...@gm...> - 2011-01-06 22:08:52
|
I'd like to introduce Ben Stein (stei7766 on SF), who joined the cclib dev team today. He already contributed one useful patch to the ORCA parser, and we hope to see more of that in the future! Cheers, Karol -- written by Karol Langner Thu Jan 6 23:13:34 CET 2011 |
From: SourceForge.net <no...@so...> - 2011-01-06 16:16:29
|
Bugs item #3077163, was opened at 2010-09-28 12:54 Message generated for change (Comment added) made by langner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsers Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: mretegan () Assigned to: Karol Langner (langner) Summary: failed to parse orca 2.8.0 output Initial Comment: Traceback (most recent call last): File "co.py", line 3, in <module> data = file.parse() File "/usr/lib/python2.6/site-packages/cclib/parser/logfileparser.py", line 142, in parse self.extract(inputfile, line) File "/usr/lib/python2.6/site-packages/cclib/parser/orcaparser.py", line 127, in extract assert line[:29].strip() == "Last DIIS Error" AssertionError ---------------------------------------------------------------------- >Comment By: Karol Langner (langner) Date: 2011-01-06 17:16 Message: File added to regression suite. ---------------------------------------------------------------------- Comment By: Karol Langner (langner) Date: 2011-01-03 16:14 Message: Applied the patch Ben sent in. Thanks! Let us know that the output file is in the PD, so we can add it to the regression suite. ---------------------------------------------------------------------- Comment By: Noel O'Boyle (baoilleach) Date: 2010-12-31 20:00 Message: Whoops, I forgot all about this bug. We welcome any help we can get. Just send an email to the developers mailing list with the patch. We'll review it, and get you set up to go. ---------------------------------------------------------------------- Comment By: Ben Stein () Date: 2010-12-31 19:23 Message: I think I've found the problem (it happens when orca switches to a non-DIIS converger). I've fixed orcaparser.py, but I'm not really sure of the proper way to contribute a patch. I use orca and cclib regularly, I'd be happy to keep the parser up to date if the project is short-handed. ---------------------------------------------------------------------- Comment By: mretegan () Date: 2010-09-28 13:01 Message: Yes. ---------------------------------------------------------------------- Comment By: Noel O'Boyle (baoilleach) Date: 2010-09-28 12:55 Message: Can you confirm that this log file is in the public domain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 |
From: Karol M. L. <kar...@gm...> - 2011-01-03 15:44:37
|
On Monday 03 January 2011 16:10:58 Karol M. Langner wrote: > On Friday 31 December 2010 23:19:01 Benjamin Stein wrote: > > Hello, > > > > This is in response to the orca parser bug (#3077163). Attached is a > > patch which should fix it up. > > > > Thanks! > > > > Ben Stein > > Hi, > > Thanks for the patch! I tested it and committed it to the trunk. If > possible, please confirm that the log file is in the PD as Noel asked, so > we can add it to the regression suite. I didn't notice the reply on SF before. In revision 923 I added this file to the regression tests. Cheers, Karol -- written by Karol Langner Mon Jan 3 16:43:16 CET 2011 |
From: SourceForge.net <no...@so...> - 2011-01-03 15:14:17
|
Bugs item #3077163, was opened at 2010-09-28 12:54 Message generated for change (Comment added) made by langner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsers Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: mretegan () >Assigned to: Karol Langner (langner) Summary: failed to parse orca 2.8.0 output Initial Comment: Traceback (most recent call last): File "co.py", line 3, in <module> data = file.parse() File "/usr/lib/python2.6/site-packages/cclib/parser/logfileparser.py", line 142, in parse self.extract(inputfile, line) File "/usr/lib/python2.6/site-packages/cclib/parser/orcaparser.py", line 127, in extract assert line[:29].strip() == "Last DIIS Error" AssertionError ---------------------------------------------------------------------- >Comment By: Karol Langner (langner) Date: 2011-01-03 16:14 Message: Applied the patch Ben sent in. Thanks! Let us know that the output file is in the PD, so we can add it to the regression suite. ---------------------------------------------------------------------- Comment By: Noel O'Boyle (baoilleach) Date: 2010-12-31 20:00 Message: Whoops, I forgot all about this bug. We welcome any help we can get. Just send an email to the developers mailing list with the patch. We'll review it, and get you set up to go. ---------------------------------------------------------------------- Comment By: Ben Stein () Date: 2010-12-31 19:23 Message: I think I've found the problem (it happens when orca switches to a non-DIIS converger). I've fixed orcaparser.py, but I'm not really sure of the proper way to contribute a patch. I use orca and cclib regularly, I'd be happy to keep the parser up to date if the project is short-handed. ---------------------------------------------------------------------- Comment By: mretegan () Date: 2010-09-28 13:01 Message: Yes. ---------------------------------------------------------------------- Comment By: Noel O'Boyle (baoilleach) Date: 2010-09-28 12:55 Message: Can you confirm that this log file is in the public domain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 |
From: Karol M. L. <kar...@gm...> - 2011-01-03 15:12:20
|
On Friday 31 December 2010 23:19:01 Benjamin Stein wrote: > Hello, > > This is in response to the orca parser bug (#3077163). Attached is a patch > which should fix it up. > > Thanks! > > Ben Stein Hi, Thanks for the patch! I tested it and committed it to the trunk. If possible, please confirm that the log file is in the PD as Noel asked, so we can add it to the regression suite. Best, Karol -- written by Karol Langner Mon Jan 3 16:10:57 CET 2011 |
From: Benjamin S. <BS...@UN...> - 2010-12-31 22:19:12
|
Hello, This is in response to the orca parser bug (#3077163). Attached is a patch which should fix it up. Thanks! Ben Stein |
From: SourceForge.net <no...@so...> - 2010-12-31 19:00:40
|
Bugs item #3077163, was opened at 2010-09-28 11:54 Message generated for change (Comment added) made by baoilleach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsers Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mretegan () Assigned to: Nobody/Anonymous (nobody) Summary: failed to parse orca 2.8.0 output Initial Comment: Traceback (most recent call last): File "co.py", line 3, in <module> data = file.parse() File "/usr/lib/python2.6/site-packages/cclib/parser/logfileparser.py", line 142, in parse self.extract(inputfile, line) File "/usr/lib/python2.6/site-packages/cclib/parser/orcaparser.py", line 127, in extract assert line[:29].strip() == "Last DIIS Error" AssertionError ---------------------------------------------------------------------- >Comment By: Noel O'Boyle (baoilleach) Date: 2010-12-31 19:00 Message: Whoops, I forgot all about this bug. We welcome any help we can get. Just send an email to the developers mailing list with the patch. We'll review it, and get you set up to go. ---------------------------------------------------------------------- Comment By: Ben Stein () Date: 2010-12-31 18:23 Message: I think I've found the problem (it happens when orca switches to a non-DIIS converger). I've fixed orcaparser.py, but I'm not really sure of the proper way to contribute a patch. I use orca and cclib regularly, I'd be happy to keep the parser up to date if the project is short-handed. ---------------------------------------------------------------------- Comment By: mretegan () Date: 2010-09-28 12:01 Message: Yes. ---------------------------------------------------------------------- Comment By: Noel O'Boyle (baoilleach) Date: 2010-09-28 11:55 Message: Can you confirm that this log file is in the public domain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 |
From: SourceForge.net <no...@so...> - 2010-12-31 18:23:21
|
Bugs item #3077163, was opened at 2010-09-28 10:54 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsers Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mretegan () Assigned to: Nobody/Anonymous (nobody) Summary: failed to parse orca 2.8.0 output Initial Comment: Traceback (most recent call last): File "co.py", line 3, in <module> data = file.parse() File "/usr/lib/python2.6/site-packages/cclib/parser/logfileparser.py", line 142, in parse self.extract(inputfile, line) File "/usr/lib/python2.6/site-packages/cclib/parser/orcaparser.py", line 127, in extract assert line[:29].strip() == "Last DIIS Error" AssertionError ---------------------------------------------------------------------- Comment By: Ben Stein () Date: 2010-12-31 18:23 Message: I think I've found the problem (it happens when orca switches to a non-DIIS converger). I've fixed orcaparser.py, but I'm not really sure of the proper way to contribute a patch. I use orca and cclib regularly, I'd be happy to keep the parser up to date if the project is short-handed. ---------------------------------------------------------------------- Comment By: mretegan () Date: 2010-09-28 11:01 Message: Yes. ---------------------------------------------------------------------- Comment By: Noel O'Boyle (baoilleach) Date: 2010-09-28 10:55 Message: Can you confirm that this log file is in the public domain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 |
From: Adam T. <ate...@gm...> - 2010-10-02 20:34:43
|
I agree that we should look into MolMod, at the very least to get ideas on how to parse formatted checkpoint files. Also, good to know that it's GPL'd although I'm not sure how that works with a LGPL'd library. Presumably, if we take files directly from MolMod, we'd need them to add an exception for us. Adam On Sat, Oct 2, 2010 at 5:51 AM, Karol M. Langner <kar...@gm...> wrote: > There was a recent post on CCL called "python scripts for gaussian", > and I mentioned cclib there. Toon Verstraelen also suggested MolMod, > which I hadn't known about so I gave it a look.: > http://molmod.ugent.be/code/wiki/MolMod > > (by the way Adam, it is GPL if you look at the code) > > I think there are things we could merge into cclib from there. > Specifically, parsing punch files and formatted checkpoint files from > gaussian. That is something I've wanted to get done for a long time, > anyway. This is in the module MolMod.io if you go into the source > tree. > > I contacted Toon, he also seems interested in cclib, but the situation > with MolMod is a but different since it is to a large extent auxiliary > code, used in the other codes developed in his group. > > I haven't had time to dive really deep into this, but it seems a good > way to quickly improve on some things in cclib. > > Cheers, > Karol > > -- > written by Karol Langner > Sat Oct 2 14:44:55 CEST 2010 > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
From: Karol M. L. <km...@mm...> - 2010-10-02 12:57:05
|
On Monday 27 September 2010 14:28:50 Noel O'Boyle wrote: > Hi all, > > It seems like there's an initiative involving PMR and others to get > comp chem file parsing working properly: Quixote. I think the > general idea is to have people uploading their log files to a > central database when they submit a paper, and to have parsers that > extract the information. They also want the ability to write out > input files for new calculations based on the info in the old ones > (or something like that). > > Although the parser is unlikely to be based on cclib (being > realistic - there was talk of ANTLR parsers and Java and so forth), > cclib should still have a role to play here even if only to provide > log files and cross-validation of extracted results. > > There's a mailing list at > http://groups.google.com/group/quixote-qcdb and there's a wiki at > http://quixote.wikispot.org/Front_Page. I've sent some emails to the > list describing cclib. > > - Noel That does sound interesting. I wonder how many people will actually be depositing log files there. -- written by Karol Langner Sat Oct 2 14:41:36 CEST 2010 |
From: Karol M. L. <kar...@gm...> - 2010-10-02 12:47:34
|
There was a recent post on CCL called "python scripts for gaussian", and I mentioned cclib there. Toon Verstraelen also suggested MolMod, which I hadn't known about so I gave it a look.: http://molmod.ugent.be/code/wiki/MolMod (by the way Adam, it is GPL if you look at the code) I think there are things we could merge into cclib from there. Specifically, parsing punch files and formatted checkpoint files from gaussian. That is something I've wanted to get done for a long time, anyway. This is in the module MolMod.io if you go into the source tree. I contacted Toon, he also seems interested in cclib, but the situation with MolMod is a but different since it is to a large extent auxiliary code, used in the other codes developed in his group. I haven't had time to dive really deep into this, but it seems a good way to quickly improve on some things in cclib. Cheers, Karol -- written by Karol Langner Sat Oct 2 14:44:55 CEST 2010 |
From: SourceForge.net <no...@so...> - 2010-09-28 11:01:41
|
Bugs item #3077163, was opened at 2010-09-28 12:54 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsers Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mretegan () Assigned to: Nobody/Anonymous (nobody) Summary: failed to parse orca 2.8.0 output Initial Comment: Traceback (most recent call last): File "co.py", line 3, in <module> data = file.parse() File "/usr/lib/python2.6/site-packages/cclib/parser/logfileparser.py", line 142, in parse self.extract(inputfile, line) File "/usr/lib/python2.6/site-packages/cclib/parser/orcaparser.py", line 127, in extract assert line[:29].strip() == "Last DIIS Error" AssertionError ---------------------------------------------------------------------- >Comment By: mretegan () Date: 2010-09-28 13:01 Message: Yes. ---------------------------------------------------------------------- Comment By: Noel O'Boyle (baoilleach) Date: 2010-09-28 12:55 Message: Can you confirm that this log file is in the public domain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 |
From: SourceForge.net <no...@so...> - 2010-09-28 10:55:46
|
Bugs item #3077163, was opened at 2010-09-28 11:54 Message generated for change (Comment added) made by baoilleach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsers Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mretegan () Assigned to: Nobody/Anonymous (nobody) Summary: failed to parse orca 2.8.0 output Initial Comment: Traceback (most recent call last): File "co.py", line 3, in <module> data = file.parse() File "/usr/lib/python2.6/site-packages/cclib/parser/logfileparser.py", line 142, in parse self.extract(inputfile, line) File "/usr/lib/python2.6/site-packages/cclib/parser/orcaparser.py", line 127, in extract assert line[:29].strip() == "Last DIIS Error" AssertionError ---------------------------------------------------------------------- >Comment By: Noel O'Boyle (baoilleach) Date: 2010-09-28 11:55 Message: Can you confirm that this log file is in the public domain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 |
From: SourceForge.net <no...@so...> - 2010-09-28 10:54:33
|
Bugs item #3077163, was opened at 2010-09-28 12:54 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsers Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mretegan () Assigned to: Nobody/Anonymous (nobody) Summary: failed to parse orca 2.8.0 output Initial Comment: Traceback (most recent call last): File "co.py", line 3, in <module> data = file.parse() File "/usr/lib/python2.6/site-packages/cclib/parser/logfileparser.py", line 142, in parse self.extract(inputfile, line) File "/usr/lib/python2.6/site-packages/cclib/parser/orcaparser.py", line 127, in extract assert line[:29].strip() == "Last DIIS Error" AssertionError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3077163&group_id=161285 |
From: Noel O'B. <bao...@gm...> - 2010-09-27 12:29:02
|
Hi all, It seems like there's an initiative involving PMR and others to get comp chem file parsing working properly: Quixote. I think the general idea is to have people uploading their log files to a central database when they submit a paper, and to have parsers that extract the information. They also want the ability to write out input files for new calculations based on the info in the old ones (or something like that). Although the parser is unlikely to be based on cclib (being realistic - there was talk of ANTLR parsers and Java and so forth), cclib should still have a role to play here even if only to provide log files and cross-validation of extracted results. There's a mailing list at http://groups.google.com/group/quixote-qcdb and there's a wiki at http://quixote.wikispot.org/Front_Page. I've sent some emails to the list describing cclib. - Noel |
From: Noel O'B. <bao...@gm...> - 2010-08-30 11:53:50
|
It really depends on why it's failing, I guess. If it's the same problem as before, where the assert was added 'just in case' but where everything was in fact okay, then the assert can simply be removed. - Noel On 29 August 2010 23:35, Adam Tenderholt <ate...@gm...> wrote: > In trying to fix my recent bug report, I see that /data/Gaussian/Gaussian98/test_Cu2.log.gz fails to parse correctly. The issue is line 801 (assert nbasis == self.nbasis). > > Should the logger be throwing a critical message instead of outright dying? > > Adam > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |