cclib-devel — Developer's mailing list

Re: [cclib-devel] Parsing multiple files (Re: Turbomole parser)

[Karol L. <kar...@kn...>]

On Monday 13 August 2007 13:17, Christopher Rowley wrote:
> Yes, I really like this solution too. I think it's worthwhile to
> preserve the merge_turbo feature for now. I think it's actually a
> preferable way to preserve the output of a job, rather than keeping
> tarballs of each directory required for a computation, although as
> you've demonstrated, it's not longer necessary.
>
> Chris

It doesn't matter for testing purposes how the data is stored if cclib can 
read both things, but keeping the cclib package small (excluding regression 
tests) is an important incentive. So when the Turbomole parser goes into the 
trunk we should not duplicate the data files and keep only one copy (the 
concatenated file or a directory).

Another thought: I bet users will generally provide Turbomole output in the 
wrong order and break the parser - give the list of files in the wrong order 
or concatenate the files in the wrong order. In the first case, cclib can 
potentially fix this by reordering them basing on the file names if they are 
not changed. If everything is in one file in the wrong order, that is alot 
harder to do. That is the main advantage I see in choosing not to concatenate 
if a package provides output in multiple files.

Karol

-- 
written by Karol Langner
Fri Aug 17 17:48:48 EDT 2007

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

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

Bugs item #1775665, was opened at 2007-08-16 17:57
Message generated for change (Settings changed) 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: Open
Resolution: None
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



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

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 12:32
Message generated for change (Settings changed) 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: Open
Resolution: None
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

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

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

[cclib-devel] [ cclib-Bugs-1767309 ] not parsing optimization steps

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

Bugs item #1767309, was opened at 2007-08-03 20:29
Message generated for change (Settings changed) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1767309&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: not parsing optimization steps

Initial Comment:
When the Symm(Follow) keyword is used to make geometry updates occur in the current symmetry, the resulting steps are not parsed. 

In the attached file, there are 4 steps; however, atomcoords is only length 1.

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

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

[cclib-devel] [ cclib-Bugs-1756789 ] Gaussian: problem reading MO values

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

Bugs item #1756789, was opened at 2007-07-19 12:20
Message generated for change (Settings changed) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756789&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: Gaussian: problem reading MO values

Initial Comment:
Reported by Jerome Kieffer; no test file due to IP issues.

Dear CCLib developpers,

I noticed a bug when reading a gaussian log file when the energy of the deepest orbital cannot fit in the formated 9 char .
Maybe this is due to the 2 iodines in this molecule (di-iodophenyl) or to the Dgauss DZVP basis set used.

Of course the bug occures by the python command :
float("**********"), in Logfile.parse.float(), line 188 of logfileparser.py

Here is an extract of the gaussian output.
 The electronic state is 1-A.
 Alpha  occ. eigenvalues -- ********************-176.38175-176.37760-165.76438
 Alpha  occ. eigenvalues -- -165.76230-165.76225-165.76023-165.75813-165.75807
 Alpha  occ. eigenvalues --  -35.82446 -35.82036 -31.33591 -31.33183 -31.33009

Kind regards.
--
Jérôme Kieffer (PhD)

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

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

[cclib-devel] [ cclib-Bugs-1756064 ] Gaussian parse error for #T

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

Bugs item #1756064, was opened at 2007-07-18 12:18
Message generated for change (Settings changed) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756064&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: Gaussian parse error for #T

Initial Comment:
Christoph Steinbeck reported that a Gaussian file broke GaussSum. It seems that #T files don't include nbasis whereas the parser code assumes that this exists.

File attached, and we have permission from Christoph to make it public domain. (This is an NMR calculation)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756064&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 (Tracker Item Submitted) made by Item Submitter
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: None
Group: None
Status: Open
Resolution: None
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



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

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

[cclib-devel] Molpro data files

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

Karol,

Could you upload a dvb_gopt_sym set of files for Molpro? (i.e. with
symmetry) Is there some problem parsing these files?

Noel

Re: [cclib-devel] Parsing multiple files (Re: Turbomole parser)

[Christopher R. <cro...@uo...>]

Yes, I really like this solution too. I think it's worthwhile to
preserve the merge_turbo feature for now. I think it's actually a
preferable way to preserve the output of a job, rather than keeping
tarballs of each directory required for a computation, although as
you've demonstrated, it's not longer necessary.

Chris

-----Original Message-----
From: ccl...@li...
[mailto:ccl...@li...] On Behalf Of Karol
Langner
Sent: Monday, August 13, 2007 7:09 PM
To: ccl...@li...
Cc: Noel O'Boyle
Subject: [cclib-devel] Parsing multiple files (Re: Turbomole parser)

On Saturday 11 August 2007 13:45, Noel O'Boyle wrote:
> Chris,
>
> The Turbomole parser seems to be coming along well. I've added a colm
> to the wiki for keeping track of progress:
>
http://cclib.sourceforge.net/wiki/index.php/Development_parsed_data#Deta
ils
>_of_current_implementation

Yes, I agree. I'd like to expand here on parsing multiple files, since 
Turbomole output is the prime example for this. After updating the files
with 
the code for parsing multiple output files, I'd like to demonstrate how
that 
works. This is from my working Turbomole branch, with the dvb_sp data
files 
copied in manually...

langner@slim:~/cclib/branches/turbomoleparser/src/cclib/parser$ python
Python 2.5 (r25:51908, Apr 30 2007, 15:03:13)
[GCC 3.4.6 (Debian 3.4.6-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from utils import ccopen

All the files were concatenated into turbo.out, I presume...
>>> ccopen("turbo.out").parse()
[Turbomole turbo.out INFO] Creating attribute natom: 20
[Turbomole turbo.out INFO] Creating attribute aonames[]
[Turbomole turbo.out INFO] Creating attribute nbasis: 60
[Turbomole turbo.out INFO] Creating attribute nmo: 60
[Turbomole turbo.out INFO] Creating attribute homos[]
[Turbomole turbo.out INFO] Creating attribute aooverlaps[]
[Turbomole turbo.out INFO] Creating attribute atomcoords[]
[Turbomole turbo.out INFO] Creating attribute atomnos[]
[Turbomole turbo.out INFO] Creating attribute moenergies[]
[Turbomole turbo.out INFO] Creating attribute mocoeffs[]
[Turbomole turbo.out INFO] Creating attribute coreelectrons[]
<cclib.data.ccData object at 0xb63a1dec>

Passing just the basis stuff doesn't get anything parsed:
>>> ccopen("basis").parse()
<cclib.data.ccData object at 0xb63a1e6c>

To parse two files sequentially, pass them as a list:
>>> ccopen(["basis","control"]).parse()
[Turbomole ['basis', 'control'] INFO] Creating attribute natom: 20
[Turbomole ['basis', 'control'] INFO] Creating attribute aonames[]
[Turbomole ['basis', 'control'] INFO] Creating attribute nbasis: 60
[Turbomole ['basis', 'control'] INFO] Creating attribute nmo: 60
[Turbomole ['basis', 'control'] INFO] Creating attribute homos[]
[Turbomole ['basis', 'control'] INFO] Creating attribute coreelectrons[]
<cclib.data.ccData object at 0xb63a484c>

This will be equivalent to parsing turbo.out in terms of parsed
attributes:
>>> ccopen(["basis","control","coord","energy","mos"]).parse()
	...
<cclib.data.ccData object at 0xb63a42cc>

By the way, no need to add extra lines for Turbomole to be recognized -
ccopen 
can do it with the condition (line[0] == "$" and line[1].islower()),
which is 
unique for Turbomole at least presently for all the cclib parsers.

In my opinion, we should do without concatenated files such as
turbo.out, and 
parse the tests using multiple files where required. What do you think?

There are caveats that need to be dealt with - passing the files in the
wrong 
order crashes the parser. And that is equivalent to cancatenating in the

wrong order, so it still requires the user to do something right :)
>>> ccopen(["control","basis"]).parse()
[Turbomole ['control', 'basis'] INFO] Creating attribute natom: 20
[Turbomole ['control', 'basis'] INFO] Creating attribute aonames[]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "logfileparser.py", line 140, in parse
    self.extract(inputfile, line)
  File "turbomoleparser.py", line 214, in extract
    for i in range(0, len(self.basis_lib), 1):
AttributeError: 'Turbomole' object has no attribute 'basis_lib'

One more issue is how to get ccget to parse multiple files into one data

object. What I mean is something that will be equivalent to passing a 
concatenated (turbo.out, for example) file to ccget. I propose to add an

option to ccget that will do that. What do you all think?

Cheers,
Karol

-- 
written by Karol Langner
Mon Aug 13 18:49:58 EDT 2007

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
cclib-devel mailing list
ccl...@li...
https://lists.sourceforge.net/lists/listinfo/cclib-devel

[cclib-devel] Parsing multiple files (Re: Turbomole parser)

[Karol L. <kar...@kn...>]

On Saturday 11 August 2007 13:45, Noel O'Boyle wrote:
> Chris,
>
> The Turbomole parser seems to be coming along well. I've added a colm
> to the wiki for keeping track of progress:
> http://cclib.sourceforge.net/wiki/index.php/Development_parsed_data#Details
>_of_current_implementation

Yes, I agree. I'd like to expand here on parsing multiple files, since 
Turbomole output is the prime example for this. After updating the files with 
the code for parsing multiple output files, I'd like to demonstrate how that 
works. This is from my working Turbomole branch, with the dvb_sp data files 
copied in manually...

langner@slim:~/cclib/branches/turbomoleparser/src/cclib/parser$ python
Python 2.5 (r25:51908, Apr 30 2007, 15:03:13)
[GCC 3.4.6 (Debian 3.4.6-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from utils import ccopen

All the files were concatenated into turbo.out, I presume...
>>> ccopen("turbo.out").parse()
[Turbomole turbo.out INFO] Creating attribute natom: 20
[Turbomole turbo.out INFO] Creating attribute aonames[]
[Turbomole turbo.out INFO] Creating attribute nbasis: 60
[Turbomole turbo.out INFO] Creating attribute nmo: 60
[Turbomole turbo.out INFO] Creating attribute homos[]
[Turbomole turbo.out INFO] Creating attribute aooverlaps[]
[Turbomole turbo.out INFO] Creating attribute atomcoords[]
[Turbomole turbo.out INFO] Creating attribute atomnos[]
[Turbomole turbo.out INFO] Creating attribute moenergies[]
[Turbomole turbo.out INFO] Creating attribute mocoeffs[]
[Turbomole turbo.out INFO] Creating attribute coreelectrons[]
<cclib.data.ccData object at 0xb63a1dec>

Passing just the basis stuff doesn't get anything parsed:
>>> ccopen("basis").parse()
<cclib.data.ccData object at 0xb63a1e6c>

To parse two files sequentially, pass them as a list:
>>> ccopen(["basis","control"]).parse()
[Turbomole ['basis', 'control'] INFO] Creating attribute natom: 20
[Turbomole ['basis', 'control'] INFO] Creating attribute aonames[]
[Turbomole ['basis', 'control'] INFO] Creating attribute nbasis: 60
[Turbomole ['basis', 'control'] INFO] Creating attribute nmo: 60
[Turbomole ['basis', 'control'] INFO] Creating attribute homos[]
[Turbomole ['basis', 'control'] INFO] Creating attribute coreelectrons[]
<cclib.data.ccData object at 0xb63a484c>

This will be equivalent to parsing turbo.out in terms of parsed attributes:
>>> ccopen(["basis","control","coord","energy","mos"]).parse()
	...
<cclib.data.ccData object at 0xb63a42cc>

By the way, no need to add extra lines for Turbomole to be recognized - ccopen 
can do it with the condition (line[0] == "$" and line[1].islower()), which is 
unique for Turbomole at least presently for all the cclib parsers.

In my opinion, we should do without concatenated files such as turbo.out, and 
parse the tests using multiple files where required. What do you think?

There are caveats that need to be dealt with - passing the files in the wrong 
order crashes the parser. And that is equivalent to cancatenating in the 
wrong order, so it still requires the user to do something right :)
>>> ccopen(["control","basis"]).parse()
[Turbomole ['control', 'basis'] INFO] Creating attribute natom: 20
[Turbomole ['control', 'basis'] INFO] Creating attribute aonames[]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "logfileparser.py", line 140, in parse
    self.extract(inputfile, line)
  File "turbomoleparser.py", line 214, in extract
    for i in range(0, len(self.basis_lib), 1):
AttributeError: 'Turbomole' object has no attribute 'basis_lib'

One more issue is how to get ccget to parse multiple files into one data 
object. What I mean is something that will be equivalent to passing a 
concatenated (turbo.out, for example) file to ccget. I propose to add an 
option to ccget that will do that. What do you all think?

Cheers,
Karol

-- 
written by Karol Langner
Mon Aug 13 18:49:58 EDT 2007

[cclib-devel] Turbomole parser

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

Chris,

The Turbomole parser seems to be coming along well. I've added a colm
to the wiki for keeping track of progress:
http://cclib.sourceforge.net/wiki/index.php/Development_parsed_data#Details_of_current_implementation

Could you send me (off-list) a username and password for the wiki and
I'll create an a/c for you.

Noel

Re: [cclib-devel] Fwd: gaussian symmetry labels

[Adam T. <a-t...@st...>]

> True. What do you suggest? A "?" for all unknown symmetries?
>
> Can you clarify - does this actually break the parser?

It actually doesn't break the parser, so I'm a bit inclined to leave  
it as is. Plus, I think it knows that some of the unknown symmetries  
are different since it labels them with different letters, so it'd be  
good to keep that information, even if it's not strictly *correct*.

Adam

[cclib-devel] Fwd: gaussian symmetry labels

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

---------- Forwarded message ----------
From: Noel O'Boyle <bao...@gm...>
Date: 09-Aug-2007 16:08
Subject: Re: [cclib-devel] gaussian symmetry labels
To: Adam Tenderholt <a-t...@st...>


On 07/08/07, Adam Tenderholt <a-t...@st...> wrote:
> > I take ?X to mean Gaussian don't have a clue. So it should set it to
> > A, I guess. The other labels should be handled correctly by cclib,
> > right?
>
> Gaussian can't figure out what the symmetry of that orbital is, but
> it can for the majority of them. I don't see any reason to change the
> behavior unless you really think we should. After all, A isn't a
> symmetry in D3h anymore than ?A, ?B, etc. are.

True. What do you suggest? A "?" for all unknown symmetries?

Can you clarify - does this actually break the parser?

> Adam
>
> > On 06/08/07, Adam Tenderholt <a-t...@st...> wrote:
> >> Hey Noel,
> >>
> >> Have you ever seen the symmetry labels ?A, ?B, ?C, and ?D ? It's on a
> >> D3h structure I'm studying. Labels A1', A1", A2', A2", E', and E"
> >> also show up. The weird labels also mainly show up in the "core"
> >> levels, although there are a few in the virtual set.
> >>
> >> Adam
> >>
> >>
> >
> > ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

[cclib-devel] [ cclib-Bugs-1756059 ] GAMESS-UK mocoeffs or aooverlaps error

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

Bugs item #1756059, was opened at 2007-07-18 13:11
Message generated for change (Settings changed) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756059&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: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: GAMESS-UK mocoeffs or aooverlaps error

Initial Comment:
I've just noticed that there's a problem with the Mulliken analysis of GAMESS-UK files. There's either something wrong with the mocoeffs or the aooverlaps parsed from these.

Need to figure out the problem and add a unit test to ensure it doesn't reoccur.

Noel

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

Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-08-09 10:34

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

Fixed in trunk.

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

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

[cclib-devel] [ cclib-Bugs-1756059 ] GAMESS-UK mocoeffs or aooverlaps error

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

Bugs item #1756059, was opened at 2007-07-18 13:11
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756059&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
Resolution: None
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: GAMESS-UK mocoeffs or aooverlaps error

Initial Comment:
I've just noticed that there's a problem with the Mulliken analysis of GAMESS-UK files. There's either something wrong with the mocoeffs or the aooverlaps parsed from these.

Need to figure out the problem and add a unit test to ensure it doesn't reoccur.

Noel

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

>Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-08-09 10:34

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

Fixed in trunk.

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

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

Re: [cclib-devel] orbitals for correlated methods

[Adam T. <a-t...@st...>]

> I wrote about this some time ago (see the above), and some thinking  
> made me
> confident to create a new attribute - nocoeffs. Natural orbitals are
> mathematically totally different numbers than MO coefficients,  
> although their
> print-out usually looks very similar. I added code for them in  
> Gaussian and
> GAMESS for CIS and MP2 - see my commit for details.

Out of curiosity, how do natural orbitals for correlated methods  
differ from those determined from DFT MOs during Weinhold's natural  
bond orders (NBO) method?

Adam

Re: [cclib-devel] orbitals for correlated methods

[Karol L. <kar...@kn...>]

On Thursday 12 July 2007 11:45, Karol Langner wrote:
> At some point I'd like cclib to also parse the MO eigenvectors for
> correlated methods - natural orbitals from MP2 or CI, and optimized
> orbitals after MCSCF calcualtions. They all have the format of mocoeffs,
> with different values. I'd like to have your opinion - should these be
> parsed into the same attribute as the SCF MOs (mocoeffs) or into a new one
> (mpcoeffs?)?

I'm still not in my normal workspace, so It'll be a few days before I read 
through all the mail from the past few weeks, but I now did one thing I am 
very eager to see in cclib in the next release - parsing natural orbitals.

I wrote about this some time ago (see the above), and some thinking made me 
confident to create a new attribute - nocoeffs. Natural orbitals are 
mathematically totally different numbers than MO coefficients, although their 
print-out usually looks very similar. I added code for them in Gaussian and 
GAMESS for CIS and MP2 - see my commit for details.

Cheers,
Karol

-- 
written by Karol Langner
Wed Aug  8 10:43:03 EDT 2007

Re: [cclib-devel] gaussian symmetry labels

[Adam T. <a-t...@st...>]

> I take ?X to mean Gaussian don't have a clue. So it should set it to
> A, I guess. The other labels should be handled correctly by cclib,
> right?

Gaussian can't figure out what the symmetry of that orbital is, but  
it can for the majority of them. I don't see any reason to change the  
behavior unless you really think we should. After all, A isn't a  
symmetry in D3h anymore than ?A, ?B, etc. are.

Adam

> On 06/08/07, Adam Tenderholt <a-t...@st...> wrote:
>> Hey Noel,
>>
>> Have you ever seen the symmetry labels ?A, ?B, ?C, and ?D ? It's on a
>> D3h structure I'm studying. Labels A1', A1", A2', A2", E', and E"
>> also show up. The weird labels also mainly show up in the "core"
>> levels, although there are a few in the virtual set.
>>
>> Adam
>>
>>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] Dropped Numeric support & misc.

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

On 05/08/07, Karol Langner <kar...@kn...> wrote:
> I believe there was a consensus to drop support for Numeric, so I did that
> just now. So... you _need_ numpy in order to use the svn revision now. I
> guess this should make alot of math-related things clear.

Sounds good..

> On a related note - while working on the Molpro parser today I ran into the
> situation where you have only partial data in the output to parse some
> attribute. For example, Molpro by default prints the SCF cycle only for the
> first/last point in a gopt, therefore scfvalues is not of the expected
> dimensions. I know that for tests we should always have proper output, but I
> wonder how we are to deal with this in general. I mean, we don't want the
> user to get an attribute with dimensions he doesn't understand, right? To me
> it seems reasonable to fill up the gaps - put something in place of the
> lacking elements. I see two possibilities: 1) always use None 2) use
> numpy.nan. What re your thoughts?

First of all, is it possible to create the correct test file? If so,
I'd appreciate if you could do so.

Secondly, IMO I wouldn't fill the gaps for the general case. Rather I
would return an array of size 2 in that dimension. I won't argue this
too much but if you fill the gap, you will probably cause a users
program to fail (e.g. GaussSum will fail with this information),
rather than plot something. Also there is the problem that we haven't
taken this attitude with the other programs. I don't feel that this
information is so important that we need to spend too much time
getting this perfect. It's easy for user to construct a calculation
where there are more SCF cycles than GeoOpts. For example, an IR
calculation in some programs. cclib just extracts the SCF information
wherever it is, and doesn't worry about the context.

Noel

> Karol
>
> --
> written by Karol Langner
> Sun Aug  5 01:04:17 EDT 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] gaussian symmetry labels

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

I take ?X to mean Gaussian don't have a clue. So it should set it to
A, I guess. The other labels should be handled correctly by cclib,
right?

On 06/08/07, Adam Tenderholt <a-t...@st...> wrote:
> Hey Noel,
>
> Have you ever seen the symmetry labels ?A, ?B, ?C, and ?D ? It's on a
> D3h structure I'm studying. Labels A1', A1", A2', A2", E', and E"
> also show up. The weird labels also mainly show up in the "core"
> levels, although there are a few in the virtual set.
>
> Adam
>
>

[cclib-devel] Parsing multiple files

[Karol L. <kar...@kn...>]

There had been some discussions about some comp. chem. programs printing 
output across many files (GAMESS, Molpro, and lately Turbomole). The only way 
to parse from multiple files into one data object until now has been to 
concatenate them and parse the combined file, not a preferable solution.

I just commited changes that allow cclib to parse a sequence of files. The 
FileInput class from the standard Python library fileinput allows many files 
to be parsed seamlessly the samy as regular file objects (thus no changes in 
the parser code!). You can now pass lists and tuples to openlogfile and 
ccopen in the filename argument, and get a FileInput object back instead of a 
regular file object. Compression with gzip and bzip2 are supported as of 
Python 2.5.

You can see this feature at work in the Molpro GeoOpt unittest - two files are 
parsed (.out and .log). I modified the test system a bit to accomodate this: 
additional data files are given in the last columns of test/testdata, as you 
can see in this case. This Molpro test still doesn't pass, but the errors are 
not due to the new feature :)

A few things need to be considered/fixed in this area:
1) Possibly support zip files containing more than one file (now an error).
2) Parsing many files into one data object can potentially mess things up, 
even for legitimate logfiles (we haven't parsed GAMESS .log files yet, for 
example). The most obvious problem, repeated print-outs of the same data, is 
easy to fix (I have done this for Molpro already).
3) The script ccget, when given many file names, presently parses each one 
separately. Should we provide an option to parse them into a single data 
object?

Hope this makes life easier in the future,
Karol

-- 
written by Karol Langner
Sun Aug  5 23:38:50 EDT 2007

[cclib-devel] Dropped Numeric support & misc.

[Karol L. <kar...@kn...>]

I believe there was a consensus to drop support for Numeric, so I did that 
just now. So... you _need_ numpy in order to use the svn revision now. I 
guess this should make alot of math-related things clear.

On a related note - while working on the Molpro parser today I ran into the 
situation where you have only partial data in the output to parse some 
attribute. For example, Molpro by default prints the SCF cycle only for the 
first/last point in a gopt, therefore scfvalues is not of the expected 
dimensions. I know that for tests we should always have proper output, but I 
wonder how we are to deal with this in general. I mean, we don't want the 
user to get an attribute with dimensions he doesn't understand, right? To me 
it seems reasonable to fill up the gaps - put something in place of the 
lacking elements. I see two possibilities: 1) always use None 2) use 
numpy.nan. What re your thoughts?

Karol

-- 
written by Karol Langner
Sun Aug  5 01:04:17 EDT 2007

[cclib-devel] [ cclib-Feature Requests-1767367 ] Suppport for parsing multiple files.

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

Feature Requests item #1767367, was opened at 2007-08-03 23:06
Message generated for change (Comment added) made by langner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819225&aid=1767367&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
Priority: 5
Private: No
Submitted By: Karol Langner (langner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Suppport for parsing multiple files.

Initial Comment:
Many computational chemistry programs print output across multiple files (most notably GAMESS, Molpro, Turbomole). Parsing more than one can provide better data (more precision) and in some cases is necessary. Concatenating files is a solution, but it should also be possible to pass multipole file names to parsers and utility scripts.

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

>Comment By: Karol Langner (langner)
Date: 2007-08-03 23:27

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

When parsing multiple files, the possible repetition of the same data
across files must be taken under consideration.

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

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

[cclib-devel] [ cclib-Feature Requests-1767367 ] Suppport for parsing multiple files.

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

Feature Requests item #1767367, was opened at 2007-08-03 23:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819225&aid=1767367&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
Priority: 5
Private: No
Submitted By: Karol Langner (langner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Suppport for parsing multiple files.

Initial Comment:
Many computational chemistry programs print output across multiple files (most notably GAMESS, Molpro, Turbomole). Parsing more than one can provide better data (more precision) and in some cases is necessary. Concatenating files is a solution, but it should also be possible to pass multipole file names to parsers and utility scripts.

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

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

Re: [cclib-devel] cclib 0.8 lock down

[Adam T. <a-t...@st...>]

> Would it be possible for you to create some test files for MP and
> TDDFT? I have an incentive (i.e. GaussSum) to get TDDFT and SCF
> working...

I have uploaded two new ORCA calculations: MP2 for water and TDDFT  
for dvb. I can't find anywhere in the ORCA manual how to do MP3/MP4  
jobs.

Adam