cclib-devel — Developer's mailing list

Re: [cclib-devel] cclib bugfix

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

Hello Björn,

I'm ccing this to the list.

Thanks for the patch. Are you happy to place this logfile in the
public domain? If so, it means that we can add it to our test suite to
ensure that this problem does not recur.

- Noel

On 10 September 2012 14:21, Björn Dahlgren <bd...@kt...> wrote:
> Dear Noel O'Boyle,
>
> I guess this should go to the devel mailing list but I never figured out how
> to deal with mailing lists so I send this directly to you. I hope it is not
> a problem.
>
> There is a bug in cclib 1.0.1
>
> when parsing a gaussian log file with coincidently reoccuring CCSD(T)=
> statements ccenergies attribute is set twice. (affected gaussian log file
> attached to this email)
>
> Changing line 353 in cclib/parser/gaussianparser.py to:
>
>             if not hasattr(self, 'ccenergy'):
>                 self.ccenergy = self.float(line.split()[1])
>
> fixes the bug
>
> All the best
> /Björn Dahlgren, KTH Royal Institute of Technology

Re: [cclib-devel] New patch

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

Great, but can you supply public domain test files for #1, #2, and #3?

- Noel

On 28 July 2012 22:55, Edward Holland <hol...@ca...> wrote:
> Hi all,
>
> I've made a few changes to cclib for some scripts i've been writing. These changes are
> 1) gaussian irc parser
> 2) gamess thermochemistry parser
> 3) refactored part of the gamess vibrations parser
> 4) Added some units to the converter
> 5) fixed some small errors
>
> The main change that might cause contention is number 3. The code in question was designed to skip a number of text lines, mostly relating to symmetry. The issue with this code is that it excepts a particular number of lines of text between each block. However this is not always the case with GAMESS output files (see bug #3476063). I found a number of other cases similar to those in bug #3476063 while working on the gamess parser. I found the most general, and only consistently valid, method of skipping these lines was to search for the start of the frequency analysis. The refactored code reflects this and passes all the cases in the tests folder.
>
> I hope the rest of the code is self explanatory.
>
> Yours
>
> Ed Holland
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] New patch

[Edward H. <hol...@ca...>]

Sorry, I forgot to attach the patch!   
https://www.dropbox.com/s/mwo0fn5vx8sjdbs/cclib_patch



On 28 Jul 2012, at 22:55, Edward Holland wrote:

> Hi all,
> 
> I've made a few changes to cclib for some scripts i've been writing. These changes are
> 1) gaussian irc parser 
> 2) gamess thermochemistry parser 
> 3) refactored part of the gamess vibrations parser
> 4) Added some units to the converter 
> 5) fixed some small errors 
> 
> The main change that might cause contention is number 3. The code in question was designed to skip a number of text lines, mostly relating to symmetry. The issue with this code is that it excepts a particular number of lines of text between each block. However this is not always the case with GAMESS output files (see bug #3476063). I found a number of other cases similar to those in bug #3476063 while working on the gamess parser. I found the most general, and only consistently valid, method of skipping these lines was to search for the start of the frequency analysis. The refactored code reflects this and passes all the cases in the tests folder. 
> 
> I hope the rest of the code is self explanatory.
> 
> Yours
> 
> Ed Holland

[cclib-devel] New patch

[Edward H. <hol...@ca...>]

Hi all,

I've made a few changes to cclib for some scripts i've been writing. These changes are
1) gaussian irc parser 
2) gamess thermochemistry parser 
3) refactored part of the gamess vibrations parser
4) Added some units to the converter 
5) fixed some small errors 

The main change that might cause contention is number 3. The code in question was designed to skip a number of text lines, mostly relating to symmetry. The issue with this code is that it excepts a particular number of lines of text between each block. However this is not always the case with GAMESS output files (see bug #3476063). I found a number of other cases similar to those in bug #3476063 while working on the gamess parser. I found the most general, and only consistently valid, method of skipping these lines was to search for the start of the frequency analysis. The refactored code reflects this and passes all the cases in the tests folder. 

I hope the rest of the code is self explanatory.

Yours

Ed Holland

Re: [cclib-devel] g09 fragment guesses

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

Hi Karol,

I do occasionally have (make?) time for cclib, although it's usually when a
friend has a problem and asks me to fix it. Lately most of my non-work time
lately has been spent with my wife, moving into a new apartment and finding
furniture and such. But that's almost over, so perhaps I'll get around to
working on cclib more.

1) Shall I run the Fe2S2 example (or something similar) as our regression
>> file? Sam's files are hundreds of MB, and I think a prototypical example
>> would be best. ORCA also handles these systems well, and while I think it
>> parses such calculations fine, we probably should also have a regression
>> file for this parser too.
>>
>
> I would stick with something small that reproduces the issue.
>

I wanted something smaller, but I couldn't think of anything better.
Ideally it would be an organic bi- or di-radical. Semi-quinones would be
good, except I don't know how to logically split that into two fragments. I
suppose a peroxide is another option (say two HO• or alkyl-O• fragments),
but I think have closed-shell singlet ground states.


>
>>  2) Do we want to parse the fragment wavefunction info as well? It would
>> make our parser that much more robust, although it adds layers of
>> complexities. If so:
>>
>
> I think it safe to assume we want to, but won't do it right now unless
> somebody asks for it.
>

I'm also not inclined to do this unless it's specifically requested. There
are just too many other more interesting things to do.


> 2a) Create new attributes as necessary (fmoenergies, fmocoeffs, fhomos,
>> etc.)? We'd also want something analogous to fooverlaps and fonames (ADF),
>> but here it'd have to be a lists instead of the normal items.
>>
>
> I feel we should keep with single attributes, changing them their shapes
> to accommodate the fragments.
>

Makes sense to me.


> 2b) Or append to the current fmoenergies, fmocoeffs, etc? Then [0]/[1]
>> corresponds to molecule alpha/beta, [2]/[3] corresponds to fragment 1
>> alpha/beta, [4]/[5] corresponds to fragment 2 alpha/beta, and so on. (I
>> don't see any reasons these calculations would have restricted fragments).
>>
>
> The other option would be use indexes [0..N-1] for alphas and the rest for
> betas. I don't have a preference.
>

My only concern with the [0..N-1]/[N-2N-1] indices are that we then have to
keep track of where the alpha ends, either with a variable or checking the
size of nbasis, and we can't simply append when a new wavefunction block is
reached. The [n]/[n+1] can be access with a loop that increments by 2 and
extending the mocoeffs is as simple as an append.

Adam

[cclib-devel] g09 fragment guesses

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

Hi all,

One of my friends from a former lab found a bug in the Gaussian parser in a
calculation involving anti-ferromagnetic coupling calculations set up via
the guess keyword (see example at
http://www.gaussian.com/g_tech/g_ur/k_guess.htm). The output is similar to
the counterpoise/BSSE calculations, although I think it also prints
aooverlaps and mocoeffs for each fragment as well as the entire molecule
whereas the counterpoise calculations do not. I've committed a few fixes to
trunk, but I have a few follow-up questions:

1) Shall I run the Fe2S2 example (or something similar) as our regression
file? Sam's files are hundreds of MB, and I think a prototypical example
would be best. ORCA also handles these systems well, and while I think it
parses such calculations fine, we probably should also have a regression
file for this parser too.

2) Do we want to parse the fragment wavefunction info as well? It would
make our parser that much more robust, although it adds layers of
complexities. If so:
2a) Create new attributes as necessary (fmoenergies, fmocoeffs, fhomos,
etc.)? We'd also want something analogous to fooverlaps and fonames (ADF),
but here it'd have to be a lists instead of the normal items.
2b) Or append to the current fmoenergies, fmocoeffs, etc? Then [0]/[1]
corresponds to molecule alpha/beta, [2]/[3] corresponds to fragment 1
alpha/beta, [4]/[5] corresponds to fragment 2 alpha/beta, and so on. (I
don't see any reasons these calculations would have restricted fragments).

Cheers,

Adam

Re: [cclib-devel] cclib-devel Digest, Vol 61, Issue 9

[Edward H. <hol...@ca...>]

Hi All,

Adam:

> I agree that this change would break scripts if people were only
> parsing the first optimization of a scan calculation, but shouldn't
> most users (at least of released versions) only be using cclib for
> optimizations at this point, and not scan calculations? Otherwise,
> they aren't getting the majority of the structures/energies from their
> results. Isn't this why these patches were created? Or am I making a
> bad assumption about cclib use?


If you are happy to make these assumptions then i can knock up a patch when
I find some free time, it was just not a decision i felt comfortable making alone.

 
> 
> I think that scfenergies (atomcoords, etc). should hold the energies
> of every completed SCF calculation, whether or not its an optimization
> or scan calculation. In the case of a scan (rigid or relaxed)
> calculation, I think special attributes for the final optimized step
> should be created.

So we should leave it as is currently in the SVN version?

> 
> P.S. Ed, did you attach the examples? Ethanol and ethanol-z were in a
> previous email…

I attached them again as i thought Karol was missing them.

Martin:
	The case for IRC calculations is much simpler than for relaxed scan cases, as gaussian 
outputs the coordinates in XYZ rather than z-mat (which fits in with cclib). I have code to extract 
this data but as of yet haven't got around to porting it into cclib. I can put this on my todo list is its 
important to you. 
	For the relaxed scan case i'm not sure if the full optimisation data is really needed. Personally
i think that providing an array of optimised coordinates should be enough. If you have strong feelings
about this please let us know. Otherwise parsing relaxed scans is on my todo list.

Yours

Ed Holland

PS Martin if you want a copy of my generalised IRC extracting script i can email that over asap.


On 24 Apr 2012, at 13:05, ccl...@li... wrote:

> Send cclib-devel mailing list submissions to
> 	ccl...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/cclib-devel
> or, via email, send a message with subject or body 'help' to
> 	ccl...@li...
> 
> You can reach the person managing the list at
> 	ccl...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cclib-devel digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: branch maintenance (Adam Tenderholt)
>   2. Re: Patch for rigid scan and thermochemsirty data
>      (Adam Tenderholt)
>   3. Re: branch maintenance (Noel O'Boyle)
>   4. Relaxed scan / IRC (Gaussian) (Martin Krupicka)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 23 Apr 2012 08:18:30 -0700
> From: Adam Tenderholt <ate...@gm...>
> Subject: Re: [cclib-devel] branch maintenance
> To: "Karol M. Langner" <kar...@gm...>
> Cc: cclib-dev List <ccl...@li...>
> Message-ID:
> 	<CAGC-pA_JFABRB61b2zPeo3kgKWXyjteVA=W59...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I'm in favor of deleting the Orca branch, although maybe Noel wants to
> weigh in. (cc'ing cclib-dev.)
> 
> On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner
> <kar...@gm...> wrote:
>> So, do we delete the orcaparser, or somehow mark it is inactive? What is our policy for branches?
>> 
>> - Karol
>> 
>> On Apr 19 2012, Karol M. Langner wrote:
>>> I also think we should merge only after a parser is reasonably mature,
>>> for instance when most of the standard unit tests run and there are only a few errors.
>>> 
>>> On Apr 19 2012, Adam Tenderholt wrote:
>>>> Ah, good catch. I didn't even think of checking trunk to see if the
>>>> Orca parser had been merged after that feature request a few days ago.
>>>> I just assumed they had downloaded cclib and didn't have Orca support.
>>>> I wonder why they submitted that feature request.
>>>> 
>>>> For the other branches, do we want to merge them into trunk if they
>>>> aren't ready? I recall that NWChem was nowhere near ready, and when I
>>>> went to work on it last year, I wasn't able to get it to print some
>>>> attribute cleanly (running in parallel causes duplication of output
>>>> sometimes). It seems like we should wait until they are more fully
>>>> supported.
>>>> 
>>>> Adam
>>>> 
>>>> On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner
>>>> <kar...@gm...> wrote:
>>>>> From what I can see, the ORCA parser was alraedy merged into trunk.
>>>>> 
>>>>> If there is nothing new there (I've looked only at the parser source), then I think
>>>>> the branch should be deleted, or marked somehow as inactive.
>>>>> 
>>>>> As far as I can see, the other parse branches (Molcas, NWChem, Turbomole) have
>>>>> not been merged into trunk yet.
>>>>> 
>>>>> Karol
>>>>> 
>>>>> On Apr 19 2012, Adam Tenderholt wrote:
>>>>>> With the recent talk about updating the license of cclib, it got me
>>>>>> thinking that we might need to perform some maintenance on the
>>>>>> branches since several are quite old (e.g. Orca). Is it best to make
>>>>>> sure the new parsers in those branches are well-supported, and then
>>>>>> merge those changes into trunk? Or should we merge trunk into those
>>>>>> branches?
>>>>>> 
>>>>>> Adam
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>> Boundary is the first to Know...and Tell You.
>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>> _______________________________________________
>>>>>> cclib-devel mailing list
>>>>>> ccl...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>>>> 
>>>>> --
>>>>> written by Karol Langner
>>>>> Thu Apr 19 18:39:04 CEST 2012
>>> 
>>> --
>>> written by Karol Langner
>>> Thu Apr 19 19:04:09 CEST 2012
>> 
>> --
>> written by Karol Langner
>> Mon Apr 23 08:47:36 CEST 2012
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 23 Apr 2012 08:29:46 -0700
> From: Adam Tenderholt <ate...@gm...>
> Subject: Re: [cclib-devel] Patch for rigid scan and thermochemsirty
> 	data
> To: cclib-dev List <ccl...@li...>
> Message-ID:
> 	<CAG...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
>> Adam:
>> ? ? ? ?Yes, the relaxed scan case in not handled by this code. This is due to issues implementing the extraction of geometries. I think the best way to do this would be to look for "optimisation complete" messages and then add the last parsed geometry to a list of scan geometries. However currently the gaussian parser stops searching after a "optimisation complete" message; changing this would affect the exposed list of geometries and potentially break scripts based on cclib. If you can think of a better way of implementing this I would be happy to provide a patch.
> 
> I agree that this change would break scripts if people were only
> parsing the first optimization of a scan calculation, but shouldn't
> most users (at least of released versions) only be using cclib for
> optimizations at this point, and not scan calculations? Otherwise,
> they aren't getting the majority of the structures/energies from their
> results. Isn't this why these patches were created? Or am I making a
> bad assumption about cclib use?
> 
>> ? ? ? ?2)
>> ? ? ? ? ? ? ? ?This seems sensible
> 
> Regarding separating the scan and thermochemistry data: I agree this
> is a good idea going forward, focusing on a independent results
> separately. As I already made the changes to the Gaussian parser, I'm
> inclined to leave the two major changes as a single commit instead of
> going back to a previous revision to separate the two into new
> separate commits.
> 
>> ? ? ? ?3)
>> ? ? ? ? ? ? ? ?I agree this seems sensible for the rigid scan case. However it brings us back to the issue of the relaxed scan again; these are a series of optimisations so reusing scfenergies could cause confusion as to the exact meaning of the values and it would also mean that data on the individual optimisation steps is lost. It would seem a choice between simplicity of the interface and completeness of the data collected needs to be made. This is perhaps something we should discuss.
> 
> I think that scfenergies (atomcoords, etc). should hold the energies
> of every completed SCF calculation, whether or not its an optimization
> or scan calculation. In the case of a scan (rigid or relaxed)
> calculation, I think special attributes for the final optimized step
> should be created.
> 
> Adam
> 
> P.S. Ed, did you attach the examples? Ethanol and ethanol-z were in a
> previous email...
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 23 Apr 2012 16:40:50 +0100
> From: "Noel O'Boyle" <bao...@gm...>
> Subject: Re: [cclib-devel] branch maintenance
> To: Adam Tenderholt <ate...@gm...>
> Cc: cclib-dev List <ccl...@li...>
> Message-ID:
> 	<CAO...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> The orca branch should have been deleted after the merge...back in 2007!
> :-) I'll do this.
> 
> For the others - well, once they're ready, they should go on the trunk too.
> If you've put some work into a parser, it's worth finishing it up, and
> getting it onto trunk. If they stay out on the branch, they will gradually
> bitrot....
> 
> - Noel
> 
> On 23 April 2012 16:18, Adam Tenderholt <ate...@gm...> wrote:
> 
>> I'm in favor of deleting the Orca branch, although maybe Noel wants to
>> weigh in. (cc'ing cclib-dev.)
>> 
>> On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner
>> <kar...@gm...> wrote:
>>> So, do we delete the orcaparser, or somehow mark it is inactive? What is
>> our policy for branches?
>>> 
>>> - Karol
>>> 
>>> On Apr 19 2012, Karol M. Langner wrote:
>>>> I also think we should merge only after a parser is reasonably mature,
>>>> for instance when most of the standard unit tests run and there are
>> only a few errors.
>>>> 
>>>> On Apr 19 2012, Adam Tenderholt wrote:
>>>>> Ah, good catch. I didn't even think of checking trunk to see if the
>>>>> Orca parser had been merged after that feature request a few days ago.
>>>>> I just assumed they had downloaded cclib and didn't have Orca support.
>>>>> I wonder why they submitted that feature request.
>>>>> 
>>>>> For the other branches, do we want to merge them into trunk if they
>>>>> aren't ready? I recall that NWChem was nowhere near ready, and when I
>>>>> went to work on it last year, I wasn't able to get it to print some
>>>>> attribute cleanly (running in parallel causes duplication of output
>>>>> sometimes). It seems like we should wait until they are more fully
>>>>> supported.
>>>>> 
>>>>> Adam
>>>>> 
>>>>> On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner
>>>>> <kar...@gm...> wrote:
>>>>>> From what I can see, the ORCA parser was alraedy merged into trunk.
>>>>>> 
>>>>>> If there is nothing new there (I've looked only at the parser
>> source), then I think
>>>>>> the branch should be deleted, or marked somehow as inactive.
>>>>>> 
>>>>>> As far as I can see, the other parse branches (Molcas, NWChem,
>> Turbomole) have
>>>>>> not been merged into trunk yet.
>>>>>> 
>>>>>> Karol
>>>>>> 
>>>>>> On Apr 19 2012, Adam Tenderholt wrote:
>>>>>>> With the recent talk about updating the license of cclib, it got me
>>>>>>> thinking that we might need to perform some maintenance on the
>>>>>>> branches since several are quite old (e.g. Orca). Is it best to
>> make
>>>>>>> sure the new parsers in those branches are well-supported, and then
>>>>>>> merge those changes into trunk? Or should we merge trunk into those
>>>>>>> branches?
>>>>>>> 
>>>>>>> Adam
>>>>>>> 
>>>>>>> 
>> ------------------------------------------------------------------------------
>>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>>> Boundary is the first to Know...and Tell You.
>>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>>> _______________________________________________
>>>>>>> cclib-devel mailing list
>>>>>>> ccl...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>>>>> 
>>>>>> --
>>>>>> written by Karol Langner
>>>>>> Thu Apr 19 18:39:04 CEST 2012
>>>> 
>>>> --
>>>> written by Karol Langner
>>>> Thu Apr 19 19:04:09 CEST 2012
>>> 
>>> --
>>> written by Karol Langner
>>> Mon Apr 23 08:47:36 CEST 2012
>> 
>> 
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 24 Apr 2012 10:42:36 +0200
> From: Martin Krupicka <ma...@bh...>
> Subject: [cclib-devel] Relaxed scan / IRC (Gaussian)
> To: ccl...@li...
> Message-ID: <4F9...@bh...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi all,
> I read the discussion regarding the relaxed scans and I would like to
> ask, if there is some agreement how this stuff should be implemented. I
> would like to use cclib for digging out data from scans and IRCs. At the
> moment I use home-made scripts, but they would need some more
> modifications, so it seems better for me to adapt cclib for that purpose.
> 
> The main question if I got it correctly is, that Relaxed scan (or IRC)
> are series of optimizations, and it is not yet clear, how they should be
> stored and presented to outside. With the functionality already in cclib
> I see two options.
> 
> 1. Generate array of results, so for each sub-optimization, the parser
> will produce independent data class.
> 
> 2. Add array, which will hold the progress of scan/IRC. The main (and
> only?) data stored in this array will  be the indices for the converged
> points. So i.e. the .scfenergies array contains the "raw" energies,
> where the e.g. .points array will contain e.g. [23,29,52], with three
> points along the scan, where .scfenergies[23] is the energy of the first
> converged result. With array of indices it is then quite easy to do all
> following manipulations with results, so I would personally prefer this
> option.
> 
> I am not sure, whether this was not already adressed and solved, so
> sorry for eventual off-topic.
> 
> Martin
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> ------------------------------
> 
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
> 
> 
> End of cclib-devel Digest, Vol 61, Issue 9
> ******************************************

[cclib-devel] Relaxed scan / IRC (Gaussian)

[Martin K. <ma...@bh...>]

Hi all,
 I read the discussion regarding the relaxed scans and I would like to
ask, if there is some agreement how this stuff should be implemented. I
would like to use cclib for digging out data from scans and IRCs. At the
moment I use home-made scripts, but they would need some more
modifications, so it seems better for me to adapt cclib for that purpose.

The main question if I got it correctly is, that Relaxed scan (or IRC)
are series of optimizations, and it is not yet clear, how they should be
stored and presented to outside. With the functionality already in cclib
I see two options.

1. Generate array of results, so for each sub-optimization, the parser
will produce independent data class.

2. Add array, which will hold the progress of scan/IRC. The main (and
only?) data stored in this array will  be the indices for the converged
points. So i.e. the .scfenergies array contains the "raw" energies,
where the e.g. .points array will contain e.g. [23,29,52], with three
points along the scan, where .scfenergies[23] is the energy of the first
converged result. With array of indices it is then quite easy to do all
following manipulations with results, so I would personally prefer this
option.

I am not sure, whether this was not already adressed and solved, so
sorry for eventual off-topic.

Martin

Re: [cclib-devel] branch maintenance

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

The orca branch should have been deleted after the merge...back in 2007!
:-) I'll do this.

For the others - well, once they're ready, they should go on the trunk too.
If you've put some work into a parser, it's worth finishing it up, and
getting it onto trunk. If they stay out on the branch, they will gradually
bitrot....

- Noel

On 23 April 2012 16:18, Adam Tenderholt <ate...@gm...> wrote:

> I'm in favor of deleting the Orca branch, although maybe Noel wants to
> weigh in. (cc'ing cclib-dev.)
>
> On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner
> <kar...@gm...> wrote:
> > So, do we delete the orcaparser, or somehow mark it is inactive? What is
> our policy for branches?
> >
> > - Karol
> >
> > On Apr 19 2012, Karol M. Langner wrote:
> >> I also think we should merge only after a parser is reasonably mature,
> >> for instance when most of the standard unit tests run and there are
> only a few errors.
> >>
> >> On Apr 19 2012, Adam Tenderholt wrote:
> >> > Ah, good catch. I didn't even think of checking trunk to see if the
> >> > Orca parser had been merged after that feature request a few days ago.
> >> > I just assumed they had downloaded cclib and didn't have Orca support.
> >> > I wonder why they submitted that feature request.
> >> >
> >> > For the other branches, do we want to merge them into trunk if they
> >> > aren't ready? I recall that NWChem was nowhere near ready, and when I
> >> > went to work on it last year, I wasn't able to get it to print some
> >> > attribute cleanly (running in parallel causes duplication of output
> >> > sometimes). It seems like we should wait until they are more fully
> >> > supported.
> >> >
> >> > Adam
> >> >
> >> > On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner
> >> > <kar...@gm...> wrote:
> >> > > From what I can see, the ORCA parser was alraedy merged into trunk.
> >> > >
> >> > > If there is nothing new there (I've looked only at the parser
> source), then I think
> >> > > the branch should be deleted, or marked somehow as inactive.
> >> > >
> >> > > As far as I can see, the other parse branches (Molcas, NWChem,
> Turbomole) have
> >> > > not been merged into trunk yet.
> >> > >
> >> > > Karol
> >> > >
> >> > > On Apr 19 2012, Adam Tenderholt wrote:
> >> > >> With the recent talk about updating the license of cclib, it got me
> >> > >> thinking that we might need to perform some maintenance on the
> >> > >> branches since several are quite old (e.g. Orca). Is it best to
> make
> >> > >> sure the new parsers in those branches are well-supported, and then
> >> > >> merge those changes into trunk? Or should we merge trunk into those
> >> > >> branches?
> >> > >>
> >> > >> Adam
> >> > >>
> >> > >>
> ------------------------------------------------------------------------------
> >> > >> For Developers, A Lot Can Happen In A Second.
> >> > >> Boundary is the first to Know...and Tell You.
> >> > >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> >> > >> http://p.sf.net/sfu/Boundary-d2dvs2
> >> > >> _______________________________________________
> >> > >> cclib-devel mailing list
> >> > >> ccl...@li...
> >> > >> https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >> > >
> >> > > --
> >> > > written by Karol Langner
> >> > > Thu Apr 19 18:39:04 CEST 2012
> >>
> >> --
> >> written by Karol Langner
> >> Thu Apr 19 19:04:09 CEST 2012
> >
> > --
> > written by Karol Langner
> > Mon Apr 23 08:47:36 CEST 2012
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Patch for rigid scan and thermochemsirty data

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

> Adam:
>        Yes, the relaxed scan case in not handled by this code. This is due to issues implementing the extraction of geometries. I think the best way to do this would be to look for "optimisation complete" messages and then add the last parsed geometry to a list of scan geometries. However currently the gaussian parser stops searching after a "optimisation complete" message; changing this would affect the exposed list of geometries and potentially break scripts based on cclib. If you can think of a better way of implementing this I would be happy to provide a patch.

I agree that this change would break scripts if people were only
parsing the first optimization of a scan calculation, but shouldn't
most users (at least of released versions) only be using cclib for
optimizations at this point, and not scan calculations? Otherwise,
they aren't getting the majority of the structures/energies from their
results. Isn't this why these patches were created? Or am I making a
bad assumption about cclib use?

>        2)
>                This seems sensible

Regarding separating the scan and thermochemistry data: I agree this
is a good idea going forward, focusing on a independent results
separately. As I already made the changes to the Gaussian parser, I'm
inclined to leave the two major changes as a single commit instead of
going back to a previous revision to separate the two into new
separate commits.

>        3)
>                I agree this seems sensible for the rigid scan case. However it brings us back to the issue of the relaxed scan again; these are a series of optimisations so reusing scfenergies could cause confusion as to the exact meaning of the values and it would also mean that data on the individual optimisation steps is lost. It would seem a choice between simplicity of the interface and completeness of the data collected needs to be made. This is perhaps something we should discuss.

I think that scfenergies (atomcoords, etc). should hold the energies
of every completed SCF calculation, whether or not its an optimization
or scan calculation. In the case of a scan (rigid or relaxed)
calculation, I think special attributes for the final optimized step
should be created.

Adam

P.S. Ed, did you attach the examples? Ethanol and ethanol-z were in a
previous email...

Re: [cclib-devel] branch maintenance

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

I'm in favor of deleting the Orca branch, although maybe Noel wants to
weigh in. (cc'ing cclib-dev.)

On Sun, Apr 22, 2012 at 11:48 PM, Karol M. Langner
<kar...@gm...> wrote:
> So, do we delete the orcaparser, or somehow mark it is inactive? What is our policy for branches?
>
> - Karol
>
> On Apr 19 2012, Karol M. Langner wrote:
>> I also think we should merge only after a parser is reasonably mature,
>> for instance when most of the standard unit tests run and there are only a few errors.
>>
>> On Apr 19 2012, Adam Tenderholt wrote:
>> > Ah, good catch. I didn't even think of checking trunk to see if the
>> > Orca parser had been merged after that feature request a few days ago.
>> > I just assumed they had downloaded cclib and didn't have Orca support.
>> > I wonder why they submitted that feature request.
>> >
>> > For the other branches, do we want to merge them into trunk if they
>> > aren't ready? I recall that NWChem was nowhere near ready, and when I
>> > went to work on it last year, I wasn't able to get it to print some
>> > attribute cleanly (running in parallel causes duplication of output
>> > sometimes). It seems like we should wait until they are more fully
>> > supported.
>> >
>> > Adam
>> >
>> > On Thu, Apr 19, 2012 at 9:43 AM, Karol M. Langner
>> > <kar...@gm...> wrote:
>> > > From what I can see, the ORCA parser was alraedy merged into trunk.
>> > >
>> > > If there is nothing new there (I've looked only at the parser source), then I think
>> > > the branch should be deleted, or marked somehow as inactive.
>> > >
>> > > As far as I can see, the other parse branches (Molcas, NWChem, Turbomole) have
>> > > not been merged into trunk yet.
>> > >
>> > > Karol
>> > >
>> > > On Apr 19 2012, Adam Tenderholt wrote:
>> > >> With the recent talk about updating the license of cclib, it got me
>> > >> thinking that we might need to perform some maintenance on the
>> > >> branches since several are quite old (e.g. Orca). Is it best to make
>> > >> sure the new parsers in those branches are well-supported, and then
>> > >> merge those changes into trunk? Or should we merge trunk into those
>> > >> branches?
>> > >>
>> > >> Adam
>> > >>
>> > >> ------------------------------------------------------------------------------
>> > >> For Developers, A Lot Can Happen In A Second.
>> > >> Boundary is the first to Know...and Tell You.
>> > >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> > >> http://p.sf.net/sfu/Boundary-d2dvs2
>> > >> _______________________________________________
>> > >> cclib-devel mailing list
>> > >> ccl...@li...
>> > >> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> > >
>> > > --
>> > > written by Karol Langner
>> > > Thu Apr 19 18:39:04 CEST 2012
>>
>> --
>> written by Karol Langner
>> Thu Apr 19 19:04:09 CEST 2012
>
> --
> written by Karol Langner
> Mon Apr 23 08:47:36 CEST 2012

Re: [cclib-devel] Patch for rigid scan and thermochemsirty data

[Edward H. <hol...@ca...>]

Hi Both,

Thanks for reviewing my changes, let me address your comments.

Adam:
	Yes, the relaxed scan case in not handled by this code. This is due to issues implementing the extraction of geometries. I think the best way to do this would be to look for "optimisation complete" messages and then add the last parsed geometry to a list of scan geometries. However currently the gaussian parser stops searching after a "optimisation complete" message; changing this would affect the exposed list of geometries and potentially break scripts based on cclib. If you can think of a better way of implementing this I would be happy to provide a patch.

Karol:
	1)
		I agree with variable seems an odd choice to be publicly accessible. However it deals with cases where gaussian ends optimisation because of "Optimization completed on the basis of negligible forces". In this case the geovalues is not lower than geotargets at the optimised step. Perhaps this case could instead be dealt with by changing geotargets when this message is found. How to select appropriate values to ensure only the correct geometries appear optimised I am unsure. 
	2)
		This seems sensible 
	3)
		I agree this seems sensible for the rigid scan case. However it brings us back to the issue of the relaxed scan again; these are a series of optimisations so reusing scfenergies could cause confusion as to the exact meaning of the values and it would also mean that data on the individual optimisation steps is lost. It would seem a choice between simplicity of the interface and completeness of the data collected needs to be made. This is perhaps something we should discuss.

I have also attached the test cases for both relaxed and rigid scans.

I hope this explains my thoughts on the topic, if anything is unclear please let me know.

Yours

Ed Holland

    
On 23 Apr 2012, at 09:18, Karol M. Langner wrote:

> Hi guys,
> 
> Yes, it would be good to standardize this.
> 
> Several initial thoughts:
> 1) attribute optdone is not useful and in fact not used
> 2) we should separate the changes related to thermochem. and scans
> 3) do we have test output files to work on scans? do we really need
> attributes such as scanenergies, when, for example for geometry
> optimization, we pack all the values into 'scfenergies', etc.? In
> principle we could do the same in this case
> 
> - Karol
> 
> On Apr 22 2012, Adam Tenderholt wrote:
>> Hi Ed,
>> 
>> Thank you for the patch. I made a few changes, the most important
>> being renaming temp to temperature. I noticed for the relaxed energy
>> scan (ethanol.out), the attributes related to the scan are not added.
>> Is this something that should be handled?
>> 
>> Noel, Karol: shall we standardize the thermochemistry info (i.e.
>> temperature, freeenergy, enthalpy, entropy), and add it to the other
>> parsers? This info should already be in the IR and Raman logfiles.
>> 
>> Adam
>> 
>> 
>> On Tue, Apr 17, 2012 at 6:41 AM, Edward Holland <hol...@ca...> wrote:
>>> Hi All,
>>> 
>>> I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this.
>>> I have attached the patch file
>>> 
>>> Hope you find the changes acceptable
>>> 
>>> Yours
>>> 
>>> Ed Holland
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Better than sec? Nothing is better than sec when it comes to
>>> monitoring Big Data applications. Try Boundary one-second
>>> resolution app monitoring today. Free.
>>> http://p.sf.net/sfu/Boundary-dev2dev
>>> _______________________________________________
>>> cclib-devel mailing list
>>> ccl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>> 
>> 
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
> 
> -- 
> written by Karol M. Langner
> Mon Apr 23 10:11:41 CEST 2012

Re: [cclib-devel] Patch for rigid scan and thermochemsirty data

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

Hi guys,

Yes, it would be good to standardize this.

Several initial thoughts:
1) attribute optdone is not useful and in fact not used
2) we should separate the changes related to thermochem. and scans
3) do we have test output files to work on scans? do we really need
attributes such as scanenergies, when, for example for geometry
optimization, we pack all the values into 'scfenergies', etc.? In
principle we could do the same in this case

- Karol

On Apr 22 2012, Adam Tenderholt wrote:
> Hi Ed,
> 
> Thank you for the patch. I made a few changes, the most important
> being renaming temp to temperature. I noticed for the relaxed energy
> scan (ethanol.out), the attributes related to the scan are not added.
> Is this something that should be handled?
> 
> Noel, Karol: shall we standardize the thermochemistry info (i.e.
> temperature, freeenergy, enthalpy, entropy), and add it to the other
> parsers? This info should already be in the IR and Raman logfiles.
> 
> Adam
> 
> 
> On Tue, Apr 17, 2012 at 6:41 AM, Edward Holland <hol...@ca...> wrote:
> > Hi All,
> >
> > I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this.
> > I have attached the patch file
> >
> > Hope you find the changes acceptable
> >
> > Yours
> >
> > Ed Holland
> >
> >
> > ------------------------------------------------------------------------------
> > Better than sec? Nothing is better than sec when it comes to
> > monitoring Big Data applications. Try Boundary one-second
> > resolution app monitoring today. Free.
> > http://p.sf.net/sfu/Boundary-dev2dev
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

-- 
written by Karol M. Langner
Mon Apr 23 10:11:41 CEST 2012

Re: [cclib-devel] Patch for rigid scan and thermochemsirty data

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

Hi Ed,

Thank you for the patch. I made a few changes, the most important
being renaming temp to temperature. I noticed for the relaxed energy
scan (ethanol.out), the attributes related to the scan are not added.
Is this something that should be handled?

Noel, Karol: shall we standardize the thermochemistry info (i.e.
temperature, freeenergy, enthalpy, entropy), and add it to the other
parsers? This info should already be in the IR and Raman logfiles.

Adam


On Tue, Apr 17, 2012 at 6:41 AM, Edward Holland <hol...@ca...> wrote:
> Hi All,
>
> I just added some stuff to the gaussian parser to collect themrochemistry data. I was realised i never got around the submitting the final patch for gaussian rigid scans so i have also included this.
> I have attached the patch file
>
> Hope you find the changes acceptable
>
> Yours
>
> Ed Holland
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

Any reason the copyright dates weren't updated to include 2012?


On Thu, Apr 19, 2012 at 9:10 AM, Noel O'Boyle <bao...@gm...> wrote:
> Hmmm...I guess you're right - we should just leave it. It's clear from the
> source that a later version can be used instead.
>
> - Noel
>
>
> On 19 April 2012 17:07, Karol M. Langner <kar...@gm...> wrote:
>>
>> With? Version 3 of the LGPL?
>>
>> On Apr 19 2012, Noel O'Boyle wrote:
>> > Looks good. We should probably replace LICENSE.txt too.
>> >
>> > On 19 April 2012 15:17, Karol M. Langner <kar...@gm...>
>> > wrote:
>> >
>> > > Done. Please review.
>> > >
>> > > On Apr 19 2012, Noel O'Boyle wrote:
>> > > > Both, I guess.
>> > > >
>> > > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...>
>> > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > Let's get this done. I'll do it, but I'm not sure where I should
>> > > > > change
>> > > > > it. Should I update the license in every source file, or just in
>> > > > > the
>> > > > > LICENSE file?
>> > > > >
>> > > > > - Karol
>> > > > >
>> > > > > On Apr 13 2011, Karol M. Langner wrote:
>> > > > > > Aye.
>> > > > > >
>> > > > > > On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
>> > > > > > > Aye.
>> > > > > > >
>> > > > > > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <
>> > > bao...@gm...>
>> > > > > wrote:
>> > > > > > > > All in favour say "aye". Aye.
>> > > > > > > >
>> > > > > > > > On 12 April 2011 10:03, Karol M. Langner <
>> > > kar...@gm...>
>> > > > > wrote:
>> > > > > > > >> Noel,
>> > > > > > > >>
>> > > > > > > >>  While working on packaging cclib I got this comment from
>> > > Michael
>> > > > > Bank. Is there
>> > > > > > > >>  any reason not to change the license to the current one
>> > > > > > > >> "or
>> > > later"?
>> > > > > > > >>
>> > > > > > > >> - Karol
>> > > > > > > >>
>> > > > > > > >> ----- Forwarded message from Michael Banck
>> > > > > > > >> <mb...@de...>
>> > > > > -----
>> > > > > > > >>
>> > > > > > > >> ...
>> > > > > > > >>
>> > > > > > > >> ** As an aside, you might want to contact the upstream
>> > > > > > > >> authors
>> > > to
>> > > > > > > >>   relicense to "LGPL v2.1 or later", or else they might run
>> > > > > > > >> into
>> > > > > > > >>   license incompatibilites further down the road (at least
>> > > > > > > >> Noel
>> > > > > should
>> > > > > > > >>   be aware of that, as OpenBabel keeps suffering from that)
>> > > > > > > >>
>> > > > > > > >> ...
>> > > > > > > >>
>> > > > > > > >> ----- End forwarded message -----
>> > > > > > > >>
>> > > > > > > >> --
>> > > > > > > >> written by Karol M. Langner
>> > > > > > > >> Tue Apr 12 11:00:31 CEST 2011
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > >
>> > >
>> > > ------------------------------------------------------------------------------
>> > > > > > > > Forrester Wave Report - Recovery time is now measured in
>> > > > > > > > hours
>> > > and
>> > > > > minutes
>> > > > > > > > not days. Key insights are discussed in the 2010 Forrester
>> > > > > > > > Wave
>> > > > > Report as
>> > > > > > > > part of an in-depth evaluation of disaster recovery service
>> > > > > providers.
>> > > > > > > > Forrester found the best-in-class provider in terms of
>> > > > > > > > services
>> > > and
>> > > > > vision.
>> > > > > > > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
>> > > > > > > > _______________________________________________
>> > > > > > > > cclib-devel mailing list
>> > > > > > > > ccl...@li...
>> > > > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> > > > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > written by Karol Langner
>> > > > > > Wed Apr 13 11:52:52 CEST 2011
>> > > > >
>> > > > > --
>> > > > > written by Karol Langner
>> > > > > Thu Apr 19 13:24:30 CEST 2012
>> > > > >
>> > >
>> > > --
>> > > written by Karol Langner
>> > > Thu Apr 19 16:16:58 CEST 2012
>> > >
>>
>> --
>> written by Karol Langner
>> Thu Apr 19 18:06:53 CEST 2012
>
>

[cclib-devel] [ cclib-Feature Requests-3518357 ] ORCA support

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

Feature Requests item #3518357, was opened at 2012-04-15 23:11
Message generated for change (Comment added) made by atenderholt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819225&aid=3518357&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: ORCA support

Initial Comment:
Orca is a great and free to use program for computational chemistry. Supporting ORCA-output files would be nice.

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

>Comment By: Adam Tenderholt (atenderholt)
Date: 2012-04-19 09:58

Message:
Karol just pointed out that the Orca parser was merged into trunk a long
time ago. Upon further investigation, I see that this parser was included
in cclib 1.0.1. 

I'm closing this ticket.

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

Comment By: Adam Tenderholt (atenderholt)
Date: 2012-04-16 09:15

Message:
There is an ORCA branch in SVN, although it hasn't been tested with the
newer versions of ORCA (i.e. 2.8 and 2.9).

If you need help with getting or using the SVN version, please don't
hesitate to ask. 

Adam


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

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

Re: [cclib-devel] branch maintenance

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

>From what I can see, the ORCA parser was alraedy merged into trunk.

If there is nothing new there (I've looked only at the parser source), then I think
the branch should be deleted, or marked somehow as inactive.

As far as I can see, the other parse branches (Molcas, NWChem, Turbomole) have
not been merged into trunk yet.

Karol

On Apr 19 2012, Adam Tenderholt wrote:
> With the recent talk about updating the license of cclib, it got me
> thinking that we might need to perform some maintenance on the
> branches since several are quite old (e.g. Orca). Is it best to make
> sure the new parsers in those branches are well-supported, and then
> merge those changes into trunk? Or should we merge trunk into those
> branches?
> 
> Adam
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

-- 
written by Karol Langner
Thu Apr 19 18:39:04 CEST 2012

[cclib-devel] branch maintenance

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

With the recent talk about updating the license of cclib, it got me
thinking that we might need to perform some maintenance on the
branches since several are quite old (e.g. Orca). Is it best to make
sure the new parsers in those branches are well-supported, and then
merge those changes into trunk? Or should we merge trunk into those
branches?

Adam

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

Hmmm...I guess you're right - we should just leave it. It's clear from the
source that a later version can be used instead.

- Noel

On 19 April 2012 17:07, Karol M. Langner <kar...@gm...> wrote:

> With? Version 3 of the LGPL?
>
> On Apr 19 2012, Noel O'Boyle wrote:
> > Looks good. We should probably replace LICENSE.txt too.
> >
> > On 19 April 2012 15:17, Karol M. Langner <kar...@gm...>
> wrote:
> >
> > > Done. Please review.
> > >
> > > On Apr 19 2012, Noel O'Boyle wrote:
> > > > Both, I guess.
> > > >
> > > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...>
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Let's get this done. I'll do it, but I'm not sure where I should
> change
> > > > > it. Should I update the license in every source file, or just in
> the
> > > > > LICENSE file?
> > > > >
> > > > > - Karol
> > > > >
> > > > > On Apr 13 2011, Karol M. Langner wrote:
> > > > > > Aye.
> > > > > >
> > > > > > On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
> > > > > > > Aye.
> > > > > > >
> > > > > > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <
> > > bao...@gm...>
> > > > > wrote:
> > > > > > > > All in favour say "aye". Aye.
> > > > > > > >
> > > > > > > > On 12 April 2011 10:03, Karol M. Langner <
> > > kar...@gm...>
> > > > > wrote:
> > > > > > > >> Noel,
> > > > > > > >>
> > > > > > > >>  While working on packaging cclib I got this comment from
> > > Michael
> > > > > Bank. Is there
> > > > > > > >>  any reason not to change the license to the current one "or
> > > later"?
> > > > > > > >>
> > > > > > > >> - Karol
> > > > > > > >>
> > > > > > > >> ----- Forwarded message from Michael Banck <
> mb...@de...>
> > > > > -----
> > > > > > > >>
> > > > > > > >> ...
> > > > > > > >>
> > > > > > > >> ** As an aside, you might want to contact the upstream
> authors
> > > to
> > > > > > > >>   relicense to "LGPL v2.1 or later", or else they might run
> into
> > > > > > > >>   license incompatibilites further down the road (at least
> Noel
> > > > > should
> > > > > > > >>   be aware of that, as OpenBabel keeps suffering from that)
> > > > > > > >>
> > > > > > > >> ...
> > > > > > > >>
> > > > > > > >> ----- End forwarded message -----
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> written by Karol M. Langner
> > > > > > > >> Tue Apr 12 11:00:31 CEST 2011
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > >
> > >
> ------------------------------------------------------------------------------
> > > > > > > > Forrester Wave Report - Recovery time is now measured in
> hours
> > > and
> > > > > minutes
> > > > > > > > not days. Key insights are discussed in the 2010 Forrester
> Wave
> > > > > Report as
> > > > > > > > part of an in-depth evaluation of disaster recovery service
> > > > > providers.
> > > > > > > > Forrester found the best-in-class provider in terms of
> services
> > > and
> > > > > vision.
> > > > > > > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> > > > > > > > _______________________________________________
> > > > > > > > cclib-devel mailing list
> > > > > > > > ccl...@li...
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > written by Karol Langner
> > > > > > Wed Apr 13 11:52:52 CEST 2011
> > > > >
> > > > > --
> > > > > written by Karol Langner
> > > > > Thu Apr 19 13:24:30 CEST 2012
> > > > >
> > >
> > > --
> > > written by Karol Langner
> > > Thu Apr 19 16:16:58 CEST 2012
> > >
>
> --
> written by Karol Langner
> Thu Apr 19 18:06:53 CEST 2012
>

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

With? Version 3 of the LGPL?

On Apr 19 2012, Noel O'Boyle wrote:
> Looks good. We should probably replace LICENSE.txt too.
> 
> On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> wrote:
> 
> > Done. Please review.
> >
> > On Apr 19 2012, Noel O'Boyle wrote:
> > > Both, I guess.
> > >
> > > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > Let's get this done. I'll do it, but I'm not sure where I should change
> > > > it. Should I update the license in every source file, or just in the
> > > > LICENSE file?
> > > >
> > > > - Karol
> > > >
> > > > On Apr 13 2011, Karol M. Langner wrote:
> > > > > Aye.
> > > > >
> > > > > On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
> > > > > > Aye.
> > > > > >
> > > > > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <
> > bao...@gm...>
> > > > wrote:
> > > > > > > All in favour say "aye". Aye.
> > > > > > >
> > > > > > > On 12 April 2011 10:03, Karol M. Langner <
> > kar...@gm...>
> > > > wrote:
> > > > > > >> Noel,
> > > > > > >>
> > > > > > >>  While working on packaging cclib I got this comment from
> > Michael
> > > > Bank. Is there
> > > > > > >>  any reason not to change the license to the current one "or
> > later"?
> > > > > > >>
> > > > > > >> - Karol
> > > > > > >>
> > > > > > >> ----- Forwarded message from Michael Banck <mb...@de...>
> > > > -----
> > > > > > >>
> > > > > > >> ...
> > > > > > >>
> > > > > > >> ** As an aside, you might want to contact the upstream authors
> > to
> > > > > > >>   relicense to "LGPL v2.1 or later", or else they might run into
> > > > > > >>   license incompatibilites further down the road (at least Noel
> > > > should
> > > > > > >>   be aware of that, as OpenBabel keeps suffering from that)
> > > > > > >>
> > > > > > >> ...
> > > > > > >>
> > > > > > >> ----- End forwarded message -----
> > > > > > >>
> > > > > > >> --
> > > > > > >> written by Karol M. Langner
> > > > > > >> Tue Apr 12 11:00:31 CEST 2011
> > > > > > >>
> > > > > > >
> > > > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > > > Forrester Wave Report - Recovery time is now measured in hours
> > and
> > > > minutes
> > > > > > > not days. Key insights are discussed in the 2010 Forrester Wave
> > > > Report as
> > > > > > > part of an in-depth evaluation of disaster recovery service
> > > > providers.
> > > > > > > Forrester found the best-in-class provider in terms of services
> > and
> > > > vision.
> > > > > > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> > > > > > > _______________________________________________
> > > > > > > cclib-devel mailing list
> > > > > > > ccl...@li...
> > > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > > > > > >
> > > > >
> > > > > --
> > > > > written by Karol Langner
> > > > > Wed Apr 13 11:52:52 CEST 2011
> > > >
> > > > --
> > > > written by Karol Langner
> > > > Thu Apr 19 13:24:30 CEST 2012
> > > >
> >
> > --
> > written by Karol Langner
> > Thu Apr 19 16:16:58 CEST 2012
> >

-- 
written by Karol Langner
Thu Apr 19 18:06:53 CEST 2012

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

Thanks for taking care of this.

On Thu, Apr 19, 2012 at 8:37 AM, Noel O'Boyle <bao...@gm...> wrote:
> Looks good. We should probably replace LICENSE.txt too.
>
>
> On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> wrote:
>>
>> Done. Please review.
>>
>> On Apr 19 2012, Noel O'Boyle wrote:
>> > Both, I guess.
>> >
>> > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > Let's get this done. I'll do it, but I'm not sure where I should
>> > > change
>> > > it. Should I update the license in every source file, or just in the
>> > > LICENSE file?
>> > >
>> > > - Karol
>> > >
>> > > On Apr 13 2011, Karol M. Langner wrote:
>> > > > Aye.
>> > > >
>> > > > On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
>> > > > > Aye.
>> > > > >
>> > > > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle
>> > > > > <bao...@gm...>
>> > > wrote:
>> > > > > > All in favour say "aye". Aye.
>> > > > > >
>> > > > > > On 12 April 2011 10:03, Karol M. Langner
>> > > > > > <kar...@gm...>
>> > > wrote:
>> > > > > >> Noel,
>> > > > > >>
>> > > > > >>  While working on packaging cclib I got this comment from
>> > > > > >> Michael
>> > > Bank. Is there
>> > > > > >>  any reason not to change the license to the current one "or
>> > > > > >> later"?
>> > > > > >>
>> > > > > >> - Karol
>> > > > > >>
>> > > > > >> ----- Forwarded message from Michael Banck <mb...@de...>
>> > > -----
>> > > > > >>
>> > > > > >> ...
>> > > > > >>
>> > > > > >> ** As an aside, you might want to contact the upstream authors
>> > > > > >> to
>> > > > > >>   relicense to "LGPL v2.1 or later", or else they might run
>> > > > > >> into
>> > > > > >>   license incompatibilites further down the road (at least Noel
>> > > should
>> > > > > >>   be aware of that, as OpenBabel keeps suffering from that)
>> > > > > >>
>> > > > > >> ...
>> > > > > >>
>> > > > > >> ----- End forwarded message -----
>> > > > > >>
>> > > > > >> --
>> > > > > >> written by Karol M. Langner
>> > > > > >> Tue Apr 12 11:00:31 CEST 2011
>> > > > > >>
>> > > > > >
>> > > > > >
>> > >
>> > > ------------------------------------------------------------------------------
>> > > > > > Forrester Wave Report - Recovery time is now measured in hours
>> > > > > > and
>> > > minutes
>> > > > > > not days. Key insights are discussed in the 2010 Forrester Wave
>> > > Report as
>> > > > > > part of an in-depth evaluation of disaster recovery service
>> > > providers.
>> > > > > > Forrester found the best-in-class provider in terms of services
>> > > > > > and
>> > > vision.
>> > > > > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
>> > > > > > _______________________________________________
>> > > > > > cclib-devel mailing list
>> > > > > > ccl...@li...
>> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> > > > > >
>> > > >
>> > > > --
>> > > > written by Karol Langner
>> > > > Wed Apr 13 11:52:52 CEST 2011
>> > >
>> > > --
>> > > written by Karol Langner
>> > > Thu Apr 19 13:24:30 CEST 2012
>> > >
>>
>> --
>> written by Karol Langner
>> Thu Apr 19 16:16:58 CEST 2012
>
>

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

Looks good. We should probably replace LICENSE.txt too.

On 19 April 2012 15:17, Karol M. Langner <kar...@gm...> wrote:

> Done. Please review.
>
> On Apr 19 2012, Noel O'Boyle wrote:
> > Both, I guess.
> >
> > On 19 April 2012 12:30, Karol M. Langner <kar...@gm...>
> wrote:
> >
> > > Hi,
> > >
> > > Let's get this done. I'll do it, but I'm not sure where I should change
> > > it. Should I update the license in every source file, or just in the
> > > LICENSE file?
> > >
> > > - Karol
> > >
> > > On Apr 13 2011, Karol M. Langner wrote:
> > > > Aye.
> > > >
> > > > On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
> > > > > Aye.
> > > > >
> > > > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <
> bao...@gm...>
> > > wrote:
> > > > > > All in favour say "aye". Aye.
> > > > > >
> > > > > > On 12 April 2011 10:03, Karol M. Langner <
> kar...@gm...>
> > > wrote:
> > > > > >> Noel,
> > > > > >>
> > > > > >>  While working on packaging cclib I got this comment from
> Michael
> > > Bank. Is there
> > > > > >>  any reason not to change the license to the current one "or
> later"?
> > > > > >>
> > > > > >> - Karol
> > > > > >>
> > > > > >> ----- Forwarded message from Michael Banck <mb...@de...>
> > > -----
> > > > > >>
> > > > > >> ...
> > > > > >>
> > > > > >> ** As an aside, you might want to contact the upstream authors
> to
> > > > > >>   relicense to "LGPL v2.1 or later", or else they might run into
> > > > > >>   license incompatibilites further down the road (at least Noel
> > > should
> > > > > >>   be aware of that, as OpenBabel keeps suffering from that)
> > > > > >>
> > > > > >> ...
> > > > > >>
> > > > > >> ----- End forwarded message -----
> > > > > >>
> > > > > >> --
> > > > > >> written by Karol M. Langner
> > > > > >> Tue Apr 12 11:00:31 CEST 2011
> > > > > >>
> > > > > >
> > > > > >
> > >
> ------------------------------------------------------------------------------
> > > > > > Forrester Wave Report - Recovery time is now measured in hours
> and
> > > minutes
> > > > > > not days. Key insights are discussed in the 2010 Forrester Wave
> > > Report as
> > > > > > part of an in-depth evaluation of disaster recovery service
> > > providers.
> > > > > > Forrester found the best-in-class provider in terms of services
> and
> > > vision.
> > > > > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> > > > > > _______________________________________________
> > > > > > cclib-devel mailing list
> > > > > > ccl...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > > > > >
> > > >
> > > > --
> > > > written by Karol Langner
> > > > Wed Apr 13 11:52:52 CEST 2011
> > >
> > > --
> > > written by Karol Langner
> > > Thu Apr 19 13:24:30 CEST 2012
> > >
>
> --
> written by Karol Langner
> Thu Apr 19 16:16:58 CEST 2012
>

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

Done. Please review.

On Apr 19 2012, Noel O'Boyle wrote:
> Both, I guess.
> 
> On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> wrote:
> 
> > Hi,
> >
> > Let's get this done. I'll do it, but I'm not sure where I should change
> > it. Should I update the license in every source file, or just in the
> > LICENSE file?
> >
> > - Karol
> >
> > On Apr 13 2011, Karol M. Langner wrote:
> > > Aye.
> > >
> > > On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
> > > > Aye.
> > > >
> > > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <bao...@gm...>
> > wrote:
> > > > > All in favour say "aye". Aye.
> > > > >
> > > > > On 12 April 2011 10:03, Karol M. Langner <kar...@gm...>
> > wrote:
> > > > >> Noel,
> > > > >>
> > > > >>  While working on packaging cclib I got this comment from Michael
> > Bank. Is there
> > > > >>  any reason not to change the license to the current one "or later"?
> > > > >>
> > > > >> - Karol
> > > > >>
> > > > >> ----- Forwarded message from Michael Banck <mb...@de...>
> > -----
> > > > >>
> > > > >> ...
> > > > >>
> > > > >> ** As an aside, you might want to contact the upstream authors to
> > > > >>   relicense to "LGPL v2.1 or later", or else they might run into
> > > > >>   license incompatibilites further down the road (at least Noel
> > should
> > > > >>   be aware of that, as OpenBabel keeps suffering from that)
> > > > >>
> > > > >> ...
> > > > >>
> > > > >> ----- End forwarded message -----
> > > > >>
> > > > >> --
> > > > >> written by Karol M. Langner
> > > > >> Tue Apr 12 11:00:31 CEST 2011
> > > > >>
> > > > >
> > > > >
> > ------------------------------------------------------------------------------
> > > > > Forrester Wave Report - Recovery time is now measured in hours and
> > minutes
> > > > > not days. Key insights are discussed in the 2010 Forrester Wave
> > Report as
> > > > > part of an in-depth evaluation of disaster recovery service
> > providers.
> > > > > Forrester found the best-in-class provider in terms of services and
> > vision.
> > > > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> > > > > _______________________________________________
> > > > > cclib-devel mailing list
> > > > > ccl...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > > > >
> > >
> > > --
> > > written by Karol Langner
> > > Wed Apr 13 11:52:52 CEST 2011
> >
> > --
> > written by Karol Langner
> > Thu Apr 19 13:24:30 CEST 2012
> >

-- 
written by Karol Langner
Thu Apr 19 16:16:58 CEST 2012

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

Both, I guess.

On 19 April 2012 12:30, Karol M. Langner <kar...@gm...> wrote:

> Hi,
>
> Let's get this done. I'll do it, but I'm not sure where I should change
> it. Should I update the license in every source file, or just in the
> LICENSE file?
>
> - Karol
>
> On Apr 13 2011, Karol M. Langner wrote:
> > Aye.
> >
> > On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
> > > Aye.
> > >
> > > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <bao...@gm...>
> wrote:
> > > > All in favour say "aye". Aye.
> > > >
> > > > On 12 April 2011 10:03, Karol M. Langner <kar...@gm...>
> wrote:
> > > >> Noel,
> > > >>
> > > >>  While working on packaging cclib I got this comment from Michael
> Bank. Is there
> > > >>  any reason not to change the license to the current one "or later"?
> > > >>
> > > >> - Karol
> > > >>
> > > >> ----- Forwarded message from Michael Banck <mb...@de...>
> -----
> > > >>
> > > >> ...
> > > >>
> > > >> ** As an aside, you might want to contact the upstream authors to
> > > >>   relicense to "LGPL v2.1 or later", or else they might run into
> > > >>   license incompatibilites further down the road (at least Noel
> should
> > > >>   be aware of that, as OpenBabel keeps suffering from that)
> > > >>
> > > >> ...
> > > >>
> > > >> ----- End forwarded message -----
> > > >>
> > > >> --
> > > >> written by Karol M. Langner
> > > >> Tue Apr 12 11:00:31 CEST 2011
> > > >>
> > > >
> > > >
> ------------------------------------------------------------------------------
> > > > Forrester Wave Report - Recovery time is now measured in hours and
> minutes
> > > > not days. Key insights are discussed in the 2010 Forrester Wave
> Report as
> > > > part of an in-depth evaluation of disaster recovery service
> providers.
> > > > Forrester found the best-in-class provider in terms of services and
> vision.
> > > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> > > > _______________________________________________
> > > > cclib-devel mailing list
> > > > ccl...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > > >
> >
> > --
> > written by Karol Langner
> > Wed Apr 13 11:52:52 CEST 2011
>
> --
> written by Karol Langner
> Thu Apr 19 13:24:30 CEST 2012
>

Re: [cclib-devel] [mbanck@debian.org: Re: [Debichem-devel] cclib]

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

Hi,

Let's get this done. I'll do it, but I'm not sure where I should change it. Should I update the license in every source file, or just in the LICENSE file?

- Karol

On Apr 13 2011, Karol M. Langner wrote:
> Aye.
> 
> On Tue, Apr 12, 2011 at 03:57:00PM -0700, Adam Tenderholt wrote:
> > Aye.
> > 
> > On Tue, Apr 12, 2011 at 2:26 AM, Noel O'Boyle <bao...@gm...> wrote:
> > > All in favour say "aye". Aye.
> > >
> > > On 12 April 2011 10:03, Karol M. Langner <kar...@gm...> wrote:
> > >> Noel,
> > >>
> > >>  While working on packaging cclib I got this comment from Michael Bank. Is there
> > >>  any reason not to change the license to the current one "or later"?
> > >>
> > >> - Karol
> > >>
> > >> ----- Forwarded message from Michael Banck <mb...@de...> -----
> > >>
> > >> ...
> > >>
> > >> ** As an aside, you might want to contact the upstream authors to
> > >>   relicense to "LGPL v2.1 or later", or else they might run into
> > >>   license incompatibilites further down the road (at least Noel should
> > >>   be aware of that, as OpenBabel keeps suffering from that)
> > >>
> > >> ...
> > >>
> > >> ----- End forwarded message -----
> > >>
> > >> --
> > >> written by Karol M. Langner
> > >> Tue Apr 12 11:00:31 CEST 2011
> > >>
> > >
> > > ------------------------------------------------------------------------------
> > > Forrester Wave Report - Recovery time is now measured in hours and minutes
> > > not days. Key insights are discussed in the 2010 Forrester Wave Report as
> > > part of an in-depth evaluation of disaster recovery service providers.
> > > Forrester found the best-in-class provider in terms of services and vision.
> > > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> > > _______________________________________________
> > > cclib-devel mailing list
> > > ccl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> > >
> 
> -- 
> written by Karol Langner
> Wed Apr 13 11:52:52 CEST 2011

-- 
written by Karol Langner
Thu Apr 19 13:24:30 CEST 2012