cclib-devel — Developer's mailing list

Re: [cclib-devel] GAMESS-US 2012

[Karol M. L. <kar...@gm...>]

On Nov 28 2012, Noel O'Boyle wrote:
> Sounds fine. We should never remove a test though, so I'd appreciate
> if you could move the old test to regressions.py with some sort of
> basic testing code (e.g. that it has the right number of etsecs).

What I did is call the appropriate unit test from a dynamically
generated function in the regression suite. This function is generated
as long as the logfile location is added to a list called 'old_tests'
inside the unit test class. It is clear from the code (I hope).

This makes archiving old logfiles as regressions easy and should scale
reasonably for doing such updates in the future. To withhold the unit
test for any reason for a particular regressed logfile (like in the
triplet TD case I brought up) just omit it from old_tests.

That being said, I will now update all GAMESS-US unit tests to the
newest 2012 version. Feel free to follow suit for other parsers, if you
like.

> Regarding parsing the version, I'm not too keen on parsing such
> metadata. That's going down a particular path we haven't gone down
> before. Maybe you can argue me around, but for sure we should not use
> version information during the parsing.

That's not what I had in mind. In any case, I don't wish or have the
free time to do this without a particular reason.

Cheers,
Karol

> On 28 November 2012 00:16, Karol M. Langner <kar...@gm...> wrote:
> > OK, I took another look at the GAMESS-US test files. It seems that
> > the files in basicGAMESS-US are from various different versions.
> > So, it seems more reasonable to just update the one output file
> > that gives more consistent results for dvb_td_triplet (that is, etsecs
> > sum up closer to 1), and possibly those that have changed substantially
> > in the new version of GAMESS-US and require parser work.
> >
> > That leaves the question, then, what to do with the old output files,
> > which are not from one set version. Rename with a version postfix and
> > transfer to regressions?
> >
> > Another option would be to just add additional logfiles for the outputs
> > that have changes, by adding _a or _b to the names like was done in the
> > case of several other parser.
> >
> > Let me know what you think,
> > Karol
> >
> > P.S. It also seems now a good idea to me to parse the version of a
> > program for information purposes, and it should be quite easy.
> >
> > On Nov 28 2012, Karol M. Langner wrote:
> >> Hi guys,
> >>
> >> I propose to update the GAMESS-US standard tests. The main motivation
> >> for this is that the dvb_td_triplet test in the 2012 version actually
> >> passes all the unit tests we have (the 2010 fails in one case). Also,
> >> there are some formatting changes in the output files, so some
> >> straightforward update to the parser is in order. I have all the output
> >> files ready.
> >>
> >> Let me know what you think. And, what do we do with the current output
> >> files in basicGAMESS-US? We should still make sure they are parsed
> >> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
> >> discussed some time ago, or rather to the regression suite?
> >>
> >> - Karol

-- 
written by Karol M. Langner
Fri Nov 30 00:00:09 CET 2012

Re: [cclib-devel] GAMESS-US 2012

[Noel O'B. <bao...@gm...>]

Sounds fine. We should never remove a test though, so I'd appreciate
if you could move the old test to regressions.py with some sort of
basic testing code (e.g. that it has the right number of etsecs).

Regarding parsing the version, I'm not too keen on parsing such
metadata. That's going down a particular path we haven't gone down
before. Maybe you can argue me around, but for sure we should not use
version information during the parsing.

- Noel

On 28 November 2012 00:16, Karol M. Langner <kar...@gm...> wrote:
> OK, I took another look at the GAMESS-US test files. It seems that
> the files in basicGAMESS-US are from various different versions.
> So, it seems more reasonable to just update the one output file
> that gives more consistent results for dvb_td_triplet (that is, etsecs
> sum up closer to 1), and possibly those that have changed substantially
> in the new version of GAMESS-US and require parser work.
>
> That leaves the question, then, what to do with the old output files,
> which are not from one set version. Rename with a version postfix and
> transfer to regressions?
>
> Another option would be to just add additional logfiles for the outputs
> that have changes, by adding _a or _b to the names like was done in the
> case of several other parser.
>
> Let me know what you think,
> Karol
>
> P.S. It also seems now a good idea to me to parse the version of a
> program for information purposes, and it should be quite easy.
>
> On Nov 28 2012, Karol M. Langner wrote:
>> Hi guys,
>>
>> I propose to update the GAMESS-US standard tests. The main motivation
>> for this is that the dvb_td_triplet test in the 2012 version actually
>> passes all the unit tests we have (the 2010 fails in one case). Also,
>> there are some formatting changes in the output files, so some
>> straightforward update to the parser is in order. I have all the output
>> files ready.
>>
>> Let me know what you think. And, what do we do with the current output
>> files in basicGAMESS-US? We should still make sure they are parsed
>> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
>> discussed some time ago, or rather to the regression suite?
>>
>> - Karol
>
> --
> written by Karol M. Langner
> Wed Nov 28 01:06:36 CET 2012
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] GAMESS-US 2012

[Karol M. L. <kar...@gm...>]

OK, I took another look at the GAMESS-US test files. It seems that
the files in basicGAMESS-US are from various different versions.
So, it seems more reasonable to just update the one output file
that gives more consistent results for dvb_td_triplet (that is, etsecs
sum up closer to 1), and possibly those that have changed substantially
in the new version of GAMESS-US and require parser work.

That leaves the question, then, what to do with the old output files,
which are not from one set version. Rename with a version postfix and
transfer to regressions?

Another option would be to just add additional logfiles for the outputs
that have changes, by adding _a or _b to the names like was done in the
case of several other parser.

Let me know what you think,
Karol

P.S. It also seems now a good idea to me to parse the version of a
program for information purposes, and it should be quite easy.

On Nov 28 2012, Karol M. Langner wrote:
> Hi guys,
> 
> I propose to update the GAMESS-US standard tests. The main motivation
> for this is that the dvb_td_triplet test in the 2012 version actually
> passes all the unit tests we have (the 2010 fails in one case). Also,
> there are some formatting changes in the output files, so some
> straightforward update to the parser is in order. I have all the output
> files ready.
> 
> Let me know what you think. And, what do we do with the current output
> files in basicGAMESS-US? We should still make sure they are parsed
> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
> discussed some time ago, or rather to the regression suite?
> 
> - Karol

-- 
written by Karol M. Langner
Wed Nov 28 01:06:36 CET 2012

[cclib-devel] GAMESS-US 2012

[Karol M. L. <kar...@gm...>]

Hi guys,

I propose to update the GAMESS-US standard tests. The main motivation
for this is that the dvb_td_triplet test in the 2012 version actually
passes all the unit tests we have (the 2010 fails in one case). Also,
there are some formatting changes in the output files, so some
straightforward update to the parser is in order. I have all the output
files ready.

Let me know what you think. And, what do we do with the current output
files in basicGAMESS-US? We should still make sure they are parsed
correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
discussed some time ago, or rather to the regression suite?

- Karol

-- 
written by Karol M. Langner
Wed Nov 28 00:30:53 CET 2012

[cclib-devel] [ cclib-Bugs-3168810 ] Problem parsing Gaussian ONIOM

[SourceForge.net <no...@so...>]

Bugs item #3168810, was opened at 2011-01-31 09:11
Message generated for change (Settings changed) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&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: Noel O'Boyle (baoilleach)
>Assigned to: Noel O'Boyle (baoilleach)
Summary: Problem parsing Gaussian ONIOM

Initial Comment:
This came from a GaussSum user ((kar...@ug...). I didn't see a quick fix so I'm posting here to avoid forgetting about it...

The attached ONIOM file fails to parse correctly.

----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2012-11-07 01:53

Message:
I don't think so. I'm assigning it to me.

I'm going to be spending some time sorting out my non-Open Babel projects
between now and the end of the year, so I'll come back to this. Right now
I'll making some changes to GaussSum.

----------------------------------------------------------------------

Comment By: Karol Langner (langner)
Date: 2012-11-05 13:43

Message:
Has this been fixed in the end?

----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-02-01 04:11

Message:
Yes - that's it.

----------------------------------------------------------------------

Comment By: Adam Tenderholt (atenderholt)
Date: 2011-01-31 13:27

Message:
What is the parsing error? I'm getting the following error, which seems
easy-ish to fix:

---
Attempting to parse ortho_prod_freq.log
Traceback (most recent call last):
  File "/usr/local/bin/ccget", line 99, in <module>
    main()
  File "/usr/local/bin/ccget", line 81, in main
    data = log.parse()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/logfileparser.py",
line 221, in parse
    self.extract(inputfile, line)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/gaussianparser.py",
line 866, in extract
    mocoeffs = [numpy.zeros((self.nmo, self.nbasis), "d")]
AttributeError: 'Gaussian' object has no attribute 'nmo'
---



----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-01-31 09:15

Message:
File too large to attach. Please find it at
http://www.redbrick.dcu.ie/~noel/tmp/ortho_prod_freq.zip. I can confirm
that it was placed in the public domain (by the bug reporter).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&group_id=161285

[cclib-devel] [ cclib-Bugs-3168810 ] Problem parsing Gaussian ONIOM

[SourceForge.net <no...@so...>]

Bugs item #3168810, was opened at 2011-01-31 09:11
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&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: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing Gaussian ONIOM

Initial Comment:
This came from a GaussSum user ((kar...@ug...). I didn't see a quick fix so I'm posting here to avoid forgetting about it...

The attached ONIOM file fails to parse correctly.

----------------------------------------------------------------------

>Comment By: Noel O'Boyle (baoilleach)
Date: 2012-11-07 01:53

Message:
I don't think so. I'm assigning it to me.

I'm going to be spending some time sorting out my non-Open Babel projects
between now and the end of the year, so I'll come back to this. Right now
I'll making some changes to GaussSum.

----------------------------------------------------------------------

Comment By: Karol Langner (langner)
Date: 2012-11-05 13:43

Message:
Has this been fixed in the end?

----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-02-01 04:11

Message:
Yes - that's it.

----------------------------------------------------------------------

Comment By: Adam Tenderholt (atenderholt)
Date: 2011-01-31 13:27

Message:
What is the parsing error? I'm getting the following error, which seems
easy-ish to fix:

---
Attempting to parse ortho_prod_freq.log
Traceback (most recent call last):
  File "/usr/local/bin/ccget", line 99, in <module>
    main()
  File "/usr/local/bin/ccget", line 81, in main
    data = log.parse()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/logfileparser.py",
line 221, in parse
    self.extract(inputfile, line)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/gaussianparser.py",
line 866, in extract
    mocoeffs = [numpy.zeros((self.nmo, self.nbasis), "d")]
AttributeError: 'Gaussian' object has no attribute 'nmo'
---



----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-01-31 09:15

Message:
File too large to attach. Please find it at
http://www.redbrick.dcu.ie/~noel/tmp/ortho_prod_freq.zip. I can confirm
that it was placed in the public domain (by the bug reporter).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&group_id=161285

[cclib-devel] [ cclib-Bugs-3476063 ] Failed hessian parsing for newer GAMESS-US

[SourceForge.net <no...@so...>]

Bugs item #3476063, was opened at 2012-01-19 06:23
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3476063&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
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Karol Langner (langner)
Assigned to: Karol Langner (langner)
Summary: Failed hessian parsing for newer GAMESS-US

Initial Comment:
Chengju Wang reported this on the cclib-users list.

----------------------------------------------------------------------

>Comment By: Karol Langner (langner)
Date: 2012-11-05 16:16

Message:
Closing, since fixed and file is now a regression.

----------------------------------------------------------------------

Comment By: Karol Langner (langner)
Date: 2012-01-19 06:49

Message:
Fixed with commit r951. The log file now parses.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3476063&group_id=161285

[cclib-devel] [ cclib-Bugs-3184890 ] ORCA doesn't parse scf energy

[SourceForge.net <no...@so...>]

Bugs item #3184890, was opened at 2011-02-17 06:24
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3184890&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: Nobody/Anonymous (nobody)
Summary: ORCA doesn't parse scf energy

Initial Comment:
If you include solvent effects via COSMO interface, the parser fails to parse the scfenergies, since the printing changes in the output.
Attached you will find a patch and a test case, both released under public domain.

Also I've tried to induce a particular situation in this computation. If you limit orca to a specific number of scf cycles, it does not print the total energy after the scf has finished if this is not converged. As far as I can tell everithing else gets printed (energy change, density change etc).


----------------------------------------------------------------------

>Comment By: Karol Langner (langner)
Date: 2012-11-05 16:16

Message:
Both of these bugs related to scfenergies in ORCA are fixed in r997. File
added to regressions.

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3184890&group_id=161285

[cclib-devel] [ cclib-Bugs-3168810 ] Problem parsing Gaussian ONIOM

[SourceForge.net <no...@so...>]

Bugs item #3168810, was opened at 2011-01-31 09:11
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&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: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing Gaussian ONIOM

Initial Comment:
This came from a GaussSum user ((kar...@ug...). I didn't see a quick fix so I'm posting here to avoid forgetting about it...

The attached ONIOM file fails to parse correctly.

----------------------------------------------------------------------

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:43

Message:
Has this been fixed in the end?

----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-02-01 04:11

Message:
Yes - that's it.

----------------------------------------------------------------------

Comment By: Adam Tenderholt (atenderholt)
Date: 2011-01-31 13:27

Message:
What is the parsing error? I'm getting the following error, which seems
easy-ish to fix:

---
Attempting to parse ortho_prod_freq.log
Traceback (most recent call last):
  File "/usr/local/bin/ccget", line 99, in <module>
    main()
  File "/usr/local/bin/ccget", line 81, in main
    data = log.parse()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/logfileparser.py",
line 221, in parse
    self.extract(inputfile, line)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/cclib/parser/gaussianparser.py",
line 866, in extract
    mocoeffs = [numpy.zeros((self.nmo, self.nbasis), "d")]
AttributeError: 'Gaussian' object has no attribute 'nmo'
---



----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2011-01-31 09:15

Message:
File too large to attach. Please find it at
http://www.redbrick.dcu.ie/~noel/tmp/ortho_prod_freq.zip. I can confirm
that it was placed in the public domain (by the bug reporter).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3168810&group_id=161285

[cclib-devel] [ cclib-Bugs-2908926 ] I never get the attribute 'scfvalues'

[SourceForge.net <no...@so...>]

Bugs item #2908926, was opened at 2009-12-04 08:56
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2908926&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: Invalid
Priority: 5
Private: No
Submitted By: xaverxn (xaverxn)
Assigned to: Nobody/Anonymous (nobody)
Summary: I never get the attribute 'scfvalues'

Initial Comment:
Hi,
I'm not sure if I'm doing anything wrong here, so forgive my if this is not a bug.
Using current trunk (rev. 826) or stable, I can't seem to get the attribute 'scfvalues' when parsing any of my gaussian log files ("AttributeError: 'ccData' object has no attribute 'scfvalues'"). Please try it with the file attached to my last bug report (Title "Assertion error trying ...", file g03_test_complete.log.tar.bz2). Attached find the python console output.

Regards, Xaver

>>> myfile=cclib.parser.ccopen('testfiles/g03_test_complete.log')
>>> data = myfile.parse()
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute charge: -2
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute mult: 5
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute atomnos[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute natom: 31
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute gbasis[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute nbasis: 286
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute nmo: 286
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute scfenergies[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute moenergies[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute homos[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute grads[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute geovalues[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute geotargets[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute atomcoords[]
[Gaussian testfiles/g03_test_complete.log INFO] Creating attribute coreelectrons[]
>>> data.scfenergies
array([-55160.82711683, -55160.82713724, -55160.82713724])
>>> data.scfvalues
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ccData' object has no attribute 'scfvalues'



----------------------------------------------------------------------

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:38

Message:
I guest this can be closed. I added a note about the #P needed for Gaussian
on the wiki.

----------------------------------------------------------------------

Comment By: xaverxn (xaverxn)
Date: 2009-12-10 06:35

Message:
Sure. I meant using cclib fo parsing (which does not give me back single
lines).

----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2009-12-10 04:03

Message:
line.split()[-2] will give you '34'.

----------------------------------------------------------------------

Comment By: xaverxn (xaverxn)
Date: 2009-12-10 03:58

Message:
Yes, I guessed sth like this. So there is no way to extract the '34' out of
the line
 SCF Done:  E(UB+HF-LYP) =  -2027.12313726     a.u. after   34 cycles
? In my understanding, that should be the same as (or a part of what)  you
would extract from #P log files.

----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2009-12-10 03:10

Message:
Presumably your files don't contain this data (compare with dvb_gopt.out in
the distribution). You need to use #P if you want scf convergence
information to be included.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2908926&group_id=161285

[cclib-devel] [ cclib-Bugs-1784327 ] Can't handle GAMESS TD-DFT

[SourceForge.net <no...@so...>]

Bugs item #1784327, was opened at 2007-08-29 11:23
Message generated for change (Settings changed) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1784327&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: Out of Date
Priority: 5
Private: No
Submitted By: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't handle GAMESS TD-DFT

Initial Comment:
Vitaliy Gorbenko contacted GaussSum. It seems that cclib can't handle GAMESS and PC GAMESS TD-DFT. I haven't verified the problem.

He provided an input and output file but I include here only the keywords for the input:

GAMESS:
 $CONTRL SCFTYP=RHF DFTTYP=B3LYP TDDFT=EXCITE $END
 $SYSTEM TIMLIM=3000 MWORDS=50 $END
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END
 $TDDFT NSTATE=10 $END
 $DAT

He also reported problems with PC GAMESS:

 $CONTRL SCFTYP=RHF CITYP=CIS COORD=CART MAXIT=1000 $END                      
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                       
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $CIS NSTATE=80 ISTSYM=0 ISTATE=1 $END                                          
 $DAT

and also:

 $CONTRL SCFTYP=RHF DFTTYP=B3LYP CITYP=TDDFT COORD=CART MAXIT=1000 $END       
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                        
 $BASIS  GBASIS=STO ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $TDDFT NSTATE=80 ISTSYM=0 ISTATE=1 TDA=.t. $END                                
 $DAT


----------------------------------------------------------------------

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:26

Message:
We've been handling TD logfiles for some time now, and I believe these
input decks are covered by the unit tests.

----------------------------------------------------------------------

Comment By: Noel O'Boyle (baoilleach)
Date: 2007-11-06 07:47

Message:
Logged In: YES 
user_id=850620
Originator: YES

The problem appears to be that etoscs is not parsed. I am looking into
this...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1784327&group_id=161285

[cclib-devel] [ cclib-Bugs-1775665 ] empty mosyms

[SourceForge.net <no...@so...>]

Bugs item #1775665, was opened at 2007-08-16 10:57
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1775665&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: empty mosyms

Initial Comment:
I have a calculation that doesn't have mosyms parsed at all. I believe it is because I used SCF=QC and it gives a section that starts with 'Orbital Symmetries in SymMO:' before the 'Orbital Symmetries:' section. I still need to generate an appropriate test file.

Quick workaround is as follows. On line 328, change

if line[1:19] == 'Orbital symmetries' and not hasattr(self, "mosyms"):

to

if line[1:20] == 'Orbital symmetries:' and not hasattr(self, "mosyms"):

Basically this just ignores the incorrect section by checking to make sure the Orbital symmetries is followed immediately by a colon.

Adam



----------------------------------------------------------------------

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:20

Message:
Just looked at the code and this was fixed at some point in the past. FTR,
this was in the Gaussian parser.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1775665&group_id=161285

[cclib-devel] [ cclib-Bugs-1756794 ] GAMESS: Raman parsing fails

[SourceForge.net <no...@so...>]

Bugs item #1756794, was opened at 2007-07-19 05:32
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756794&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: Wont Fix
Priority: 5
Private: No
Submitted By: Noel O'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: GAMESS: Raman parsing fails

Initial Comment:
Reported by Charlie Bradshaw, but IP issues prevent me looking at the test file.

Dear Noel,

The attached .zip file contains a gamess log with runtype=raman on the
musk ambrette molecule.  GaussSum fails to open the log due to a
parsing error.  According to the documentation IR_raman.py should
handle this.  This log file also crashes Chemcraft, so it may be a
problem with the log.  There were a number of modes with *******
instead of activity where I changed the string of "*" to 0.0.

Best regards,

Charlie

Dr. Charles F. Bradshaw
The MITRE Corporation

----------------------------------------------------------------------

>Comment By: Karol Langner (langner)
Date: 2012-11-05 13:14

Message:
No point in keeping this open. We cannot fix it without the file anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756794&group_id=161285