cclib-devel — Developer's mailing list

[cclib-devel] Fwd: SourceForge Repo Clone Complete

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

New svn location for the upgraded project. I think the old one still
works, but the changes will be lost.

---------- Forwarded message ----------
From: SourceForge.net <nor...@in...>
Date: 20 December 2012 22:27
Subject: SourceForge Repo Clone Complete
To: no...@in...


Your cloned repository code in project cclib is now ready for use.

Old repository url: http://cclib.svn.sourceforge.net/svnroot/cclib

New repository checkout command: svn checkout --username=baoilleach
svn+ssh://baoilleach@svn.code.sf.net/p/cclib/code/trunk cclib-code

You and any other developers should do a fresh checkout using the new
repository location.

Re: [cclib-devel] GAMESS-US 2012

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

Forgot to attach the output. Here it is.

On Dec 01 2012, Karol M. Langner wrote:
> Hi again,
> 
> I've got the remaining logfiles ready, and am comparing them with the
> old ones before uploading. For the dvb_ir test, in the 2012 output,
> which I attach here, I get this new warning:
> 
>      *******************************************************
>      * THIS IS NOT A STATIONARY POINT ON THE MOLECULAR PES *
>      *     THE VIBRATIONAL ANALYSIS IS NOT VALID !!!       *
>      *******************************************************
> 
> I suppose this is because this is not the transition state anymore
> for the particular combination of method/basis set that gave a
> transition state in the older version logfile.
> 
> Do you think this warrants generating a new transition state, or should
> we just live with this warning?
> 
> Cheers,
> Karol
> 
> On Nov 30 2012, Karol M. Langner wrote:
> > On Nov 28 2012, Noel O'Boyle wrote:
> > > Sounds fine. We should never remove a test though, so I'd appreciate
> > > if you could move the old test to regressions.py with some sort of
> > > basic testing code (e.g. that it has the right number of etsecs).
> > 
> > What I did is call the appropriate unit test from a dynamically
> > generated function in the regression suite. This function is generated
> > as long as the logfile location is added to a list called 'old_tests'
> > inside the unit test class. It is clear from the code (I hope).
> > 
> > This makes archiving old logfiles as regressions easy and should scale
> > reasonably for doing such updates in the future. To withhold the unit
> > test for any reason for a particular regressed logfile (like in the
> > triplet TD case I brought up) just omit it from old_tests.
> > 
> > That being said, I will now update all GAMESS-US unit tests to the
> > newest 2012 version. Feel free to follow suit for other parsers, if you
> > like.
> > 
> > > Regarding parsing the version, I'm not too keen on parsing such
> > > metadata. That's going down a particular path we haven't gone down
> > > before. Maybe you can argue me around, but for sure we should not use
> > > version information during the parsing.
> > 
> > That's not what I had in mind. In any case, I don't wish or have the
> > free time to do this without a particular reason.
> > 
> > Cheers,
> > Karol
> > 
> > > On 28 November 2012 00:16, Karol M. Langner <kar...@gm...> wrote:
> > > > OK, I took another look at the GAMESS-US test files. It seems that
> > > > the files in basicGAMESS-US are from various different versions.
> > > > So, it seems more reasonable to just update the one output file
> > > > that gives more consistent results for dvb_td_triplet (that is, etsecs
> > > > sum up closer to 1), and possibly those that have changed substantially
> > > > in the new version of GAMESS-US and require parser work.
> > > >
> > > > That leaves the question, then, what to do with the old output files,
> > > > which are not from one set version. Rename with a version postfix and
> > > > transfer to regressions?
> > > >
> > > > Another option would be to just add additional logfiles for the outputs
> > > > that have changes, by adding _a or _b to the names like was done in the
> > > > case of several other parser.
> > > >
> > > > Let me know what you think,
> > > > Karol
> > > >
> > > > P.S. It also seems now a good idea to me to parse the version of a
> > > > program for information purposes, and it should be quite easy.
> > > >
> > > > On Nov 28 2012, Karol M. Langner wrote:
> > > >> Hi guys,
> > > >>
> > > >> I propose to update the GAMESS-US standard tests. The main motivation
> > > >> for this is that the dvb_td_triplet test in the 2012 version actually
> > > >> passes all the unit tests we have (the 2010 fails in one case). Also,
> > > >> there are some formatting changes in the output files, so some
> > > >> straightforward update to the parser is in order. I have all the output
> > > >> files ready.
> > > >>
> > > >> Let me know what you think. And, what do we do with the current output
> > > >> files in basicGAMESS-US? We should still make sure they are parsed
> > > >> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
> > > >> discussed some time ago, or rather to the regression suite?
> > > >>
> > > >> - Karol
> > 
> > -- 
> > written by Karol M. Langner
> > Fri Nov 30 00:00:09 CET 2012
> 
> -- 
> written by Karol M. Langner
> Sat Dec  1 13:28:58 CET 2012

-- 
written by Karol M. Langner
Sat Dec  1 13:34:30 CET 2012

Re: [cclib-devel] GAMESS-US 2012

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

Hi again,

I've got the remaining logfiles ready, and am comparing them with the
old ones before uploading. For the dvb_ir test, in the 2012 output,
which I attach here, I get this new warning:

     *******************************************************
     * THIS IS NOT A STATIONARY POINT ON THE MOLECULAR PES *
     *     THE VIBRATIONAL ANALYSIS IS NOT VALID !!!       *
     *******************************************************

I suppose this is because this is not the transition state anymore
for the particular combination of method/basis set that gave a
transition state in the older version logfile.

Do you think this warrants generating a new transition state, or should
we just live with this warning?

Cheers,
Karol

On Nov 30 2012, Karol M. Langner wrote:
> On Nov 28 2012, Noel O'Boyle wrote:
> > Sounds fine. We should never remove a test though, so I'd appreciate
> > if you could move the old test to regressions.py with some sort of
> > basic testing code (e.g. that it has the right number of etsecs).
> 
> What I did is call the appropriate unit test from a dynamically
> generated function in the regression suite. This function is generated
> as long as the logfile location is added to a list called 'old_tests'
> inside the unit test class. It is clear from the code (I hope).
> 
> This makes archiving old logfiles as regressions easy and should scale
> reasonably for doing such updates in the future. To withhold the unit
> test for any reason for a particular regressed logfile (like in the
> triplet TD case I brought up) just omit it from old_tests.
> 
> That being said, I will now update all GAMESS-US unit tests to the
> newest 2012 version. Feel free to follow suit for other parsers, if you
> like.
> 
> > Regarding parsing the version, I'm not too keen on parsing such
> > metadata. That's going down a particular path we haven't gone down
> > before. Maybe you can argue me around, but for sure we should not use
> > version information during the parsing.
> 
> That's not what I had in mind. In any case, I don't wish or have the
> free time to do this without a particular reason.
> 
> Cheers,
> Karol
> 
> > On 28 November 2012 00:16, Karol M. Langner <kar...@gm...> wrote:
> > > OK, I took another look at the GAMESS-US test files. It seems that
> > > the files in basicGAMESS-US are from various different versions.
> > > So, it seems more reasonable to just update the one output file
> > > that gives more consistent results for dvb_td_triplet (that is, etsecs
> > > sum up closer to 1), and possibly those that have changed substantially
> > > in the new version of GAMESS-US and require parser work.
> > >
> > > That leaves the question, then, what to do with the old output files,
> > > which are not from one set version. Rename with a version postfix and
> > > transfer to regressions?
> > >
> > > Another option would be to just add additional logfiles for the outputs
> > > that have changes, by adding _a or _b to the names like was done in the
> > > case of several other parser.
> > >
> > > Let me know what you think,
> > > Karol
> > >
> > > P.S. It also seems now a good idea to me to parse the version of a
> > > program for information purposes, and it should be quite easy.
> > >
> > > On Nov 28 2012, Karol M. Langner wrote:
> > >> Hi guys,
> > >>
> > >> I propose to update the GAMESS-US standard tests. The main motivation
> > >> for this is that the dvb_td_triplet test in the 2012 version actually
> > >> passes all the unit tests we have (the 2010 fails in one case). Also,
> > >> there are some formatting changes in the output files, so some
> > >> straightforward update to the parser is in order. I have all the output
> > >> files ready.
> > >>
> > >> Let me know what you think. And, what do we do with the current output
> > >> files in basicGAMESS-US? We should still make sure they are parsed
> > >> correctly. Shall I move them to, say, basicGAMESS-US-2005 as we
> > >> discussed some time ago, or rather to the regression suite?
> > >>
> > >> - Karol
> 
> -- 
> written by Karol M. Langner
> Fri Nov 30 00:00:09 CET 2012

-- 
written by Karol M. Langner
Sat Dec  1 13:28:58 CET 2012