From: SourceForge.net <no...@so...> - 2010-06-17 05:24:53
|
Bugs item #3017436, was opened at 2010-06-16 22:24 Message generated for change (Tracker Item Submitted) made by atenderholt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&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: Adam Tenderholt (atenderholt) Assigned to: Nobody/Anonymous (nobody) Summary: assert nmo == self.nmo fails Initial Comment: Gaussian 03 log file from an optimization fails to parse correctly. NBsUse changes during the optimization. I initially thought it was dropping functions when converting from cartesian to spherical coordinates (d orbitals), but specifying 5D didn't help. This is using Python 2.6.x on a Mac with cclib trunk (r908). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285 |
From: SourceForge.net <no...@so...> - 2010-06-23 18:59:33
|
Bugs item #3017436, was opened at 2010-06-17 06:24 Message generated for change (Comment added) made by baoilleach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&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: Adam Tenderholt (atenderholt) Assigned to: Nobody/Anonymous (nobody) Summary: assert nmo == self.nmo fails Initial Comment: Gaussian 03 log file from an optimization fails to parse correctly. NBsUse changes during the optimization. I initially thought it was dropping functions when converting from cartesian to spherical coordinates (d orbitals), but specifying 5D didn't help. This is using Python 2.6.x on a Mac with cclib trunk (r908). ---------------------------------------------------------------------- >Comment By: Noel O'Boyle (baoilleach) Date: 2010-06-23 19:59 Message: Fixed in r909. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285 |
From: Karol M. L. <km...@mm...> - 2010-06-19 11:51:44
|
I've run into this before, but did not happen to run cclib on the file. I think this happens when Gaussian detects linear dependencies in the basis set, which can happend as the geometry changes. So, how do we deal with this? The parser shouldn't break at lease, so do we loosen the assert here and just issue a warning? Some further parts of the parser assume that nmo does not change, so it might raise other problems when nmo changes. - Karol On Thursday 17 June 2010 07:24:53 SourceForge.net wrote: > Bugs item #3017436, was opened at 2010-06-16 22:24 > Message generated for change (Tracker Item Submitted) made by atenderholt > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&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: Adam Tenderholt (atenderholt) > Assigned to: Nobody/Anonymous (nobody) > Summary: assert nmo == self.nmo fails > > Initial Comment: > Gaussian 03 log file from an optimization fails to parse correctly. NBsUse > changes during the optimization. I initially thought it was dropping > functions when converting from cartesian to spherical coordinates (d > orbitals), but specifying 5D didn't help. > > This is using Python 2.6.x on a Mac with cclib trunk (r908). -- written by Karol Langner Sat Jun 19 13:25:50 CEST 2010 |
From: Noel O'B. <bao...@gm...> - 2010-06-23 19:01:36
|
On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote: > I've run into this before, but did not happen to run cclib on the file. I > think this happens when Gaussian detects linear dependencies in the basis > set, which can happend as the geometry changes. That's right. > So, how do we deal with this? The parser shouldn't break at lease, so do we > loosen the assert here and just issue a warning? Some further parts of the > parser assume that nmo does not change, so it might raise other problems when > nmo changes. I just removed the assert statement in r909. I only added it to be careful. In reality, it doesn't affect anything, as the value will be correct for whatever is parsed after that. > - Karol > > On Thursday 17 June 2010 07:24:53 SourceForge.net wrote: >> Bugs item #3017436, was opened at 2010-06-16 22:24 >> Message generated for change (Tracker Item Submitted) made by atenderholt >> You can respond by visiting: >> https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&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: Adam Tenderholt (atenderholt) >> Assigned to: Nobody/Anonymous (nobody) >> Summary: assert nmo == self.nmo fails >> >> Initial Comment: >> Gaussian 03 log file from an optimization fails to parse correctly. NBsUse >> changes during the optimization. I initially thought it was dropping >> functions when converting from cartesian to spherical coordinates (d >> orbitals), but specifying 5D didn't help. >> >> This is using Python 2.6.x on a Mac with cclib trunk (r908). > > -- > written by Karol Langner > Sat Jun 19 13:25:50 CEST 2010 > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
From: Karol M. L. <km...@mm...> - 2010-06-23 19:59:05
|
On Wednesday 23 June 2010 21:01:29 Noel O'Boyle wrote: > On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote: > > I've run into this before, but did not happen to run cclib on the file. I > > think this happens when Gaussian detects linear dependencies in the > > basis set, which can happend as the geometry changes. > > That's right. > > > So, how do we deal with this? The parser shouldn't break at lease, so do > > we loosen the assert here and just issue a warning? Some further parts of > > the parser assume that nmo does not change, so it might raise other > > problems when nmo changes. > > I just removed the assert statement in r909. I only added it to be > careful. In reality, it doesn't affect anything, as the value will be > correct for whatever is parsed after that. Maybe issue a warning to the logger? -- written by Karol Langner Wed Jun 23 21:56:06 CEST 2010 |
From: Noel O'B. <bao...@gm...> - 2010-06-23 20:06:28
|
On 23 June 2010 20:56, Karol M. Langner <km...@mm...> wrote: > On Wednesday 23 June 2010 21:01:29 Noel O'Boyle wrote: >> On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote: >> > I've run into this before, but did not happen to run cclib on the file. I >> > think this happens when Gaussian detects linear dependencies in the >> > basis set, which can happend as the geometry changes. >> >> That's right. >> >> > So, how do we deal with this? The parser shouldn't break at lease, so do >> > we loosen the assert here and just issue a warning? Some further parts of >> > the parser assume that nmo does not change, so it might raise other >> > problems when nmo changes. >> >> I just removed the assert statement in r909. I only added it to be >> careful. In reality, it doesn't affect anything, as the value will be >> correct for whatever is parsed after that. > > Maybe issue a warning to the logger? Well, you know, it's really our responsibility to sort it out - passing the warning onto the user wouldn't be fair. I'm pretty happy that this is fine. Everything is parsed in order, so the value of nbasis available at any point will be the correct one. > -- > written by Karol Langner > Wed Jun 23 21:56:06 CEST 2010 > |