Menu
▾
▴
cclib-devel
|
From: Noel O'B. <bao...@gm...> - 2009-05-29 14:27:13
|
I have never heard of such a restriction. If it existed, it would state so in the log file. On this basis, I will forward this email to cclib-dev to record that all is cool with the code and log files. - Noel 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: > Aah ok. As long as releasing the log files is not violating any licensing > agreement by Gaussian Inc. Do you know whether they have restrictions on the > release of log files? > > Hugh > > On Friday 29 May 2009 16:10:46 you wrote: >> I meant the log files - on windows they are ".out" instead of ".log". >> >> And confirmation by email is fine. >> >> - Noel >> >> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >> > Dear Noel >> > >> > What do you mean by the "output files"? >> > >> > But yes, I can confirm that (for the code anyway). Is it enough to >> > confirm by email? >> > >> > Regards >> > Hugh >> > >> > On Friday 29 May 2009 15:24:33 you wrote: >> >> That's great, Hugh. >> >> >> >> Can you confirm that you are happy to place the code under the GPL >> >> licence, and the output files in the public domain? >> >> >> >> Once this is done, we can add the code/tests. >> >> >> >> - Noel >> >> >> >> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >> >> > Dear Noel >> >> > >> >> > I've implemented the feature in the Gaussian parser. Please find >> >> > attached the updated files and z-matrix and cartesian log files that >> >> > it works for. >> >> > >> >> > The code creates two attributes grads and gradvars. The first is an >> >> > ndarray of the gradients, the second is the names of the variables as >> >> > a list of strings. >> >> > >> >> > Cheers >> >> > Hugh >> >> > >> >> > >> >> > -- >> >> > _______________________________ >> >> > Hugh Chaffey-Millar, Dr. >> >> > Alexander von Humboldt Fellow >> >> > >> >> > Technische Universität München >> >> > Fachgebiet Molekulare Katalyse >> >> > Department Chemie >> >> > >> >> > Lichtenbergstr. 4 >> >> > 85747 Garching b. München >> >> > >> >> > Tel: +49 (0)89 289 13072 >> >> > hug...@ch... >> > >> > -- >> > _______________________________ >> > Hugh Chaffey-Millar, Dr. >> > Alexander von Humboldt Fellow >> > >> > Technische Universität München >> > Fachgebiet Molekulare Katalyse >> > Department Chemie >> > >> > Lichtenbergstr. 4 >> > 85747 Garching b. München >> > >> > Tel: +49 (0)89 289 13072 >> > hug...@ch... > > > -- > _______________________________ > Hugh Chaffey-Millar, Dr. > Alexander von Humboldt Fellow > > Technische Universität München > Fachgebiet Molekulare Katalyse > Department Chemie > > Lichtenbergstr. 4 > 85747 Garching b. München > > Tel: +49 (0)89 289 13072 > hug...@ch... > |
|
From: Adam T. <a-t...@st...> - 2009-05-29 20:59:18
|
I just wanted to point out that cclib is now licensed under the LGPL. And Hugh, thanks for your contributions. :-) On May 29, 2009, at 7:27 AM, Noel O'Boyle wrote: > I have never heard of such a restriction. If it existed, it would > state so in the log file. > > On this basis, I will forward this email to cclib-dev to record that > all is cool with the code and log files. > > - Noel > > 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >> Aah ok. As long as releasing the log files is not violating any >> licensing >> agreement by Gaussian Inc. Do you know whether they have >> restrictions on the >> release of log files? >> >> Hugh >> >> On Friday 29 May 2009 16:10:46 you wrote: >>> I meant the log files - on windows they are ".out" instead of >>> ".log". >>> >>> And confirmation by email is fine. >>> >>> - Noel >>> >>> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>>> Dear Noel >>>> >>>> What do you mean by the "output files"? >>>> >>>> But yes, I can confirm that (for the code anyway). Is it enough to >>>> confirm by email? >>>> >>>> Regards >>>> Hugh >>>> >>>> On Friday 29 May 2009 15:24:33 you wrote: >>>>> That's great, Hugh. >>>>> >>>>> Can you confirm that you are happy to place the code under the GPL >>>>> licence, and the output files in the public domain? >>>>> >>>>> Once this is done, we can add the code/tests. >>>>> >>>>> - Noel >>>>> >>>>> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>>>>> Dear Noel >>>>>> >>>>>> I've implemented the feature in the Gaussian parser. Please find >>>>>> attached the updated files and z-matrix and cartesian log files >>>>>> that >>>>>> it works for. >>>>>> >>>>>> The code creates two attributes grads and gradvars. The first >>>>>> is an >>>>>> ndarray of the gradients, the second is the names of the >>>>>> variables as >>>>>> a list of strings. >>>>>> >>>>>> Cheers >>>>>> Hugh >>>>>> >>>>>> >>>>>> -- >>>>>> _______________________________ >>>>>> Hugh Chaffey-Millar, Dr. >>>>>> Alexander von Humboldt Fellow >>>>>> >>>>>> Technische Universität München >>>>>> Fachgebiet Molekulare Katalyse >>>>>> Department Chemie >>>>>> >>>>>> Lichtenbergstr. 4 >>>>>> 85747 Garching b. München >>>>>> >>>>>> Tel: +49 (0)89 289 13072 >>>>>> hug...@ch... >>>> >>>> -- >>>> _______________________________ >>>> Hugh Chaffey-Millar, Dr. >>>> Alexander von Humboldt Fellow >>>> >>>> Technische Universität München >>>> Fachgebiet Molekulare Katalyse >>>> Department Chemie >>>> >>>> Lichtenbergstr. 4 >>>> 85747 Garching b. München >>>> >>>> Tel: +49 (0)89 289 13072 >>>> hug...@ch... >> >> >> -- >> _______________________________ >> Hugh Chaffey-Millar, Dr. >> Alexander von Humboldt Fellow >> >> Technische Universität München >> Fachgebiet Molekulare Katalyse >> Department Chemie >> >> Lichtenbergstr. 4 >> 85747 Garching b. München >> >> Tel: +49 (0)89 289 13072 >> hug...@ch... >> > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity > professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel |
|
From: Noel O'B. <bao...@gm...> - 2009-05-29 22:39:54
|
Um, good point. Can I plead "lesser poetic license"? :-) 2009/5/29 Adam Tenderholt <a-t...@st...>: > I just wanted to point out that cclib is now licensed under the LGPL. > > And Hugh, thanks for your contributions. :-) > > > On May 29, 2009, at 7:27 AM, Noel O'Boyle wrote: > >> I have never heard of such a restriction. If it existed, it would >> state so in the log file. >> >> On this basis, I will forward this email to cclib-dev to record that >> all is cool with the code and log files. >> >> - Noel >> >> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>> >>> Aah ok. As long as releasing the log files is not violating any licensing >>> agreement by Gaussian Inc. Do you know whether they have restrictions on >>> the >>> release of log files? >>> >>> Hugh >>> >>> On Friday 29 May 2009 16:10:46 you wrote: >>>> >>>> I meant the log files - on windows they are ".out" instead of ".log". >>>> >>>> And confirmation by email is fine. >>>> >>>> - Noel >>>> >>>> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>>>> >>>>> Dear Noel >>>>> >>>>> What do you mean by the "output files"? >>>>> >>>>> But yes, I can confirm that (for the code anyway). Is it enough to >>>>> confirm by email? >>>>> >>>>> Regards >>>>> Hugh >>>>> >>>>> On Friday 29 May 2009 15:24:33 you wrote: >>>>>> >>>>>> That's great, Hugh. >>>>>> >>>>>> Can you confirm that you are happy to place the code under the GPL >>>>>> licence, and the output files in the public domain? >>>>>> >>>>>> Once this is done, we can add the code/tests. >>>>>> >>>>>> - Noel >>>>>> >>>>>> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>>>>>> >>>>>>> Dear Noel >>>>>>> >>>>>>> I've implemented the feature in the Gaussian parser. Please find >>>>>>> attached the updated files and z-matrix and cartesian log files that >>>>>>> it works for. >>>>>>> >>>>>>> The code creates two attributes grads and gradvars. The first is an >>>>>>> ndarray of the gradients, the second is the names of the variables as >>>>>>> a list of strings. >>>>>>> >>>>>>> Cheers >>>>>>> Hugh >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _______________________________ >>>>>>> Hugh Chaffey-Millar, Dr. >>>>>>> Alexander von Humboldt Fellow >>>>>>> >>>>>>> Technische Universität München >>>>>>> Fachgebiet Molekulare Katalyse >>>>>>> Department Chemie >>>>>>> >>>>>>> Lichtenbergstr. 4 >>>>>>> 85747 Garching b. München >>>>>>> >>>>>>> Tel: +49 (0)89 289 13072 >>>>>>> hug...@ch... >>>>> >>>>> -- >>>>> _______________________________ >>>>> Hugh Chaffey-Millar, Dr. >>>>> Alexander von Humboldt Fellow >>>>> >>>>> Technische Universität München >>>>> Fachgebiet Molekulare Katalyse >>>>> Department Chemie >>>>> >>>>> Lichtenbergstr. 4 >>>>> 85747 Garching b. München >>>>> >>>>> Tel: +49 (0)89 289 13072 >>>>> hug...@ch... >>> >>> >>> -- >>> _______________________________ >>> Hugh Chaffey-Millar, Dr. >>> Alexander von Humboldt Fellow >>> >>> Technische Universität München >>> Fachgebiet Molekulare Katalyse >>> Department Chemie >>> >>> Lichtenbergstr. 4 >>> 85747 Garching b. München >>> >>> Tel: +49 (0)89 289 13072 >>> hug...@ch... >>> >> >> >> ------------------------------------------------------------------------------ >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity professionals. >> Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian >> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel > > |
|
From: Hugh Chaffey-M. <hug...@ch...> - 2009-05-30 08:48:50
|
No problem, you can place in under the LGPL. ...and my contribution was fairly small, but I will possibly add the same feature for a few other packages in due course. Kind regards Hugh Chaffey-Millar Adam Tenderholt wrote: > I just wanted to point out that cclib is now licensed under the LGPL. > > And Hugh, thanks for your contributions. :-) > > > On May 29, 2009, at 7:27 AM, Noel O'Boyle wrote: > >> I have never heard of such a restriction. If it existed, it would >> state so in the log file. >> >> On this basis, I will forward this email to cclib-dev to record that >> all is cool with the code and log files. >> >> - Noel >> >> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>> Aah ok. As long as releasing the log files is not violating any >>> licensing >>> agreement by Gaussian Inc. Do you know whether they have >>> restrictions on the >>> release of log files? >>> >>> Hugh >>> >>> On Friday 29 May 2009 16:10:46 you wrote: >>>> I meant the log files - on windows they are ".out" instead of ".log". >>>> >>>> And confirmation by email is fine. >>>> >>>> - Noel >>>> >>>> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>>>> Dear Noel >>>>> >>>>> What do you mean by the "output files"? >>>>> >>>>> But yes, I can confirm that (for the code anyway). Is it enough to >>>>> confirm by email? >>>>> >>>>> Regards >>>>> Hugh >>>>> >>>>> On Friday 29 May 2009 15:24:33 you wrote: >>>>>> That's great, Hugh. >>>>>> >>>>>> Can you confirm that you are happy to place the code under the GPL >>>>>> licence, and the output files in the public domain? >>>>>> >>>>>> Once this is done, we can add the code/tests. >>>>>> >>>>>> - Noel >>>>>> >>>>>> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: >>>>>>> Dear Noel >>>>>>> >>>>>>> I've implemented the feature in the Gaussian parser. Please find >>>>>>> attached the updated files and z-matrix and cartesian log files >>>>>>> that >>>>>>> it works for. >>>>>>> >>>>>>> The code creates two attributes grads and gradvars. The first is an >>>>>>> ndarray of the gradients, the second is the names of the >>>>>>> variables as >>>>>>> a list of strings. >>>>>>> >>>>>>> Cheers >>>>>>> Hugh >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _______________________________ >>>>>>> Hugh Chaffey-Millar, Dr. >>>>>>> Alexander von Humboldt Fellow >>>>>>> >>>>>>> Technische Universität München >>>>>>> Fachgebiet Molekulare Katalyse >>>>>>> Department Chemie >>>>>>> >>>>>>> Lichtenbergstr. 4 >>>>>>> 85747 Garching b. München >>>>>>> >>>>>>> Tel: +49 (0)89 289 13072 >>>>>>> hug...@ch... >>>>> >>>>> -- >>>>> _______________________________ >>>>> Hugh Chaffey-Millar, Dr. >>>>> Alexander von Humboldt Fellow >>>>> >>>>> Technische Universität München >>>>> Fachgebiet Molekulare Katalyse >>>>> Department Chemie >>>>> >>>>> Lichtenbergstr. 4 >>>>> 85747 Garching b. München >>>>> >>>>> Tel: +49 (0)89 289 13072 >>>>> hug...@ch... >>> >>> >>> -- >>> _______________________________ >>> Hugh Chaffey-Millar, Dr. >>> Alexander von Humboldt Fellow >>> >>> Technische Universität München >>> Fachgebiet Molekulare Katalyse >>> Department Chemie >>> >>> Lichtenbergstr. 4 >>> 85747 Garching b. München >>> >>> Tel: +49 (0)89 289 13072 >>> hug...@ch... >>> >> >> ------------------------------------------------------------------------------ >> >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity >> professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian >> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >> _______________________________________________ >> cclib-devel mailing list >> ccl...@li... >> https://lists.sourceforge.net/lists/listinfo/cclib-devel > > -- _______________________________ Hugh Chaffey-Millar, Dr. Alexander von Humboldt Fellow Technische Universität München Fachgebiet Molekulare Katalyse Department Chemie Lichtenbergstr. 4 85747 Garching b. München Tel: +49 (0)89 289 13182 hug...@ch... |
|
From: Noel O'B. <bao...@gm...> - 2009-06-05 15:55:47
|
Hello Hugh,
I've been testing the patch, and looking at the output of other comp
chem programs. I was thinking it might be better if you could extract
the section giving the forces in terms of cartesian coordinates, e.g.
-------------------------------------------------------------------
Center Atomic Forces (Hartrees/Bohr)
Number Number X Y Z
-------------------------------------------------------------------
1 1 -0.012534744 -0.021754635 -0.008346094
2 6 0.018984731 0.032948887 -0.038003451
3 1 -0.002133484 -0.006226040 0.023174772
4 1 -0.004316502 -0.004968213 0.023174772
-------------------------------------------------------------------
Firstly, this seems to be available in the other comp chem log files I
looked at. Secondly, cclib has no concept of what the variables
describing the internal coordinates refer to. It might be possible to
also extract this information from the Gaussian log file, but that
opens up a lot of issues in relation to other software and all the
various types of internal coordinates.
What do you think?
- Noel
2009/5/29 Hugh Chaffey-Millar <hug...@ch...>:
> Dear Noel
>
> I've implemented the feature in the Gaussian parser. Please find attached the
> updated files and z-matrix and cartesian log files that it works for.
>
> The code creates two attributes grads and gradvars. The first is an ndarray of
> the gradients, the second is the names of the variables as a list of strings.
>
> Cheers
> Hugh
>
>
> --
> _______________________________
> Hugh Chaffey-Millar, Dr.
> Alexander von Humboldt Fellow
>
> Technische Universität München
> Fachgebiet Molekulare Katalyse
> Department Chemie
>
> Lichtenbergstr. 4
> 85747 Garching b. München
>
> Tel: +49 (0)89 289 13072
> hug...@ch...
>
|
|
From: Hugh Chaffey-M. <hug...@ch...> - 2009-06-06 14:38:43
|
Hi Noel That's probably reasonable, but the code only extracts internal coordinates if these were given in the input file as a z-matrix, and if this is the case, the "user" will know what they refer to. Returning gradients in the context of the supplied z-matrix is particularly important if the user wants to implement a custom geometry optimisation strategy and, for example, freeze some bonds, project out some forces, etc. If cclib were to only return the forces in terms of Cartesians, then the programmer would need to somehow construct a matrix of dX_i/dI_j, i.e. the matrix whose elements are the change of cartesian coordinate X_i with respect to internal coordinate I_j, for each point in the optimisation. In light of the fact that other packages only give cartesians it's probably reasonable, in the name of uniformity to extract these from a Gaussian file, but I believe forces in terms of the supplied z-matrix are also important. I, for example, for my current research, need to know the forces in terms of the z-matrix variables. If you want I can add code to extract the cartesians as well. Just let me know. Also, if you have any other comments about my python coding style or other suggestions regarding the way in which you'd like it to be written, please feel free to pass them on. I've only been coding in python for a few months. As I may have mentioned, I will probably add support for a number of other programs, such as GAMESS, NWChem and possibly VASP, at some point, so obviously should do this in a style that is consistent with the rest of cclib. On another matter, I noticed a broken link of the main page: in the opening sentence "cclib is an open source library, written in Python" the Python link is broken. :-) In any case, thanks for a great library - very useful! Cheers Hugh Noel O'Boyle wrote: > Hello Hugh, > > I've been testing the patch, and looking at the output of other comp > chem programs. I was thinking it might be better if you could extract > the section giving the forces in terms of cartesian coordinates, e.g. > ------------------------------------------------------------------- > Center Atomic Forces (Hartrees/Bohr) > Number Number X Y Z > ------------------------------------------------------------------- > 1 1 -0.012534744 -0.021754635 -0.008346094 > 2 6 0.018984731 0.032948887 -0.038003451 > 3 1 -0.002133484 -0.006226040 0.023174772 > 4 1 -0.004316502 -0.004968213 0.023174772 > ------------------------------------------------------------------- > > Firstly, this seems to be available in the other comp chem log files I > looked at. Secondly, cclib has no concept of what the variables > describing the internal coordinates refer to. It might be possible to > also extract this information from the Gaussian log file, but that > opens up a lot of issues in relation to other software and all the > various types of internal coordinates. > > What do you think? > > - Noel > > 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>: > >> Dear Noel >> >> I've implemented the feature in the Gaussian parser. Please find attached the >> updated files and z-matrix and cartesian log files that it works for. >> >> The code creates two attributes grads and gradvars. The first is an ndarray of >> the gradients, the second is the names of the variables as a list of strings. >> >> Cheers >> Hugh >> >> >> -- >> _______________________________ >> Hugh Chaffey-Millar, Dr. >> Alexander von Humboldt Fellow >> >> Technische Universität München >> Fachgebiet Molekulare Katalyse >> Department Chemie >> >> Lichtenbergstr. 4 >> 85747 Garching b. München >> >> Tel: +49 (0)89 289 13072 >> hug...@ch... >> >> > > > -- _______________________________ Hugh Chaffey-Millar, Dr. Alexander von Humboldt Fellow Technische Universität München Fachgebiet Molekulare Katalyse Department Chemie Lichtenbergstr. 4 85747 Garching b. München Tel: +49 (0)89 289 13182 hug...@ch... |
|
From: Noel O'B. <bao...@gm...> - 2009-06-06 15:42:02
|
2009/6/6 Hugh Chaffey-Millar <hug...@ch...>:
> Hi Noel
>
> That's probably reasonable, but the code only extracts internal coordinates
> if these were given in the input file as a z-matrix, and if this is the
> case, the "user" will know what they refer to. Returning gradients in the
> context of the supplied z-matrix is particularly important if the user wants
> to implement a custom geometry optimisation strategy and, for example,
> freeze some bonds, project out some forces, etc. If cclib were to only
> return the forces in terms of Cartesians, then the programmer would need to
> somehow construct a matrix of dX_i/dI_j, i.e. the matrix whose elements are
> the change of cartesian coordinate X_i with respect to internal coordinate
> I_j, for each point in the optimisation.
That's a good defense. Regarding the first point though, I would like
as much as possible for all the necessary information to be available
simply by parsing the log file. I will look again through a variety of
the log files I have here.
> In light of the fact that other packages only give cartesians it's probably
> reasonable, in the name of uniformity to extract these from a Gaussian file,
> but I believe forces in terms of the supplied z-matrix are also important.
> I, for example, for my current research, need to know the forces in terms of
> the z-matrix variables.
That's fine. BTW to clarify, it may not be that the other packages
only give cartesians - it may just be the nature of the input provided
in our test suite.
> If you want I can add code to extract the cartesians as well. Just let me
> know.
I think that would be good. It would also be useful to consider how
other programs handle this problem and try to find some commonality.
The wiki is often useful for gathering together this sort of
information.
> Also, if you have any other comments about my python coding style or
> other suggestions regarding the way in which you'd like it to be written,
> please feel free to pass them on. I've only been coding in python for a few
> months.
The code looks good.
> As I may have mentioned, I will probably add support for a number of other
> programs, such as GAMESS, NWChem and possibly VASP, at some point, so
> obviously should do this in a style that is consistent with the rest of
> cclib.
Sure. We try to stick to the PEP whatever for nice Python, and we try
to make it easier for others to read the code. We don't generally
worry about speed, but I note that line.find("whatever") is slower
than line[1:27] == "whatever".
> On another matter, I noticed a broken link of the main page: in the opening
> sentence "cclib is an open source library, written in Python" the Python
> link is broken. :-)
Will do. If you're going to be doing a lot more hacking on cclib we'll
get you set up with SVN, wiki access and so on. Let us know when you
want this.
> In any case, thanks for a great library - very useful!
>
> Cheers
> Hugh
>
>
>
> Noel O'Boyle wrote:
>>
>> Hello Hugh,
>>
>> I've been testing the patch, and looking at the output of other comp
>> chem programs. I was thinking it might be better if you could extract
>> the section giving the forces in terms of cartesian coordinates, e.g.
>> -------------------------------------------------------------------
>> Center Atomic Forces (Hartrees/Bohr)
>> Number Number X Y Z
>> -------------------------------------------------------------------
>> 1 1 -0.012534744 -0.021754635 -0.008346094
>> 2 6 0.018984731 0.032948887 -0.038003451
>> 3 1 -0.002133484 -0.006226040 0.023174772
>> 4 1 -0.004316502 -0.004968213 0.023174772
>> -------------------------------------------------------------------
>>
>> Firstly, this seems to be available in the other comp chem log files I
>> looked at. Secondly, cclib has no concept of what the variables
>> describing the internal coordinates refer to. It might be possible to
>> also extract this information from the Gaussian log file, but that
>> opens up a lot of issues in relation to other software and all the
>> various types of internal coordinates.
>>
>> What do you think?
>>
>> - Noel
>>
>> 2009/5/29 Hugh Chaffey-Millar <hug...@ch...>:
>>
>>>
>>> Dear Noel
>>>
>>> I've implemented the feature in the Gaussian parser. Please find attached
>>> the
>>> updated files and z-matrix and cartesian log files that it works for.
>>>
>>> The code creates two attributes grads and gradvars. The first is an
>>> ndarray of
>>> the gradients, the second is the names of the variables as a list of
>>> strings.
>>>
>>> Cheers
>>> Hugh
>>>
>>>
>>> --
>>> _______________________________
>>> Hugh Chaffey-Millar, Dr.
>>> Alexander von Humboldt Fellow
>>>
>>> Technische Universität München
>>> Fachgebiet Molekulare Katalyse
>>> Department Chemie
>>>
>>> Lichtenbergstr. 4
>>> 85747 Garching b. München
>>>
>>> Tel: +49 (0)89 289 13072
>>> hug...@ch...
>>>
>>>
>>
>>
>>
>
>
> --
> _______________________________
> Hugh Chaffey-Millar, Dr.
> Alexander von Humboldt Fellow
>
> Technische Universität München
> Fachgebiet Molekulare Katalyse
> Department Chemie
>
> Lichtenbergstr. 4
> 85747 Garching b. München
>
> Tel: +49 (0)89 289 13182
> hug...@ch...
>
>
>
|
|
From: Karol L. <kar...@gm...> - 2009-06-11 22:44:12
|
Hi Hugh, On Saturday 06 June 2009 14:13:01 Hugh Chaffey-Millar wrote: > That's probably reasonable, but the code only extracts internal > coordinates if these were given in the input file as a z-matrix, and if > this is the case, the "user" will know what they refer to. Returning > gradients in the context of the supplied z-matrix is particularly > important if the user wants to implement a custom geometry optimisation > strategy and, for example, freeze some bonds, project out some forces, > etc. If cclib were to only return the forces in terms of Cartesians, > then the programmer would need to somehow construct a matrix of > dX_i/dI_j, i.e. the matrix whose elements are the change of cartesian > coordinate X_i with respect to internal coordinate I_j, for each point > in the optimisation. > > In light of the fact that other packages only give cartesians it's > probably reasonable, in the name of uniformity to extract these from a > Gaussian file, but I believe forces in terms of the supplied z-matrix > are also important. I, for example, for my current research, need to > know the forces in terms of the z-matrix variables. > > If you want I can add code to extract the cartesians as well. Just let > me know. Also, if you have any other comments about my python coding > style or other suggestions regarding the way in which you'd like it to > be written, please feel free to pass them on. I've only been coding in > python for a few months. Could I also look over your code and input/output example? On a related note, cclib has a hessian property that should contain the force constants, but currently it's implemented only for Molpro. As Noel wrote, cclib doesn't understand Z-matrices and works only with cartesian coordinates. Before parsing energy derivatives or anything else in terms of internal coordinates, there would have to be some kind of generic support for them in cclib. Maybe a 'zmatrix' attribute or at least one containing bond/angle definitions. Z-matrix parsing and/or interconversion with cartesians would be useful... currently I do it on a regular basis with openbabel. If not parsed, perhaps a helper method could build and return the z-matrix via openbabel. For derived quantities like (second) derivatives, it will be harder to maintain clarity and consistency between outputs from various programs if we were to provide them potentially in both cartesian and internal coordinates. I would again suggest a helper method in this case that converts the standard cartesian form to internal coordinates, with a Z-matrix or atom ordering given as input. > As I may have mentioned, I will probably add support for a number of > other programs, such as GAMESS, NWChem and possibly VASP, at some point, > so obviously should do this in a style that is consistent with the rest > of cclib. We don't parse nwchem or VASP output files at the moment, so there is no parse to currently add code to for those programs. > On another matter, I noticed a broken link of the main page: in the > opening sentence "cclib is an open source library, written in Python" > the Python link is broken. :-) Thanks, typo fixed. Best, Karol -- written by Karol Langner Fri Jun 12 00:13:30 CEST 2009 |
|
From: Hugh Chaffey-M. <hug...@ch...> - 2009-06-12 08:47:48
|
Hi Karol > Could I also look over your code and input/output example? Sure, I'll send these in a separate email to you only, since Noel has it already. > Z-matrix parsing and/or interconversion with cartesians would be useful... > currently I do it on a regular basis with openbabel. If not parsed, perhaps > a helper method could build and return the z-matrix via openbabel. That would surely be useful. Coul I quickly ask, do you use the C++ API directly when doing this or do you mean you convert between file formats with z-matrix/cartesian specifications? > For derived quantities like (second) derivatives, it will be harder to > maintain clarity and consistency between outputs from various programs if > we were to provide them potentially in both cartesian and internal > coordinates. I would again suggest a helper method in this case that > converts the standard cartesian form to internal coordinates, with a > Z-matrix or atom ordering given as input. Yep I suppose that would be good. When gradients are already available in terms of the z-matrix, I would have thought it incurs unnecessary complexity to invoke other methods to convert the gradients from cartesians to z-matrix. But in general, such infrastructure in the code would be useful. In a related project I'm currently working on, I have already written code to convert from forces in cartesians to forces in z-matrix, and it numerically differentiates the function Z(C) that returns z-matrix coordinates, Z, in terms of the cartesians, C, and implements the function Z using the python interface to openbabel. > > As I may have mentioned, I will probably add support for a number of > > other programs, such as GAMESS, NWChem and possibly VASP, at some point, > > so obviously should do this in a style that is consistent with the rest > > of cclib. > > We don't parse nwchem or VASP output files at the moment, so there is no > parse to currently add code to for those programs. Well if I were to write some code to parse them, would you want to add it to cclib? Cheers Hugh |
|
From: Karol M. L. <kar...@gm...> - 2009-07-15 15:26:14
|
On Friday 12 June 2009 10:41:29 Hugh Chaffey-Millar wrote: > Hi Karol > > > Could I also look over your code and input/output example? > > Sure, I'll send these in a separate email to you only, since Noel has it > already. Thanks for that code. It's been a while, but I implemented parsing gradients today for Gaussian. I write the code from scratch, but used your log files. There is a small fragment in the comment of the latest commit. Is that OK? It's really quite short - that would be revision 850. Here's the diff: http://cclib.svn.sourceforge.net/viewvc/cclib/trunk/src/cclib/parser/gaussianparser.py?r1=850&r2=849&pathrev=850&diff_format=h At this point, the parser parses the cartesian forces into a regular mxnx3 matrix, where n is the number of atoms and m in the number of optimization steps. The numbers are in gaussian-esque hartree/bohr - I guess I should convert that to eV/angstrem... what do you say Noel? Here is one of your log files parsed with the new code: langner@machine:~$ cat <<EOF | python > import cclib > a = cclib.parser.ccopen("MeOMe-grad.log").parse() > print a.grads > EOF [Gaussian MeOMe-grad.log INFO] Creating attribute charge: 0 [Gaussian MeOMe-grad.log INFO] Creating attribute mult: 1 [Gaussian MeOMe-grad.log INFO] Creating attribute atomnos[] [Gaussian MeOMe-grad.log INFO] Creating attribute natom: 9 [Gaussian MeOMe-grad.log INFO] Creating attribute atomcoords[] [Gaussian MeOMe-grad.log INFO] Creating attribute nbasis: 57 [Gaussian MeOMe-grad.log INFO] Creating attribute nmo: 57 [Gaussian MeOMe-grad.log INFO] Creating attribute scftargets[] [Gaussian MeOMe-grad.log INFO] Creating attribute scfenergies[] [Gaussian MeOMe-grad.log INFO] Creating attribute mosyms[] [Gaussian MeOMe-grad.log INFO] Creating attribute homos[] [Gaussian MeOMe-grad.log INFO] Creating attribute moenergies[] [Gaussian MeOMe-grad.log INFO] Creating attribute grads[] [Gaussian MeOMe-grad.log INFO] Creating attribute geovalues[] [Gaussian MeOMe-grad.log INFO] Creating attribute geotargets[] [Gaussian MeOMe-grad.log INFO] Creating attribute coreelectrons[] [[[ 0.01026324 0.01389559 0.02445051] [ 0.00747792 -0.01446347 0.00280476] [ 0.00470098 0.00834956 -0.01982187] [-0.0217437 -0.00201811 -0.00282018] [-0.00126088 0.00092114 -0.00145291] [ 0.00980594 -0.02822511 -0.00185482] [-0.02168228 0.00376007 0.00074849] [ 0.00764326 0.00369573 0.01417389] [ 0.00479553 0.01408459 -0.01622786]]] It should also work with the current standard geometry optimization tests we have, so there's no need for more tests at the moment. I'll add some tests soon for the standard tests. Cheers, Karol -- written by Karol Langner Wed Jul 15 17:04:13 CEST 2009 |
|
From: Noel O'B. <bao...@gm...> - 2009-06-12 08:58:48
|
2009/6/12 Hugh Chaffey-Millar <hug...@ch...>: > Hi Karol > >> Could I also look over your code and input/output example? > > Sure, I'll send these in a separate email to you only, since Noel has it > already. > >> Z-matrix parsing and/or interconversion with cartesians would be useful... >> currently I do it on a regular basis with openbabel. If not parsed, perhaps >> a helper method could build and return the z-matrix via openbabel. > > That would surely be useful. Coul I quickly ask, do you use the C++ API > directly when doing this or do you mean you convert between file formats with > z-matrix/cartesian specifications? > >> For derived quantities like (second) derivatives, it will be harder to >> maintain clarity and consistency between outputs from various programs if >> we were to provide them potentially in both cartesian and internal >> coordinates. I would again suggest a helper method in this case that >> converts the standard cartesian form to internal coordinates, with a >> Z-matrix or atom ordering given as input. > > Yep I suppose that would be good. When gradients are already available in > terms of the z-matrix, I would have thought it incurs unnecessary complexity > to invoke other methods to convert the gradients from cartesians to z-matrix. > But in general, such infrastructure in the code would be useful. > > In a related project I'm currently working on, I have already written code to > convert from forces in cartesians to forces in z-matrix, and it numerically > differentiates the function Z(C) that returns z-matrix coordinates, Z, in > terms of the cartesians, C, and implements the function Z using the python > interface to openbabel. We'd like this sort of code. >> > As I may have mentioned, I will probably add support for a number of >> > other programs, such as GAMESS, NWChem and possibly VASP, at some point, >> > so obviously should do this in a style that is consistent with the rest >> > of cclib. >> >> We don't parse nwchem or VASP output files at the moment, so there is no >> parse to currently add code to for those programs. > > Well if I were to write some code to parse them, would you want to add it to > cclib? Absolutely. The only requirement is that the parser implements enough functionality to pass the test framework. > Cheers > Hugh > > > |
|
From: Hugh Chaffey-M. <hug...@ch...> - 2009-06-16 12:06:55
|
Dear Noel and Karol > > In a related project I'm currently working on, I have already written > > code to convert from forces in cartesians to forces in z-matrix, and it > > numerically differentiates the function Z(C) that returns z-matrix > > coordinates, Z, in terms of the cartesians, C, and implements the > > function Z using the python interface to openbabel. > > We'd like this sort of code. > > > Well if I were to write some code to parse them, would you want to add it > > to cclib? > > Absolutely. The only requirement is that the parser implements enough > functionality to pass the test framework. Ok, as I make progress on the project, I'll let you know as various pieces of code become ready. Regards Hugh |
|
From: Karol M. L. <kar...@gm...> - 2009-07-15 15:26:58
|
To answer a few more questions... > > Z-matrix parsing and/or interconversion with cartesians would be > > useful... currently I do it on a regular basis with openbabel. If not > > parsed, perhaps a helper method could build and return the z-matrix via > > openbabel. > > That would surely be useful. Coul I quickly ask, do you use the C++ API > directly when doing this or do you mean you convert between file formats > with z-matrix/cartesian specifications? No, I hack away in bash... passing around *.xyz files and text files with Z-matrices :) I also wrote a little function for converting between these things (in Python), but don't use it all that often it turns out. > > For derived quantities like (second) derivatives, it will be harder to > > maintain clarity and consistency between outputs from various programs if > > we were to provide them potentially in both cartesian and internal > > coordinates. I would again suggest a helper method in this case that > > converts the standard cartesian form to internal coordinates, with a > > Z-matrix or atom ordering given as input. > > Yep I suppose that would be good. When gradients are already available in > terms of the z-matrix, I would have thought it incurs unnecessary > complexity to invoke other methods to convert the gradients from cartesians > to z-matrix. But in general, such infrastructure in the code would be > useful. Yes... in my opinion this should be done post-parsing, as a helper method. Cartesians and internals are fully interchangeable (besides the origin), so this really is not a problem, given the proper methods. Note one more thing. Gaussian itself prints the internal gradient only when explicitly given Z-matrix input. It always print cartesian gradients, however, so just parsing that makes everything a lot simpler. > In a related project I'm currently working on, I have already written code > to convert from forces in cartesians to forces in z-matrix, and it > numerically differentiates the function Z(C) that returns z-matrix > coordinates, Z, in terms of the cartesians, C, and implements the function > Z using the python interface to openbabel. That code would be a good starting point for these helper methods. Would you care to share it? > > > As I may have mentioned, I will probably add support for a number of > > > other programs, such as GAMESS, NWChem and possibly VASP, at some > > > point, so obviously should do this in a style that is consistent with > > > the rest of cclib. > > > > We don't parse nwchem or VASP output files at the moment, so there is no > > parse to currently add code to for those programs. > > Well if I were to write some code to parse them, would you want to add it > to cclib? Perhaps. To start off with, we could create a branch of cclib that would implement just the gradients for VASP, and when we have enough attributes parsed compared to other programs, we could include it in the main development branch. Cheers, Karol |
|
From: Hugh Chaffey-M. <hug...@ch...> - 2009-07-15 16:57:37
|
Hi thanks for the changes to cclib! > > In a related project I'm currently working on, I have already written > > code to convert from forces in cartesians to forces in z-matrix, and it > > numerically differentiates the function Z(C) that returns z-matrix > > coordinates, Z, in terms of the cartesians, C, and implements the > > function Z using the python interface to openbabel. > > That code would be a good starting point for these helper methods. Would > you care to share it? Sure, when it's in better shape I'll send it through. I've also re-implemented the z-matrix => cartesian conversion (that is needed for the above) from OpenBabel in pure Python (Reasons: the openbabel version had bugs, didn't emit xyz with sufficient precision to do numerical differentiation, it required a lot of code to utilise it from within Python ). I can make both of these available if you want. > > Well if I were to write some code to parse them, would you want to add it > > to cclib? > > Perhaps. To start off with, we could create a branch of cclib that would > implement just the gradients for VASP, and when we have enough attributes > parsed compared to other programs, we could include it in the main > development branch. Ok. I will be doing some hacking over the coming months and as I have support implemented I'll send it through. Cheers Hugh |
|
From: Hugh Chaffey-M. <hug...@ch...> - 2009-06-03 13:19:48
|
Dear Noel Gaussian reports gradients in Hartrees/Bohr and Hartrees/Radian but other packages might not be the same. What is the policy here, should everything be converted to SI or what units should be used. The code I sent you just retrieved the information directly from the Gaussian file so uses the same units as. Cheers Hugh |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X