cclib-devel — Developer's mailing list

Re: [cclib-devel] Python 3 port

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

No - on the Python 3 branch. Almost there.

When done, I'll copy the existing trunk to a Python2 branch, and copy
Python3 to trunk.

- Noel

On 28 February 2013 15:58, Karol M. Langner <kar...@gm...> wrote:
> Are you working in trunk?
>
> On Feb 27 2013, Noel O'Boyle wrote:
>> Hi there,
>>
>> Just to let you guys know that I'm currently working my way through
>> the parsers for the Python 3 port. It's taking longer than I expected
>> but I hope to have it done by next week.
>>
>> - Noel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
> --
> written by Karol M. Langner
> Thu Feb 28 16:58:29 CET 2013

[cclib-devel] Python 3 port

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

Hi there,

Just to let you guys know that I'm currently working my way through
the parsers for the Python 3 port. It's taking longer than I expected
but I hope to have it done by next week.

- Noel

Re: [cclib-devel] [cclib-users] Orca 2.9.0 error

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

I agree, and I'll leave this one to you guys. Have you checked if perhaps this is caused by a change between ORCA versions? I'm not really up-to-date on it's output.

Karol

On Feb 25 2013, Noel O'Boyle wrote:
> I'm all for parsing it. Since this is fairly GaussSum-specific I'm
> happy to do it if you can make sure these files are public domain. In
> the meanwhile, you can point out to the user that he can comment out
> the offending code.
> 
> On 25 February 2013 17:31, Adam Tenderholt <ate...@gm...> wrote:
> > CC: dev list
> >
> > Any thoughts on this? Should we try to parse the alternate SCF convergence
> > info, or just change the code so it doesn't raise an exception?
> >
> > Adam
> >
> > On Mon, Feb 25, 2013 at 3:14 AM, msmqbm <ms...@ci...> wrote:
> >>
> >> Dear Adam,
> >>
> >> Thanks for your message. The reason for that strange output is the
> >> NormalPrint keyword, it has nothing to do with the MRCI (you can delete that
> >> part). Here I attach an output with a DFT calculation and a normalPrint
> >> keyword, so that you can see the source of the problem.
> >> It's ok if you make this input or output public.
> >>
> >> It would be nice that, even if the parser cannot read the whole file, it
> >> didn't raise an exception, so that one could get at least the geometry, the
> >> number of atoms or the information it has read so far.
> >>
> >> Cheers,
> >>
> >>
> >> On 02/25/2013 01:24 AM, Adam Tenderholt wrote:
> >>
> >> Hi Melchor,
> >>
> >> Sorry for the delay. I've finally looked into your parse error. The
> >> problem is the output from the SCF convergence. For instance, it your file,
> >> it is:
> >>
> >> --------------
> >> SCF ITERATIONS
> >> --------------
> >>                ***  Starting incremental Fock matrix formation  ***
> >>
> >>                          ----------------------------
> >>                          !        ITERATION     0   !
> >>                          ----------------------------
> >>    Total Energy        :    -377.995940441385 Eh
> >>    Energy Change       :    -377.995940441385 Eh
> >>    MAX-DP              :       0.104636203272
> >>    RMS-DP              :       0.004511416837
> >>    Actual Damping      :       0.7000
> >>    Actual Level Shift  :       0.2500 Eh
> >>    Int. Num. El.       :    43.99928165 (UP=   21.99964083 DN=
> >> 21.99964083)
> >>    Exchange            :   -34.30375363
> >>    Correlation         :    -2.02696332
> >>
> >>
> >>                          ----------------------------
> >>                          !        ITERATION     1   !
> >>                          ----------------------------
> >>    Total Energy        :    -378.158637308210 Eh
> >>    Energy Change       :      -0.162696866825 Eh
> >>    MAX-DP              :       0.056981704567
> >>    RMS-DP              :       0.002392614971
> >>    Actual Damping      :       0.7000
> >>    Actual Level Shift  :       0.2500 Eh
> >>    Int. Num. El.       :    43.99902992 (UP=   21.99951496 DN=
> >> 21.99951496)
> >>    Exchange            :   -34.01830967
> >>    Correlation         :    -2.01718102
> >>
> >> However, cclib is expecting the following:
> >>
> >> --------------
> >> SCF ITERATIONS
> >> --------------
> >> ITER       Energy         Delta-E        Max-DP      RMS-DP      [F,P]
> >> Damp
> >>                ***  Starting incremental Fock matrix formation  ***
> >>   0   -381.9867779344   0.000000000000 0.05707535  0.00425410  0.0807540
> >> 0.7000
> >>   1   -382.0079986969  -0.021220762511 0.02895905  0.00220039  0.0411442
> >> 0.7000
> >>
> >> I tried to make sense of your input file, but I don't have any experience
> >> with MRCI calculations with ORCA. Do you know if there was some option that
> >> caused the SCF convergence to be printed differently? Or is this how the
> >> convergence for all MRCI calculations is printed?
> >>
> >> Also, are you willing to place your logfile in the public domain? We would
> >> like to include it with our other regression files.
> >>
> >> Thanks,
> >>
> >> Adam
> >>
> >>
> >>
> >>
> >> On Thu, Feb 21, 2013 at 1:48 AM, msmqbm <ms...@ci...> wrote:
> >>>
> >>> Dear cclib developers,
> >>> When trying to parse an Orca 2.9.0 output file I get the following error:
> >>>
> >>> >>> import cclib
> >>> >>> f1= cclib.parser.ORCA("DAT6600.out")
> >>> >>> data1= f1.parse()
> >>> [ORCA DAT6600.out INFO] Creating attribute atomcoords[]
> >>> [ORCA DAT6600.out INFO] Creating attribute atomnos[]
> >>> [ORCA DAT6600.out INFO] Creating attribute natom: 9
> >>> [ORCA DAT6600.out INFO] Creating attribute nbasis: 90
> >>> [ORCA DAT6600.out INFO] Creating attribute charge: 0
> >>> [ORCA DAT6600.out INFO] Creating attribute mult: 1
> >>> [ORCA DAT6600.out INFO] Creating attribute scfvalues[]
> >>> Traceback (most recent call last):
> >>>   File "<stdin>", line 1, in <module>
> >>>   File "/usr/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
> >>> line 221, in parse
> >>>     self.extract(inputfile, line)
> >>>   File "/usr/lib/python2.7/dist-packages/cclib/parser/orcaparser.py",
> >>> line 90, in extract
> >>>     assert line[1] == "Energy"
> >>> AssertionError
> >>>
> >>> I'm using cclib version 1.1 (the latest one). I attach the file
> >>> DAT6600.out.
> >>>
> >>> Is there a solution to this?
> >>>
> >>> Thanks in advance,
> >>>
> >>> --
> >>> Melchor Sánchez
> >>> PhD candidate
> >>> Institute of Advanced Chemistry of Catalonia
> >>> http://www.iqac.csic.es/qteor
> >>> IQAC - CSIC
> >>> Tel. +34 934006100 ext: 1307
> >>> Jordi Girona 18-26
> >>> 08034 Barcelona (Spain)
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> Everyone hates slow websites. So do we.
> >>> Make your web apps faster with AppDynamics
> >>> Download AppDynamics Lite for free today:
> >>> http://p.sf.net/sfu/appdyn_d2d_feb
> >>> _______________________________________________
> >>> cclib-users mailing list
> >>> ccl...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/cclib-users
> >>>
> >>
> >>
> >>
> >> --
> >> Melchor Sánchez
> >> PhD candidate
> >> Institute of Advanced Chemistry of Catalonia
> >> http://www.iqac.csic.es/qteor
> >> IQAC - CSIC
> >> Tel. +34 934006100 ext: 1307
> >> Jordi Girona 18-26
> >> 08034 Barcelona (Spain)
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_feb
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

-- 
written by Karol M. Langner
Tue Feb 26 00:22:12 CET 2013

Re: [cclib-devel] [cclib-users] Orca 2.9.0 error

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

I'm all for parsing it. Since this is fairly GaussSum-specific I'm
happy to do it if you can make sure these files are public domain. In
the meanwhile, you can point out to the user that he can comment out
the offending code.

On 25 February 2013 17:31, Adam Tenderholt <ate...@gm...> wrote:
> CC: dev list
>
> Any thoughts on this? Should we try to parse the alternate SCF convergence
> info, or just change the code so it doesn't raise an exception?
>
> Adam
>
> On Mon, Feb 25, 2013 at 3:14 AM, msmqbm <ms...@ci...> wrote:
>>
>> Dear Adam,
>>
>> Thanks for your message. The reason for that strange output is the
>> NormalPrint keyword, it has nothing to do with the MRCI (you can delete that
>> part). Here I attach an output with a DFT calculation and a normalPrint
>> keyword, so that you can see the source of the problem.
>> It's ok if you make this input or output public.
>>
>> It would be nice that, even if the parser cannot read the whole file, it
>> didn't raise an exception, so that one could get at least the geometry, the
>> number of atoms or the information it has read so far.
>>
>> Cheers,
>>
>>
>> On 02/25/2013 01:24 AM, Adam Tenderholt wrote:
>>
>> Hi Melchor,
>>
>> Sorry for the delay. I've finally looked into your parse error. The
>> problem is the output from the SCF convergence. For instance, it your file,
>> it is:
>>
>> --------------
>> SCF ITERATIONS
>> --------------
>>                ***  Starting incremental Fock matrix formation  ***
>>
>>                          ----------------------------
>>                          !        ITERATION     0   !
>>                          ----------------------------
>>    Total Energy        :    -377.995940441385 Eh
>>    Energy Change       :    -377.995940441385 Eh
>>    MAX-DP              :       0.104636203272
>>    RMS-DP              :       0.004511416837
>>    Actual Damping      :       0.7000
>>    Actual Level Shift  :       0.2500 Eh
>>    Int. Num. El.       :    43.99928165 (UP=   21.99964083 DN=
>> 21.99964083)
>>    Exchange            :   -34.30375363
>>    Correlation         :    -2.02696332
>>
>>
>>                          ----------------------------
>>                          !        ITERATION     1   !
>>                          ----------------------------
>>    Total Energy        :    -378.158637308210 Eh
>>    Energy Change       :      -0.162696866825 Eh
>>    MAX-DP              :       0.056981704567
>>    RMS-DP              :       0.002392614971
>>    Actual Damping      :       0.7000
>>    Actual Level Shift  :       0.2500 Eh
>>    Int. Num. El.       :    43.99902992 (UP=   21.99951496 DN=
>> 21.99951496)
>>    Exchange            :   -34.01830967
>>    Correlation         :    -2.01718102
>>
>> However, cclib is expecting the following:
>>
>> --------------
>> SCF ITERATIONS
>> --------------
>> ITER       Energy         Delta-E        Max-DP      RMS-DP      [F,P]
>> Damp
>>                ***  Starting incremental Fock matrix formation  ***
>>   0   -381.9867779344   0.000000000000 0.05707535  0.00425410  0.0807540
>> 0.7000
>>   1   -382.0079986969  -0.021220762511 0.02895905  0.00220039  0.0411442
>> 0.7000
>>
>> I tried to make sense of your input file, but I don't have any experience
>> with MRCI calculations with ORCA. Do you know if there was some option that
>> caused the SCF convergence to be printed differently? Or is this how the
>> convergence for all MRCI calculations is printed?
>>
>> Also, are you willing to place your logfile in the public domain? We would
>> like to include it with our other regression files.
>>
>> Thanks,
>>
>> Adam
>>
>>
>>
>>
>> On Thu, Feb 21, 2013 at 1:48 AM, msmqbm <ms...@ci...> wrote:
>>>
>>> Dear cclib developers,
>>> When trying to parse an Orca 2.9.0 output file I get the following error:
>>>
>>> >>> import cclib
>>> >>> f1= cclib.parser.ORCA("DAT6600.out")
>>> >>> data1= f1.parse()
>>> [ORCA DAT6600.out INFO] Creating attribute atomcoords[]
>>> [ORCA DAT6600.out INFO] Creating attribute atomnos[]
>>> [ORCA DAT6600.out INFO] Creating attribute natom: 9
>>> [ORCA DAT6600.out INFO] Creating attribute nbasis: 90
>>> [ORCA DAT6600.out INFO] Creating attribute charge: 0
>>> [ORCA DAT6600.out INFO] Creating attribute mult: 1
>>> [ORCA DAT6600.out INFO] Creating attribute scfvalues[]
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "/usr/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
>>> line 221, in parse
>>>     self.extract(inputfile, line)
>>>   File "/usr/lib/python2.7/dist-packages/cclib/parser/orcaparser.py",
>>> line 90, in extract
>>>     assert line[1] == "Energy"
>>> AssertionError
>>>
>>> I'm using cclib version 1.1 (the latest one). I attach the file
>>> DAT6600.out.
>>>
>>> Is there a solution to this?
>>>
>>> Thanks in advance,
>>>
>>> --
>>> Melchor Sánchez
>>> PhD candidate
>>> Institute of Advanced Chemistry of Catalonia
>>> http://www.iqac.csic.es/qteor
>>> IQAC - CSIC
>>> Tel. +34 934006100 ext: 1307
>>> Jordi Girona 18-26
>>> 08034 Barcelona (Spain)
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>> _______________________________________________
>>> cclib-users mailing list
>>> ccl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cclib-users
>>>
>>
>>
>>
>> --
>> Melchor Sánchez
>> PhD candidate
>> Institute of Advanced Chemistry of Catalonia
>> http://www.iqac.csic.es/qteor
>> IQAC - CSIC
>> Tel. +34 934006100 ext: 1307
>> Jordi Girona 18-26
>> 08034 Barcelona (Spain)
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] [cclib-users] Orca 2.9.0 error

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

CC: dev list

Any thoughts on this? Should we try to parse the alternate SCF convergence
info, or just change the code so it doesn't raise an exception?

Adam

On Mon, Feb 25, 2013 at 3:14 AM, msmqbm <ms...@ci...> wrote:

>  Dear Adam,
>
> Thanks for your message. The reason for that strange output is the
> NormalPrint keyword, it has nothing to do with the MRCI (you can delete
> that part). Here I attach an output with a DFT calculation and a
> normalPrint keyword, so that you can see the source of the problem.
> It's ok if you make this input or output public.
>
> It would be nice that, even if the parser cannot read the whole file, it
> didn't raise an exception, so that one could get at least the geometry, the
> number of atoms or the information it has read so far.
>
> Cheers,
>
>
> On 02/25/2013 01:24 AM, Adam Tenderholt wrote:
>
> Hi Melchor,
>
>  Sorry for the delay. I've finally looked into your parse error. The
> problem is the output from the SCF convergence. For instance, it your file,
> it is:
>
>  --------------
> SCF ITERATIONS
> --------------
>                ***  Starting incremental Fock matrix formation  ***
>
>                           ----------------------------
>                          !        ITERATION     0   !
>                          ----------------------------
>    Total Energy        :    -377.995940441385 Eh
>    Energy Change       :    -377.995940441385 Eh
>    MAX-DP              :       0.104636203272
>    RMS-DP              :       0.004511416837
>    Actual Damping      :       0.7000
>    Actual Level Shift  :       0.2500 Eh
>    Int. Num. El.       :    43.99928165 (UP=   21.99964083 DN=
> 21.99964083)
>    Exchange            :   -34.30375363
>    Correlation         :    -2.02696332
>
>
>                           ----------------------------
>                          !        ITERATION     1   !
>                          ----------------------------
>    Total Energy        :    -378.158637308210 Eh
>    Energy Change       :      -0.162696866825 Eh
>    MAX-DP              :       0.056981704567
>    RMS-DP              :       0.002392614971
>    Actual Damping      :       0.7000
>    Actual Level Shift  :       0.2500 Eh
>    Int. Num. El.       :    43.99902992 (UP=   21.99951496 DN=
> 21.99951496)
>    Exchange            :   -34.01830967
>    Correlation         :    -2.01718102
>
>  However, cclib is expecting the following:
>
>  --------------
> SCF ITERATIONS
> --------------
> ITER       Energy         Delta-E        Max-DP      RMS-DP      [F,P]
> Damp
>                ***  Starting incremental Fock matrix formation  ***
>   0   -381.9867779344   0.000000000000 0.05707535  0.00425410  0.0807540
> 0.7000
>   1   -382.0079986969  -0.021220762511 0.02895905  0.00220039  0.0411442
> 0.7000
>
>  I tried to make sense of your input file, but I don't have any
> experience with MRCI calculations with ORCA. Do you know if there was some
> option that caused the SCF convergence to be printed differently? Or is
> this how the convergence for all MRCI calculations is printed?
>
>  Also, are you willing to place your logfile in the public domain? We
> would like to include it with our other regression files.
>
>  Thanks,
>
>  Adam
>
>
>
>
> On Thu, Feb 21, 2013 at 1:48 AM, msmqbm <ms...@ci...> wrote:
>
>> Dear cclib developers,
>> When trying to parse an Orca 2.9.0 output file I get the following error:
>>
>> >>> import cclib
>> >>> f1= cclib.parser.ORCA("DAT6600.out")
>> >>> data1= f1.parse()
>> [ORCA DAT6600.out INFO] Creating attribute atomcoords[]
>> [ORCA DAT6600.out INFO] Creating attribute atomnos[]
>> [ORCA DAT6600.out INFO] Creating attribute natom: 9
>> [ORCA DAT6600.out INFO] Creating attribute nbasis: 90
>> [ORCA DAT6600.out INFO] Creating attribute charge: 0
>> [ORCA DAT6600.out INFO] Creating attribute mult: 1
>> [ORCA DAT6600.out INFO] Creating attribute scfvalues[]
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "/usr/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
>> line 221, in parse
>>     self.extract(inputfile, line)
>>   File "/usr/lib/python2.7/dist-packages/cclib/parser/orcaparser.py",
>> line 90, in extract
>>     assert line[1] == "Energy"
>> AssertionError
>>
>> I'm using cclib version 1.1 (the latest one). I attach the file
>> DAT6600.out.
>>
>> Is there a solution to this?
>>
>> Thanks in advance,
>>
>> --
>> Melchor Sánchez
>> PhD candidate
>> Institute of Advanced Chemistry of Catalonia
>> http://www.iqac.csic.es/qteor
>> IQAC - CSIC
>> Tel. +34 934006100 ext: 1307 <%2B34%20934006100%20ext%3A%201307>
>> Jordi Girona 18-26
>> 08034 Barcelona (Spain)
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> cclib-users mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-users
>>
>>
>
>
> --
> Melchor Sánchez
> PhD candidate
> Institute of Advanced Chemistry of Cataloniahttp://www.iqac.csic.es/qteor
> IQAC - CSIC
> Tel. +34 934006100 ext: 1307
> Jordi Girona 18-26
> 08034 Barcelona (Spain)
>
>

Re: [cclib-devel] cclib 1.1 staged release

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

That seems to have worked nicely. Good for Sourceforge!

On Feb 10 2013, Noel O'Boyle wrote:
> Hey there,
> 
> cclib-1.1 has been released using SF's staged releases. In three days
> it goes live for everyone, but before that the devs can download it
> from the usual place.
> 
> Assuming all's well, I'll update the wiki the next few days.
> 
> - Noel

-- 
written by Karol M. Langner
Mon Feb 18 02:40:37 CET 2013

Re: [cclib-devel] cclib included in the Softpedia software database

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

Dear Softpedia,

Could you add a link to the homepage for the software at http:/cclib.sf.net.

Regards,
- Noel

On 17 February 2013 18:48, Karol M. Langner <km...@mm...> wrote:
> Hello,
>
> This is more appropriate for the cclib mailing list. Forwarding.
>
> Karol Langner
>
> On Feb 15 2013, Softpedia Editorial Team wrote:
>> Hello,
>>
>> As you may already know, cclib, one of your products, is part of
>> Softpedia's database of software programs for the Windows operating system.
>> It is featured with a description text, screenshots, download links and
>> technical details on this page:
>> http://www.softpedia.com/get/Programming/Components-Libraries/cclib.shtml
>>
>> The description text was created by our editors, using sources such as text
>> from your product's homepage, information from its help system, the PAD
>> file (if available) and the editor's own opinions on the program itself.
>>
>>
>>
>>
>>
>> Your developer page on Softpedia can be reached at the URL below. It
>> contains the list of software products and a link to your website.
>> http://www.softpedia.com/developer/cclib-Development-Team-91384.html
>>
>> If you feel that having your product listed on Softpedia is not a benefit
>> for you or simply need something changed or updated, please contact us via
>> email at web...@so... and we will work with you to fix any
>> problem you may have found with the product's listing.
>>
>> --
>> Sincerely,
>> The Softpedia Team
>>
>> -----------------------------------------------------------------------
>> Softpedia is a library of over 1 million free and free-to-try software
>> programs for Windows, Mac OS and Linux, games and gaming tools, Windows
>> device drivers, mobile devices and IT-related articles.
>> -----------------------------------------------------------------------
>> Softpedia - the encyclopedia of free software downloads
>> http://www.softpedia.com/
>>
>
> --
> written by Karol M. Langner
> Sun Feb 17 19:46:59 CET 2013
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] cclib included in the Softpedia software database

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

Hello,

This is more appropriate for the cclib mailing list. Forwarding.

Karol Langner

On Feb 15 2013, Softpedia Editorial Team wrote:
> Hello,
> 
> As you may already know, cclib, one of your products, is part of
> Softpedia's database of software programs for the Windows operating system.
> It is featured with a description text, screenshots, download links and
> technical details on this page:
> http://www.softpedia.com/get/Programming/Components-Libraries/cclib.shtml
> 
> The description text was created by our editors, using sources such as text
> from your product's homepage, information from its help system, the PAD
> file (if available) and the editor's own opinions on the program itself.
> 
> 
> 
> 
> 
> Your developer page on Softpedia can be reached at the URL below. It
> contains the list of software products and a link to your website.
> http://www.softpedia.com/developer/cclib-Development-Team-91384.html 
> 
> If you feel that having your product listed on Softpedia is not a benefit
> for you or simply need something changed or updated, please contact us via
> email at web...@so... and we will work with you to fix any
> problem you may have found with the product's listing.
> 
> -- 
> Sincerely,
> The Softpedia Team
> 
> -----------------------------------------------------------------------
> Softpedia is a library of over 1 million free and free-to-try software
> programs for Windows, Mac OS and Linux, games and gaming tools, Windows
> device drivers, mobile devices and IT-related articles.
> -----------------------------------------------------------------------
> Softpedia - the encyclopedia of free software downloads
> http://www.softpedia.com/
> 

-- 
written by Karol M. Langner
Sun Feb 17 19:46:59 CET 2013

[cclib-devel] cclib 1.1 is released

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

Hello all,

cclib 1.1 is now available for download from http://cclib.sf.net (or
directly at https://sourceforge.net/projects/cclib/files/cclib/cclib-1.1/).
This contains a number of new features as well as several improvements
to the parsers. All users are recommended to upgrade to version 1.1.

Note that this will be the last release in the Python 2 series, as we
plan to move to Python 3.

Changes since cclib-1.0.1:

Features:
    * Add progress info for all parsers
    * Support ONIOM calculations in Gaussian (Karen Hemelsoet)
    * New attribute atomcharges extracts Mulliken and Lowdin atomic
    charges if present
    * New attribute atomspins extracts Mulliken and Lowdin atomic spin
    densities if present
    * New thermodynamic attributes: freeenergy, temperature, enthalpy
    (Edward Holland)
    * Extract PES information: scanenergies, scancoords, scanparm,
scannames (Edward Holland)

Bugfixes:
    * Handle coupled cluster energies in Gaussian 09 (Björn Dahlgren)
    * Vibrational displacement vectors missing for Gaussian 09 (Björn
    Dahlgren)
    * Fix problem parsing vibrational frequencies in some GAMESS-US files
    * Fix missing final scfenergy in ADF geometry optimisations
    * Fix missing final scfenergy for ORCA where a specific number of SCF
    cycles has been specified
    * ORCA scfenergies not parsed if COSMO solvent effects included
    * Allow spin unrestricted calculations to use the fragment MO overlaps
    correctly for the MPA and CDA calculations
    * Handle Gaussian MO energies that are printed as a row of asterisks
    (Jerome Kieffer)
    * Add more explicit license notices, and allow LGPL versions after 2.1
    * Support Firefly calculations where nmo != nbasis (Pavel Solntsev)
    * Fix problem parsing vibrational frequency information in recent
    GAMESS (US) files (Chengju Wang)
    * Apply patch from Chengju Wang to handle GAMESS calculations with more
    than 99 atoms
    * Handle Gaussian files with more than 99 atoms having pseudopotentials
    (Björn Baumeier)

Regards,
   Noel, Adam, Karol

[cclib-devel] cclib 1.1 staged release

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

Hey there,

cclib-1.1 has been released using SF's staged releases. In three days
it goes live for everyone, but before that the devs can download it
from the usual place.

Assuming all's well, I'll update the wiki the next few days.

- Noel

Re: [cclib-devel] C bridge and changes to the progress updater

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

On 9 February 2013 20:06, Adam Tenderholt <ate...@gm...> wrote:
>> The issue is just the fact that the API is changing in a way that is
>>
>> not backwards compatible. If software that previously worked with
>> cclib will now fail to work, we need to renumber the release to 2.x. I
>> know that it may only require a small change to the user's code, but
>> the API numbering is an implicit contract with the user, and it's
>> understood as such by users and the Linux distros. If you can figure
>> out a way that preserves the old behaviour while extending it to the
>> new improved way, then it's not a problem and can go in trunk and into
>> the next release. But to be honest, we can do a 2.x in the next few
>> months, I'm not suggesting postponing it indefinitely.
>
>
> I forgot that it's a bad idea to break backwards compatibility with a point
> release. I'll commit those changes to another branch. Somewhat related: I
> noticed that there is still a Qt3 progress class. I have no idea if it still
> works since I moved to Qt4 years ago. Do you think it should be removed now?
> Or wait until 2.x?

Well, I guess it might as well wait under 2.x. But you could do it on
the branch and I'll merge it after release.

>>
>> Another thing I was wondering about is whether your C code is going to
>> be specific to Python 2? It would be nice to start targeting Python 3.
>> I know I've mentioned this before, but I really think we need to get
>> onto Python 3 at this point, and it might be better to make the change
>> now (i.e. right after the release) if you are going to be writing C
>> code. The Python 3 branch in svn is in good shape, if a year or so out
>> of date, but it wouldn't take me long to sort it out.
>
>
> I think the bulk of the C API is fairly similar, although there are likely
> some minor changes necessary (e.g. int becomes long, string becomes
> unicode/bytes). Since your focus is probably to get the 1.1 release out, and
> then make sure the Python3 branch is up to date, I'll probably continue on
> the Python2 C functions and port to Python3 once we're more ready.

Ok, dok.

> Any idea of a timeframe for the 1.1 release?

Tomorrow is good for me, unless anyone objects. All I really need to
do now is package it up.

- Noel

Re: [cclib-devel] C bridge and changes to the progress updater

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

On 9 February 2013 16:53, Adam Tenderholt <ate...@gm...> wrote:
> And here I thought when you extended Avogadro to parse a file with cclib,
> Avogadro had a python interpreter built in.

That's a good point. :-) I guess I thought it just happened by magic.

> It's actually calling the system
> Python and its installed packages? Well, it's possible to actually imbed an
> interpreter, load modules, and play around with Python objects
> (http://docs.python.org/2/extending/embedding.html). The API has a bit of a
> learning curve, so I figure if cclib provided functions that took care of
> most use cases, others might find it useful.
>
> The C-functions don't really impact the Python source (except for the
> callback function changes I've already made). But since I'm still working on
> the C-functions, I'm ok with those going into a separate branch (or the
> website).
>
> As far as the callback changes I've made, do you also want those in a
> separate branch? Or can they go in trunk for the 1.1 release? It involved
> only a handful of changes to logfileparser.py and the progress classes, and
> I think it's ready to go out with the next release.

The issue is just the fact that the API is changing in a way that is
not backwards compatible. If software that previously worked with
cclib will now fail to work, we need to renumber the release to 2.x. I
know that it may only require a small change to the user's code, but
the API numbering is an implicit contract with the user, and it's
understood as such by users and the Linux distros. If you can figure
out a way that preserves the old behaviour while extending it to the
new improved way, then it's not a problem and can go in trunk and into
the next release. But to be honest, we can do a 2.x in the next few
months, I'm not suggesting postponing it indefinitely.

Another thing I was wondering about is whether your C code is going to
be specific to Python 2? It would be nice to start targeting Python 3.
I know I've mentioned this before, but I really think we need to get
onto Python 3 at this point, and it might be better to make the change
now (i.e. right after the release) if you are going to be writing C
code. The Python 3 branch in svn is in good shape, if a year or so out
of date, but it wouldn't take me long to sort it out.

- Noel

Re: [cclib-devel] C bridge and changes to the progress updater

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

And here I thought when you extended Avogadro to parse a file with cclib,
Avogadro had a python interpreter built in. It's actually calling the
system Python and its installed packages? Well, it's possible to actually
imbed an interpreter, load modules, and play around with Python objects (
http://docs.python.org/2/extending/embedding.html). The API has a bit of a
learning curve, so I figure if cclib provided functions that took care of
most use cases, others might find it useful.

The C-functions don't really impact the Python source (except for the
callback function changes I've already made). But since I'm still working
on the C-functions, I'm ok with those going into a separate branch (or the
website).

As far as the callback changes I've made, do you also want those in a
separate branch? Or can they go in trunk for the 1.1 release? It involved
only a handful of changes to logfileparser.py and the progress classes, and
I think it's ready to go out with the next release. The changes also make
implementing custom progress classes more flexible since instead of needing
both (and exactly) initialize and update functions, it only needs a
function (with any name) that expects a number and text.

Adam


On Sat, Feb 9, 2013 at 12:54 AM, Noel O'Boyle <bao...@gm...> wrote:

> I've never heard of calling a Python library from C++, but sounds very
> interesting. Regarding the API change, that will need a cclib 2.0. I
> have no particular objection to this if necessary but you should
> probably check this into a branch while I get out this release. Unless
> there's a way to support the existing behaviour while adding the new
> one.
>
> - Noel
>
> On 9 February 2013 07:32, Adam Tenderholt <ate...@gm...> wrote:
> > Hi all,
> >
> > I've been thinking about how to make cclib a bit more friendly towards
> > non-Python developers/users. Specifically, those that wish to incorporate
> > cclib into their existing C/C++/Obj-C codebases, but don't want to deal
> with
> > getting into too much of the mess that is the Python C-API or have the
> > overhead of Boost (which is C++) or others. I propose creating a handful
> of
> > C functions that handle most of the nitty-gritty of this.
> >
> > For instance, I envision a simple #include "cclib.h" with functions like
> > getParserModule() and ccopen(), to return the cclib.parser module and a
> > logfileparser object. I've already begun the implementation of these
> > functions. There may still need to be some calls to the Python C-API, but
> > this bridge should be as simple as possible. Seem reasonable? Or have a
> > better suggestion?
> >
> > Also, related to this is a minor required change to the progress part of
> > logfileparser API. Since I want this to be rooted in C, it should not be
> > dependent on classes. So instead of passing a progress object to the
> > initializer, a callback function should be passed. I've already made
> these
> > changes (uncommitted to SVN though) and updated the TextProgress and
> > Qt4Progress classes by passing their update functions to the
> logfileparser.
> >
> > Cheers,
> >
> > Adam
> >
> >
> >
> ------------------------------------------------------------------------------
> > Free Next-Gen Firewall Hardware Offer
> > Buy your Sophos next-gen firewall before the end March 2013
> > and get the hardware for free! Learn more.
> > http://p.sf.net/sfu/sophos-d2d-feb
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
>

Re: [cclib-devel] C bridge and changes to the progress updater

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

I've never heard of calling a Python library from C++, but sounds very
interesting. Regarding the API change, that will need a cclib 2.0. I
have no particular objection to this if necessary but you should
probably check this into a branch while I get out this release. Unless
there's a way to support the existing behaviour while adding the new
one.

- Noel

On 9 February 2013 07:32, Adam Tenderholt <ate...@gm...> wrote:
> Hi all,
>
> I've been thinking about how to make cclib a bit more friendly towards
> non-Python developers/users. Specifically, those that wish to incorporate
> cclib into their existing C/C++/Obj-C codebases, but don't want to deal with
> getting into too much of the mess that is the Python C-API or have the
> overhead of Boost (which is C++) or others. I propose creating a handful of
> C functions that handle most of the nitty-gritty of this.
>
> For instance, I envision a simple #include "cclib.h" with functions like
> getParserModule() and ccopen(), to return the cclib.parser module and a
> logfileparser object. I've already begun the implementation of these
> functions. There may still need to be some calls to the Python C-API, but
> this bridge should be as simple as possible. Seem reasonable? Or have a
> better suggestion?
>
> Also, related to this is a minor required change to the progress part of
> logfileparser API. Since I want this to be rooted in C, it should not be
> dependent on classes. So instead of passing a progress object to the
> initializer, a callback function should be passed. I've already made these
> changes (uncommitted to SVN though) and updated the TextProgress and
> Qt4Progress classes by passing their update functions to the logfileparser.
>
> Cheers,
>
> Adam
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] C bridge and changes to the progress updater

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

Hi all,

I've been thinking about how to make cclib a bit more friendly towards
non-Python developers/users. Specifically, those that wish to incorporate
cclib into their existing C/C++/Obj-C codebases, but don't want to deal
with getting into too much of the mess that is the Python C-API or have the
overhead of Boost (which is C++) or others. I propose creating a handful of
C functions that handle most of the nitty-gritty of this.

For instance, I envision a simple #include "cclib.h" with functions like
getParserModule() and ccopen(), to return the cclib.parser module and a
logfileparser object. I've already begun the implementation of these
functions. There may still need to be some calls to the Python C-API, but
this bridge should be as simple as possible. Seem reasonable? Or have a
better suggestion?

Also, related to this is a minor required change to the progress part of
logfileparser API. Since I want this to be rooted in C, it should not be
dependent on classes. So instead of passing a progress object to the
initializer, a callback function should be passed. I've already made these
changes (uncommitted to SVN though) and updated the TextProgress and
Qt4Progress classes by passing their update functions to the logfileparser.

Cheers,

Adam

[cclib-devel] New release?

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

Hey everyone,

I was thinking about getting out a release. It's high time. There's a
couple of patches that users supplied in the last year, but I know
that if I delay to include them, the release will be pushed back a few
months.

So I suggest a release now. Then try to integrate the patches, and
release again.

Any thoughts?

- Noel

Re: [cclib-devel] cclib bugfix

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

Fixed in SVN. Thanks for reporting.

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

[cclib-devel] Using Link for Gaussian parsers

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

Hi there,

I just noticed two cases of testing for "Leaving Link XXX" in the
Gaussian parser. Just to note that we should avoid this as the "Link"
statement is not present unless the user specified "#P", as far as I
know.

I'm removing one of them in the course of fixing a bug of Bjorn's...

- Noel

Re: [cclib-devel] possible cclib bug/undefined behaviour

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

I have just checked this with the development version and it seems to
be fine; that is, with the attached logfile, I see 36 vibfreqs not 72.

- Noel

On 9 October 2012 14:55, Björn Dahlgren <bd...@kt...> wrote:
> Dear all,
>
> I just wanted to raise the question if the following is a desired behaviour:
>
> parsing a combined Gaussian `opt=(calcall) freq` job logfile yields spurious
> copies of frequencies from optimization in `vibfreqs`.
>
> I attach a zipped logfile to illustrate the problem. i.e. this 14 atom
> structure have 72 vibfreqs (!) instead of 36...
>
> Cheers,
> /Björn
>

Re: [cclib-devel] cclib bug parsing Gaussian 09 frequency job output

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

Fixed as you suggested in revision 1024. No need for the test case
(but thanks!), as we had examples already in the suite. The problem
was a change in the format between Gaussian 03 and Gaussian 09.

- Noel

On 7 January 2013 13:49, Björn Dahlgren <bd...@kt...> wrote:
> Dear all,
>
> in the latest version of cclib there is a bug in gaussianparser.py (line 772
> in svn revision 1021) for assigning vibdisps:
>
> if line[1:29] == "Atom AN      X      Y      Z":
>
> where the line in attached h2o_freq.log looks like:
>
>   Atom  AN      X      Y      Z        X      Y      Z        X      Y
> Z
>
> That is 2 spaces + 'Atom' + 2 spaces + 'AN' etc.
> This causes cclib not to assign vibdisps for this freqency job.
>
> Changing the line with the if statement into:
>
>                  if line.strip().split()[:5] == ['Atom', 'AN', 'X', 'Y',
> 'Z']:
>
> Makes it less sensitive to varying spaces.
>
> Best regards,
> Björn Dahlgren
>
> P.S. you may of course include attached log file into test-suite and make it
> public
>
> On Tue, Oct 9, 2012 at 1:59 PM, Björn Dahlgren <bd...@kt...> wrote:
>>
>> Dear all,
>>
>> I just wanted to raise the question if the following is a desired
>> behaviour:
>>
>> parsing a combined Gaussian `opt=(calcall) freq` job logfile yields
>> spurious copies of frequencies from optimization in `vibfreqs`.
>>
>> I attach a logfile to illustrate the problem. i.e. this 14 atom structure
>> have 72 vibfreqs (!) instead of 36...
>>
>> Cheers,
>> /Björn
>>
>

Re: [cclib-devel] [cclib-users] Extract Mulliken atomic charges and spin densities

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

Done.

On 8 October 2012 18:56, Adam Tenderholt <ate...@gm...> wrote:
> I've added a regression test for Gaussian 09 Lowdin charges (dvb_lowdin).
> The logfile should be wget-able, and the regression file currently fails
> because it can't find lowdin in atomcharges (but can find mulliken).
>
>
> On Mon, Oct 8, 2012 at 9:14 AM, Karol M. Langner <kar...@gm...>
> wrote:
>>
>> Sure, if you can spare the time, add them as a regression or replace the
>> current unit test.
>>
>> - Karol
>>
>> P.S. I also took a stab at updating the wiki for atomcharges/atomspins,
>> but in the end it would be good to generate some of the wiki (parsed data
>> tables) automatically.
>>
>> On Oct 08 2012, Adam Tenderholt wrote:
>> > Hi Karol,
>> >
>> > Thanks for working on these attributes. Looks like you covered the big
>> > five
>> > (Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for
>> > Gaussian that causes Lowdin charges to be printed. Want me to try this?
>> >
>> > Adam
>> >
>> >
>> > On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner
>> > <kar...@gm...>wrote:
>> >
>> > > On Oct 06 2012, Karol M. Langner wrote:
>> > > > On Oct 05 2012, Noel O'Boyle wrote:
>> > > > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...>
>> > > wrote:
>> > > > > > Copying to cclib-dev instead of cclib-users...
>> > > > > >
>> > > > > >> So, Noel, Adam... what do you think? We can't have na attribute
>> > > > > >> for
>> > > > > >> every type of population analysis parsed. I see two options:
>> > > > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
>> > > > > >> 2) use a list of tuples consisting of a string and an array of
>> > > charges
>> > > > > >
>> > > > > >
>> > > > > > I agree that it's bad form to have to deal with all permutations
>> > > > > > of
>> > > > > > attributes like mulliken_charges, loewdin_charges, etc, so it's
>> > > > > > best
>> > > to have
>> > > > > > just have charges and densities attributes.
>> > > > > >
>> > > > > > I think dictionaries are more elegant than a list of tuples. For
>> > > example,
>> > > > > > getting the Mulliken charges is simply charges["Mulliken"]
>> > > > > > instead
>> > > of having
>> > > > > > to iterate over the elements in a charges list looking for
>> > > "Mulliken" in
>> > > > > > tuple[0].
>> > > > >
>> > > > > +1
>> > > >
>> > > > I just implemented this in recent commits, for several parsers and
>> > > > Mulliken/Lowdin charges where they are printed. In some cases
>> > > > (Molpro
>> > > > and Jaguar) I could not find them and I think some flag in the input
>> > > > would need to be turned on in order to print them. I don't think I
>> > > > will
>> > > > update the data files and parsers for that unless somebody asks,
>> > > > though.
>> > > >
>> > > > The attribute is called atomcharges and I added unit tests for their
>> > > > length (should equal natom) and sum (should be zero for the unit
>> > > > tests).
>> > > >
>> > > > As far as spin densities are concerned, this is also easily done --
>> > > > should we call the corresponding attribute atomspins?
>> > >
>> > > I went ahead and implemented this for ORCA, too. If you guys think a
>> > > different attribute name will better, jsut change it. Implementing
>> > > this
>> > > for other parsers will require updating output files to have spin
>> > > densities. I might do that for GAMESS and one more sometime in the
>> > > future, but I suppose the rest will be upon request.
>> > >
>> > > - Karol
>> > >
>> > > --
>> > > written by Karol M. Langner
>> > > Sat Oct  6 20:32:38 CEST 2012
>> > >
>>
>> --
>> written by Karol M. Langner
>> Mon Oct  8 18:13:15 CEST 2012
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] cclib bug parsing Gaussian 09 frequency job output

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

Thanks Björn. I'm getting back into some cclib development and have
made a note to look into this.

- Noel

On 7 January 2013 13:49, Björn Dahlgren <bd...@kt...> wrote:
> Dear all,
>
> in the latest version of cclib there is a bug in gaussianparser.py (line 772
> in svn revision 1021) for assigning vibdisps:
>
> if line[1:29] == "Atom AN      X      Y      Z":
>
> where the line in attached h2o_freq.log looks like:
>
>   Atom  AN      X      Y      Z        X      Y      Z        X      Y
> Z
>
> That is 2 spaces + 'Atom' + 2 spaces + 'AN' etc.
> This causes cclib not to assign vibdisps for this freqency job.
>
> Changing the line with the if statement into:
>
>                  if line.strip().split()[:5] == ['Atom', 'AN', 'X', 'Y',
> 'Z']:
>
> Makes it less sensitive to varying spaces.
>
> Best regards,
> Björn Dahlgren
>
> P.S. you may of course include attached log file into test-suite and make it
> public
>
> On Tue, Oct 9, 2012 at 1:59 PM, Björn Dahlgren <bd...@kt...> wrote:
>>
>> Dear all,
>>
>> I just wanted to raise the question if the following is a desired
>> behaviour:
>>
>> parsing a combined Gaussian `opt=(calcall) freq` job logfile yields
>> spurious copies of frequencies from optimization in `vibfreqs`.
>>
>> I attach a logfile to illustrate the problem. i.e. this 14 atom structure
>> have 72 vibfreqs (!) instead of 36...
>>
>> Cheers,
>> /Björn
>>
>

[cclib-devel] Reminder re new subversion

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

Hi there,

Just to remind you that it's a waste of time to commit to the old
subversion (as far as I understand). If you commit by accident, just
re-commit to the new one.

Details of the new one can be found on the project page.

- Noel

[cclib-devel] Fwd: SourceForge Repo Clone Complete

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

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

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


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

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

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

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

Re: [cclib-devel] GAMESS-US 2012

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

Forgot to attach the output. Here it is.

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

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