cclib-devel — Developer's mailing list

Re: [cclib-devel] Python 3 port

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

Trunk is now Python3. The old Python2 trunk is at branches/python2,
but please don't commit anything there.

The tests pass as before...at least the regression tests. There may
well be errors though so keep an eye out for anything fishy.

- Noel

On 28 February 2013 16:16, Noel O'Boyle <bao...@gm...> wrote:
> 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

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