cclib-devel — Developer's mailing list

Re: [cclib-devel] Modifications to cclib 1.0

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

>>> 
>>> 
>>> Any thoughts on keeping them as vibmasses or should we call them
>>> atomicmasses?
>> 
>> It sounds like atommasses (like atomnos) would make most sense.
> 
> OK, I can do this in the trunk later today. Adam, you'll have to sync the 
> branches you develop.
> 

Karol, do you just want to merge the changes I made for the Gaussian and ADF parsers (turbomol branch) into trunk before you start working on them? You'll have the rename them from vibmasses to atomicmasses.

Adam

Re: [cclib-devel] Modifications to cclib 1.0

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

On Thursday 08 April 2010 22:16:38 Noel O'Boyle wrote:
> On 8 April 2010 20:10, Adam Tenderholt <ate...@gm...> wrote:
> >> 2) Do we add the molmass attribute? Perhaps it would be more usefull to
> >> add an atomicmass attribute; more information and can be easily summed.
> >
> > I'm actually interested in adding the atomic masses, and have already
> > done so in the Turbomole branch for the turbomole, Gaussian, and ADF
> > parsers. I've been calling the vibmasses since my interest in them is
> > to calculate isotope-dependent vibrational spectra (NRVS, to be
> > precise).
> >
> > Any thoughts on keeping them as vibmasses or should we call them
> > atomicmasses?
>
> It sounds like atommasses (like atomnos) would make most sense.

I assume we will be using daltons.

-- 
written by Karol Langner
Fri Apr  9 11:36:29 CEST 2010

Re: [cclib-devel] Modifications to cclib 1.0

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

On Thursday 08 April 2010 22:16:38 Noel O'Boyle wrote:
> On 8 April 2010 20:10, Adam Tenderholt <ate...@gm...> wrote:
> >> 2) Do we add the molmass attribute? Perhaps it would be more usefull to
> >> add an atomicmass attribute; more information and can be easily summed.
> >
> > I'm actually interested in adding the atomic masses, and have already
> > done so in the Turbomole branch for the turbomole, Gaussian, and ADF
> > parsers. I've been calling the vibmasses since my interest in them is
> > to calculate isotope-dependent vibrational spectra (NRVS, to be
> > precise).
> >
> > Any thoughts on keeping them as vibmasses or should we call them
> > atomicmasses?
>
> It sounds like atommasses (like atomnos) would make most sense.

OK, I can do this in the trunk later today. Adam, you'll have to sync the 
branches you develop.

- Karol

-- 
written by Karol Langner
Fri Apr  9 10:03:52 CEST 2010

Re: [cclib-devel] Modifications to cclib 1.0

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

On 8 April 2010 20:10, Adam Tenderholt <ate...@gm...> wrote:
>> 2) Do we add the molmass attribute? Perhaps it would be more usefull to add an
>> atomicmass attribute; more information and can be easily summed.
>
> I'm actually interested in adding the atomic masses, and have already
> done so in the Turbomole branch for the turbomole, Gaussian, and ADF
> parsers. I've been calling the vibmasses since my interest in them is
> to calculate isotope-dependent vibrational spectra (NRVS, to be
> precise).
>
> Any thoughts on keeping them as vibmasses or should we call them atomicmasses?

It sounds like atommasses (like atomnos) would make most sense.

> Adam
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Modifications to cclib 1.0

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

> 2) Do we add the molmass attribute? Perhaps it would be more usefull to add an
> atomicmass attribute; more information and can be easily summed.

I'm actually interested in adding the atomic masses, and have already
done so in the Turbomole branch for the turbomole, Gaussian, and ADF
parsers. I've been calling the vibmasses since my interest in them is
to calculate isotope-dependent vibrational spectra (NRVS, to be
precise).

Any thoughts on keeping them as vibmasses or should we call them atomicmasses?

Adam

Re: [cclib-devel] Modifications to cclib 1.0

[Karol M. L. <km...@mm...>]

Hi!

Great. I added the file to our regression suite. I used the parts of your 
patch that fix scfenergies and homos, so that the regression parses 
correctly.

As far as adding new attributes and the MOPAC parser, I suppose we need to 
discuss that a bit more. Basically three issues I see here:
1) Do we want to add the MOPAC parser now? Probably should be as a separate 
branch.
2) Do we add the molmass attribute? Perhaps it would be more usefull to add an 
atomicmass attribute; more information and can be easily summed.
3) Do we want to add the rotation constants and symmetries now? I don't know 
if and how these things are printed in other programs (GAMESS, ADF).

Thanks again for the contribution,
Karol

On Tuesday 06 April 2010 22:08:06 Gregory Magoon wrote:
> 1. I have no objections to your use of the Gaussian log file.
>
> 2. I use the rotational constants as part of the rotational partition
> function for computing gas-phase thermodynamic quantities (entropy,
> enthalpy, heat capacity). I suppose I could instead calculate the moments
> of inertia based on the atomic coordinates and masses, but it is easier to
> just read in the result that Gaussian/MOPAC calculates. (For rotational
> symmetry number, I actually don't end up using the value from the Gaussian
> log file since it is often underestimated by Gaussian...I have instead been
> using a program called SYMMETRY which allows point group calculation within
> a user-specified tolerance: http://www.cobalt.chem.ucalgary.ca/ps/symmetry/
> ).
>
> 3. I have written some Python scripts that provide an interface between
> the Java
> code and cclib (I haven't included them in the public version of RMG yet).
> The Python scripts are executed from the Java code using
> Runtime.getRuntime().exec() and the Python script produces output read in
> by the Java code in a particular format. I have the Java code interface
> with RDKit
> in a similar way. (For what it's worth, there is also a Python version
> of RMG in
> development: http://github.com/GreenGroup/RMG-Py )
>
> Greg
>
> Quoting Noel O'Boyle <bao...@gm...>:
> > Thanks for the patch Greg and the positive comments.
> >
> > We'll look into integrating this as soon as possible - in particular,
> > it would be great to beef up our MOPAC support. We'll probably have
> > more questions later but right now, I've got three that spring to
> > mind:
> > (1) Are you happy to place the attached log file in the public domain?
> > (This is a requirement for our test suite)
> > (2) Why are you interested in parsing the rotational data?
> > (3) RMG looks like a nice project, but how are you using cclib given
> > that it's a Java/FORTRAN project?
> >
> > - Noel
> >
> > On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote:
> >> Hello cclib developers,
> >>  I've recently started to use cclib with the reaction mechanism
> >> generation software that I work on (http://rmg.sourceforge.net). I
> >> figured I would pass along some of the modifications I have made to
> >> cclib (see the attached .gitpatch file; these assume v1.0 as the
> >> starting point) in case they could be
> >> of benefit to you or other users.
> >> The modifications include:
> >> 1. Fixed (or at least partially fixed) a bug encountered when
> >> parsing triplet
> >> oxygen atom results from Gaussian03. Originally, this case (see attached
> >> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of
> >> orbital symmetry and assignment of HOMOS due to the fact that there were
> >> no alpha virtual orbitals.
> >> 2. Implemented parsing of certain quantities from MOPAC2009 results.
> >> 3. Parsed a few additional quantities from Gaussian output, like
> >> molecular mass,
> >> rotational symmetry number, and rotational constants.
> >> I have tested my changes mostly, if not exclusively, with PM3
> >> calculations from
> >> Gaussian03 and MOPAC2009, but testall.py with the modified code
> >> seems to give
> >> the same results for Gaussian03 as it did before my modifications (91
> >> tests pass and 3 tests are skipped).
> >>
> >> If you think any of these changes are useful, please feel free to
> >> include them
> >> (or something based on them) in the next cclib release (and feel
> >> free to remove
> >> any of my superfluous comments). Also, if you have any questions about
> >> the changes, please let me know.
> >>
> >> Thanks very much for your work on cclib and for making it open-source,
> >> Greg Magoon

-- 
written by Karol Langner
Wed Apr  7 12:25:50 CEST 2010

Re: [cclib-devel] Modifications to cclib 1.0

[Gregory M. <gm...@MI...>]

Hi Noel,
Thanks for the quick response. In answer to your questions:

1. I have no objections to your use of the Gaussian log file.

2. I use the rotational constants as part of the rotational partition function
for computing gas-phase thermodynamic quantities (entropy, enthalpy, heat
capacity). I suppose I could instead calculate the moments of inertia based on
the atomic coordinates and masses, but it is easier to just read in the result
that Gaussian/MOPAC calculates. (For rotational symmetry number, I actually
don't end up using the value from the Gaussian log file since it is often
underestimated by Gaussian...I have instead been using a program called
SYMMETRY which allows point group calculation within a user-specified
tolerance: http://www.cobalt.chem.ucalgary.ca/ps/symmetry/ ).

3. I have written some Python scripts that provide an interface between 
the Java
code and cclib (I haven't included them in the public version of RMG yet). The
Python scripts are executed from the Java code using
Runtime.getRuntime().exec() and the Python script produces output read in by
the Java code in a particular format. I have the Java code interface 
with RDKit
in a similar way. (For what it's worth, there is also a Python version 
of RMG in
development: http://github.com/GreenGroup/RMG-Py )

Greg

Quoting Noel O'Boyle <bao...@gm...>:

> Thanks for the patch Greg and the positive comments.
>
> We'll look into integrating this as soon as possible - in particular,
> it would be great to beef up our MOPAC support. We'll probably have
> more questions later but right now, I've got three that spring to
> mind:
> (1) Are you happy to place the attached log file in the public domain?
> (This is a requirement for our test suite)
> (2) Why are you interested in parsing the rotational data?
> (3) RMG looks like a nice project, but how are you using cclib given
> that it's a Java/FORTRAN project?
>
> - Noel
>
> On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote:
>> Hello cclib developers,
>>  I've recently started to use cclib with the reaction mechanism generation
>> software that I work on (http://rmg.sourceforge.net). I figured I would pass
>> along some of the modifications I have made to cclib (see the attached
>> .gitpatch file; these assume v1.0 as the starting point) in case 
>> they could be
>> of benefit to you or other users.
>> The modifications include:
>> 1. Fixed (or at least partially fixed) a bug encountered when 
>> parsing triplet
>> oxygen atom results from Gaussian03. Originally, this case (see attached
>> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital
>> symmetry and assignment of HOMOS due to the fact that there were no alpha
>> virtual orbitals.
>> 2. Implemented parsing of certain quantities from MOPAC2009 results.
>> 3. Parsed a few additional quantities from Gaussian output, like 
>> molecular mass,
>> rotational symmetry number, and rotational constants.
>> I have tested my changes mostly, if not exclusively, with PM3 
>> calculations from
>> Gaussian03 and MOPAC2009, but testall.py with the modified code 
>> seems to give
>> the same results for Gaussian03 as it did before my modifications (91 tests
>> pass and 3 tests are skipped).
>>
>> If you think any of these changes are useful, please feel free to 
>> include them
>> (or something based on them) in the next cclib release (and feel 
>> free to remove
>> any of my superfluous comments). Also, if you have any questions about the
>> changes, please let me know.
>>
>> Thanks very much for your work on cclib and for making it open-source,
>> Greg Magoon
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>>
>

Re: [cclib-devel] Modifications to cclib 1.0

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

Thanks for the patch Greg and the positive comments.

We'll look into integrating this as soon as possible - in particular,
it would be great to beef up our MOPAC support. We'll probably have
more questions later but right now, I've got three that spring to
mind:
(1) Are you happy to place the attached log file in the public domain?
(This is a requirement for our test suite)
(2) Why are you interested in parsing the rotational data?
(3) RMG looks like a nice project, but how are you using cclib given
that it's a Java/FORTRAN project?

- Noel

On 6 April 2010 19:51, Gregory Magoon <gm...@mi...> wrote:
> Hello cclib developers,
>  I've recently started to use cclib with the reaction mechanism generation
> software that I work on (http://rmg.sourceforge.net). I figured I would pass
> along some of the modifications I have made to cclib (see the attached
> .gitpatch file; these assume v1.0 as the starting point) in case they could be
> of benefit to you or other users.
> The modifications include:
> 1. Fixed (or at least partially fixed) a bug encountered when parsing triplet
> oxygen atom results from Gaussian03. Originally, this case (see attached
> QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital
> symmetry and assignment of HOMOS due to the fact that there were no alpha
> virtual orbitals.
> 2. Implemented parsing of certain quantities from MOPAC2009 results.
> 3. Parsed a few additional quantities from Gaussian output, like molecular mass,
> rotational symmetry number, and rotational constants.
> I have tested my changes mostly, if not exclusively, with PM3 calculations from
> Gaussian03 and MOPAC2009, but testall.py with the modified code seems to give
> the same results for Gaussian03 as it did before my modifications (91 tests
> pass and 3 tests are skipped).
>
> If you think any of these changes are useful, please feel free to include them
> (or something based on them) in the next cclib release (and feel free to remove
> any of my superfluous comments). Also, if you have any questions about the
> changes, please let me know.
>
> Thanks very much for your work on cclib and for making it open-source,
> Greg Magoon
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

[cclib-devel] Modifications to cclib 1.0

[Gregory M. <gm...@MI...>]

Hello cclib developers,
 I've recently started to use cclib with the reaction mechanism generation
software that I work on (http://rmg.sourceforge.net). I figured I would pass
along some of the modifications I have made to cclib (see the attached
.gitpatch file; these assume v1.0 as the starting point) in case they could be
of benefit to you or other users.
The modifications include:
1. Fixed (or at least partially fixed) a bug encountered when parsing triplet
oxygen atom results from Gaussian03. Originally, this case (see attached
QVGXLLKOCUKJST-UHFFFAOYAJmult3Fixed.out) failed during parsing of orbital
symmetry and assignment of HOMOS due to the fact that there were no alpha
virtual orbitals.
2. Implemented parsing of certain quantities from MOPAC2009 results.
3. Parsed a few additional quantities from Gaussian output, like molecular mass,
rotational symmetry number, and rotational constants.
I have tested my changes mostly, if not exclusively, with PM3 calculations from
Gaussian03 and MOPAC2009, but testall.py with the modified code seems to give
the same results for Gaussian03 as it did before my modifications (91 tests
pass and 3 tests are skipped).

If you think any of these changes are useful, please feel free to include them
(or something based on them) in the next cclib release (and feel free to remove
any of my superfluous comments). Also, if you have any questions about the
changes, please let me know.

Thanks very much for your work on cclib and for making it open-source,
Greg Magoon

Re: [cclib-devel] PBC in Gaussian09

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

There are no mocoeffs in the G09 file. There are in the G03 file, and
we appear to parse them.

- Noel

On 29 March 2010 17:39, Nuno A. G. Bandeira <nun...@is...> wrote:
> The previous one was run with G03 rev. E, this one is G09.
>
>
> --
> Nuno A. G. Bandeira, AMRSC
> Laboratoire de Chimie LR6
> Ecole Normale Superieure de Lyon
> 46, Allee d'Italie
> 69364 Lyon Cedex 07 - France
> http://cqb.fc.ul.pt/intheochem/nuno/
> --
>
>
>

Re: [cclib-devel] PBC in Gaussian09

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

Hi Nuno,

Your file does not contain molecular orbital coefficients.

- Noel

On 26 March 2010 16:19, Nuno A. G. Bandeira <nun...@is...> wrote:
> Dear developers,
>
> CClib does not correctly parse the information from G09 PBC calculations.
> The error message goes :
>
>>>> analysis.calculate()
> [MPA Gaussian log file /cygdrive/c/neoprene.out ERROR] Missing mocoeffs
> False
>>>>
>
> So attached is the same tutorial file they have in the manual.
>
> Also can I ask how can I update the cclib libraries in QMForge in Windows ?
> The program is immensely outdated but it would suit me for my purposes
> rather than using cumbersome command lines.
>
> I've tried to simply replace the cclib contents in the library.zip file but
> no luck so far it seems.
>
>
> --
> Nuno A. G. Bandeira, AMRSC
> Laboratoire de Chimie LR6
> Ecole Normale Superieure de Lyon
> 46, Allee d'Italie
> 69364 Lyon Cedex 07 - France
> http://cqb.fc.ul.pt/intheochem/nuno/
> --
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] [POSSIBLE VIRUS:###] PBC in Gaussian09

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

 Hi Nuno (and others),

I'm the (busy? bad?) maintainer of QMForge. Unfortunately, I haven't
figured out an easy way to upgrade its cclib libraries without
completely rebuilding the binary Windows distribution. Which is
complicated because last time I was working on QMForge (yes, years
ago), I was porting to a newer version of Qt (or PyQt) which had
changed enough that it actually broke parts of QMForge.

If you are feeling adventurous, you can download and install the most
recent versions of PyQt, PyOpenGL, openbabel, cclib, and the source
distribution of QMForge. I can try to troubleshoot any of your
problems via email. I'll also try to move working on cclib/QMForge to
the top of my list of things to do, but it definitely won't be ready
for at least a couple of weeks.

Sorry for the trouble,

Adam

On Fri, Mar 26, 2010 at 8:19 AM, Nuno A. G. Bandeira
<nun...@is...> wrote:
> Dear developers,
>
> CClib does not correctly parse the information from G09 PBC calculations.
> The error message goes :
>
>>>> analysis.calculate()
> [MPA Gaussian log file /cygdrive/c/neoprene.out ERROR] Missing mocoeffs
> False
>>>>
>
> So attached is the same tutorial file they have in the manual.
>
> Also can I ask how can I update the cclib libraries in QMForge in Windows ?
> The program is immensely outdated but it would suit me for my purposes
> rather than using cumbersome command lines.
>
> I've tried to simply replace the cclib contents in the library.zip file but
> no luck so far it seems.
>
>
> --
> Nuno A. G. Bandeira, AMRSC
> Laboratoire de Chimie LR6
> Ecole Normale Superieure de Lyon
> 46, Allee d'Italie
> 69364 Lyon Cedex 07 - France
> http://cqb.fc.ul.pt/intheochem/nuno/
> --
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

[cclib-devel] ANN: cclib 1.0 now available

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

Hello everyone,

cclib 1.0 is now available for download from http://cclib.sf.net. It's
been some time since the last release, so we recommend you to upgrade
to this version.

Changes since cclib-0.9:

Features:
	* Handle PBC calculations from Gaussian
	* Updates to handle Gaussian09
	* Support TDDFT calculations from ADF
	* A number of improvements for GAMESS support
	* ccopen now supports any file-like object with a read() method, so it
	can parse across HTTP

Bugfixes:
	* Many many additional files parsed thanks to bugs reported by users

Remember to cite cclib if you use it to obtain results for
publication. This encourages us to keep doing what we do.

Regards,
   The cclib development team

Re: [cclib-devel] [cclib-users] GAMESS-US and mpenergies

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

This is now fixed. Thanks again. Keep sending any failures.

- Noel

On 6 March 2010 13:13, Paulo E. Abreu <pau...@ci...> wrote:
> Hello,
> There is still a problem with the mp2energies for non-restricted MP2
> calculation.
> I have attached files (which I put in the public domain) of example
> calculations:
> N2-RMP2.out (RHF MP2 calculation) is parsed correctly
> N2-UMP2.out (UHF MP2 calculation) is not parsed correctly
> N2-ROMP2.out (ROHF MP2 calculation) is not parsed correctly
> Hope this helps ironing these minor bugs.
> All the best,
> Paulo
>
> On Thu, Mar 4, 2010 at 3:49 PM, Noel O'Boyle <bao...@gm...> wrote:
>>
>> This is now fixed in our development version. I'd appreciate if you
>> could test it and let us know if it's working fine for you.
>>
>> - Noel
>>
>> On 25 February 2010 15:47, Paulo E. Abreu <pau...@ci...> wrote:
>> > Hiya Noel,
>> > Attached you will find a MP2 calculation on water. Parsing this file
>> > with
>> > cclib I get
>> > [GAMESS h2o-mp2.out INFO] Creating attribute atomcoords[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute atomnos[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute gbasis[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute nbasis: 19
>> > [GAMESS h2o-mp2.out INFO] Creating attribute charge: 0
>> > [GAMESS h2o-mp2.out INFO] Creating attribute mult: 1
>> > [GAMESS h2o-mp2.out INFO] Creating attribute homos[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute natom: 3
>> > [GAMESS h2o-mp2.out INFO] Creating attribute scftargets[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute scfvalues[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute scfenergies[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute moenergies[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute mosyms[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute nmo: 19
>> > [GAMESS h2o-mp2.out INFO] Creating attribute mocoeffs[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute atombasis[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute aonames[]
>> > [GAMESS h2o-mp2.out INFO] Creating attribute coreelectrons[]
>> > No mpenergies are defined.
>> > And yes you can distribute this file.
>> > Hope this helps.
>> > Paulo
>> >
>> > On Thu, Feb 25, 2010 at 3:34 PM, Noel O'Boyle <bao...@gm...>
>> > wrote:
>> >>
>> >> Hello Paulo,
>> >>
>> >> Sounds like a bug.
>> >>
>> >> Could you provide us with a public domain test file? That is, this
>> >> should be a test file which you are happy for us to share with the
>> >> world.
>> >>
>> >> - Noel
>> >>
>> >> On 25 February 2010 12:16, Paulo E. Abreu <pau...@ci...> wrote:
>> >> > Hello,
>> >> > I have been using cclib for my parsers and just noticed something odd
>> >> > about
>> >> > GAMESS-US files with MP2 calculations.
>> >> > According to http://cclib.sourceforge.net/wiki/index.php/Parsed_Data
>> >> > and
>> >> >  http://cclib.sourceforge.net/wiki/index.php/Mpenergies
>> >> > this is available for GAMESS-US output files. The problem is that I
>> >> > cannot
>> >> > access this information. The logging after parsing the file
>> >> > does not show any mpenergies and consequently when I try to use it I
>> >> > get
>> >> > an
>> >> > error
>> >> > AttributeError: 'ccData' object has no attribute 'mpenergies'
>> >> > Is there something which I am missing here ?
>> >> > ===begin code snippet
>> >> > myfile = ccopen("mp2.out")
>> >> > data = myfile.parse()
>> >> > print data.mpenergies
>> >> > ===end code snippet
>> >> > Thanks a lot
>> >> > --
>> >> > Paulo E. Abreu
>> >> > Professor Auxiliar
>> >> > Departamento de Química
>> >> > Faculdade de Ciências e Tecnologia da Universidade de Coimbra
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Download Intel&#174; Parallel Studio Eval
>> >> > Try the new software tools for yourself. Speed compiling, find bugs
>> >> > proactively, and fine-tune applications for parallel performance.
>> >> > See why Intel Parallel Studio got high marks during beta.
>> >> > http://p.sf.net/sfu/intel-sw-dev
>> >> > _______________________________________________
>> >> > cclib-users mailing list
>> >> > ccl...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/cclib-users
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > Paulo E. Abreu
>> > Professor Auxiliar
>> > Departamento de Química
>> > Faculdade de Ciências e Tecnologia da Universidade de Coimbra
>> >
>
>
>
> --
> Paulo E. Abreu
> Professor Auxiliar
> Departamento de Química
> Faculdade de Ciências e Tecnologia da Universidade de Coimbra
>

[cclib-devel] Fwd: [cclib-users] cclib-0.91 bug Gaussian parser does not parse Vibsyms correctly if T symm

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

---------- Forwarded message ----------
From: Klemens Noga <kn...@ch...>
Date: 5 March 2010 09:48
Subject: Re: [cclib-users] cclib-0.91 bug Gaussian parser does not
parse  Vibsyms correctly if T symm
To: Noel O'Boyle <bao...@gm...>


Dear Noel,

Feel free to place those files in the public domain.

Best regards,

Klemens

On 5 Mar 2010, at 10:39, Noel O'Boyle wrote:

> Hello Klemens,
>
> Thanks for letting us know. To fix bugs we need public domain test
> files - are you happy to place your attached files in the public
> domain? If not, we'd appreciate if you could generate some small test
> files that reproduce the problem.
>
> I've leave the others to discuss Turbomole.
>
> - Noel
>
> On 5 March 2010 07:32, Klemens Noga <kn...@ch...> wrote:
>>
>> Dear all,
>>
>> My name is Klemens Noga and I'm PhD student in Theoretical Chemistry at
>> Jagiellonian University in Krakow, Poland. I've started using cclib to parse
>> data from GAMESS and Gaussian output files and I probably found bug. When
>> there are vibrations with T symmetry they aren't parsed into vibsyms list
>> correctly. You could check it in attached example files. Is there any simple
>> solution?
>> Secondly, I'm interested in parsing data from Turbomole outputs. I've heard
>> that cclib development team is working at this issue but i've found only
>> very old information and I'm curious about progress.
>>
>> Best regads,
>>
>> Klemens
>>
>>
>>
>>
>>
>> Klemens Noga
>> Ph.D. student
>> Department of Theoretical Chemistry
>> Faculty of Chemistry, Jagiellonian University
>> Ingardena st. 3, 30-060 Krakow, Poland
>> tel. +48-12-6632023
>> e.mail: kn...@ch...
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> cclib-users mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-users
>>
>>

Klemens Noga
Ph.D. student
Department of Theoretical Chemistry
Faculty of Chemistry, Jagiellonian University
Ingardena st. 3, 30-060 Krakow, Poland
tel. +48-12-6632023
e.mail: kn...@ch...

[cclib-devel] cclib 1.0 this weekend

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

Dear Adam and Karol,

It's been 18 months or so since the last cclib release, and so it's
time to get out another one. I know Adam's working on some new
features on a branch, and I still have to integrate a patch sent by a
user, so we'll have another release in a month or two. But right now,
I'd appreciate if you could check the cclib-1.0b release on
SourceForge and make any updates to the CHANGELOG etc that you feel
necessary.

- Noel

Re: [cclib-devel] [cclib-users] GAMESS-US and mpenergies

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

This is now fixed in our development version. I'd appreciate if you
could test it and let us know if it's working fine for you.

- Noel

On 25 February 2010 15:47, Paulo E. Abreu <pau...@ci...> wrote:
> Hiya Noel,
> Attached you will find a MP2 calculation on water. Parsing this file with
> cclib I get
> [GAMESS h2o-mp2.out INFO] Creating attribute atomcoords[]
> [GAMESS h2o-mp2.out INFO] Creating attribute atomnos[]
> [GAMESS h2o-mp2.out INFO] Creating attribute gbasis[]
> [GAMESS h2o-mp2.out INFO] Creating attribute nbasis: 19
> [GAMESS h2o-mp2.out INFO] Creating attribute charge: 0
> [GAMESS h2o-mp2.out INFO] Creating attribute mult: 1
> [GAMESS h2o-mp2.out INFO] Creating attribute homos[]
> [GAMESS h2o-mp2.out INFO] Creating attribute natom: 3
> [GAMESS h2o-mp2.out INFO] Creating attribute scftargets[]
> [GAMESS h2o-mp2.out INFO] Creating attribute scfvalues[]
> [GAMESS h2o-mp2.out INFO] Creating attribute scfenergies[]
> [GAMESS h2o-mp2.out INFO] Creating attribute moenergies[]
> [GAMESS h2o-mp2.out INFO] Creating attribute mosyms[]
> [GAMESS h2o-mp2.out INFO] Creating attribute nmo: 19
> [GAMESS h2o-mp2.out INFO] Creating attribute mocoeffs[]
> [GAMESS h2o-mp2.out INFO] Creating attribute atombasis[]
> [GAMESS h2o-mp2.out INFO] Creating attribute aonames[]
> [GAMESS h2o-mp2.out INFO] Creating attribute coreelectrons[]
> No mpenergies are defined.
> And yes you can distribute this file.
> Hope this helps.
> Paulo
>
> On Thu, Feb 25, 2010 at 3:34 PM, Noel O'Boyle <bao...@gm...> wrote:
>>
>> Hello Paulo,
>>
>> Sounds like a bug.
>>
>> Could you provide us with a public domain test file? That is, this
>> should be a test file which you are happy for us to share with the
>> world.
>>
>> - Noel
>>
>> On 25 February 2010 12:16, Paulo E. Abreu <pau...@ci...> wrote:
>> > Hello,
>> > I have been using cclib for my parsers and just noticed something odd
>> > about
>> > GAMESS-US files with MP2 calculations.
>> > According to http://cclib.sourceforge.net/wiki/index.php/Parsed_Data and
>> >  http://cclib.sourceforge.net/wiki/index.php/Mpenergies
>> > this is available for GAMESS-US output files. The problem is that I
>> > cannot
>> > access this information. The logging after parsing the file
>> > does not show any mpenergies and consequently when I try to use it I get
>> > an
>> > error
>> > AttributeError: 'ccData' object has no attribute 'mpenergies'
>> > Is there something which I am missing here ?
>> > ===begin code snippet
>> > myfile = ccopen("mp2.out")
>> > data = myfile.parse()
>> > print data.mpenergies
>> > ===end code snippet
>> > Thanks a lot
>> > --
>> > Paulo E. Abreu
>> > Professor Auxiliar
>> > Departamento de Química
>> > Faculdade de Ciências e Tecnologia da Universidade de Coimbra
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > cclib-users mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-users
>> >
>> >
>
>
>
> --
> Paulo E. Abreu
> Professor Auxiliar
> Departamento de Química
> Faculdade de Ciências e Tecnologia da Universidade de Coimbra
>

[cclib-devel] Fwd: [cclib-users] GAMESS-US and mpenergies

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

---------- Forwarded message ----------
From: Paulo E. Abreu <pau...@ci...>
Date: 25 February 2010 15:47
Subject: Re: [cclib-users] GAMESS-US and mpenergies
To: Noel O'Boyle <bao...@gm...>


Hiya Noel,
Attached you will find a MP2 calculation on water. Parsing this file
with cclib I get
[GAMESS h2o-mp2.out INFO] Creating attribute atomcoords[]
[GAMESS h2o-mp2.out INFO] Creating attribute atomnos[]
[GAMESS h2o-mp2.out INFO] Creating attribute gbasis[]
[GAMESS h2o-mp2.out INFO] Creating attribute nbasis: 19
[GAMESS h2o-mp2.out INFO] Creating attribute charge: 0
[GAMESS h2o-mp2.out INFO] Creating attribute mult: 1
[GAMESS h2o-mp2.out INFO] Creating attribute homos[]
[GAMESS h2o-mp2.out INFO] Creating attribute natom: 3
[GAMESS h2o-mp2.out INFO] Creating attribute scftargets[]
[GAMESS h2o-mp2.out INFO] Creating attribute scfvalues[]
[GAMESS h2o-mp2.out INFO] Creating attribute scfenergies[]
[GAMESS h2o-mp2.out INFO] Creating attribute moenergies[]
[GAMESS h2o-mp2.out INFO] Creating attribute mosyms[]
[GAMESS h2o-mp2.out INFO] Creating attribute nmo: 19
[GAMESS h2o-mp2.out INFO] Creating attribute mocoeffs[]
[GAMESS h2o-mp2.out INFO] Creating attribute atombasis[]
[GAMESS h2o-mp2.out INFO] Creating attribute aonames[]
[GAMESS h2o-mp2.out INFO] Creating attribute coreelectrons[]
No mpenergies are defined.
And yes you can distribute this file.
Hope this helps.
Paulo

On Thu, Feb 25, 2010 at 3:34 PM, Noel O'Boyle <bao...@gm...> wrote:
>
> Hello Paulo,
>
> Sounds like a bug.
>
> Could you provide us with a public domain test file? That is, this
> should be a test file which you are happy for us to share with the
> world.
>
> - Noel
>
> On 25 February 2010 12:16, Paulo E. Abreu <pau...@ci...> wrote:
> > Hello,
> > I have been using cclib for my parsers and just noticed something odd about
> > GAMESS-US files with MP2 calculations.
> > According to http://cclib.sourceforge.net/wiki/index.php/Parsed_Data and
> >  http://cclib.sourceforge.net/wiki/index.php/Mpenergies
> > this is available for GAMESS-US output files. The problem is that I cannot
> > access this information. The logging after parsing the file
> > does not show any mpenergies and consequently when I try to use it I get an
> > error
> > AttributeError: 'ccData' object has no attribute 'mpenergies'
> > Is there something which I am missing here ?
> > ===begin code snippet
> > myfile = ccopen("mp2.out")
> > data = myfile.parse()
> > print data.mpenergies
> > ===end code snippet
> > Thanks a lot
> > --
> > Paulo E. Abreu
> > Professor Auxiliar
> > Departamento de Química
> > Faculdade de Ciências e Tecnologia da Universidade de Coimbra
> >
> > ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > cclib-users mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >
> >



--
Paulo E. Abreu
Professor Auxiliar
Departamento de Química
Faculdade de Ciências e Tecnologia da Universidade de Coimbra

[cclib-devel] New release

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

To get things moving, I've suddenly made a cclib-1.0a release directly
from trunk. It probably breaks horribly, but I'll tidy it up and
hopefully get a final out in the next week or two.

- Noel

Re: [cclib-devel] cclib test files

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

On 12 February 2010 15:00, Xaver Wurzenberger <xav...@we...> wrote:
> Hi,
>
>> Yes. All of our test files are public domain.
>
> You might want to make that clear by putting a copyright/license txt file
> there. Otherwise noone knows they can copy and use these files.

Good idea - I'll do that.

>> The test files we require are listed on
>> http://cclib.sourceforge.net/wiki/index.php/Tests under point 1 of
>> "Test Data".
>
> I can do this if you whish.
>
> Let me get this straight:
> You want the following b3lyp/sto-3g calculations of 1,4-divinylbenzene with
> C2h symmetry:
> 1) A geometry optimisation,
> 2) a single point calculation (restricted)
> 3) another sp (unrestricted),
> 4) a frequency calculation
> 5) a TD-DFT calculation

Yes - these are the files we want...but only if they are not already
present (check SVN on the turbomole branch).

> What does "and any variants of these which break the parser such as
> symmetry/nosymmetry" mean, exactly?

You can turn off symmetry perception in Gaussian, for example. If this
breaks the parser, then it'd be useful to include an example test file
for this case.

> I guess te points 1), 4) and 5) are restricted calc's?

Yes.

> I have never done TD-DFT but will give it a shot if that's not too
> complicated...



> Xaver
>
>
> Am Friday 12 February 2010 15:34:10 schrieben Sie:
>> On 12 February 2010 13:56, Xaver Wurzenberger <xav...@we...> wrote:
>> > 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.
>>
>> Yes. All of our test files are public domain. If you run "./wget.sh"
>> in the data directory, and then run "python regression.py", it will
>> run through all of the files.
>>
>> > 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?
>>
>> The maintainers of those repositories have not followed this up, but
>> we are happy to work with them.
>>
>> > 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?
>>
>> We have Gaussian 09 already actually. We even have some Turbomole (see
>> http://cclib.svn.sourceforge.net/viewvc/cclib/branches/turbomoleparser/data
>>/Turbomole/). I'm not sure why the Turbomole code never made it into trunk
>> though - it could be that we didn't have enough test files. The test files
>> we require are listed on
>> http://cclib.sourceforge.net/wiki/index.php/Tests under point 1 of
>> "Test Data".
>>
>> > Regards,
>> > Xaver
>> >
>> > -------------------------------------------------------------------------
>> >----- 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] turbomole branch

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

Afraid not...

On 13 February 2010 20:39, Adam Tenderholt <ate...@gm...> wrote:
> Anyone know the status of the turbomole branch off the top of their head? I'm trying to hack together a script for a friend to read turbomole files and just wondering where it stands.
>
> Thanks,
>
> 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
>

Re: [cclib-devel] new parsed data

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

I'll go with vibmasses then. It ought to just be a 1D array corresponding to individual atoms since each mode is determined from the mass-weighted Hessian.

Adam



On Feb 12, 2010, at 1:37 AM, Noel O'Boyle wrote:

> 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] turbomole branch

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

Anyone know the status of the turbomole branch off the top of their head? I'm trying to hack together a script for a friend to read turbomole files and just wondering where it stands.

Thanks,

Adam

Re: [cclib-devel] cclib test files

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

Hi,

> Yes. All of our test files are public domain.

You might want to make that clear by putting a copyright/license txt file 
there. Otherwise noone knows they can copy and use these files.

> The test files we require are listed on
> http://cclib.sourceforge.net/wiki/index.php/Tests under point 1 of
> "Test Data".

I can do this if you whish. 

Let me get this straight:
You want the following b3lyp/sto-3g calculations of 1,4-divinylbenzene with 
C2h symmetry:
1) A geometry optimisation,
2) a single point calculation (restricted)
3) another sp (unrestricted),
4) a frequency calculation
5) a TD-DFT calculation
What does "and any variants of these which break the parser such as 
symmetry/nosymmetry" mean, exactly?
I guess te points 1), 4) and 5) are restricted calc's?
I have never done TD-DFT but will give it a shot if that's not too 
complicated...

Xaver


Am Friday 12 February 2010 15:34:10 schrieben Sie:
> On 12 February 2010 13:56, Xaver Wurzenberger <xav...@we...> wrote:
> > 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.
>
> Yes. All of our test files are public domain. If you run "./wget.sh"
> in the data directory, and then run "python regression.py", it will
> run through all of the files.
>
> > 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?
>
> The maintainers of those repositories have not followed this up, but
> we are happy to work with them.
>
> > 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?
>
> We have Gaussian 09 already actually. We even have some Turbomole (see
> http://cclib.svn.sourceforge.net/viewvc/cclib/branches/turbomoleparser/data
>/Turbomole/). I'm not sure why the Turbomole code never made it into trunk
> though - it could be that we didn't have enough test files. The test files
> we require are listed on
> http://cclib.sourceforge.net/wiki/index.php/Tests under point 1 of
> "Test Data".
>
> > Regards,
> > Xaver
> >
> > -------------------------------------------------------------------------
> >----- 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] cclib test files

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

On 12 February 2010 13:56, Xaver Wurzenberger <xav...@we...> wrote:
> 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.

Yes. All of our test files are public domain. If you run "./wget.sh"
in the data directory, and then run "python regression.py", it will
run through all of the files.

> 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?

The maintainers of those repositories have not followed this up, but
we are happy to work with them.

> 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?

We have Gaussian 09 already actually. We even have some Turbomole (see
http://cclib.svn.sourceforge.net/viewvc/cclib/branches/turbomoleparser/data/Turbomole/).
I'm not sure why the Turbomole code never made it into trunk though -
it could be that we didn't have enough test files. The test files we
require are listed on
http://cclib.sourceforge.net/wiki/index.php/Tests under point 1 of
"Test Data".

> Regards,
> Xaver
>
> ------------------------------------------------------------------------------
> 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
>