cclib-devel — Developer's mailing list

[cclib-devel] Mediawiki and equations/images

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

(Regarding instant message question from Karol)

Mediawiki on sourceforge is a pain to set up. I was happy to get it
working in the first place (after several attempts).

OpenBabel have both images and equations working: see for example,
http://openbabel.sourceforge.net/wiki/OBForceFieldGhemical

I am not really interested in spending more time on configuring
Mediawiki, especially as I am worried about losing all of the wiki
data. Feel free to experiment yourself if you feel confident, although
let me know if you are trying something major so that I can export the
database.

P.S. I haven't yet checked the exportwiki python script. It did work;
the problem may be due to categories, which weren't present when I
wrote the script.

Regards,
   Noel

Re: [cclib-devel] etenergies

[Karol L. <kar...@kn...>]

On Tuesday 06 of March 2007 10:46, you wrote:
> > > I think you can guess I'm not really keen on this. 'implicit' vs.
> > > 'explicit' and so on. Can you think of a 'use case' where this has an
> > > advantage? If the result is always treated in the same way by a
> > > particular algorithm (e.g. convoluting the UV spectrum is the same no
> > > matter what the origin of the data), I think that specialising the
> > > data just makes things more difficult. I know that TD-DFT is much
> > > different than CI, but I'd be worried about going down that route in
> > > general. For example, isn't optimising in internal coordinates
> > > different than optimising in cartesian coordinates? OK, it's not so
> > > different as TD-DFT vs CI, so maybe you're right! :-)

In the trunk, etenergies is now parsed for CIS output from Gaussian and 
GAMESS. Now, the GAMESS parser doesn't parse TD-DFT/HF... so should there be 
a checkmark in the appropriate box in the 'Parsed data' table? This is not 
meant to be an argument for the implicit/explicit discussion (I am for 
keeping just etenergies), just a note that we need to clear out some policies 
for ambiguous attributes (used for various kinds of output).

Karol

-- 
written by Karol Langner
Wed Mar 14 22:02:18 CET 2007

Re: [cclib-devel] etenergies

[Karol L. <kar...@kn...>]

On Tuesday 06 of March 2007 10:46, Noel O'Boyle wrote:
> > > > On a related note, I'm in favor of parsing output in a way that makes
> > > > it clear what kind of calcualtion was done. In the case of
> > > > etenergies, the values can come from TD-HF, CI, or any other excited
> > > > state method - perhaps a string attribute such as "etmethod" could
> > > > label this . The same point for scfenergies, which can contain
> > > > energies from HF, DFT, or whatever, an "scfmethod" attribute mmight
> > > > be useful. Just an idea.
> > >
> > > I think you can guess I'm not really keen on this. 'implicit' vs.
> > > 'explicit' and so on. Can you think of a 'use case' where this has an
> > > advantage? If the result is always treated in the same way by a
> > > particular algorithm (e.g. convoluting the UV spectrum is the same no
> > > matter what the origin of the data), I think that specialising the
> > > data just makes things more difficult. I know that TD-DFT is much
> > > different than CI, but I'd be worried about going down that route in
> > > general. For example, isn't optimising in internal coordinates
> > > different than optimising in cartesian coordinates? OK, it's not so
> > > different as TD-DFT vs CI, so maybe you're right! :-)
> >
> > Yeah, optimizing in cartesian and internal coordinates is mathematically
> > equivalent, the result should be the same :)  but you're right, cclib
> > can't account for the "correctness" of the method used. As long as the
> > values are supposed to describe the same thing, we should treat it the
> > same way. If something specific for CI will be parsed, then there will be
> > a ci<somethinf> attribute.
>
> They call this duck-typing in Python; if it walks like a duck, and
> quacks like a duck, then it *is* a duck (or at least we can treat it
> like a duck).

Thought I might mention, that the Gaussian parser nicely parses CI jobs 
presently, at least the one test I uploaded so far.

Karol

-- 
written by Karol Langner
Wed Mar 14 21:27:23 CET 2007

[cclib-devel] downloadwiki.py

[Karol L. <kar...@kn...>]

I can't seem to use the script downloadwiki.py. After installing 
BesutifulSoup, I get the following error:

langner@slim:~/tmp/python/cclib/trunk$ python2.3 downloadwiki.py 
Traceback (most recent call last):
  File "downloadwiki.py", line 8, in ?
    soup = BeautifulSoup(allpages)
  File "/usr/lib/python2.3/site-packages/BeautifulSoup.py", line 307, in 
__init__
    self.feed(text)
  File "/usr/lib/python2.3/site-packages/BeautifulSoup.py", line 310, in feed
    SGMLParser.feed(self, text)
  File "/usr/lib/python2.3/sgmllib.py", line 94, in feed
    self.rawdata = self.rawdata + data
TypeError: cannot concatenate 'str' and 'instance' objects

Does the script actually work?

-- 
written by Karol Langner
Fri Mar  9 17:50:42 CET 2007

Re: [cclib-devel] missing tests

[Adam T. <a-t...@st...>]

>>> 3) fonames, fragnames, frags - should be in testSP for ADF,  
>>> together with
>>> fooverlaps
>>
>> I guess so.
>
> I won't do this, as I don't even know what these attributes mean  
> off-hand.

fonames are the ADF version of aonames. Do we actually test to make  
sure aonames are correct for the other parsers?

fragnames and frags are used to keep track of atoms in fragments. For  
some reason, ADF doesn't always consistently keep the ordering of the  
atomic fragments the same as the ordering of the atoms---I first  
noticed this when I was selecting a carbon atom in PyMOlyze and a  
hydrogen atom would be selected instead. These attributes are also  
useful when there is a fragment consisting of more than 1 atom (say  
an entire ligand). I'm not sure if there is a simple test whether  
these are correct aside from checking to make sure len(frags) == len 
(fragnames) although I could add a regression test for a single file  
to make sure we don't break our code at some point.

Adam

Re: [cclib-devel] etenergies

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

On 05/03/07, Karol Langner <kar...@kn...> wrote:
> On Monday 05 of March 2007 17:41, you wrote:
> > On 05/03/07, Karol Langner <kar...@kn...> wrote:
> > > Well, I guess if we parse the excitation energies, then the total
> > > energies of the excited states are redundant?
> >
> > For electronic transitions, we're talking about the vertical
> > excitation energy. The equilibrium energy of the excited state will
> > probably be lower (relaxation). But, it would be redundant as you say
> > if CI is calculating the same thing as TDDFT.
> Do you relaxed as in with an optimized geometry?
Yes.
> >
> > > As to CI calculations, there is some
> > > specific information about the excited states (for example the
> > > coefficients for MO excitations).
> >
> > This sounds like etsecs, but we should check.
> You're right, didn't notice etsecs (where does the name come from anyway?).
Isn't it obvious? :-) Well, it was difficult to come up with a good
name. "singly-excited configurations"='sec'. Each electronic
transition is expressed as a linear combination of single one-electron
transitions in the original molecule (or something like that, I'm a
bit unclear on the specifics). It's a good idea to get an example of
an unrestricted calc for the CI also, as they are usually harder to
parse.

> > > On a related note, I'm in favor of parsing output in a way that makes it
> > > clear what kind of calcualtion was done. In the case of etenergies, the
> > > values can come from TD-HF, CI, or any other excited state method -
> > > perhaps a string attribute such as "etmethod" could label this . The same
> > > point for scfenergies, which can contain energies from HF, DFT, or
> > > whatever, an "scfmethod" attribute mmight be useful. Just an idea.
> >
> > I think you can guess I'm not really keen on this. 'implicit' vs.
> > 'explicit' and so on. Can you think of a 'use case' where this has an
> > advantage? If the result is always treated in the same way by a
> > particular algorithm (e.g. convoluting the UV spectrum is the same no
> > matter what the origin of the data), I think that specialising the
> > data just makes things more difficult. I know that TD-DFT is much
> > different than CI, but I'd be worried about going down that route in
> > general. For example, isn't optimising in internal coordinates
> > different than optimising in cartesian coordinates? OK, it's not so
> > different as TD-DFT vs CI, so maybe you're right! :-)
> Yeah, optimizing in cartesian and internal coordinates is mathematically
> equivalent, the result should be the same :)  but you're right, cclib can't
> account for the "correctness" of the method used. As long as the values are
> supposed to describe the same thing, we should treat it the same way. If
> something specific for CI will be parsed, then there will be a ci<somethinf>
> attribute.
They call this duck-typing in Python; if it walks like a duck, and
quacks like a duck, then it *is* a duck (or at least we can treat it
like a duck).


> --
> written by Karol Langner
> Mon Mar  5 18:52:50 CET 2007
>

Re: [cclib-devel] missing tests

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

On 05/03/07, Karol Langner <kar...@kn...> wrote:
> On Monday 05 of March 2007 17:00, you wrote:
> > On 05/03/07, Karol Langner <kar...@kn...> wrote:
> > > I did an overview of which attributes are not tested presently. We should
> > > have tests for all attributes, even if only very simple ones. Here goes:
> >
> > BTW, it's trivial to use 'coverage.py' to look at parser code
> > coverage. You might find it interesting.
>
> Where would i find this 'coverage.py
Acutally, it's the first google hit. But here it is:
http://nedbatchelder.com/code/modules/coverage.html

> > > 1) aonmaes - should this be in testBasis.py?
> >
> > I would say testSP.py. There's nothing much to test with aonames,
> > actually, as it wasn't possible to standardise the names at all. The
> > only thing to test is the length, probably.
>
> Sure, but maybe at least this. BTW, I'm wondering if it's possible to build
> aonames from the basis set print-out?
I think we want aonames even for calculations that don't contain
gbasis. We can come back to this issue later if you have any ideas for
standard names.

> > > 2) etenergies, etoscs, etrotats, etsecs, etsyms - these should probably
> > > be tested repeatedly for the various kinds of calculations that give
> > > excited states (like testTD.py for the TD-DFT calcs we have files for
> > > right now)
> >
> > Acknowledged. cclib 0.8 should have better 'et' support all around. We
> > are missing several test files just for TDDFT.
>
> I agree. Just added a simple test for one TD-DFT file from Gaussian. I will be
> adding CI code soon, so there'll be more to come.
>
> > > 3) fonames, fragnames, frags - should be in testSP for ADF, together with
> > > fooverlaps
> >
> > I guess so.
>
> I won't do this, as I don't even know what these attributes mean off-hand.
>
> karol
>
> --
> written by Karol Langner
> Mon Mar  5 17:29:13 CET 2007
>

Re: [cclib-devel] etenergies

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

On 05/03/07, Karol Langner <kar...@kn...> wrote:
> Well, I guess if we parse the excitation energies, then the total energies of
> the excited states are redundant?
For electronic transitions, we're talking about the vertical
excitation energy. The equilibrium energy of the excited state will
probably be lower (relaxation). But, it would be redundant as you say
if CI is calculating the same thing as TDDFT.

> As to CI calculations, there is some
> specific information about the excited states (for example the coefficients
> for MO excitations).

This sounds like etsecs, but we should check.

> On a related note, I'm in favor of parsing output in a way that makes it clear
> what kind of calcualtion was done. In the case of etenergies, the values can
> come from TD-HF, CI, or any other excited state method - perhaps a string
> attribute such as "etmethod" could label this . The same point for
> scfenergies, which can contain energies from HF, DFT, or whatever, an
> "scfmethod" attribute mmight be useful. Just an idea.

I think you can guess I'm not really keen on this. 'implicit' vs.
'explicit' and so on. Can you think of a 'use case' where this has an
advantage? If the result is always treated in the same way by a
particular algorithm (e.g. convoluting the UV spectrum is the same no
matter what the origin of the data), I think that specialising the
data just makes things more difficult. I know that TD-DFT is much
different than CI, but I'd be worried about going down that route in
general. For example, isn't optimising in internal coordinates
different than optimising in cartesian coordinates? OK, it's not so
different as TD-DFT vs CI, so maybe you're right! :-)

> On Sunday 04 of March 2007 22:16, Noel O'Boyle wrote:
> > I would put them all into etxxx. Is there anything extra or different
> > about a CIS calculation? We are talking about "transitions to excited
> > states" rather than "excited states" themselves, right?
> >
> > On 04/03/07, Karol Langner <kar...@kn...> wrote:
> > > I'd like to open a little discussion about parsing excited states. I
> > > uploaded a CIS job and am wondering on how the parsing of excited states
> > > should look like in cclib. Should etenergies (and the other etxxx
> > > attributes) pick up excited states from any kind of calculation - TDHF,
> > > CI, etc.? Or should there be separate attributes for the different kinds
> > > of calculations. The question is similiar to the one we had earlier -
> > > having mpenergies and ccenergies versus one attribute for correlated
> > > energies.
> > >
> > > Karol
>
> --
> written by Karol Langner
> Mon Mar  5 10:42:04 CET 2007
>

Re: [cclib-devel] missing tests

[Karol L. <kar...@kn...>]

On Monday 05 of March 2007 17:00, you wrote:
> On 05/03/07, Karol Langner <kar...@kn...> wrote:
> > I did an overview of which attributes are not tested presently. We should
> > have tests for all attributes, even if only very simple ones. Here goes:
>
> BTW, it's trivial to use 'coverage.py' to look at parser code
> coverage. You might find it interesting.

Where would i find this 'coverage.py

> > 1) aonmaes - should this be in testBasis.py?
>
> I would say testSP.py. There's nothing much to test with aonames,
> actually, as it wasn't possible to standardise the names at all. The
> only thing to test is the length, probably.

Sure, but maybe at least this. BTW, I'm wondering if it's possible to build
aonames from the basis set print-out?

> > 2) etenergies, etoscs, etrotats, etsecs, etsyms - these should probably
> > be tested repeatedly for the various kinds of calculations that give
> > excited states (like testTD.py for the TD-DFT calcs we have files for
> > right now)
>
> Acknowledged. cclib 0.8 should have better 'et' support all around. We
> are missing several test files just for TDDFT.

I agree. Just added a simple test for one TD-DFT file from Gaussian. I will
 be adding CI code soon, so there'll be more to come.

> > 3) fonames, fragnames, frags - should be in testSP for ADF, together with
> > fooverlaps
>
> I guess so.

I won't do this, as I don't even know what these attributes mean off-hand.

karol

-- 
written by Karol Langner
Mon Mar  5 17:39:46 CET 2007

Re: [cclib-devel] missing tests

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

On 05/03/07, Karol Langner <kar...@kn...> wrote:
> I did an overview of which attributes are not tested presently. We should have
> tests for all attributes, even if only very simple ones. Here goes:

BTW, it's trivial to use 'coverage.py' to look at parser code
coverage. You might find it interesting.

> 1) aonmaes - should this be in testBasis.py?
I would say testSP.py. There's nothing much to test with aonames,
actually, as it wasn't possible to standardise the names at all. The
only thing to test is the length, probably.

> 2) etenergies, etoscs, etrotats, etsecs, etsyms - these should probably be
> tested repeatedly for the various kinds of calculations that give excited
> states (like testTD.py for the TD-DFT calcs we have files for right now)
Acknowledged. cclib 0.8 should have better 'et' support all around. We
are missing several test files just for TDDFT.

> 3) fonames, fragnames, frags - should be in testSP for ADF, together with
> fooverlaps
I guess so.

> Cheers,
> Karol
>
> --
> written by Karol Langner
> Mon Mar  5 16:43:57 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] missing tests

[Karol L. <kar...@kn...>]

I did an overview of which attributes are not tested presently. We should have 
tests for all attributes, even if only very simple ones. Here goes:

1) aonmaes - should this be in testBasis.py?

2) etenergies, etoscs, etrotats, etsecs, etsyms - these should probably be 
tested repeatedly for the various kinds of calculations that give excited 
states (like testTD.py for the TD-DFT calcs we have files for right now)

3) fonames, fragnames, frags - should be in testSP for ADF, together with 
fooverlaps

Cheers,
Karol

-- 
written by Karol Langner
Mon Mar  5 16:43:57 CET 2007

Re: [cclib-devel] PyVib2 for Windows

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

On 05/03/07, Maxim Fedorovsky <Max...@un...> wrote:
> Noel O'Boyle schrieb:
> > You refer to "Cartesian excursions". I wonder if this is the same as
> > what I call "cartesian displacement vectors".
> What I mean : sum_{a=1, N;  i=1, 3} m_a * Lx_{a, i}**2 = 1, where the
> masses are expressed in atomic units.
> MOLDEN, for instance, uses Lx but takes the masses in atomic mass units
> rather than in a.u.
Hmmm...that's a very exact answer, but not a quick one to digest. I'll
look into this once I get back.

> > Anyway, my question is, if we extract the information that PyVib2
> > likes, would PyVib2 use cclib?
> >
> > Regards,
> >   Noel
> >
> I guess, that as for any project, an additional dependency should
> justify its existence. Each of the PyVib2's dependencies was chosen very
> carefully. For instance, take Matplotlib -- an outstanding quality of 2D
> rendering is a weighty argument for using the package. If there would be
> more *reasonable* pro's than contra's in introducing cclib -- why not ? :)
But in fact, using cclib doesn't necessarily introduce any
dependencies. You can include the relevant code directly in your
project (and this is what I recommend). I do this with GaussSum, as a
vendor drop-in (http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html)
and previously as an svn external
(http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html)
pointing to the latest release.

>From the point of view of cclib, we would like to extract as much
information as possible that is useful to people, especially people
who do analyses.

Noel

Re: [cclib-devel] PyVib2 for Windows

[Maxim F. <Max...@un...>]

Noel O'Boyle schrieb:
> You refer to "Cartesian excursions". I wonder if this is the same as
> what I call "cartesian displacement vectors".
What I mean : sum_{a=1, N;  i=1, 3} m_a * Lx_{a, i}**2 = 1, where the 
masses are expressed in atomic units.
MOLDEN, for instance, uses Lx but takes the masses in atomic mass units 
rather than in a.u.
>
> Anyway, my question is, if we extract the information that PyVib2
> likes, would PyVib2 use cclib?
>
> Regards,
>   Noel
>
I guess, that as for any project, an additional dependency should 
justify its existence. Each of the PyVib2's dependencies was chosen very 
carefully. For instance, take Matplotlib -- an outstanding quality of 2D 
rendering is a weighty argument for using the package. If there would be 
more *reasonable* pro's than contra's in introducing cclib -- why not ? :)


With best regards,
Maxim Fedorovsky.

Re: [cclib-devel] PyVib2 for Windows

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

On 05/03/07, Maxim Fedorovsky <Max...@un...> wrote:
> Noel O'Boyle schrieb:
> > Works for me. Looks great, although I'm not sure what it's doing - I'd
> > better read the manual. :-)
> >
> > We're starting to plan what we want to include in cclib 0.8. Can you
> > describe exactly what information you currently extract from the log
> > files? (Please 'cc' everything to cclib-dev list)
> >
> > P.S. I'm away soon until the 17th March, so don't worry if you don't
> > hear from me.
> >
> > Regards,
> >   Noel
>     Hello !
>
> To see what exactly is extracted refer to the docstrings of the
> pyviblib.io.parsers module,
> http://pyvib2.sourceforge.net/doc/pydoc/pyviblib.io.parsers.html.
You refer to "Cartesian excursions". I wonder if this is the same as
what I call "cartesian displacement vectors".

> PyVib2
> uses properties (and so, new-style classes) rather than class attributes
> to store the information.

> The pyviblib.io.writers module might be also of interest for you.
They are interesting, but it's not currently a goal of cclib to write
output files, until a standard XML output file for comp chem has been
developed (which I understand is currently in development by a number
of interested parties).

Anyway, my question is, if we extract the information that PyVib2
likes, would PyVib2 use cclib?

Regards,
   Noel

Re: [cclib-devel] PyVib2 for Windows

[Maxim F. <Max...@un...>]

Noel O'Boyle schrieb:
> Works for me. Looks great, although I'm not sure what it's doing - I'd
> better read the manual. :-)
>
> We're starting to plan what we want to include in cclib 0.8. Can you
> describe exactly what information you currently extract from the log
> files? (Please 'cc' everything to cclib-dev list)
>
> P.S. I'm away soon until the 17th March, so don't worry if you don't
> hear from me.
>
> Regards,
>   Noel
    Hello !

Thanks for testing) If something appears to you to be illogical or 
annoying, please tell me.

To see what exactly is extracted refer to the docstrings of the 
pyviblib.io.parsers module, 
http://pyvib2.sourceforge.net/doc/pydoc/pyviblib.io.parsers.html. PyVib2 
uses properties (and so, new-style classes) rather than class attributes 
to store the information.

The pyviblib.io.writers module might be also of interest for you.

Apropos, I have recently implemented the support of FCHK files (parsing 
and vibrational analysis) in OpenBabel.


With best regards,
Maxim Fedorovsky.

Re: [cclib-devel] etenergies

[Karol L. <kar...@kn...>]

Well, I guess if we parse the excitation energies, then the total energies of 
the excited states are redundant? As to CI calculations, there is some 
specific information about the excited states (for example the coefficients 
for MO excitations).

On a related note, I'm in favor of parsing output in a way that makes it clear 
what kind of calcualtion was done. In the case of etenergies, the values can 
come from TD-HF, CI, or any other excited state method - perhaps a string 
attribute such as "etmethod" could label this . The same point for 
scfenergies, which can contain energies from HF, DFT, or whatever, an 
"scfmethod" attribute mmight be useful. Just an idea.

On Sunday 04 of March 2007 22:16, Noel O'Boyle wrote:
> I would put them all into etxxx. Is there anything extra or different
> about a CIS calculation? We are talking about "transitions to excited
> states" rather than "excited states" themselves, right?
>
> On 04/03/07, Karol Langner <kar...@kn...> wrote:
> > I'd like to open a little discussion about parsing excited states. I
> > uploaded a CIS job and am wondering on how the parsing of excited states
> > should look like in cclib. Should etenergies (and the other etxxx
> > attributes) pick up excited states from any kind of calculation - TDHF,
> > CI, etc.? Or should there be separate attributes for the different kinds
> > of calculations. The question is similiar to the one we had earlier -
> > having mpenergies and ccenergies versus one attribute for correlated
> > energies.
> >
> > Karol

-- 
written by Karol Langner
Mon Mar  5 10:42:04 CET 2007

Re: [cclib-devel] PyVib2 for Windows

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

Works for me. Looks great, although I'm not sure what it's doing - I'd
better read the manual. :-)

We're starting to plan what we want to include in cclib 0.8. Can you
describe exactly what information you currently extract from the log
files? (Please 'cc' everything to cclib-dev list)

P.S. I'm away soon until the 17th March, so don't worry if you don't
hear from me.

Regards,
   Noel

On 03/03/07, Maxim Fedorovsky <Max...@un...> wrote:
>        Dear Noel,
>
>     The executable for Windows is available now. It was frozen for
> Python 2.4.4, ActiveTcl 8.4.14, latest VTK 5.0.2, numpy 1.0.1,
> matplotlib 0.90, Pmw 1.20, under WinXP (SP 2.0) compiled with MS VC++
> 6.0. I have tested it on several computers. Please let me know if it
> does not run.
>
>     Results for methyloxirane which can be opened are located on
> http://pyvib2.sourceforge.net/material.shtml.
>
>
>     Best wishes,
>     Max.
>

Re: [cclib-devel] etenergies

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

I would put them all into etxxx. Is there anything extra or different
about a CIS calculation? We are talking about "transitions to excited
states" rather than "excited states" themselves, right?

On 04/03/07, Karol Langner <kar...@kn...> wrote:
> I'd like to open a little discussion about parsing excited states. I uploaded
> a CIS job and am wondering on how the parsing of excited states should look
> like in cclib. Should etenergies (and the other etxxx attributes) pick up
> excited states from any kind of calculation - TDHF, CI, etc.? Or should there
> be separate attributes for the different kinds of calculations. The question
> is similiar to the one we had earlier - having mpenergies and ccenergies
> versus one attribute for correlated energies.
>
> Karol
>
> --
> written by Karol Langner
> Sun Mar  4 15:18:52 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] ANN: cclib 0.7b released

[Karol L. <kar...@kn...>]

On Sunday 04 of March 2007 18:26, Noel O'Boyle wrote:
> cclib 0.7b has been released. Let's try to update all of the wiki
> documentation as soon as possible.
>
> I'd like to release 0.7 final as soon as I get back (17th); this will
> be identical to 0.7b except for any bug fixes, and will be announced
> on CCL.

So there should now be a Jaguar column on the parsed data page?

-- 
written by Karol Langner
Sun Mar  4 18:46:46 CET 2007

[cclib-devel] ANN: cclib 0.7b released

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

cclib 0.7b has been released. Let's try to update all of the wiki
documentation as soon as possible.

I'd like to release 0.7 final as soon as I get back (17th); this will
be identical to 0.7b except for any bug fixes, and will be announced
on CCL.

Noel

[cclib-devel] etenergies

[Karol L. <kar...@kn...>]

I'd like to open a little discussion about parsing excited states. I uploaded 
a CIS job and am wondering on how the parsing of excited states should look 
like in cclib. Should etenergies (and the other etxxx attributes) pick up 
excited states from any kind of calculation - TDHF, CI, etc.? Or should there 
be separate attributes for the different kinds of calculations. The question 
is similiar to the one we had earlier - having mpenergies and ccenergies 
versus one attribute for correlated energies.

Karol

-- 
written by Karol Langner
Sun Mar  4 15:18:52 CET 2007

Re: [cclib-devel] mpenergies and GAMESS

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

On 02/03/07, Karol Langner <kar...@kn...> wrote:
> On Friday 02 of March 2007 12:05, Noel O'Boyle wrote:
> > Running ccget mpenergies on the GAMESS-US output files, we get:
> >
> > Attempting to parse water_ccd.out
> > mpenergies:
> > [ [-2073.99919009]]
> > Attempting to parse water_ccsd(t).out
> > mpenergies:
> > [ [-2073.99919009]]
> > Attempting to parse water_ccsd.out
> > mpenergies:
> > [ [-2073.99919009]]
> > Attempting to parse water_mp2.out
> > mpenergies:
> > [ [-2040.91709961]]
> >
> > Should I be worried about the difference in the values? The reason I
> > ask now, is that I am wondering whether to include this code (the code
> > for parsing mpenergies from CC calculations) in the release branch.
> >
> > Noel
>
> This difference is due to a difference in basis sets. Job water_mp2 uses
> STO-3G, while all the CC calculations were done for 6-31G(d,p). The problem
> is that GAMESS aborts if the number of correlating orbitals is smaller than
> the number of occupied ones (2 versus 4 for STO-3G). I'm not sure how
> critical this is from the chemical point of view, but Gaussian for instance
> has no problem with it (no warning).
OK, that's fine...I'll go ahead with merging this code.

Re: [cclib-devel] mpenergies and GAMESS

[Karol L. <kar...@kn...>]

On Friday 02 of March 2007 12:05, Noel O'Boyle wrote:
> Running ccget mpenergies on the GAMESS-US output files, we get:
>
> Attempting to parse water_ccd.out
> mpenergies:
> [ [-2073.99919009]]
> Attempting to parse water_ccsd(t).out
> mpenergies:
> [ [-2073.99919009]]
> Attempting to parse water_ccsd.out
> mpenergies:
> [ [-2073.99919009]]
> Attempting to parse water_mp2.out
> mpenergies:
> [ [-2040.91709961]]
>
> Should I be worried about the difference in the values? The reason I
> ask now, is that I am wondering whether to include this code (the code
> for parsing mpenergies from CC calculations) in the release branch.
>
> Noel

This difference is due to a difference in basis sets. Job water_mp2 uses 
STO-3G, while all the CC calculations were done for 6-31G(d,p). The problem 
is that GAMESS aborts if the number of correlating orbitals is smaller than 
the number of occupied ones (2 versus 4 for STO-3G). I'm not sure how 
critical this is from the chemical point of view, but Gaussian for instance 
has no problem with it (no warning).

Karol

-- 
written by Karol Langner
Fri Mar  2 17:54:53 CET 2007

[cclib-devel] mpenergies and GAMESS

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

Running ccget mpenergies on the GAMESS-US output files, we get:

Attempting to parse water_ccd.out
mpenergies:
[ [-2073.99919009]]
Attempting to parse water_ccsd(t).out
mpenergies:
[ [-2073.99919009]]
Attempting to parse water_ccsd.out
mpenergies:
[ [-2073.99919009]]
Attempting to parse water_mp2.out
mpenergies:
[ [-2040.91709961]]

Should I be worried about the difference in the values? The reason I
ask now, is that I am wondering whether to include this code (the code
for parsing mpenergies from CC calculations) in the release branch.

Noel

Re: [cclib-devel] Fwd: Refactoring

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

On 01/03/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 27 of February 2007 15:34, Noel O'Boyle wrote:
> > On 26/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > > With this in mind, could we just base the release on trunk (i.e. I'll
> > > > merge all of the change to release), and then I'll remove any items in
> > > > development (e.g. ccenergies).
> > >
> > > That sounds reasonable.
> >
> > OK, done.
>
> Out of curiousity, did something happen here that caused some tests in testMP
> to fail? I noticed that a few lines of code were gone (readded them today).
I saw your log message, but I didn't notice anything. You should be
able to look through the SVN diffs of that file to see what the story
is. The SVN browser on our SF website is useful for this.

> > The only tests left to pass are those involving coreelectrons (because
> > of tests I've added today basically). We need
> >
> > (1) a test file for GAMESS-US and/or PC-GAMESS, and then code for it
> > (2) code for GAMESS-UK
> > (3) bug fix for ADF (I presume it's a bug)
>
> So this is all done, I think. Any other coding bits you need help with?
I think we're ready to rock. Sometime this weekend, I'll make the beta
release. We'll sit tight for a week or two (I'll be away) and try to
find problems, and then make a final release, and announce it on CCL,
etc.

Good luck with the talk.

Noel