cclib-devel — Developer's mailing list

[cclib-devel] cclib test files

[Xaver W. <xav...@we...>]

Hello,

I am interested about the current state and plans of the cclib test files 
(suite).

As I understand it, the SVN "data" folder contains the current collection, and 
the contents of the "regressiontest.txt" lists the files for regression 
testing (which do not contain the ORCA files, e. g.). The SVN "data" files 
are all "public domain", right? Because I couldn't find a copyright/license 
notice.

I saw there were once plans to merge this with the openBabel or BlueObelisk 
data (comments on 
http://baoilleach.blogspot.com/2009/06/ill-fix-bugbut-only-if-you-give-me.html). 
Is this still planned?

And last but not least, I am able to get my hands on (public domain ;-) ) 
testfiles of turbomole and Gaussian 09. Interested? What would I need to get 
you, exactly?

Regards,
Xaver

Re: [cclib-devel] Hessian code for gaussianparser.py

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

Looks really good. Having the tests is great. I particularly like the
way you stuck a full Hessian to vibfreq conversion in there. We might
move this out to the algorithms at some point to make it more widely
available.

I'll try to do the patch this weekend.

Feel free to contribute incognito, but I'm wondering who exactly do we
owe this code to. Google isn't exactly helpful in this case. :-)

- Noel

On 10 February 2010 03:28, Matt W <pb...@gm...> wrote:
> Hi Noel,
>   Attached is a patch file against rev 881.  I actually generated it with
> mercurial, so the -p1 option is needed with patch.  Molpro seems to use
> atomic units (Hartrees/Bohr^2) for the Hessian, and the Molpro parser
> doesn't do any conversion.  Gaussian uses the same units, so I also didn't
> do any conversion, although units of eV/Angstrom^2 would seem to be more
> consistent with other cclib quantities.
>
> I noticed that the Molpro parser was reading in atomic masses but they
> weren't being made public, so I changed that (in data.py) and wrote a test
> (testhess.py) that compares the vib freqs calculated from the Hessian and
> the masses to the freqs read in directly from the Gaussian or Molpro file.
> One strange thing is that Molpro prints abundance averaged atomic weights by
> default, while Gaussian prints relative atomic (isotopic) masses (carbon-12
> = 12 exactly).  If you'd rather not have the additional changes, the part of
> the patch against gaussianparser.py is fine on its own.
>
> Best Regards,
>
> Matt White
>
> On Sun, Feb 7, 2010 at 7:16 AM, Noel O'Boyle <bao...@gm...> wrote:
>>
>> Hi Matt,
>>
>> Sounds good. If you could send a patch to this list, we can take a
>> look. We already have some hessian code somewhere (I think?) so we
>> will need to make sure that the units are standardised and so forth.
>>
>> If you checked our code out of subversion, "svn diff" will create the
>> patch. Otherwise, use "diff -u oldfile newfile > a.patch". If all else
>> fails, just attach the modified file.
>>
>> - Noel
>>
>> On 5 February 2010 06:26, Matt W <pb...@gm...> wrote:
>> > Hello all,
>> >   I recently wrote a short bit of code for cclib to read the Hessian
>> > from a
>> > Gaussian output file.  If there is interest in adding this to the
>> > project,
>> > what is the best way to submit it?
>> >
>> > Best Regards,
>> >
>> > Matt W
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > The Planet: dedicated and managed hosting, cloud storage, colocation
>> > Stay online with enterprise data centers and the best network in the
>> > business
>> > Choose flexible plans and management services without long-term
>> > contracts
>> > Personal 24x7 support from experience hosting pros just a phone call
>> > away.
>> > http://p.sf.net/sfu/theplanet-com
>> > _______________________________________________
>> > cclib-devel mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> >
>> >
>
>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] new parsed data

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

Sounds fine with me. masses is usually better than weights, but just
call it whatever is more common in the field. I'm guessing these
aren't simply the atomic masses of the elements, right, it's some sort
of 1D array for every vibration. Is there some relationship with the
cartesian displacement vectors?

- Noel

On 11 February 2010 18:24, Adam Tenderholt <ate...@gm...> wrote:
> I'm finding myself interested in having two new attributes in cclib:
>
> 1) vibweights (or vibmasses) -- the atomic masses used in calculating frequencies. Someone from my old lab wants me to extend a script used to calculate NRVS data (that depends upon cclib) to work with more than just Gaussian (i.e. MolPro).
>
> 2) nmrisos (and possibly nmranisos) -- NMR shielding tensors.
>
> Thoughts on attribute names? The first is something I'd like to hash out this weekend. The second is just something that I might find somewhat useful, but I'd probably only implement it for Gaussian unless others really have a need for it with other programs.
>
> Adam
>
>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] new parsed data

[Adam T. <ate...@gm...>]

I'm finding myself interested in having two new attributes in cclib:

1) vibweights (or vibmasses) -- the atomic masses used in calculating frequencies. Someone from my old lab wants me to extend a script used to calculate NRVS data (that depends upon cclib) to work with more than just Gaussian (i.e. MolPro).

2) nmrisos (and possibly nmranisos) -- NMR shielding tensors. 

Thoughts on attribute names? The first is something I'd like to hash out this weekend. The second is just something that I might find somewhat useful, but I'd probably only implement it for Gaussian unless others really have a need for it with other programs.

Adam

Re: [cclib-devel] Hessian code for gaussianparser.py

[Matt W <pb...@gm...>]

diff -r 881155faef88 -r 7456e8b3840b src/cclib/parser/data.py
--- a/src/cclib/parser/data.py
+++ b/src/cclib/parser/data.py
@@ -69,7 +69,7 @@
         """
 
         # Names of all supported attributes.
-        self._attrlist = ['aonames', 'aooverlaps', 'atombasis',
+        self._attrlist = ['amass', 'aonames', 'aooverlaps', 'atombasis',
                           'atomcoords', 'atomnos',
                           'ccenergies', 'charge', 'coreelectrons',
                           'etenergies', 'etoscs', 'etrotats', 'etsecs', 'etsyms',
@@ -82,7 +82,8 @@
                           'vibdisps', 'vibfreqs', 'vibirs', 'vibramans', 'vibsyms']
 
         # The expected types for all supported attributes.
-        self._attrtypes = { "aonames":        list,
+        self._attrtypes = { "amass":          numpy.ndarray,
+                            "aonames":        list,
                             "aooverlaps":     numpy.ndarray,
                             "atombasis":      list,
                             "atomcoords":     numpy.ndarray,
diff -r 881155faef88 -r 7456e8b3840b src/cclib/parser/gaussianparser.py
--- a/src/cclib/parser/gaussianparser.py
+++ b/src/cclib/parser/gaussianparser.py
@@ -969,6 +969,58 @@
         if line[1:7] == "ONIOM:":
             self.oniom = True
 
+        # Read in entire archive section, then extract Hessian if present
+        # The lower-triangular part of the Hessian is returned flattened.
+        # To convert to a 3N x 3N rank 2 matrix:
+        #   hess = numpy.zeros([3N,3N]); hess[numpy.tril_indices(3N)] = data.hessian
+        # The archive section is the only place the Hessian is found unless
+        #  additional print ("p") was specified in the Gaussian input file
+        # Under Windows, Gaussian uses "|" instead of "\" as separator
+        #  in archive section
+        if line[1:5] == "1|1|" or line[1:5] == "1\\1\\":
+
+            self.updateprogress(inputfile, "Archive Section", self.fupdate)            
+            arcsep = line[4];
+            arcstr = ""
+            # archive section is terminated by "||@", but just look for 
+            #  blank line following
+            while line.strip():
+                arcstr += line.strip()
+                line = inputfile.next()
+            # sections separated by "||"
+            arcsects = arcstr.split(arcsep + arcsep)
+            
+            # Section immediately preceeding Hessian ends with "NImag=<int>"
+            # Note that output file may contain multiple archive sections (e.g.,
+            #  for an opt + freq job, Hessian is in 2nd one).
+            for ii in range(len(arcsects)):
+                if arcsects[ii].find("NImag=") > -1:
+                    self.hessian = map(float, arcsects[ii+1].split(","))
+                       
+        # Atomic masses: In "Isotopes and Nuclear Properties:" section if
+        #  additional print ("p") is on, otherwise only present if freq job
+        #  (in Thermochemistry section).
+        # The "Isotopes and Nuclear Properties:" section may appear more than
+        #  once (e.g opt + freq job); this code will yield values from the final one
+        if line.find("Isotopes and Nuclear Properties") > -1:
+            self.amass = []
+
+        if line[1:8] == "AtmWgt=":
+            self.amass += map(float, line.split()[1:])
+        
+        # Get mass from Thermochemistry section if we haven't found it yet
+        # looking for "Atom  1 has atomic number x and mass y"; space 
+        #  between "Atom" and "1" is different in G03 and G09
+        if line.find("1 has atomic number") > -1 and not hasattr(self, "amass"):
+            self.amass = []
+            broken = line.split()
+            # no blank line following, so use len(split()) to detect end
+            while len(broken) == 9:
+                self.amass.append(float(broken[8]))
+                line = inputfile.next()
+                broken = line.split()
+
+
 if __name__ == "__main__":
     import doctest, gaussianparser
     doctest.testmod(gaussianparser, verbose=False)
diff -r 881155faef88 -r 7456e8b3840b test/testdata
--- a/test/testdata
+++ b/test/testdata
@@ -100,3 +100,7 @@
 vib       Molpro      MolproIRTest          basicMolpro2006       dvb_ir.out            dvb_ir.log
 vib       ORCA        OrcaIRTest            basicORCA2.6          dvb_ir.out
 vib       ORCA        OrcaRamanTest         basicORCA2.6          dvb_raman.out
+
+hess      Gaussian    Gaussian03HessTest    basicGaussian03       dvb_ir.out
+hess      Gaussian    Gaussian09HessTest    basicGaussian09       dvb_raman.log
+hess      Molpro      MolproHessTest        basicMolpro2006       dvb_ir.out            dvb_ir.log
diff -r 881155faef88 -r 7456e8b3840b test/testhess.py
--- /dev/null
+++ b/test/testhess.py
@@ -0,0 +1,67 @@
+__revision__ = "$Revision$"
+
+import numpy
+import bettertest
+
+
+class GenericHessTest(bettertest.TestCase):
+    """Generic Hessian unittest."""
+
+    def modes_from_hess(self, flathess, mass, units=5140.4872066):
+        """ Calculate normal mode freqs (in 1/cm) and vectors from hessian.
+        Default units=5140.4872066 assumes Hessian in Hartree/Bohr^2 and mass 
+        in amu (12C := 12 amu) """
+  
+        # get full Hessian as square matrix
+        N = 3*len(mass);  # number of modes
+        hess = numpy.zeros((N,N))
+        # trilidx = numpy.where(numpy.tril(numpy.ones((hdim,hdim),int),0) != 0)  # NumPy 1.3
+        hess[numpy.tril_indices(N)] = flathess
+        # fill in upper triangle
+        hess = hess.transpose()
+        hess[numpy.tril_indices(N)] = flathess
+      
+        # create mass weighting matrix - repeat for x,y,z 
+        invrootmass = numpy.repeat(1/numpy.sqrt(numpy.array(mass)), 3)
+        # for weighing hessian
+        ivmassouter = numpy.outer(invrootmass, invrootmass)
+        # we need a column vector for scaling normal modes all at once
+        invrootmass = numpy.reshape(invrootmass, (-1,1))
+  
+        # Perform mass-weighting and diagonalize to get normal modes
+        freq, modes = numpy.linalg.eigh(hess * ivmassouter)
+        # convert freqs to 1/cm
+        freq = numpy.sign(freq) * numpy.sqrt(numpy.abs(freq)) * units
+        
+        # scale and renormalize eigenvectors
+        modes = modes * invrootmass
+        modes = numpy.transpose(modes/numpy.sqrt(numpy.sum(modes**2, 0)))
+        # after reshape, indicies are (<mode number>, <atom number>, X, Y, or Z) 
+        modes = numpy.reshape(modes, (N, N/3, 3))
+        # The LAPACK routine used by numpy's eigh() always returns eigenvalues in 
+        #  ascending order, so we can safely assume the first 6 modes are the zero
+        #  freq modes. This only works for a PES minimum, not a transition state
+        return freq[6:], modes[6:]
+
+    def testfreqval(self):
+        """ Do the vibfreqs read directly match those calculated from the Hessian within +/-0.1/cm? """
+        freqs, modes = self.modes_from_hess(self.data.hessian, self.data.amass)
+        self.assertEqual(len(self.data.vibfreqs), len(freqs))
+        for delta in (self.data.vibfreqs - freqs):
+            self.assertInside(delta, 0, 0.1)
+      
+
+class Gaussian03HessTest(GenericHessTest):
+    """Gaussian 03 Hessian unittest."""
+
+class Gaussian09HessTest(GenericHessTest):
+    """Gaussian 09 Hessian unittest."""
+
+class MolproHessTest(GenericHessTest):
+    """Molpro Hessian unittest."""
+
+
+if __name__=="__main__":
+
+    from testall import testall
+    testall(modules=["hess"])

Re: [cclib-devel] Hessian code for gaussianparser.py

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

Hi Matt,

Sounds good. If you could send a patch to this list, we can take a
look. We already have some hessian code somewhere (I think?) so we
will need to make sure that the units are standardised and so forth.

If you checked our code out of subversion, "svn diff" will create the
patch. Otherwise, use "diff -u oldfile newfile > a.patch". If all else
fails, just attach the modified file.

- Noel

On 5 February 2010 06:26, Matt W <pb...@gm...> wrote:
> Hello all,
>   I recently wrote a short bit of code for cclib to read the Hessian from a
> Gaussian output file.  If there is interest in adding this to the project,
> what is the best way to submit it?
>
> Best Regards,
>
> Matt W
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

[cclib-devel] Hessian code for gaussianparser.py

[Matt W <pb...@gm...>]

Hello all,
  I recently wrote a short bit of code for cclib to read the Hessian from a
Gaussian output file.  If there is interest in adding this to the project,
what is the best way to submit it?

Best Regards,

Matt W

[cclib-devel] [ cclib-Bugs-2939920 ] Failed parsing of open-shell CCSD energies in GAMESS US.

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

Bugs item #2939920, was opened at 2010-01-26 02:41
Message generated for change (Settings changed) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2939920&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failed parsing of open-shell CCSD energies in GAMESS US.

Initial Comment:
The open-shell coupled cluster CCSD energies have a different output format from the closed-shell code (using revision 2009-12-01 R3 of GAMESS US).  The tag-line for ROHF-CCSD is "CCSD ENERGY:" not "CCSD    ENERGY:" as it is in the closed-shell output of GAMESS (note extra spaces). Version 0.91 of cclib cannot retrieve the CCSD energies from the open-shell run.  I am placing the GAMESS US log-file open_shell_ccsd_test.log in the public domain as an example of this type of output.

Hope this is helpful.  Regards,

Dan Matusek

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

Comment By: Noel O'Boyle (baoilleach)
Date: 2010-01-26 17:15

Message:
Initial fix in r881.

Dan, could you by any chance rerun our existing water ccsd, ccd and
ccsd(t) example files (in data/basicGAMESS-US) with the settings used for
this run, i.e. open shell. I would like to make sure that the fix is bullet
proof.

BTW, it might be useful to create a sourceforge login - that way you would
be automatically updated of fixes to your reported bugs...

- Noel

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

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

Re: [cclib-devel] Using something more robust than regular expressions

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

Your approach sounds like a cleaner way to do it and I am aware of
another parser that is similar. I will be interested to see whether
such an approach stands the test of time.

However I think it is unlikely that we will rewrite all of our parsers
at this stage as I am confident that our parsers are very robust.
Fixing bugs just takes a few minutes, as we have an extensive test
suite of 100 or more files submitted by users.

I'm curious though - why did you write your own parser instead of
using the existing one in cclib?

- Noel

On 26 January 2010 17:20, Mark Monroe <mo...@oc...> wrote:
> Dear cclib developers,
>
> Have you thought of using a more robust representation of what to match
> than regular expressions? The cclib-Bugs-2939920 is an example of why
> regular expressions are not the best way to go.
>
> I have written my own GAMESS parsing library using a combination of
> regular expressions and the pyparsing library.
>
> The regular expressions are used to extract blocks of text from a GAMESS
> output file. Then pyparsing is used to extract the data I need from
> those blocks.
>
> Pyparsing is slow compared to regular expressions, but far easier to use
> and specify what you want to match. By extracting and processing
> meaningful blocks of text, like the HESS-END block in a GAMESS dat file,
> you can then use pyparsing to easily extract the data you want.
>
> Mark
>
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Using something more robust than regular expressions

[Mark M. <mo...@oc...>]

Dear cclib developers,

Have you thought of using a more robust representation of what to match
than regular expressions? The cclib-Bugs-2939920 is an example of why
regular expressions are not the best way to go.

I have written my own GAMESS parsing library using a combination of
regular expressions and the pyparsing library. 

The regular expressions are used to extract blocks of text from a GAMESS
output file. Then pyparsing is used to extract the data I need from
those blocks.

Pyparsing is slow compared to regular expressions, but far easier to use
and specify what you want to match. By extracting and processing
meaningful blocks of text, like the HESS-END block in a GAMESS dat file,
you can then use pyparsing to easily extract the data you want.

Mark

[cclib-devel] [ cclib-Bugs-2939920 ] Failed parsing of open-shell CCSD energies in GAMESS US.

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

Bugs item #2939920, was opened at 2010-01-26 02:41
Message generated for change (Settings changed) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2939920&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parsers
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failed parsing of open-shell CCSD energies in GAMESS US.

Initial Comment:
The open-shell coupled cluster CCSD energies have a different output format from the closed-shell code (using revision 2009-12-01 R3 of GAMESS US).  The tag-line for ROHF-CCSD is "CCSD ENERGY:" not "CCSD    ENERGY:" as it is in the closed-shell output of GAMESS (note extra spaces). Version 0.91 of cclib cannot retrieve the CCSD energies from the open-shell run.  I am placing the GAMESS US log-file open_shell_ccsd_test.log in the public domain as an example of this type of output.

Hope this is helpful.  Regards,

Dan Matusek

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

>Comment By: Noel O'Boyle (baoilleach)
Date: 2010-01-26 17:15

Message:
Initial fix in r881.

Dan, could you by any chance rerun our existing water ccsd, ccd and
ccsd(t) example files (in data/basicGAMESS-US) with the settings used for
this run, i.e. open shell. I would like to make sure that the fix is bullet
proof.

BTW, it might be useful to create a sourceforge login - that way you would
be automatically updated of fixes to your reported bugs...

- Noel

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

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

[cclib-devel] [ cclib-Bugs-2939920 ] Failed parsing of open-shell CCSD energies in GAMESS US.

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

Bugs item #2939920, was opened at 2010-01-26 02:41
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2939920&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failed parsing of open-shell CCSD energies in GAMESS US.

Initial Comment:
The open-shell coupled cluster CCSD energies have a different output format from the closed-shell code (using revision 2009-12-01 R3 of GAMESS US).  The tag-line for ROHF-CCSD is "CCSD ENERGY:" not "CCSD    ENERGY:" as it is in the closed-shell output of GAMESS (note extra spaces). Version 0.91 of cclib cannot retrieve the CCSD energies from the open-shell run.  I am placing the GAMESS US log-file open_shell_ccsd_test.log in the public domain as an example of this type of output.

Hope this is helpful.  Regards,

Dan Matusek

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

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

Re: [cclib-devel] Solution for bug - ID: 2935847

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

Fixed in r880. Thanks again.

- Noel

2010/1/23 Noel O'Boyle <bao...@gm...>:
> Hi Dan,
>
> Thanks for the bug report and fix. We need just one more thing - a
> public domain log file that exhibits the problem. Are you happy to
> place the file test2.log in the public domain?
>
> Regards,
>   Noel
>
> 2010/1/22 Daniel Matusek <drm...@gm...>:
>> To whom it may concern,
>>
>>  I submitted the bug report for the GAMESS US parser failing on a job
>> with numerical frequencies (ID: 2935847) and, after further
>> investigation, think I have found the source of the error.  Numerical
>> Hessian jobs do not print IR intensities by default so the parser
>> fails at this point.  I have fixed this by wrapping the lines
>> containing the irIntensity array (line 457 in gamessparser.py, rev
>> 797) in a conditional similar to the section on Raman intensities.
>> However, I don't know that this would be a robust fix so I am not
>> submitting a formal patch.  Hopefully this can be dealt with in the
>> next release.
>>
>> I hope that this is helpful.  In case no one has said so, cclib is a
>> very useful tool and you should be congratulated on your efforts.
>> Regards,
>>
>> Dan Matusek
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for Conference
>> attendees to learn about information security's most important issues through
>> interactions with peers, luminaries and emerging and established companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>

[cclib-devel] [ cclib-Bugs-2935847 ] Failed parse of numerical Hessian vibrational frequencies.

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

Bugs item #2935847, was opened at 2010-01-20 20:23
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2935847&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failed parse of numerical Hessian vibrational frequencies.

Initial Comment:
The version of cclib used was 0.91.  The GAMESS US (Jan-12-2009 revision)  job is an ROHF optimisation + vibrational frequency calculation using a fully numerical Hessian.  The parser fails with the following error messages:
                   ....
[GAMESS test2.log INFO] Creating attribute geovalues[]
[GAMESS test2.log INFO] Creating attribute vibfreqs[]
[GAMESS test2.log INFO] Creating attribute vibirs[]
[GAMESS test2.log INFO] Creating attribute vibdisps[]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/site-packages/cclib/parser/logfileparser.py", line 142, in parse
    self.extract(inputfile, line)
  File "/usr/lib/python2.5/site-packages/cclib/parser/gamessparser.py", line 516, in extract
    assert line == blank
AssertionError
>>>
P.S.:  I have also tried using the latest revision of gamessparer.py (873, with output shown above) and the error persists.  Sorry I can't be more helpful.

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

>Comment By: Noel O'Boyle (baoilleach)
Date: 2010-01-24 21:46

Message:
Fix in r880

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

Comment By: Adam Tenderholt (atenderholt)
Date: 2010-01-22 21:24

Message:
"Numerical
Hessian jobs do not print IR intensities by default so the parser
fails at this point.  I have fixed this by wrapping the lines
containing the irIntensity array (line 457 in gamessparser.py, rev
797) in a conditional similar to the section on Raman intensities.
However, I don't know that this would be a robust fix so I am not
submitting a formal patch.  Hopefully this can be dealt with in the
next release." --Daniel Matusek

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

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

[cclib-devel] ccwatcher release

[Xaver W. <xav...@we...>]

Hi guys,

in case you are interested, I'd like to inform you about the release of my 
very first application, a comp-chem monitoring & plotting application, dubbed 
'ccwatcher', has been released on sourceforge 
(https://sourceforge.net/projects/ccwatcher/)! It can use cclib as a backend.
While I am very proud of this and would love to receive some feedback, please 
keep in mind that I am a real programming newbie and this is still beta 
quality.

Best regards,
Xaver

[cclib-devel] Fwd: Solution for bug - ID: 2935847

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

---------- Forwarded message ----------
From: Dan Matusek <drm...@gm...>
Date: 23 January 2010 16:38
Subject: Re: [cclib-devel] Solution for bug - ID: 2935847
To: Noel O'Boyle <bao...@gm...>


Hi Noel,

 I am indeed happy to place test2.log in the public domain.  I
somehow doubt its results are a great revelation...

Regards,

Dan

On 23 January 2010 07:18, Noel O'Boyle <bao...@gm...> wrote:
> Hi Dan,
>
> Thanks for the bug report and fix. We need just one more thing - a
> public domain log file that exhibits the problem. Are you happy to
> place the file test2.log in the public domain?
>
> Regards,
>   Noel
>
> 2010/1/22 Daniel Matusek <drm...@gm...>:
>> To whom it may concern,
>>
>>  I submitted the bug report for the GAMESS US parser failing on a job
>> with numerical frequencies (ID: 2935847) and, after further
>> investigation, think I have found the source of the error.  Numerical
>> Hessian jobs do not print IR intensities by default so the parser
>> fails at this point.  I have fixed this by wrapping the lines
>> containing the irIntensity array (line 457 in gamessparser.py, rev
>> 797) in a conditional similar to the section on Raman intensities.
>> However, I don't know that this would be a robust fix so I am not
>> submitting a formal patch.  Hopefully this can be dealt with in the
>> next release.
>>
>> I hope that this is helpful.  In case no one has said so, cclib is a
>> very useful tool and you should be congratulated on your efforts.
>> Regards,
>>
>> Dan Matusek
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for Conference
>> attendees to learn about information security's most important issues through
>> interactions with peers, luminaries and emerging and established companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>

Re: [cclib-devel] Solution for bug - ID: 2935847

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

Hi Dan,

Thanks for the bug report and fix. We need just one more thing - a
public domain log file that exhibits the problem. Are you happy to
place the file test2.log in the public domain?

Regards,
   Noel

2010/1/22 Daniel Matusek <drm...@gm...>:
> To whom it may concern,
>
>  I submitted the bug report for the GAMESS US parser failing on a job
> with numerical frequencies (ID: 2935847) and, after further
> investigation, think I have found the source of the error.  Numerical
> Hessian jobs do not print IR intensities by default so the parser
> fails at this point.  I have fixed this by wrapping the lines
> containing the irIntensity array (line 457 in gamessparser.py, rev
> 797) in a conditional similar to the section on Raman intensities.
> However, I don't know that this would be a robust fix so I am not
> submitting a formal patch.  Hopefully this can be dealt with in the
> next release.
>
> I hope that this is helpful.  In case no one has said so, cclib is a
> very useful tool and you should be congratulated on your efforts.
> Regards,
>
> Dan Matusek
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Solution for bug - ID: 2935847

[Adam T. <ate...@gm...>]

Hi Dan,

Thank you for the kind words and for your input regarding a possible
fix to the bug you found.

Adam


On Fri, Jan 22, 2010 at 8:49 AM, Daniel Matusek <drm...@gm...> wrote:
> To whom it may concern,
>
>  I submitted the bug report for the GAMESS US parser failing on a job
> with numerical frequencies (ID: 2935847) and, after further
> investigation, think I have found the source of the error.  Numerical
> Hessian jobs do not print IR intensities by default so the parser
> fails at this point.  I have fixed this by wrapping the lines
> containing the irIntensity array (line 457 in gamessparser.py, rev
> 797) in a conditional similar to the section on Raman intensities.
> However, I don't know that this would be a robust fix so I am not
> submitting a formal patch.  Hopefully this can be dealt with in the
> next release.
>
> I hope that this is helpful.  In case no one has said so, cclib is a
> very useful tool and you should be congratulated on your efforts.
> Regards,
>
> Dan Matusek
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] [ cclib-Bugs-2935847 ] Failed parse of numerical Hessian vibrational frequencies.

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

Bugs item #2935847, was opened at 2010-01-20 12:23
Message generated for change (Comment added) made by atenderholt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2935847&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failed parse of numerical Hessian vibrational frequencies.

Initial Comment:
The version of cclib used was 0.91.  The GAMESS US (Jan-12-2009 revision)  job is an ROHF optimisation + vibrational frequency calculation using a fully numerical Hessian.  The parser fails with the following error messages:
                   ....
[GAMESS test2.log INFO] Creating attribute geovalues[]
[GAMESS test2.log INFO] Creating attribute vibfreqs[]
[GAMESS test2.log INFO] Creating attribute vibirs[]
[GAMESS test2.log INFO] Creating attribute vibdisps[]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/site-packages/cclib/parser/logfileparser.py", line 142, in parse
    self.extract(inputfile, line)
  File "/usr/lib/python2.5/site-packages/cclib/parser/gamessparser.py", line 516, in extract
    assert line == blank
AssertionError
>>>
P.S.:  I have also tried using the latest revision of gamessparer.py (873, with output shown above) and the error persists.  Sorry I can't be more helpful.

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

>Comment By: Adam Tenderholt (atenderholt)
Date: 2010-01-22 13:24

Message:
"Numerical
Hessian jobs do not print IR intensities by default so the parser
fails at this point.  I have fixed this by wrapping the lines
containing the irIntensity array (line 457 in gamessparser.py, rev
797) in a conditional similar to the section on Raman intensities.
However, I don't know that this would be a robust fix so I am not
submitting a formal patch.  Hopefully this can be dealt with in the
next release." --Daniel Matusek

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

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

[cclib-devel] Solution for bug - ID: 2935847

[Daniel M. <drm...@gm...>]

To whom it may concern,

  I submitted the bug report for the GAMESS US parser failing on a job
with numerical frequencies (ID: 2935847) and, after further
investigation, think I have found the source of the error.  Numerical
Hessian jobs do not print IR intensities by default so the parser
fails at this point.  I have fixed this by wrapping the lines
containing the irIntensity array (line 457 in gamessparser.py, rev
797) in a conditional similar to the section on Raman intensities.
However, I don't know that this would be a robust fix so I am not
submitting a formal patch.  Hopefully this can be dealt with in the
next release.

I hope that this is helpful.  In case no one has said so, cclib is a
very useful tool and you should be congratulated on your efforts.
Regards,

Dan Matusek

[cclib-devel] [ cclib-Bugs-2935847 ] Failed parse of numerical Hessian vibrational frequencies.

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

Bugs item #2935847, was opened at 2010-01-20 20:23
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=2935847&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failed parse of numerical Hessian vibrational frequencies.

Initial Comment:
The version of cclib used was 0.91.  The GAMESS US (Jan-12-2009 revision)  job is an ROHF optimisation + vibrational frequency calculation using a fully numerical Hessian.  The parser fails with the following error messages:
                   ....
[GAMESS test2.log INFO] Creating attribute geovalues[]
[GAMESS test2.log INFO] Creating attribute vibfreqs[]
[GAMESS test2.log INFO] Creating attribute vibirs[]
[GAMESS test2.log INFO] Creating attribute vibdisps[]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/site-packages/cclib/parser/logfileparser.py", line 142, in parse
    self.extract(inputfile, line)
  File "/usr/lib/python2.5/site-packages/cclib/parser/gamessparser.py", line 516, in extract
    assert line == blank
AssertionError
>>>
P.S.:  I have also tried using the latest revision of gamessparer.py (873, with output shown above) and the error persists.  Sorry I can't be more helpful.

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

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

[cclib-devel] [ cclib-Feature Requests-2921890 ] Make scfvalues available from non-#P Gaussian files

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

Feature Requests item #2921890, was opened at 2009-12-27 17:07
Message generated for change (Tracker Item Submitted) made by xaverxn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819225&aid=2921890&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: xaverxn (xaverxn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make scfvalues available from non-#P Gaussian files

Initial Comment:
So far, cclib can extract certain information only from gaussian files with additional output activated (#P keyword). As you can see from my last bug report, this is true for the number of steps needed for SCF convergence (but maybe others, too). As this information is available from non-#P logs as well, I'd like to be able to get it from cclib, too. Of course the content of 'scfvalues' can't be extracted. If you don't want to change it's content structure, you could simply create as many empty lists as steps needed, so len(data.scfvalues) gives the right number for #P and non-#P logs.

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

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

[cclib-devel] [ cclib-Feature Requests-2921888 ] A list of lines from which info was extracted

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

Feature Requests item #2921888, was opened at 2009-12-27 16:57
Message generated for change (Tracker Item Submitted) made by xaverxn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819225&aid=2921888&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: xaverxn (xaverxn)
Assigned to: Nobody/Anonymous (nobody)
Summary: A list of lines from which info was extracted

Initial Comment:
Hi,
I'd like to have access to the the actual lines cclib extracted information from. They could simply be stored in a (python) list during parsing. That way cclib users would have a kind of 'concentrated' log file, with just the lines 'cclib deems most important'.

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

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

Re: [cclib-devel] basis functions don't match

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

I guess that the set of non-redundant basis functions depends on the
geometry somehow. I think I've seen this before,  but it's a rare
occurence. Is it possible to get ahold of the log file and file a bug?

- Noel

2009/12/22 Adam Tenderholt <a-t...@st...>:
> One of my labmates has a problem with a Gaussian optimization where cclib says that the number of basis functions don't match. I've tracked the problem to NBsUs changing at certain steps. Any idea of why this is happening?
>
> Adam
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] basis functions don't match

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

One of my labmates has a problem with a Gaussian optimization where cclib says that the number of basis functions don't match. I've tracked the problem to NBsUs changing at certain steps. Any idea of why this is happening?

Adam