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