cclib-devel — Developer's mailing list

[cclib-devel] parser-refactoring

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

Hi,

With revision 614, I have basically completed the refactoring changes I 
planned. All tests still pass, two ADF regression tests fail, but this was 
true before my commits, if I remember correctly.

I'm probably not going to do anything else today, to let the changes "sink 
in". I might add a few more minor things tommorow related with the 
refactoring, though. This would be good moment to discuss the possibility of 
using a dictionary of functions instead of the extract() method, or other 
further ideas. My main worry is where all the functions would be defined.

- Karol

-- 
written by Karol Langner
Thu Apr 26 17:17:09 CEST 2007

[cclib-devel] fupdate/cupdate

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

I just made fupdate and cupdate attributes of the parser class. They can be 
set upon initializing the parser. The parse() method still takes them as 
optional arguments, because I don't know if this is used by your programs 
somewhere (GausSum, PyMOlyze, ...). If not, I guess that can be thrown out, 
too.

I'm still not too aware what the difference between these is, but I'll get to 
that eventually when I take a deeper look.

- Karol

-- 
written by Karol Langner
Thu Apr 26 15:40:36 CEST 2007

Re: [cclib-devel] Fwd: Re: parser-refactoring revisited

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

On 26/04/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 26 April 2007 12:57, Noel O'Boyle wrote:
> > On 26/04/07, Karol Langner <kar...@kn...> wrote:
> > > On Thursday 26 April 2007 08:04, Noel wrote:
> > > > Do any of our parsers set the attribute, but then delattr it? Might be
> > > > worth checking. Also, it would be possible to check the types of
> > > > attributes at this point, using an assert statement. I can look into
> > > > this.
> > >
> > > langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
> > > logfileparser.py:                delattr(self, attr)
> > >
> > > The actual parsing no - the only place it is used is in LogFile.clean().
> > >
> > > What do you mean by "checking the types of attributes at this point"? Do
> > > you mean checking that the value is the correct type inside
> > > LogFile.__setattr()?
> >
> > E.g. verify that mocoeffs is a list of 1 or 2 numeric arrays of rank 2
> > or whatever. It wouldn't add much overhead to the program, and would
> > act as a sanity check.
>
> As you know, presently types are checked after parsing (I added the _attrtypes
> list today). This could be done additionally in __setattr__. Checking the
> contents of lists, though, is done only for lists that are supposed to
> contain arrays. The method __setattr__, however, is called only when a new
> value is assigned (using equivalence or whatever). So that would be a rather
> weak sanity check for list contents - if something is appended to the list,
> or one of the elements changed, the method is not called.
>
Sorry - I forget that it was already being checked after parsing.

> - Karol
>
> --
> written by Karol Langner
> Thu Apr 26 15:11:57 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Fwd: Re: parser-refactoring revisited

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

On Thursday 26 April 2007 12:57, Noel O'Boyle wrote:
> On 26/04/07, Karol Langner <kar...@kn...> wrote:
> > On Thursday 26 April 2007 08:04, Noel wrote:
> > > Do any of our parsers set the attribute, but then delattr it? Might be
> > > worth checking. Also, it would be possible to check the types of
> > > attributes at this point, using an assert statement. I can look into
> > > this.
> >
> > langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
> > logfileparser.py:                delattr(self, attr)
> >
> > The actual parsing no - the only place it is used is in LogFile.clean().
> >
> > What do you mean by "checking the types of attributes at this point"? Do
> > you mean checking that the value is the correct type inside
> > LogFile.__setattr()?
>
> E.g. verify that mocoeffs is a list of 1 or 2 numeric arrays of rank 2
> or whatever. It wouldn't add much overhead to the program, and would
> act as a sanity check.

As you know, presently types are checked after parsing (I added the _attrtypes 
list today). This could be done additionally in __setattr__. Checking the 
contents of lists, though, is done only for lists that are supposed to 
contain arrays. The method __setattr__, however, is called only when a new 
value is assigned (using equivalence or whatever). So that would be a rather 
weak sanity check for list contents - if something is appended to the list, 
or one of the elements changed, the method is not called.

- Karol

-- 
written by Karol Langner
Thu Apr 26 15:11:57 CEST 2007

Re: [cclib-devel] Fwd: Re: parser-refactoring revisited

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

On 26/04/07, Karol Langner <kar...@kn...> wrote:
> On Thursday 26 April 2007 08:04, Noel wrote:
> > Do any of our parsers set the attribute, but then delattr it? Might be
> > worth checking. Also, it would be possible to check the types of
> > attributes at this point, using an assert statement. I can look into
> > this.
>
> langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
> logfileparser.py:                delattr(self, attr)
>
> The actual parsing no - the only place it is used is in LogFile.clean().
>
> What do you mean by "checking the types of attributes at this point"? Do you
> mean checking that the value is the correct type inside LogFile.__setattr()?

E.g. verify that mocoeffs is a list of 1 or 2 numeric arrays of rank 2
or whatever. It wouldn't add much overhead to the program, and would
act as a sanity check.

> > > 5) Numeric->numpy transition. This isn't strictly related to the
> > > refactoring, but it might as well be done at once. The related changes
> > > seem to be trivial.
> >
> > Can we leave this until all current tests pass after the first refactoring.
>
> Of course. I added it, becuase hopefully the refactoring will not break any
> tests.
>
> - Karol
>
> --
> written by Karol Langner
> Thu Apr 26 14:26:08 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Fwd: Re: parser-refactoring revisited

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

On Thursday 26 April 2007 08:04, Noel wrote:
> Do any of our parsers set the attribute, but then delattr it? Might be
> worth checking. Also, it would be possible to check the types of
> attributes at this point, using an assert statement. I can look into
> this.

langner@slim:~/tmp/python/cclib/trunk/src/cclib/parser$ grep "delattr" *
logfileparser.py:                delattr(self, attr)

The actual parsing no - the only place it is used is in LogFile.clean().

What do you mean by "checking the types of attributes at this point"? Do you
mean checking that the value is the correct type inside LogFile.__setattr()?

> > 5) Numeric->numpy transition. This isn't strictly related to the
> > refactoring, but it might as well be done at once. The related changes
> > seem to be trivial.
>
> Can we leave this until all current tests pass after the first refactoring.

Of course. I added it, becuase hopefully the refactoring will not break any
tests.

- Karol

-- 
written by Karol Langner
Thu Apr 26 14:26:08 CEST 2007

Re: [cclib-devel] Openbabel 2.1 Windows installer

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

On 26/04/07, Chris Morley <c.m...@ga...> wrote:
> I also have had these compiling difficulties. My computer was down for a
> couple of weeks before the release of the source files and I wasn't able
> to check that they continued to compile. I have downloaded the released
> source and it needed a couple of minor changes. I also had to reinstall
> all my programs so that my wxWidgets version is 2.83.
Are you saying that I need wxWidgets 2.8.3 also? I think you are - I
saw that you updated the compile instructions on the wiki.

> In addition, Geoff
> seems to have removed some essential files from the distribution - like
> the libxml2 headers.
I'm posting to the list so Geoff can fill us in.

> At http://www.gaseq.co.uk/OB/openbabel-2.1.0.7z is a copy of the 2.1.0
> project which compiles for me. (I haven't tried OBPython recently.) We
> can get in a mess with versions and really will have to do it better
> next time.
I think it's fine so long as we use SVN and tag the release once it
compiles fine and has been tested. Then it is clear exactly what was
contained in the release. If we work locally, it will be more
difficult to untangle things.

> I suspect that the following data files should be included:
> SMARTS_InteLigand.txt
> logp.txt
> mr.txt
> psa.txt
> ghemical.prm
> It is difficult finding machine empty enough to be sure.
I have a pretty empty machine for testing once we get to this stage.

> If you would prefer to do this a different way, please say.
I'd really like to work from SVN, although it looks like we should be
working off the 2.1.x release branch rather than the trunk. If you
could get this to compile I think this is a better idea than working
off a download of the 2.1.0 release.

Geoff periodically merges from the release branch to the trunk (and
vice versa I guess in some cases), so any changes you/we make will be
incorporated into the trunk also.

Noel

[cclib-devel] aonames and a new attribute

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

I've been trying to upgrade GaussSum to use cclib 0.7 but I've run
into a difficulty of sorts. I realised that:
(1) some Jaguar files don't have aonames
(2) GaussSum was parsing the aonames to figure out which basis
functions were on which atoms

First of all, GaussSum shouldn't need to be parsing a text string to
figure out information which was available to cclib. This means we
need to add a new attribute which assigns basis functions to atoms,
e.g. a list of lists called atombasis where atombasis[0] is a list
containing the indices of the basis fns on the first atom.

Secondly, we need to tighten up our definitions of aonames. I note
here that some output files have more information than others. It is
not possible to standardise aonames across parsers but we should at
least provide some guidelines for how aonames should be constructed in
general.

Noel

Re: [cclib-devel] parser-refactoring revisited

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

On 26/04/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  I've already started, but I'd like to shortly summarize the changes I'm about
> to do in the trunk related to refactoring the parser, in the order they will
> proceed. Ideally, these changes won't break anything, but you never know, so
> be on the lookout! The goal is to get certain things working automatically
> and to move as many elements of the parsing process to the generic class
> LogFile, which in turn is supposed to make writing and modifying the child
> parsers easier in the future.
>
> 1) Move all calls to logger.infio() for newly created attributes to the method
> LogFile.__setattr__() - which is called automatically when an attibute is
> set. Prints the log message only if the attribute is new and present in
> LogFile.attrlist.
Do any of our parsers set the attribute, but then delattr it? Might be
worth checking. Also, it would be possible to check the types of
attributes at this point, using an assert statement. I can look into
this.

> 2) Up till now, we refrained from setting temporary attributes while parsing
> in order to keep things tidy. By utilizing an additional list attribute
> ("__nodelete"), these can be used (alot, if neede), and will be deleted after
> parsing (so the user does not see that they existed). Interestingly, this
> also requires that we keep LogFile.attrlist up-to-date :-)
>
> 3) THE MAJOR CHANGE - moving the "for line in inputfile" loop to
> LogFile.parse(). This may seem like just moving one line, but there are some
> extra things to change in order to keep things parsing (like using temporary
> attributes), and a number of things to consider. Note a paradigm shift in the
> way the parsers work: the method extract() will be now called many times
> instead of once. In my opinion, this is a natural step that makes the parsers
> more flexible and opens interesting possibilities for further enhacements,
>
> 4) Making fupdate and cupdate attributes of the class - this is reasonable, as
> then they won't have to be passed around to extract() in each call.
Sure.

> 5) Numeric->numpy transition. This isn't strictly related to the refactoring,
> but it might as well be done at once. The related changes seem to be trivial.

Can we leave this until all current tests pass after the first refactoring.

> 6) A few other minor changes I might not remember at the moment, but will
> comment on.
>
> Any further changes to the parser structure really need to be discussed
> thouroughly so as not to waste development time. For example, as mentioned by
> Noel, we could choose to use a dictionary of functions that parse separate
> blocks of output (best if the keys are regexps). I like the idea, and the
> present changes are a step in that direction. It would be pretty, optimal,
> and well-structured, which all makes writing new parses easier and more fun.
> Then main question is - where would all these functions be defined? If they
> are to be class methods, things can get messy, since there will be quite a
> lot of them. But first things first.

> Hope this clears up the up-coming commits,
> Karol
>
> --
> written by Karol Langner
> Thu Apr 26 01:24:12 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] parser-refactoring revisited

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

Hi,

 I've already started, but I'd like to shortly summarize the changes I'm about 
to do in the trunk related to refactoring the parser, in the order they will 
proceed. Ideally, these changes won't break anything, but you never know, so 
be on the lookout! The goal is to get certain things working automatically 
and to move as many elements of the parsing process to the generic class 
LogFile, which in turn is supposed to make writing and modifying the child 
parsers easier in the future.

1) Move all calls to logger.infio() for newly created attributes to the method 
LogFile.__setattr__() - which is called automatically when an attibute is 
set. Prints the log message only if the attribute is new and present in 
LogFile.attrlist.

2) Up till now, we refrained from setting temporary attributes while parsing 
in order to keep things tidy. By utilizing an additional list attribute 
("__nodelete"), these can be used (alot, if neede), and will be deleted after 
parsing (so the user does not see that they existed). Interestingly, this 
also requires that we keep LogFile.attrlist up-to-date :-)

3) THE MAJOR CHANGE - moving the "for line in inputfile" loop to 
LogFile.parse(). This may seem like just moving one line, but there are some 
extra things to change in order to keep things parsing (like using temporary 
attributes), and a number of things to consider. Note a paradigm shift in the 
way the parsers work: the method extract() will be now called many times 
instead of once. In my opinion, this is a natural step that makes the parsers 
more flexible and opens interesting possibilities for further enhacements,

4) Making fupdate and cupdate attributes of the class - this is reasonable, as 
then they won't have to be passed around to extract() in each call.

5) Numeric->numpy transition. This isn't strictly related to the refactoring, 
but it might as well be done at once. The related changes seem to be trivial.

6) A few other minor changes I might not remember at the moment, but will 
comment on.

Any further changes to the parser structure really need to be discussed 
thouroughly so as not to waste development time. For example, as mentioned by 
Noel, we could choose to use a dictionary of functions that parse separate 
blocks of output (best if the keys are regexps). I like the idea, and the 
present changes are a step in that direction. It would be pretty, optimal, 
and well-structured, which all makes writing new parses easier and more fun. 
Then main question is - where would all these functions be defined? If they 
are to be class methods, things can get messy, since there will be quite a 
lot of them. But first things first.

Hope this clears up the up-coming commits,
Karol

-- 
written by Karol Langner
Thu Apr 26 01:24:12 CEST 2007

[cclib-devel] LogFile.__setattr__

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

The first of the changes in refactoring the parser. The __setattr__ method can 
nicel handle calling logger.info() when new attributes are created. All calls 
in extract() in all parsers are gone now. Maybe some other things could also 
be simplified this way - no ideas right now, though.

Cheers,
Karol

-- 
written by Karol Langner
Wed Apr 25 21:05:30 CEST 2007

Re: [cclib-devel] Managing releases

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

First of all, I've added you to the "openbabel-python" package as an owner.

Next, once you log in, click on the "openbabel" package (*not*
openbabel-python) and then the "Remove this package completely"
button...

Note that the only problem is that the new higher version number will
replace the old release, and I don't yet have a new Windows release
available. So, if could you hold off making the new 1.2.0 release
until I get a Windows release together (which may take some time
depending on how things are compiling in Windows and how busy Chris
is) that'd be great.

Regards,
   Noel

On 25/04/07, Geoffrey Hutchison <ge...@ge...> wrote:
>
> On Apr 25, 2007, at 9:42 AM, Noel O'Boyle wrote:
>
> >    http://cheeseshop.python.org/pypi?:action=browse&amp;c=389
> >
> > I'm guessing that you didn't realise it was there already, as it would
> > be good to keep the Windows and Linux releases in sync.
>
>
> Yes, exactly. I didn't realize you uploaded the previous iteration.
> If you have a suggestion for what to do, let me know. There's
> probably some procedure to remove the one I uploaded, right?
>
> Thanks,
> -Geoff
>

Re: [cclib-devel] Managing releases

[Geoffrey H. <ge...@ge...>]

On Apr 25, 2007, at 9:42 AM, Noel O'Boyle wrote:

>    http://cheeseshop.python.org/pypi?:action=browse&c=389
>
> I'm guessing that you didn't realise it was there already, as it would
> be good to keep the Windows and Linux releases in sync.


Yes, exactly. I didn't realize you uploaded the previous iteration.  
If you have a suggestion for what to do, let me know. There's  
probably some procedure to remove the one I uploaded, right?

Thanks,
-Geoff

[cclib-devel] Managing releases

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

Hey Geoff,

I think users are going to be confused by two separate cheeseshop
entries for OpenBabel.
    http://cheeseshop.python.org/pypi?:action=browse&c=389

I'm guessing that you didn't realise it was there already, as it would
be good to keep the Windows and Linux releases in sync.

Noel

[cclib-devel] Gaussian pop=regular

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

While I was away, a GaussSum bug report reached me where a user used
'pop=regular' instead of the default pop, or pop=full, which we can
handle.

"pop=regular" is described by the manual as:
"The five highest occupied and five lowest virtual orbitals are
printed, along with the density matrices and a full (orbital by
orbital and atom by atom) Mulliken population analysis. Since the size
of the output depends on the square of the size of the molecule, it
can become quite substantial for larger molecules."

An error occurs when reading in the mocoeffs. The overall problem is
that we assume that mocoeffs contains the MO coefficients of all of
the orbitals up to a particular orbital N, where N is less than or
equal to the total number of MOs.

I feel that adapting mocoeffs to handle the "pop=regular" situation is
one special case too many. Instead, I intend to make sure that cclib
doesn't fail to parse, but avoid setting the 'mocoeffs' attribute.
Users of GaussSum know that they need to use 'pop=full' if they want
to do a population analysis.

Regards,
   Noel

Re: [cclib-devel] parser-refactoring

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

I won't force the issue either way, but I feel it might be a good idea
to push ahead with the refactoring and get it over with. This will
mean a 0.8 release rather than 0.7.1, but we can make this a quick
release if all it contains is the refactoring plus some bugfixes (ADF)
and enhancements (ccenergies, tightening up the TD-DFT, filling holes
in Jaguar).

I suppose what it boils down to is how long it will take to fix the
ADF bugs. I haven't looked at these but, due to the nature of ADF
output files, ADF bugs are typically more complex than your average
one

Noel

On 27/03/07, Karol Langner <kar...@kn...> wrote:
> On Monday 26 of March 2007 20:26, Adam Tenderholt wrote:
> > What are the plans for version 0.7.1? It obviously will contain the
> > bug fixes we make to the ADF parser and the new functionality being
> > added to the Jaguar parser, as well as some of the changes I'll be
> > making to the methods. Is it appropriate to include the refactoring
> > in this release, or should it wait until 0.8?
> >
> > The reason I bring up this issue is how we should handle the svn
> > tree. If the refactoring is going into the 0.7.1 release, then I see
> > no reason to not merge it with trunk whenever you're ready. If this
> > is the case, then I'd like the most recent changes in trunk to be
> > merged with the 0.7 branch first as I'm trying to get Jaguar support
> > working better in PyMOlyze. If the refactoring goes into the 0.8
> > release, then you could simple rename that branch to 0.8 and we'll
> > push patches from trunk into that branch as necessary.
> >
> > Adam
>
> Good point, it's more logical to wait until after 0.7.1. Still, perhaps some
> of the smaller changes that don't alter the parser strusture (like automated
> logger messages in __setitem__) could be included in the next subrelease.
>
> Karol
>
> --
> written by Karol Langner
> Tue Mar 27 08:22:02 CEST 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] Parsing speed

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

I checked this out some time ago, but not very comprehensively. This
time, I've compared the speed of:

   regular expressions
   in line
   line.find() == x
   line.startswith( ,x)
   line[x:y]

and line[x:y] is at least twice as fast as the other contenders. The
order (from memory) is roughly that listed above.

Regards,
   Noel

Re: [cclib-devel] oscillator strengths/transition dipoles (was: etsecs conversions)

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

On Wednesday 28 of March 2007 15:08, Karol Langner wrote:
> > >I'm not too surprised that Gaussian and GAMESS give
> > > entirely different trnsition dipoles and oscillator strengths (compare
> > > the water_cis jobs in both programs). An I mean entirely - Gaussian
> > > often gives zero (0.0000) where GAMESS gives significantly non-zero
> > > numbers. In Jaguar, again different numbers - although here they
> > > qualitively agree with those in GAMESS and so might result from
> > > numerical differences. I don't understand this, or I'm not reading the
> > > numbers right.
> >
> > I think we're hitting the limit of our knowledge here. :-)
>
> Very true :) I'd like to push my limit a little bit further in this topic,
> though.

Well, looks like if I use the SAPS hamiltonian in GAMESS (hamtyp=saps), the 
oscillator strengths are fine, they agree with Gaussian and Jaguar. That's 
good news! I uploaded test for both types of hamilatonians.

The determinant0-based one is the problematic one - I don't know if it's an 
error in the program or if it's a different algorithm, but I will inquire. 
Notice, though, that the oscillator strengths for transitions to triplet 
states are non-zero in water_cis_dets.out, which is theoretically impossible 
unless spin-orbit coupling is taken under consideration.

Karol

-- 
written by Karol Langner
Thu Mar 29 22:14:35 CEST 2007

Re: [cclib-devel] ADF output error again

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

> Does this mean that you have access to ADF2006.01 also? If so, it
> would be nice to get the output of a TD-DFT calculation on dvb at some
> stage.

I just realized I used ADF2004.01 to run that file, so it should be  
moved into the 2004.01 directory. I can get ADF2006.01 for my lab's  
computers since we have a contract with SCM, but I haven't yet  
because ADF2004.01 works for me so why upgrade? ;o)

Adam

Re: [cclib-devel] etsecs conversions

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

On Wednesday 28 of March 2007 10:45, Noel O'Boyle wrote:
> > But, there seems to be a problem related to the excitation coefficients
> > (which need a tolerance above 0.0005, by the way). Namely, some of the
> > coefficients printed by Gaussian have different signs than the ones
> > printed by GAMESS (observe also that the ones given by Jaguar are
> > consistently with an extra minus compared to GAMESS). This is probably
> > due to the symmetry type (A1, B1, A2, ...). I don't know what the
> > relation is, however, and we should standardize this. Any ideas? Notice
> > that the appropriate new test in testCI.py fails.
>
> As discussed in the other thread, I think we should ignore the signs
> for the purposes of testing. Although I wonder is this related to
> alpha/beta? Should both the alpha and beta orbitals for the same
> transition have the same sign?

I believe the signs before CI coefficients of alpha/beta determinants should 
be the same for singlet states. If I'm not mistaken, for triplets they should 
be reversed.

-- 
written by Karol Langner
Wed Mar 28 15:14:48 CEST 2007

Re: [cclib-devel] oscillator strengths/transition dipoles (was: etsecs conversions)

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

On Wednesday 28 of March 2007 10:36, Noel O'Boyle wrote:
> > The sign, however, should influence the transition moments and so also
> > the oscillator strengths.
>
> Are you sure? In my mind, the secs are a mathematical construction
> that gives a solution to the TD-DFT or CI calculation. It is the sign
> of *this* single solution that is important. After all, there is a
> single oscillator strength associated with the solution, not several
> oscillator strengths, one for each sec. Again, I don't know much about
> this. :-)

No, I'm not sure. In any case, I guess then that it makes sense to test only 
the absolute values of the coefficients, which is what I will do.

> >I'm not too surprised that Gaussian and GAMESS give
> > entirely different trnsition dipoles and oscillator strengths (compare
> > the water_cis jobs in both programs). An I mean entirely - Gaussian often
> > gives zero (0.0000) where GAMESS gives significantly non-zero numbers. In
> > Jaguar, again different numbers - although here they qualitively agree
> > with those in GAMESS and so might result from numerical differences. I
> > don't understand this, or I'm not reading the numbers right.
>
> I think we're hitting the limit of our knowledge here. :-)

Very true :) I'd like to push my limit a little bit further in this topic, 
though.

> > These considerations may not be what cclib is about, but I guess it's
> > important for cclib to parse consistently - and probably to only parse
> > things that are consistent?
>
> The first is true, but I don't agree with the second. Different
> programs might simply be using different algorithms to calculate the
> same quantity. What we want to do is to take that information and
> present it faithfully to the user so that they can analyse it. It is a
> different question to compare and contrast the output of different
> comp chem packages...perhaps that's another paper (although I
> recommend reading the Gaussian license first of all)!

Point taken. I'm aware comparing timings of Gaussian with other programs is 
not allowed, what about calculations results themselves? I've seen a few 
articles that make such comparisons.

-- 
written by Karol Langner
Wed Mar 28 15:05:07 CEST 2007

Re: [cclib-devel] etsecs conversions

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

On 27/03/07, Karol Langner <kar...@kn...> wrote:
> OK, now all the parsers read in the "raw" coefficients - which mean the jaguar
> parser divides them by sqrt(2.0). I added tests for etenergies and etsecs to
> check across parsers, basing on the values from the GAMESS test (water for
> CIS/STO-3G - see my most recent commit).
>
> The values of etenergies look good - although I had to give a tolerance of
> 50cm-1 (is that alot?).
Experimentally, we typically use nm, and the conversion from cm-1 to
nm (1E7/x = y) has different 'sizes' at different wavelengths. At
around 300nm (which is where I expect these transitions are...the
typical 'organic chemistry' range), 50cm-1 is less than 1 nm, which is
more than acceptable. :-)

> But, there seems to be a problem related to the excitation coefficients (which
> need a tolerance above 0.0005, by the way). Namely, some of the coefficients
> printed by Gaussian have different signs than the ones printed by GAMESS
> (observe also that the ones given by Jaguar are consistently with an extra
> minus compared to GAMESS). This is probably due to the symmetry type (A1, B1,
> A2, ...). I don't know what the relation is, however, and we should
> standardize this. Any ideas? Notice that the appropriate new test in
> testCI.py fails.
As discussed in the other thread, I think we should ignore the signs
for the purposes of testing. Although I wonder is this related to
alpha/beta? Should both the alpha and beta orbitals for the same
transition have the same sign?

> Karol
>
> --
> written by Karol Langner
> Tue Mar 27 19:45:33 CEST 2007
>

Re: [cclib-devel] oscillator strengths/transition dipoles (was: etsecs conversions)

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

On 28/03/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 27 of March 2007 19:55, Karol Langner wrote:
> > But, there seems to be a problem related to the excitation coefficients
> > (which need a tolerance above 0.0005, by the way). Namely, some of the
> > coefficients printed by Gaussian have different signs than the ones printed
> > by GAMESS (observe also that the ones given by Jaguar are consistently with
> > an extra minus compared to GAMESS). This is probably due to the symmetry
> > type (A1, B1, A2, ...). I don't know what the relation is, however, and we
> > should standardize this. Any ideas? Notice that the appropriate new test in
> > testCI.py fails.
>
> After some thought and conversations with colleagues, I can't think of any
> physical/chemical reason that the coefficients would have different signs.
> After all, only their squares have meaning in terms of the Hamiltonian - so
> their sign could be the byproduct of numerical assumptions in the code.

I don't know anything more about this than you, but the magical
'phase' value of + or - comes up often when solving calculations. For
example, the IR vibrational displacements can have opposite signs in
different programs. So the O-H stretch can become an O-H squeeze. They
are conceptually equivalent, but depending on the eigenvector solver
(or something) that you use, the signs can turn out differently.

> The sign, however, should influence the transition moments and so also the
> oscillator strengths.
Are you sure? In my mind, the secs are a mathematical construction
that gives a solution to the TD-DFT or CI calculation. It is the sign
of *this* single solution that is important. After all, there is a
single oscillator strength associated with the solution, not several
oscillator strengths, one for each sec. Again, I don't know much about
this. :-)

>I'm not too surprised that Gaussian and GAMESS give
> entirely different trnsition dipoles and oscillator strengths (compare the
> water_cis jobs in both programs). An I mean entirely - Gaussian often gives
> zero (0.0000) where GAMESS gives significantly non-zero numbers. In Jaguar,
> again different numbers - although here they qualitively agree with those in
> GAMESS and so might result from numerical differences. I don't understand
> this, or I'm not reading the numbers right.
I think we're hitting the limit of our knowledge here. :-)

> These considerations may not be what cclib is about, but I guess it's
> important for cclib to parse consistently - and probably to only parse things
> that are consistent?
The first is true, but I don't agree with the second. Different
programs might simply be using different algorithms to calculate the
same quantity. What we want to do is to take that information and
present it faithfully to the user so that they can analyse it. It is a
different question to compare and contrast the output of different
comp chem packages...perhaps that's another paper (although I
recommend reading the Gaussian license first of all)!

> Karol
>
> --
> written by Karol Langner
> Wed Mar 28 01:06:11 CEST 2007
>

Re: [cclib-devel] ADF output error again

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

On 28/03/07, Adam Tenderholt <a-t...@st...> wrote:
> > From what I understand from the manual, ADF handles
> > orthogonalization of valence orbitals with frozen core orbitals with
> > a set of Core Functions (which are distinct from the core orbitals).
> > If you look at the overlap matrix for the SIGMA symmetry basis
> > function, you see that it only uses 27-42. Normally these aren't
> > included in the output file, but there was a keyword specified to
> > include them. I'm re-running the file without it to see if it fixes
> > the parse error.
>
> I've uploaded a new Au2 logfile to the website, but I couldn't put it
> in the ADF2006.01 directory because I didn't have permissions (Noel,
> can you take care of this and regressionfiles.txt).
Sorry about that - I've changed the directory permissions and moved
the files into the correct location. Could you run "chmod a+r" on the
output file?

Does this mean that you have access to ADF2006.01 also? If so, it
would be nice to get the output of a TD-DFT calculation on dvb at some
stage.

> I removed the
> keyword that prints the CF moceoffs and it now finishes correctly. A
> Mulliken analysis using PyMOlyze gives approximately the same LUMO
> composition as is printed in the logfile (there are always slight
> differences since ADF doesn't print every contribution), so
> everything should be ok.
Great.

> Adam
>
>
> -------------------------------------------------------------------------
> 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] ADF output error again

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

On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote:
> I've uploaded a new Au2 logfile to the website, but I couldn't put it
> in the ADF2006.01 directory because I didn't have permissions (Noel,
> can you take care of this and regressionfiles.txt). I removed the
> keyword that prints the CF moceoffs and it now finishes correctly. A
> Mulliken analysis using PyMOlyze gives approximately the same LUMO
> composition as is printed in the logfile (there are always slight
> differences since ADF doesn't print every contribution), so
> everything should be ok.

So the question is how we should handle the core functions - just skip them?

-- 
written by Karol Langner
Wed Mar 28 11:12:09 CEST 2007