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
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
|
3
|
4
|
5
|
6
|
7
|
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
|
15
|
16
(2) |
17
(1) |
18
|
19
(10) |
20
|
21
|
|
22
(2) |
23
(5) |
24
(2) |
25
|
26
|
27
|
28
|
|
29
|
30
|
|
|
|
|
|
|
From: Edward H. <hol...@ca...> - 2012-04-24 12:33:43
|
Hi All, Adam: > I agree that this change would break scripts if people were only > parsing the first optimization of a scan calculation, but shouldn't > most users (at least of released versions) only be using cclib for > optimizations at this point, and not scan calculations? Otherwise, > they aren't getting the majority of the structures/energies from their > results. Isn't this why these patches were created? Or am I making a > bad assumption about cclib use? If you are happy to make these assumptions then i can knock up a patch when I find some free time, it was just not a decision i felt comfortable making alone. > > I think that scfenergies (atomcoords, etc). should hold the energies > of every completed SCF calculation, whether or not its an optimization > or scan calculation. In the case of a scan (rigid or relaxed) > calculation, I think special attributes for the final optimized step > should be created. So we should leave it as is currently in the SVN version? > > P.S. Ed, did you attach the examples? Ethanol and ethanol-z were in a > previous email… I attached them again as i thought Karol was missing them. Martin: The case for IRC calculations is much simpler than for relaxed scan cases, as gaussian outputs the coordinates in XYZ rather than z-mat (which fits in with cclib). I have code to extract this data but as of yet haven't got around to porting it into cclib. I can put this on my todo list is its important to you. For the relaxed scan case i'm not sure if the full optimisation data is really needed. Personally i think that providing an array of optimised coordinates should be enough. If you have strong feelings about this please let us know. Otherwise parsing relaxed scans is on my todo list. Yours Ed Holland PS Martin if you want a copy of my generalised IRC extracting script i can email that over asap. On 24 Apr 2012, at 13:05, ccl...@li... wrote: > Send cclib-devel mailing list submissions to > ccl...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/cclib-devel > or, via email, send a message with subject or body 'help' to > ccl...@li... > > You can reach the person managing the list at > ccl...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cclib-devel digest..." > > > Today's Topics: > > 1. Re: branch maintenance (Adam Tenderholt) > 2. Re: Patch for rigid scan and thermochemsirty data > (Adam Tenderholt) > 3. Re: branch maintenance (Noel O'Boyle) > 4. Relaxed scan / IRC (Gaussian) (Martin Krupicka) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Apr 2012 08:18:30 -0700 > From: Adam Tenderholt <ate...@gm...> > Subject: Re: [cclib-devel] branch maintenance > To: "Karol M. Langner" <kar...@gm...> > Cc: cclib-dev List <ccl...@li...> > Message-ID: > <CAG...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > I'm in favor of deleting the Orca branch, although maybe Noel wants to > weigh in. (cc'ing cclib-dev.) > > On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner > <kar...@gm...> wrote: >> So, do we delete the orcaparser, or somehow mark it is inactive? What is our policy for branches? >> >> - Karol >> >> On Apr 19 2012, Karol M. Langner wrote: >>> I also think we should merge only after a parser is reasonably mature, >>> for instance when most of the standard unit tests run and there are only a few errors. >>> >>> On Apr 19 2012, Adam Tenderholt wrote: >>>> Ah, good catch. I didn't even think of checking trunk to see if the >>>> Orca parser had been merged after that feature request a few days ago. >>>> I just assumed they had downloaded cclib and didn't have Orca support. >>>> I wonder why they submitted that feature request. >>>> >>>> For the other branches, do we want to merge them into trunk if they >>>> aren't ready? I recall that NWChem was nowhere near ready, and when I >>>> went to work on it last year, I wasn't able to get it to print some >>>> attribute cleanly (running in parallel causes duplication of output >>>> sometimes). It seems like we should wait until they are more fully >>>> supported. >>>> >>>> Adam >>>> >>>> On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner >>>> <kar...@gm...> wrote: >>>>> From what I can see, the ORCA parser was alraedy merged into trunk. >>>>> >>>>> If there is nothing new there (I've looked only at the parser source), then I think >>>>> the branch should be deleted, or marked somehow as inactive. >>>>> >>>>> As far as I can see, the other parse branches (Molcas, NWChem, Turbomole) have >>>>> not been merged into trunk yet. >>>>> >>>>> Karol >>>>> >>>>> On Apr 19 2012, Adam Tenderholt wrote: >>>>>> With the recent talk about updating the license of cclib, it got me >>>>>> thinking that we might need to perform some maintenance on the >>>>>> branches since several are quite old (e.g. Orca). Is it best to make >>>>>> sure the new parsers in those branches are well-supported, and then >>>>>> merge those changes into trunk? Or should we merge trunk into those >>>>>> branches? >>>>>> >>>>>> Adam >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> For Developers, A Lot Can Happen In A Second. >>>>>> Boundary is the first to Know...and Tell You. >>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>>>>> http://p.sf.net/sfu/Boundary-d2dvs2 >>>>>> _______________________________________________ >>>>>> cclib-devel mailing list >>>>>> ccl...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >>>>> >>>>> -- >>>>> written by Karol Langner >>>>> Thu Apr 19 18:39:04 CEST 2012 >>> >>> -- >>> written by Karol Langner >>> Thu Apr 19 19:04:09 CEST 2012 >> >> -- >> written by Karol Langner >> Mon Apr 23 08:47:36 CEST 2012 > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Apr 2012 08:29:46 -0700 > From: Adam Tenderholt <ate...@gm...> > Subject: Re: [cclib-devel] Patch for rigid scan and thermochemsirty > data > To: cclib-dev List <ccl...@li...> > Message-ID: > <CAG...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > >> Adam: >> ? ? ? ?Yes, the relaxed scan case in not handled by this code. This is due to issues implementing the extraction of geometries. I think the best way to do this would be to look for "optimisation complete" messages and then add the last parsed geometry to a list of scan geometries. However currently the gaussian parser stops searching after a "optimisation complete" message; changing this would affect the exposed list of geometries and potentially break scripts based on cclib. If you can think of a better way of implementing this I would be happy to provide a patch. > > I agree that this change would break scripts if people were only > parsing the first optimization of a scan calculation, but shouldn't > most users (at least of released versions) only be using cclib for > optimizations at this point, and not scan calculations? Otherwise, > they aren't getting the majority of the structures/energies from their > results. Isn't this why these patches were created? Or am I making a > bad assumption about cclib use? > >> ? ? ? ?2) >> ? ? ? ? ? ? ? ?This seems sensible > > Regarding separating the scan and thermochemistry data: I agree this > is a good idea going forward, focusing on a independent results > separately. As I already made the changes to the Gaussian parser, I'm > inclined to leave the two major changes as a single commit instead of > going back to a previous revision to separate the two into new > separate commits. > >> ? ? ? ?3) >> ? ? ? ? ? ? ? ?I agree this seems sensible for the rigid scan case. However it brings us back to the issue of the relaxed scan again; these are a series of optimisations so reusing scfenergies could cause confusion as to the exact meaning of the values and it would also mean that data on the individual optimisation steps is lost. It would seem a choice between simplicity of the interface and completeness of the data collected needs to be made. This is perhaps something we should discuss. > > I think that scfenergies (atomcoords, etc). should hold the energies > of every completed SCF calculation, whether or not its an optimization > or scan calculation. In the case of a scan (rigid or relaxed) > calculation, I think special attributes for the final optimized step > should be created. > > Adam > > P.S. Ed, did you attach the examples? Ethanol and ethanol-z were in a > previous email... > > > > ------------------------------ > > Message: 3 > Date: Mon, 23 Apr 2012 16:40:50 +0100 > From: "Noel O'Boyle" <bao...@gm...> > Subject: Re: [cclib-devel] branch maintenance > To: Adam Tenderholt <ate...@gm...> > Cc: cclib-dev List <ccl...@li...> > Message-ID: > <CAO...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > The orca branch should have been deleted after the merge...back in 2007! > :-) I'll do this. > > For the others - well, once they're ready, they should go on the trunk too. > If you've put some work into a parser, it's worth finishing it up, and > getting it onto trunk. If they stay out on the branch, they will gradually > bitrot.... > > - Noel > > On 23 April 2012 16:18, Adam Tenderholt <ate...@gm...> wrote: > >> I'm in favor of deleting the Orca branch, although maybe Noel wants to >> weigh in. (cc'ing cclib-dev.) >> >> On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner >> <kar...@gm...> wrote: >>> So, do we delete the orcaparser, or somehow mark it is inactive? What is >> our policy for branches? >>> >>> - Karol >>> >>> On Apr 19 2012, Karol M. Langner wrote: >>>> I also think we should merge only after a parser is reasonably mature, >>>> for instance when most of the standard unit tests run and there are >> only a few errors. >>>> >>>> On Apr 19 2012, Adam Tenderholt wrote: >>>>> Ah, good catch. I didn't even think of checking trunk to see if the >>>>> Orca parser had been merged after that feature request a few days ago. >>>>> I just assumed they had downloaded cclib and didn't have Orca support. >>>>> I wonder why they submitted that feature request. >>>>> >>>>> For the other branches, do we want to merge them into trunk if they >>>>> aren't ready? I recall that NWChem was nowhere near ready, and when I >>>>> went to work on it last year, I wasn't able to get it to print some >>>>> attribute cleanly (running in parallel causes duplication of output >>>>> sometimes). It seems like we should wait until they are more fully >>>>> supported. >>>>> >>>>> Adam >>>>> >>>>> On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner >>>>> <kar...@gm...> wrote: >>>>>> From what I can see, the ORCA parser was alraedy merged into trunk. >>>>>> >>>>>> If there is nothing new there (I've looked only at the parser >> source), then I think >>>>>> the branch should be deleted, or marked somehow as inactive. >>>>>> >>>>>> As far as I can see, the other parse branches (Molcas, NWChem, >> Turbomole) have >>>>>> not been merged into trunk yet. >>>>>> >>>>>> Karol >>>>>> >>>>>> On Apr 19 2012, Adam Tenderholt wrote: >>>>>>> With the recent talk about updating the license of cclib, it got me >>>>>>> thinking that we might need to perform some maintenance on the >>>>>>> branches since several are quite old (e.g. Orca). Is it best to >> make >>>>>>> sure the new parsers in those branches are well-supported, and then >>>>>>> merge those changes into trunk? Or should we merge trunk into those >>>>>>> branches? >>>>>>> >>>>>>> Adam >>>>>>> >>>>>>> >> ------------------------------------------------------------------------------ >>>>>>> For Developers, A Lot Can Happen In A Second. >>>>>>> Boundary is the first to Know...and Tell You. >>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2 >>>>>>> _______________________________________________ >>>>>>> cclib-devel mailing list >>>>>>> ccl...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel >>>>>> >>>>>> -- >>>>>> written by Karol Langner >>>>>> Thu Apr 19 18:39:04 CEST 2012 >>>> >>>> -- >>>> written by Karol Langner >>>> Thu Apr 19 19:04:09 CEST 2012 >>> >>> -- >>> written by Karol Langner >>> Mon Apr 23 08:47:36 CEST 2012 >> >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 4 > Date: Tue, 24 Apr 2012 10:42:36 +0200 > From: Martin Krupicka <ma...@bh...> > Subject: [cclib-devel] Relaxed scan / IRC (Gaussian) > To: ccl...@li... > Message-ID: <4F9...@bh...> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > I read the discussion regarding the relaxed scans and I would like to > ask, if there is some agreement how this stuff should be implemented. I > would like to use cclib for digging out data from scans and IRCs. At the > moment I use home-made scripts, but they would need some more > modifications, so it seems better for me to adapt cclib for that purpose. > > The main question if I got it correctly is, that Relaxed scan (or IRC) > are series of optimizations, and it is not yet clear, how they should be > stored and presented to outside. With the functionality already in cclib > I see two options. > > 1. Generate array of results, so for each sub-optimization, the parser > will produce independent data class. > > 2. Add array, which will hold the progress of scan/IRC. The main (and > only?) data stored in this array will be the indices for the converged > points. So i.e. the .scfenergies array contains the "raw" energies, > where the e.g. .points array will contain e.g. [23,29,52], with three > points along the scan, where .scfenergies[23] is the energy of the first > converged result. With array of indices it is then quite easy to do all > following manipulations with results, so I would personally prefer this > option. > > I am not sure, whether this was not already adressed and solved, so > sorry for eventual off-topic. > > Martin > > > > > > > > > ------------------------------ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ------------------------------ > > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > > End of cclib-devel Digest, Vol 61, Issue 9 > ****************************************** |
|
From: Martin K. <ma...@bh...> - 2012-04-24 08:55:16
|
Hi all, I read the discussion regarding the relaxed scans and I would like to ask, if there is some agreement how this stuff should be implemented. I would like to use cclib for digging out data from scans and IRCs. At the moment I use home-made scripts, but they would need some more modifications, so it seems better for me to adapt cclib for that purpose. The main question if I got it correctly is, that Relaxed scan (or IRC) are series of optimizations, and it is not yet clear, how they should be stored and presented to outside. With the functionality already in cclib I see two options. 1. Generate array of results, so for each sub-optimization, the parser will produce independent data class. 2. Add array, which will hold the progress of scan/IRC. The main (and only?) data stored in this array will be the indices for the converged points. So i.e. the .scfenergies array contains the "raw" energies, where the e.g. .points array will contain e.g. [23,29,52], with three points along the scan, where .scfenergies[23] is the energy of the first converged result. With array of indices it is then quite easy to do all following manipulations with results, so I would personally prefer this option. I am not sure, whether this was not already adressed and solved, so sorry for eventual off-topic. Martin |
|
From: Noel O'B. <bao...@gm...> - 2012-04-23 15:41:01
|
The orca branch should have been deleted after the merge...back in 2007! :-) I'll do this. For the others - well, once they're ready, they should go on the trunk too. If you've put some work into a parser, it's worth finishing it up, and getting it onto trunk. If they stay out on the branch, they will gradually bitrot.... - Noel On 23 April 2012 16:18, Adam Tenderholt <ate...@gm...> wrote: > I'm in favor of deleting the Orca branch, although maybe Noel wants to > weigh in. (cc'ing cclib-dev.) > > On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner > <kar...@gm...> wrote: > > So, do we delete the orcaparser, or somehow mark it is inactive? What is > our policy for branches? > > > > - Karol > > > > On Apr 19 2012, Karol M. Langner wrote: > >> I also think we should merge only after a parser is reasonably mature, > >> for instance when most of the standard unit tests run and there are > only a few errors. > >> > >> On Apr 19 2012, Adam Tenderholt wrote: > >> > Ah, good catch. I didn't even think of checking trunk to see if the > >> > Orca parser had been merged after that feature request a few days ago. > >> > I just assumed they had downloaded cclib and didn't have Orca support. > >> > I wonder why they submitted that feature request. > >> > > >> > For the other branches, do we want to merge them into trunk if they > >> > aren't ready? I recall that NWChem was nowhere near ready, and when I > >> > went to work on it last year, I wasn't able to get it to print some > >> > attribute cleanly (running in parallel causes duplication of output > >> > sometimes). It seems like we should wait until they are more fully > >> > supported. > >> > > >> > Adam > >> > > >> > On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner > >> > <kar...@gm...> wrote: > >> > > From what I can see, the ORCA parser was alraedy merged into trunk. > >> > > > >> > > If there is nothing new there (I've looked only at the parser > source), then I think > >> > > the branch should be deleted, or marked somehow as inactive. > >> > > > >> > > As far as I can see, the other parse branches (Molcas, NWChem, > Turbomole) have > >> > > not been merged into trunk yet. > >> > > > >> > > Karol > >> > > > >> > > On Apr 19 2012, Adam Tenderholt wrote: > >> > >> With the recent talk about updating the license of cclib, it got me > >> > >> thinking that we might need to perform some maintenance on the > >> > >> branches since several are quite old (e.g. Orca). Is it best to > make > >> > >> sure the new parsers in those branches are well-supported, and then > >> > >> merge those changes into trunk? Or should we merge trunk into those > >> > >> branches? > >> > >> > >> > >> Adam > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> For Developers, A Lot Can Happen In A Second. > >> > >> Boundary is the first to Know...and Tell You. > >> > >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > >> > >> http://p.sf.net/sfu/Boundary-d2dvs2 > >> > >> _______________________________________________ > >> > >> cclib-devel mailing list > >> > >> ccl...@li... > >> > >> https://lists.sourceforge.net/lists/listinfo/cclib-devel > >> > > > >> > > -- > >> > > written by Karol Langner > >> > > Thu Apr 19 18:39:04 CEST 2012 > >> > >> -- > >> written by Karol Langner > >> Thu Apr 19 19:04:09 CEST 2012 > > > > -- > > written by Karol Langner > > Mon Apr 23 08:47:36 CEST 2012 > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <ate...@gm...> - 2012-04-23 15:35:41
|
> Adam: > Yes, the relaxed scan case in not handled by this code. This is due to issues implementing the extraction of geometries. I think the best way to do this would be to look for "optimisation complete" messages and then add the last parsed geometry to a list of scan geometries. However currently the gaussian parser stops searching after a "optimisation complete" message; changing this would affect the exposed list of geometries and potentially break scripts based on cclib. If you can think of a better way of implementing this I would be happy to provide a patch. I agree that this change would break scripts if people were only parsing the first optimization of a scan calculation, but shouldn't most users (at least of released versions) only be using cclib for optimizations at this point, and not scan calculations? Otherwise, they aren't getting the majority of the structures/energies from their results. Isn't this why these patches were created? Or am I making a bad assumption about cclib use? > 2) > This seems sensible Regarding separating the scan and thermochemistry data: I agree this is a good idea going forward, focusing on a independent results separately. As I already made the changes to the Gaussian parser, I'm inclined to leave the two major changes as a single commit instead of going back to a previous revision to separate the two into new separate commits. > 3) > I agree this seems sensible for the rigid scan case. However it brings us back to the issue of the relaxed scan again; these are a series of optimisations so reusing scfenergies could cause confusion as to the exact meaning of the values and it would also mean that data on the individual optimisation steps is lost. It would seem a choice between simplicity of the interface and completeness of the data collected needs to be made. This is perhaps something we should discuss. I think that scfenergies (atomcoords, etc). should hold the energies of every completed SCF calculation, whether or not its an optimization or scan calculation. In the case of a scan (rigid or relaxed) calculation, I think special attributes for the final optimized step should be created. Adam P.S. Ed, did you attach the examples? Ethanol and ethanol-z were in a previous email... |
|
From: Adam T. <ate...@gm...> - 2012-04-23 15:19:00
|
I'm in favor of deleting the Orca branch, although maybe Noel wants to weigh in. (cc'ing cclib-dev.) On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner <kar...@gm...> wrote: > So, do we delete the orcaparser, or somehow mark it is inactive? What is our policy for branches? > > - Karol > > On Apr 19 2012, Karol M. Langner wrote: >> I also think we should merge only after a parser is reasonably mature, >> for instance when most of the standard unit tests run and there are only a few errors. >> >> On Apr 19 2012, Adam Tenderholt wrote: >> > Ah, good catch. I didn't even think of checking trunk to see if the >> > Orca parser had been merged after that feature request a few days ago. >> > I just assumed they had downloaded cclib and didn't have Orca support. >> > I wonder why they submitted that feature request. >> > >> > For the other branches, do we want to merge them into trunk if they >> > aren't ready? I recall that NWChem was nowhere near ready, and when I >> > went to work on it last year, I wasn't able to get it to print some >> > attribute cleanly (running in parallel causes duplication of output >> > sometimes). It seems like we should wait until they are more fully >> > supported. >> > >> > Adam >> > >> > On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner >> > <kar...@gm...> wrote: >> > > From what I can see, the ORCA parser was alraedy merged into trunk. >> > > >> > > If there is nothing new there (I've looked only at the parser source), then I think >> > > the branch should be deleted, or marked somehow as inactive. >> > > >> > > As far as I can see, the other parse branches (Molcas, NWChem, Turbomole) have >> > > not been merged into trunk yet. >> > > >> > > Karol >> > > >> > > On Apr 19 2012, Adam Tenderholt wrote: >> > >> With the recent talk about updating the license of cclib, it got me >> > >> thinking that we might need to perform some maintenance on the >> > >> branches since several are quite old (e.g. Orca). Is it best to make >> > >> sure the new parsers in those branches are well-supported, and then >> > >> merge those changes into trunk? Or should we merge trunk into those >> > >> branches? >> > >> >> > >> Adam >> > >> >> > >> ------------------------------------------------------------------------------ >> > >> For Developers, A Lot Can Happen In A Second. >> > >> Boundary is the first to Know...and Tell You. >> > >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> > >> http://p.sf.net/sfu/Boundary-d2dvs2 >> > >> _______________________________________________ >> > >> cclib-devel mailing list >> > >> ccl...@li... >> > >> https://lists.sourceforge.net/lists/listinfo/cclib-devel >> > > >> > > -- >> > > written by Karol Langner >> > > Thu Apr 19 18:39:04 CEST 2012 >> >> -- >> written by Karol Langner >> Thu Apr 19 19:04:09 CEST 2012 > > -- > written by Karol Langner > Mon Apr 23 08:47:36 CEST 2012 |
|
From: Edward H. <hol...@ca...> - 2012-04-23 09:15:10
|
Hi Both,
Thanks for reviewing my changes, let me address your comments.
Adam:
Yes, the relaxed scan case in not handled by this code. This is due to issues implementing the extraction of geometries. I think the best way to do this would be to look for "optimisation complete" messages and then add the last parsed geometry to a list of scan geometries. However currently the gaussian parser stops searching after a "optimisation complete" message; changing this would affect the exposed list of geometries and potentially break scripts based on cclib. If you can think of a better way of implementing this I would be happy to provide a patch.
Karol:
1)
I agree with variable seems an odd choice to be publicly accessible. However it deals with cases where gaussian ends optimisation because of "Optimization completed on the basis of negligible forces". In this case the geovalues is not lower than geotargets at the optimised step. Perhaps this case could instead be dealt with by changing geotargets when this message is found. How to select appropriate values to ensure only the correct geometries appear optimised I am unsure.
2)
This seems sensible
3)
I agree this seems sensible for the rigid scan case. However it brings us back to the issue of the relaxed scan again; these are a series of optimisations so reusing scfenergies could cause confusion as to the exact meaning of the values and it would also mean that data on the individual optimisation steps is lost. It would seem a choice between simplicity of the interface and completeness of the data collected needs to be made. This is perhaps something we should discuss.
I have also attached the test cases for both relaxed and rigid scans.
I hope this explains my thoughts on the topic, if anything is unclear please let me know.
Yours
Ed Holland
On 23 Apr 2012, at 09:18, Karol M. Langner wrote:
> Hi guys,
>
> Yes, it would be good to standardize this.
>
> Several initial thoughts:
> 1) attribute optdone is not useful and in fact not used
> 2) we should separate the changes related to thermochem. and scans
> 3) do we have test output files to work on scans? do we really need
> attributes such as scanenergies, when, for example for geometry
> optimization, we pack all the values into 'scfenergies', etc.? In
> principle we could do the same in this case
>
> - Karol
>
> On Apr 22 2012, Adam Tenderholt wrote:
>> Hi Ed,
>>
>> Thank you for the patch. I made a few changes, the most important
>> being renaming temp to temperature. I noticed for the relaxed energy
>> scan (ethanol.out), the attributes related to the scan are not added.
>> Is this something that should be handled?
>>
>> Noel, Karol: shall we standardize the thermochemistry info (i.e.
>> temperature, freeenergy, enthalpy, entropy), and add it to the other
>> parsers? This info should already be in the IR and Raman logfiles.
>>
>> Adam
>>
>>
>> On Tue, Apr 17, 2012 at 6:41 AM, Edward Holland <hol...@ca...> wrote:
>>> Hi All,
>>>
>>> I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this.
>>> I have attached the patch file
>>>
>>> Hope you find the changes acceptable
>>>
>>> Yours
>>>
>>> Ed Holland
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Better than sec? Nothing is better than sec when it comes to
>>> monitoring Big Data applications. Try Boundary one-second
>>> resolution app monitoring today. Free.
>>> http://p.sf.net/sfu/Boundary-dev2dev
>>> _______________________________________________
>>> cclib-devel mailing list
>>> ccl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
> --
> written by Karol M. Langner
> Mon Apr 23 10:11:41 CEST 2012
|
|
From: Karol M. L. <kar...@gm...> - 2012-04-23 08:18:32
|
Hi guys, Yes, it would be good to standardize this. Several initial thoughts: 1) attribute optdone is not useful and in fact not used 2) we should separate the changes related to thermochem. and scans 3) do we have test output files to work on scans? do we really need attributes such as scanenergies, when, for example for geometry optimization, we pack all the values into 'scfenergies', etc.? In principle we could do the same in this case - Karol On Apr 22 2012, Adam Tenderholt wrote: > Hi Ed, > > Thank you for the patch. I made a few changes, the most important > being renaming temp to temperature. I noticed for the relaxed energy > scan (ethanol.out), the attributes related to the scan are not added. > Is this something that should be handled? > > Noel, Karol: shall we standardize the thermochemistry info (i.e. > temperature, freeenergy, enthalpy, entropy), and add it to the other > parsers? This info should already be in the IR and Raman logfiles. > > Adam > > > On Tue, Apr 17, 2012 at 6:41 AM, Edward Holland <hol...@ca...> wrote: > > Hi All, > > > > I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this. > > I have attached the patch file > > > > Hope you find the changes acceptable > > > > Yours > > > > Ed Holland > > > > > > ------------------------------------------------------------------------------ > > Better than sec? Nothing is better than sec when it comes to > > monitoring Big Data applications. Try Boundary one-second > > resolution app monitoring today. Free. > > http://p.sf.net/sfu/Boundary-dev2dev > > _______________________________________________ > > cclib-devel mailing list > > ccl...@li... > > https://lists.sourceforge.net/lists/listinfo/cclib-devel > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel -- written by Karol M. Langner Mon Apr 23 10:11:41 CEST 2012 |
|
From: Adam T. <ate...@gm...> - 2012-04-22 18:13:16
|
Hi Ed, Thank you for the patch. I made a few changes, the most important being renaming temp to temperature. I noticed for the relaxed energy scan (ethanol.out), the attributes related to the scan are not added. Is this something that should be handled? Noel, Karol: shall we standardize the thermochemistry info (i.e. temperature, freeenergy, enthalpy, entropy), and add it to the other parsers? This info should already be in the IR and Raman logfiles. Adam On Tue, Apr 17, 2012 at 6:41 AM, Edward Holland <hol...@ca...> wrote: > Hi All, > > I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this. > I have attached the patch file > > Hope you find the changes acceptable > > Yours > > Ed Holland > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Adam T. <ate...@gm...> - 2012-04-22 17:34:46
|
Any reason the copyright dates weren't updated to include 2012? On Thu, Apr 19, 2012 at 9:10 AM, Noel O'Boyle <bao...@gm...> wrote: > Hmmm...I guess you're right - we should just leave it. It's clear from the > source that a later version can be used instead. > > - Noel > > > On 19 April 2012 17:07, Karol M. Langner <kar...@gm...> wrote: >> >> With? Version 3 of the LGPL? >> >> On Apr 19 2012, Noel O'Boyle wrote: >> > Looks good. We should probably replace LICENSE.txt too. >> > >> > On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> >> > wrote: >> > >> > > Done. Please review. >> > > >> > > On Apr 19 2012, Noel O'Boyle wrote: >> > > > Both, I guess. >> > > > >> > > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> >> > > wrote: >> > > > >> > > > > Hi, >> > > > > >> > > > > Let's get this done. I'll do it, but I'm not sure where I should >> > > > > change >> > > > > it. Should I update the license in every source file, or just in >> > > > > the >> > > > > LICENSE file? >> > > > > >> > > > > - Karol >> > > > > >> > > > > On Apr 13 2011, Karol M. Langner wrote: >> > > > > > 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 >> > > > > >> > > > > -- >> > > > > written by Karol Langner >> > > > > Thu Apr 19 13:24:30 CEST 2012 >> > > > > >> > > >> > > -- >> > > written by Karol Langner >> > > Thu Apr 19 16:16:58 CEST 2012 >> > > >> >> -- >> written by Karol Langner >> Thu Apr 19 18:06:53 CEST 2012 > > |
|
From: SourceForge.net <no...@so...> - 2012-04-19 16:58:10
|
Feature Requests item #3518357, was opened at 2012-04-15 23:11 Message generated for change (Comment added) made by atenderholt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819225&aid=3518357&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: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: ORCA support Initial Comment: Orca is a great and free to use program for computational chemistry. Supporting ORCA-output files would be nice. ---------------------------------------------------------------------- >Comment By: Adam Tenderholt (atenderholt) Date: 2012-04-19 09:58 Message: Karol just pointed out that the Orca parser was merged into trunk a long time ago. Upon further investigation, I see that this parser was included in cclib 1.0.1. I'm closing this ticket. ---------------------------------------------------------------------- Comment By: Adam Tenderholt (atenderholt) Date: 2012-04-16 09:15 Message: There is an ORCA branch in SVN, although it hasn't been tested with the newer versions of ORCA (i.e. 2.8 and 2.9). If you need help with getting or using the SVN version, please don't hesitate to ask. Adam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819225&aid=3518357&group_id=161285 |
|
From: Karol M. L. <kar...@gm...> - 2012-04-19 16:43:55
|
>From what I can see, the ORCA parser was alraedy merged into trunk. If there is nothing new there (I've looked only at the parser source), then I think the branch should be deleted, or marked somehow as inactive. As far as I can see, the other parse branches (Molcas, NWChem, Turbomole) have not been merged into trunk yet. Karol On Apr 19 2012, Adam Tenderholt wrote: > With the recent talk about updating the license of cclib, it got me > thinking that we might need to perform some maintenance on the > branches since several are quite old (e.g. Orca). Is it best to make > sure the new parsers in those branches are well-supported, and then > merge those changes into trunk? Or should we merge trunk into those > branches? > > Adam > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel -- written by Karol Langner Thu Apr 19 18:39:04 CEST 2012 |
|
From: Adam T. <ate...@gm...> - 2012-04-19 16:19:59
|
With the recent talk about updating the license of cclib, it got me thinking that we might need to perform some maintenance on the branches since several are quite old (e.g. Orca). Is it best to make sure the new parsers in those branches are well-supported, and then merge those changes into trunk? Or should we merge trunk into those branches? Adam |
|
From: Noel O'B. <bao...@gm...> - 2012-04-19 16:11:10
|
Hmmm...I guess you're right - we should just leave it. It's clear from the source that a later version can be used instead. - Noel On 19 April 2012 17:07, Karol M. Langner <kar...@gm...> wrote: > With? Version 3 of the LGPL? > > On Apr 19 2012, Noel O'Boyle wrote: > > Looks good. We should probably replace LICENSE.txt too. > > > > On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> > wrote: > > > > > Done. Please review. > > > > > > On Apr 19 2012, Noel O'Boyle wrote: > > > > Both, I guess. > > > > > > > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > Let's get this done. I'll do it, but I'm not sure where I should > change > > > > > it. Should I update the license in every source file, or just in > the > > > > > LICENSE file? > > > > > > > > > > - Karol > > > > > > > > > > On Apr 13 2011, Karol M. Langner wrote: > > > > > > 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 > > > > > > > > > > -- > > > > > written by Karol Langner > > > > > Thu Apr 19 13:24:30 CEST 2012 > > > > > > > > > > > -- > > > written by Karol Langner > > > Thu Apr 19 16:16:58 CEST 2012 > > > > > -- > written by Karol Langner > Thu Apr 19 18:06:53 CEST 2012 > |
|
From: Karol M. L. <kar...@gm...> - 2012-04-19 16:07:58
|
With? Version 3 of the LGPL? On Apr 19 2012, Noel O'Boyle wrote: > Looks good. We should probably replace LICENSE.txt too. > > On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> wrote: > > > Done. Please review. > > > > On Apr 19 2012, Noel O'Boyle wrote: > > > Both, I guess. > > > > > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> > > wrote: > > > > > > > Hi, > > > > > > > > Let's get this done. I'll do it, but I'm not sure where I should change > > > > it. Should I update the license in every source file, or just in the > > > > LICENSE file? > > > > > > > > - Karol > > > > > > > > On Apr 13 2011, Karol M. Langner wrote: > > > > > 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 > > > > > > > > -- > > > > written by Karol Langner > > > > Thu Apr 19 13:24:30 CEST 2012 > > > > > > > > -- > > written by Karol Langner > > Thu Apr 19 16:16:58 CEST 2012 > > -- written by Karol Langner Thu Apr 19 18:06:53 CEST 2012 |
|
From: Adam T. <ate...@gm...> - 2012-04-19 16:07:02
|
Thanks for taking care of this. On Thu, Apr 19, 2012 at 8:37 AM, Noel O'Boyle <bao...@gm...> wrote: > Looks good. We should probably replace LICENSE.txt too. > > > On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> wrote: >> >> Done. Please review. >> >> On Apr 19 2012, Noel O'Boyle wrote: >> > Both, I guess. >> > >> > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> >> > wrote: >> > >> > > Hi, >> > > >> > > Let's get this done. I'll do it, but I'm not sure where I should >> > > change >> > > it. Should I update the license in every source file, or just in the >> > > LICENSE file? >> > > >> > > - Karol >> > > >> > > On Apr 13 2011, Karol M. Langner wrote: >> > > > 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 >> > > >> > > -- >> > > written by Karol Langner >> > > Thu Apr 19 13:24:30 CEST 2012 >> > > >> >> -- >> written by Karol Langner >> Thu Apr 19 16:16:58 CEST 2012 > > |
|
From: Noel O'B. <bao...@gm...> - 2012-04-19 15:38:07
|
Looks good. We should probably replace LICENSE.txt too. On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> wrote: > Done. Please review. > > On Apr 19 2012, Noel O'Boyle wrote: > > Both, I guess. > > > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> > wrote: > > > > > Hi, > > > > > > Let's get this done. I'll do it, but I'm not sure where I should change > > > it. Should I update the license in every source file, or just in the > > > LICENSE file? > > > > > > - Karol > > > > > > On Apr 13 2011, Karol M. Langner wrote: > > > > 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 > > > > > > -- > > > written by Karol Langner > > > Thu Apr 19 13:24:30 CEST 2012 > > > > > -- > written by Karol Langner > Thu Apr 19 16:16:58 CEST 2012 > |
|
From: Karol M. L. <kar...@gm...> - 2012-04-19 14:18:01
|
Done. Please review. On Apr 19 2012, Noel O'Boyle wrote: > Both, I guess. > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> wrote: > > > Hi, > > > > Let's get this done. I'll do it, but I'm not sure where I should change > > it. Should I update the license in every source file, or just in the > > LICENSE file? > > > > - Karol > > > > On Apr 13 2011, Karol M. Langner wrote: > > > 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 > > > > -- > > written by Karol Langner > > Thu Apr 19 13:24:30 CEST 2012 > > -- written by Karol Langner Thu Apr 19 16:16:58 CEST 2012 |
|
From: Noel O'B. <bao...@gm...> - 2012-04-19 12:10:59
|
Both, I guess. On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> wrote: > Hi, > > Let's get this done. I'll do it, but I'm not sure where I should change > it. Should I update the license in every source file, or just in the > LICENSE file? > > - Karol > > On Apr 13 2011, Karol M. Langner wrote: > > 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 > > -- > written by Karol Langner > Thu Apr 19 13:24:30 CEST 2012 > |
|
From: Karol M. L. <kar...@gm...> - 2012-04-19 11:31:22
|
Hi, Let's get this done. I'll do it, but I'm not sure where I should change it. Should I update the license in every source file, or just in the LICENSE file? - Karol On Apr 13 2011, Karol M. Langner wrote: > 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 -- written by Karol Langner Thu Apr 19 13:24:30 CEST 2012 |
|
From: Edward H. <hol...@ca...> - 2012-04-17 13:41:48
|
Hi All, I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this. I have attached the patch file |
|
From: SourceForge.net <no...@so...> - 2012-04-16 16:15:32
|
Feature Requests item #3518357, was opened at 2012-04-15 23:11 Message generated for change (Comment added) made by atenderholt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819225&aid=3518357&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: None Group: None Status: Open Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: ORCA support Initial Comment: Orca is a great and free to use program for computational chemistry. Supporting ORCA-output files would be nice. ---------------------------------------------------------------------- >Comment By: Adam Tenderholt (atenderholt) Date: 2012-04-16 09:15 Message: There is an ORCA branch in SVN, although it hasn't been tested with the newer versions of ORCA (i.e. 2.8 and 2.9). If you need help with getting or using the SVN version, please don't hesitate to ask. Adam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819225&aid=3518357&group_id=161285 |
|
From: SourceForge.net <no...@so...> - 2012-04-16 06:11:08
|
Feature Requests item #3518357, was opened at 2012-04-15 23:11 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819225&aid=3518357&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: None Group: None Status: Open Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: ORCA support Initial Comment: Orca is a great and free to use program for computational chemistry. Supporting ORCA-output files would be nice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819225&aid=3518357&group_id=161285 |
|
From: Adam T. <ate...@gm...> - 2012-04-01 17:53:01
|
Hi Pavlo,
Can you supply cclib with a public domain file that has this problem? We should have similar file in our regression tests.
Thanks,
Adam
On Apr 1, 2012, at 9:02 AM, Pavel Solntsev wrote:
> Dear Adam.
>
> I found another bug in cclib.
> If you have ECP job cclib doesn't extract correct number for HOMO orbitals.
> Firefly removes all core electrons and corresponding orbitals. All
> another orbitals are renumbered. After that number of the HOMO orbital
> will be lower by number of the core orbitals. I solved program by
> commenting couple lines in the gamessparser.py file. Now cclib works
> correctly with FF output files with and without ECP. I didn't check
> cclib with GAMESS US, but it looks like it should not be any problem.
>
> # line 857
> if line[1:28] == "NUMBER OF OCCUPIED ORBITALS" and not
> hasattr(self,'homos'):
> homos = [int(line.split()[-1])-1]
> line = inputfile.next()
> homos.append(int(line.split()[-1])-1)
> self.homos = numpy.array(homos, "i")
>
>
> All the best.
>
> Pavlo.
>
>
>
> On 03/28/2012 11:19 AM, Adam Tenderholt wrote:
>> Oops, one minor mistake in my email. You need to keep the following
>> line (since it does all the parsing magic):
>>
>> 150 data = parser.parse()
>>
>> Adam
>>
>>
>> On Wed, Mar 28, 2012 at 9:18 AM, Adam Tenderholt <ate...@gm...> wrote:
>>> Hi Pavel,
>>>
>>> Your error now looks like a problem with QMForge. For the windows and
>>> Mac version, I wanted the cclib info/warning/errors to be displayed in
>>> a nice window after parsing the file. This, however, appears to be
>>> broken due to Qt 4.8 (I think I wrote QMForge with Qt 4.4 or 4.5 in
>>> mind...it's been too long).
>>>
>>> The easiest fix that will get you up and running involves changing the
>>> source code of QMForge a bit. Edit qmforge.py, go to the open function
>>> (near line 126), and comment out (or remove) the following lines:
>>>
>>> 129 viewer = LogViewer(self)
>>>
>>> and
>>>
>>> 149 parser.logger.addHandler(viewer)
>>> 150 data = parser.parse()
>>> 151 warnings = viewer.ui.textEdit.toPlainText()
>>> 152 if len(warnings) > 0:
>>> 153 viewer.show()
>>>
>>> Let me know if this works for you. The info/warnings/errors from cclib
>>> should be printed in the console.
>>>
>>> Take care,
>>>
>>> Adam
>>>
>>>
>>> On Wed, Mar 28, 2012 at 7:34 AM, Pavel Solntsev
>>> <pav...@gm...> wrote:
>>>> Hi Adam.
>>>>
>>>> I checked another output file from Firefly with last version of the
>>>> cclib and also found some problems .
>>>> In terminal i can see:
>>>> $ qmforge
>>>> [GAMESS
>>>> /home/pavel/Documents/people/Lysenko/IC/ag2trz2/sp/ag2trz2_ci_sp_b3lyp.out
>>>> WARNING] Number of occupied orbitals not consistent. This is normal for
>>>> ECP and FMO jobs.
>>>> Traceback (most recent call last):
>>>> File "/usr/local/lib/python2.7/dist-packages/qmforge/qmforge.py", line
>>>> 250, in fileOpen
>>>> File "/usr/local/lib/python2.7/dist-packages/qmforge/qmforge.py", line
>>>> 150, in open
>>>> 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 877, in extract
>>>> self.logger.warning("Number of occupied orbitals not consistent.
>>>> This is normal for ECP and FMO jobs.")
>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1144, in warning
>>>> self._log(WARNING, msg, args, **kwargs)
>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1250, in _log
>>>> self.handle(record)
>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1260, in handle
>>>> self.callHandlers(record)
>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1300, in callHandlers
>>>> hdlr.handle(record)
>>>> TypeError: QWidget.handle(): too many arguments
>>>> $
>>>>
>>>> My input file is normal single point run with ECP.
>>>> $CONTRL SCFTYP=RHF RUNTYP=energy
>>>> DFTTYP=B3LYP
>>>> MAXIT=100 inttyp=hondo icut=10 itol=30
>>>> ICHARG=2 MULT=1
>>>> ecp=read exetyp=run $END
>>>> $SYSTEM TIMLIM=9999999 mwords=40 $END
>>>> $BASIS extfil=.t. $END
>>>> $SCF DIRSCF=.TRUE. fdiff=.t. $END
>>>> $smp call64=.t. $end
>>>> $DATA
>>>> Ci
>>>>
>>>> coordinates
>>>>
>>>> $ecp
>>>> ......
>>>> $end
>>>>
>>>> Unfortunately i can't provide this file in the public domain, but i can
>>>> send it to you.
>>>>
>>>> Thank you very much for you help.
>>>>
>>>> PS.
>>>>
>>>>
>>>>
>>>>
>>>> On 03/25/2012 01:09 PM, Adam Tenderholt wrote:
>>>>> Hi Pavel,
>>>>>
>>>>> I have fixed this bug in the svn trunk version of cclib. Please let me know if you'd prefer me to send you the updated source code.
>>>>>
>>>>> Take care,
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Mar 22, 2012, at 9:04 AM, Pavel Solntsev wrote:
>>>>>
>>>>>> Yes. You can place this log file in the public domain
>>>>>>
>>>>>> PS.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 03/22/2012 05:44 AM, Noel O'Boyle wrote:
>>>>>>> Hello Pavel,
>>>>>>>
>>>>>>> We have a policy of only fixing bugs for public domain log files. Are
>>>>>>> you happy to place this log file in the public domain?
>>>>>>>
>>>>>>> - Noel
>>>>>>>
>>>>>>> On 22 March 2012 05:12, Pavel Solntsev <pav...@gm...> wrote:
>>>>>>>> Hi i have a file from Firefly ( pcgamess)i can't parse with cclib. I use
>>>>>>>> version form svn and QMforge program. In console i got
>>>>>>>> [GAMESS <path to my file>/triazole_tddft_c1_b3lyp_631Gdp_sp.out WARNING]
>>>>>>>> MO section found but could not be parsed!
>>>>>>>> Traceback (most recent call last):
>>>>>>>> File "/usr/local/lib/python2.7/dist-packages/qmforge/qmforge.py", line
>>>>>>>> 250, in fileOpen
>>>>>>>> File "/usr/local/lib/python2.7/dist-packages/qmforge/qmforge.py", line
>>>>>>>> 150, in open
>>>>>>>> File
>>>>>>>> "/usr/local/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
>>>>>>>> line 221, in parse
>>>>>>>> File
>>>>>>>> "/usr/local/lib/python2.7/dist-packages/cclib/parser/gamessparser.py",
>>>>>>>> line 720, in extract
>>>>>>>> self.logger.warning('MO section found but could not be parsed!')
>>>>>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1144, in warning
>>>>>>>> self._log(WARNING, msg, args, **kwargs)
>>>>>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1250, in _log
>>>>>>>> self.handle(record)
>>>>>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1260, in handle
>>>>>>>> self.callHandlers(record)
>>>>>>>> File "/usr/lib/python2.7/logging/__init__.py", line 1300, in callHandlers
>>>>>>>> hdlr.handle(record)
>>>>>>>> TypeError: QWidget.handle(): too many arguments
>>>>>>>>
>>>>>>>> If i run this file with gamess us it goes withput problems. The problem
>>>>>>>> file for Firefly is attached.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>> Pavlo.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pavlo V. Solntsev
>>>>>>>> pavlo.solntsev at gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> This SF email is sponsosred by:
>>>>>>>> Try Windows Azure free for 90 days Click Here
>>>>>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>>>>>> _______________________________________________
>>>>>>>> cclib-devel mailing list
>>>>>>>> ccl...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>>>>>>>
>>>>>> --
>>>>>> Pavlo V. Solntsev
>>>>>> pavlo.solntsev at gmail.com
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> This SF email is sponsosred by:
>>>>>> Try Windows Azure free for 90 days Click Here
>>>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>>>> _______________________________________________
>>>>>> cclib-devel mailing list
>>>>>> ccl...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>>>
>>>> --
>>>> Pavlo V. Solntsev
>>>> pavlo.solntsev at gmail.com
>>>>
>
>
> --
> Pavlo V. Solntsev
> pavlo.solntsev at gmail.com
>
|
