cclib-devel — Developer's mailing list

Re: [cclib-devel] ADF output error again

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

On Wednesday 28 of March 2007 02:12, Adam Tenderholt wrote:
> > I commited a revision that parses the irrep subspecies from the
> > output and
> > stores them in a list called 'irreps' (each element one irrep). I
> > also added
> > a tweak for normalisedegenerates() and the part that parses
> > mocoeffs and
> > mosyms (only restricted variant now), so that any set of subspecies
> > is used
> > for repeating the parsed energies. A dict is created before that to
> > add to
> > mosyms, which is passed to normalisedegenerates()  as a optional
> > argument.
> > All the tests still pass, but if I broke something don't hesitate
> > to revert
> > this, since I'm not into ADF too much yet.
>
> Do you know what the problem with parsing the Frags_NiCO4_orig.out
> file was before you made this commit?

No, I don't. Up to now, I've only looked at Au2.out. The error printed 
suggests that it has something to do with symemtry labels?:

 File 
"/home/langner/apps/python/lib/python2.5/site-packages/cclib/parser/adfparser.py", 
line 664, in extract
    aolist = symlist[sym][spin]
KeyError: 'SIGMA'


> > However, after these changes the jobs we have trouble with still
> > don't get
> > parsed. Notice that the number of SFOs in each irrep listed in the
> > table with
> > MO coefficients is not the same as that given in the section
> > describing the
> > SFOs (for example, 42 versus 16 for SIGMA.g in 'Au2.out'). I think
> > this is
> > the heart of the problem, at least  in this case, and I don't
> > understand it.
>
>  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 had no idea about this.

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

Re: [cclib-devel] ADF output error again

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

> 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). 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.

Adam

Re: [cclib-devel] ADF output error again

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

> I commited a revision that parses the irrep subspecies from the  
> output and
> stores them in a list called 'irreps' (each element one irrep). I  
> also added
> a tweak for normalisedegenerates() and the part that parses  
> mocoeffs and
> mosyms (only restricted variant now), so that any set of subspecies  
> is used
> for repeating the parsed energies. A dict is created before that to  
> add to
> mosyms, which is passed to normalisedegenerates()  as a optional  
> argument.
> All the tests still pass, but if I broke something don't hesitate  
> to revert
> this, since I'm not into ADF too much yet.

Do you know what the problem with parsing the Frags_NiCO4_orig.out  
file was before you made this commit?

> However, after these changes the jobs we have trouble with still  
> don't get
> parsed. Notice that the number of SFOs in each irrep listed in the  
> table with
> MO coefficients is not the same as that given in the section  
> describing the
> SFOs (for example, 42 versus 16 for SIGMA.g in 'Au2.out'). I think  
> this is
> the heart of the problem, at least  in this case, and I don't  
> understand it.

 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.

Adam

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

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

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.

The sign, however, should influence the transition moments and so also the 
oscillator strengths. 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.

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?

Karol

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

Re: [cclib-devel] etsecs conversions

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

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?).

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.

Karol

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

Re: [cclib-devel] etsecs conversions

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

On 27/03/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 27 of March 2007 16:28, Noel O'Boyle wrote:
> > On 27/03/07, Karol Langner <kar...@kn...> wrote:
> > > Another note: jaguar prints the coefficients squared and doubled, just
> > > like they were calculated by the Gaussian parser.
> >
> > Is the original sign included? If not, then it's obviously not
> > possible to use the original 'unsquared' numbers.
>
> I wrote too quickly... jaguar does something more: the original coefficients
> (read parser-wise the ones offered by GAMESS/Gaussian) are effecctively
> squared, doubled, square-rooted, and multiplied times the original sign....
> that is, they are scaled by a factor of 2.0^0.5. Since alpha/beta electron
> excitations have the same sign for singlet states, it is possible to
> reproduce the original number.
>
> The only question that remains is what do we want to put in etsecs in the end?
> Both alpha and beta excitations, even if they are not printed?

Seems fine to me

BTW, will get to you on parser refactoring as soon as possible. I want
to take a quick look over the branch code first...

> Karol
>
> --
> written by Karol Langner
> Tue Mar 27 17:38:28 CEST 2007
>

Re: [cclib-devel] etsecs conversions

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

On Tuesday 27 of March 2007 16:28, Noel O'Boyle wrote:
> On 27/03/07, Karol Langner <kar...@kn...> wrote:
> > Another note: jaguar prints the coefficients squared and doubled, just
> > like they were calculated by the Gaussian parser.
>
> Is the original sign included? If not, then it's obviously not
> possible to use the original 'unsquared' numbers.

I wrote too quickly... jaguar does something more: the original coefficients 
(read parser-wise the ones offered by GAMESS/Gaussian) are effecctively 
squared, doubled, square-rooted, and multiplied times the original sign.... 
that is, they are scaled by a factor of 2.0^0.5. Since alpha/beta electron 
excitations have the same sign for singlet states, it is possible to 
reproduce the original number.

The only question that remains is what do we want to put in etsecs in the end? 
Both alpha and beta excitations, even if they are not printed?

Karol

-- 
written by Karol Langner
Tue Mar 27 17:38:28 CEST 2007

Re: [cclib-devel] etsecs conversions

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

On 27/03/07, Karol Langner <kar...@kn...> wrote:
> Another note: jaguar prints the coefficients squared and doubled, just like
> they were calculated by the Gaussian parser.

Is the original sign included? If not, then it's obviously not
possible to use the original 'unsquared' numbers.

> --
> written by Karol Langner
> Tue Mar 27 17:23:44 CEST 2007
>

Re: [cclib-devel] etsecs conversions

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

Another note: jaguar prints the coefficients squared and doubled, just like 
they were calculated by the Gaussian parser.

-- 
written by Karol Langner
Tue Mar 27 17:23:44 CEST 2007

Re: [cclib-devel] etsecs conversions

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

On Tuesday 27 of March 2007 14:38, Noel O'Boyle wrote:
> Sorry - I should have been more clear. They almost sum to 1, and so an
> assertInside would still be a useful test since if the values sum to
> something quite different than 1, there is some problem. However, may
> I suggest redefining etsecs to use the original positive or negative
> coefficients. The test should use the squared values though. I know we
> shouldn't redefine the API in a point release, but I feel no
> responsibility towards API attributes that we didn't test rigourously.

Right, etsecs is not defined anywhere yet (neither on the wiki, nor in any 
comments, I think). I'll change it, then, and add something to the wiki. How 
should we handle alpha/beta electrons? Should the GAMESS parser only read in 
the alpha coefficients? Or should the Gaussian parser add beta coefficient 
even if they re not printed?

-- 
written by Karol Langner
Tue Mar 27 17:16:39 CEST 2007

Re: [cclib-devel] etsecs conversions

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

On Tuesday 27 of March 2007 14:38, Noel O'Boyle wrote:
> On 27/03/07, Karol Langner <kar...@kn...> wrote:
> > On Tuesday 27 of March 2007 14:21, Noel O'Boyle wrote:
> > > This code may be old and creaky, but the general idea was as follows:
> > >
> > > (1) You multiply by two because for an excitation from a
> > > doubly-occupied orbital there are two excitations in fact...one
> > > involving the alpha electron and one involving the beta electron. For
> > > an unrestricted calculation, you shouldnt multiple by two.
> >
> > GAMESS, for example, prints the excitations of both alpha nad beta
> > electrons, even for restricted calculations (see test file
> > "water_cis.out"). The coefficients alpha and beta electrons are always
> > the same.
> >
> > > (2) You square because that is the definition of etsecs. It is a
> > > somewhat arbitary definition so I am happy to change it. The idea is
> > > that these sqr values somehow represent the fractional contribution of
> > > a particular SEC to the whole transition. Unfortunately, at least in
> > > TD-DFT, this is almost but not exactly true (i.e. these fractional
> > > contributions dont add to 1). In fact, this is probably a good unit
> > > test to have to make sure that all parsers are doing the same thing.
> >
> > So we can't really test if they sum up to 1, since they don't :)
>
> Sorry - I should have been more clear. They almost sum to 1, and so an
> assertInside would still be a useful test since if the values sum to
> something quite different than 1, there is some problem. However, may
> I suggest redefining etsecs to use the original positive or negative
> coefficients. The test should use the squared values though. I know we
> shouldn't redefine the API in a point release, but I feel no
> responsibility towards API attributes that we didn't test rigourously.

OK, I understand.

> > Another point: as far as I can see, there's no way to force Jaguar to
> > print out triplet excited states.
>
> You're saying that it is possible to do the calculation, but just not
> print out the results?

No, that is a logical mistake on my part.

-- 
written by Karol Langner
Tue Mar 27 17:12:37 CEST 2007

Re: [cclib-devel] etsecs conversions

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

On 27/03/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 27 of March 2007 14:21, Noel O'Boyle wrote:
> > This code may be old and creaky, but the general idea was as follows:
> >
> > (1) You multiply by two because for an excitation from a
> > doubly-occupied orbital there are two excitations in fact...one
> > involving the alpha electron and one involving the beta electron. For
> > an unrestricted calculation, you shouldnt multiple by two.
>
> GAMESS, for example, prints the excitations of both alpha nad beta electrons,
> even for restricted calculations (see test file "water_cis.out"). The
> coefficients alpha and beta electrons are always the same.
>
> > (2) You square because that is the definition of etsecs. It is a
> > somewhat arbitary definition so I am happy to change it. The idea is
> > that these sqr values somehow represent the fractional contribution of
> > a particular SEC to the whole transition. Unfortunately, at least in
> > TD-DFT, this is almost but not exactly true (i.e. these fractional
> > contributions dont add to 1). In fact, this is probably a good unit
> > test to have to make sure that all parsers are doing the same thing.
>
> So we can't really test if they sum up to 1, since they don't :)

Sorry - I should have been more clear. They almost sum to 1, and so an
assertInside would still be a useful test since if the values sum to
something quite different than 1, there is some problem. However, may
I suggest redefining etsecs to use the original positive or negative
coefficients. The test should use the squared values though. I know we
shouldn't redefine the API in a point release, but I feel no
responsibility towards API attributes that we didn't test rigourously.

> Another point: as far as I can see, there's no way to force Jaguar to print
> out triplet excited states.
You're saying that it is possible to do the calculation, but just not
print out the results?

> Karol
>
> --
> written by Karol Langner
> Tue Mar 27 15:25:35 CEST 2007
>

Re: [cclib-devel] etsecs conversions

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

On Tuesday 27 of March 2007 14:21, Noel O'Boyle wrote:
> This code may be old and creaky, but the general idea was as follows:
>
> (1) You multiply by two because for an excitation from a
> doubly-occupied orbital there are two excitations in fact...one
> involving the alpha electron and one involving the beta electron. For
> an unrestricted calculation, you shouldnt multiple by two.

GAMESS, for example, prints the excitations of both alpha nad beta electrons, 
even for restricted calculations (see test file "water_cis.out"). The 
coefficients alpha and beta electrons are always the same.

> (2) You square because that is the definition of etsecs. It is a
> somewhat arbitary definition so I am happy to change it. The idea is
> that these sqr values somehow represent the fractional contribution of
> a particular SEC to the whole transition. Unfortunately, at least in
> TD-DFT, this is almost but not exactly true (i.e. these fractional
> contributions dont add to 1). In fact, this is probably a good unit
> test to have to make sure that all parsers are doing the same thing.

So we can't really test if they sum up to 1, since they don't :)

Another point: as far as I can see, there's no way to force Jaguar to print 
out triplet excited states.

Karol

-- 
written by Karol Langner
Tue Mar 27 15:25:35 CEST 2007

Re: [cclib-devel] etsecs conversions

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

This code may be old and creaky, but the general idea was as follows:

(1) You multiply by two because for an excitation from a
doubly-occupied orbital there are two excitations in fact...one
involving the alpha electron and one involving the beta electron. For
an unrestricted calculation, you shouldnt multiple by two.

(2) You square because that is the definition of etsecs. It is a
somewhat arbitary definition so I am happy to change it. The idea is
that these sqr values somehow represent the fractional contribution of
a particular SEC to the whole transition. Unfortunately, at least in
TD-DFT, this is almost but not exactly true (i.e. these fractional
contributions dont add to 1). In fact, this is probably a good unit
test to have to make sure that all parsers are doing the same thing.

Noel

On 27/03/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
> The fragment  of the Gaussian parser that reads etsecs:
>
>                   percent = self.float(t[1])
>                   sqr = percent**2*2 # The fractional contribution of this CI
>                   if percent < 0:
>                       sqr = -sqr
>
>  Why are the excitation coefficients squared and multiplied by 2?
>
> Karol
>
> --
> written by Karol Langner
> Tue Mar 27 10:52:43 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] etsecs conversions

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

Hi,

The fragment  of the Gaussian parser that reads etsecs:

                  percent = self.float(t[1])
                  sqr = percent**2*2 # The fractional contribution of this CI
                  if percent < 0:
                      sqr = -sqr

 Why are the excitation coefficients squared and multiplied by 2?

Karol

-- 
written by Karol Langner
Tue Mar 27 10:52:43 CEST 2007

Re: [cclib-devel] parser-refactoring

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

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

Re: [cclib-devel] parser-refactoring

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

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

Re: [cclib-devel] parser-refactoring

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

Now that 0.7 is out, I wanted to return to the discussion about refactoring 
the parsers. The 'parser-refactoring' branch has a working version of the new 
Gaussian parser that I wrote up some time ago.

The major change is that the parser loop is in the LogFile class, and calls 
the method of the child class (i called it "_extract"). This allows generic 
changes to be done to all the parsers in parallel. Temporary variables need 
to be attributes in order to survive between iterations, and I added code 
that deletes them after parsing (everything that's not in _attrlist and 
wasn't there before parsing).

There are a few other additions that should make writing parsers easier. For 
example, the __setattr__ can take care of issuing messages to the logger when 
new attributes are created. Most of these smaller changes can and probalby 
should be discussed separately.

Let me know how you feel about how to proceed. I would prefer not to work too 
long in a branch on something that is so fundamental to cclib (not like a 
new, specific parser) where the files keep changing. I think it would be more 
efficient and reasonable to stretch out the "refactoring" but keep it alive. 
That is, to take up one issue at a time on this list and to work in small 
steps in the trunk (following consensus).

Karol

-- 
written by Karol Langner
Mon Mar 26 16:30:38 CEST 2007

Re: [cclib-devel] Question about r588

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

> Exactly, I outlined that keyword on the wiki:
> http://cclib.sourceforge.net/wiki/index.php/Moenergies

Right. It also means that the MPA and CSPA methods need to be fixed  
to handle cases where len(mocoeffs[0]) != len(mocoeffs[1]) and len 
(mocoeffs[0]) != nbasis. There may also be other methods, like OPA,  
that don't need every virtual orbital which will also need to be fixed.

Adam

Re: [cclib-devel] Question about r588

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

On Saturday 24 of March 2007 01:31, Adam Tenderholt wrote:
> > Does this mean that you're throwing away some of the mocoeffs that
> > you've parsed? Or do you simply mean that the parser was previously
> > looking for mocoeffs that didn't exist?
>
> There's an option (ipvirt) in Jaguar where you can tell it to print
> all of the virtual orbitals or a specific number. So the parser was
> previously looking for mocoeffs for high-energy virtual orbitals that
> weren't in the logfile.
>
> Adam

Exactly, I outlined that keyword on the wiki:
http://cclib.sourceforge.net/wiki/index.php/Moenergies

-- 
written by Karol Langner
Sat Mar 24 10:08:41 CET 2007

Re: [cclib-devel] Question about r588

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

> Does this mean that you're throwing away some of the mocoeffs that
> you've parsed? Or do you simply mean that the parser was previously
> looking for mocoeffs that didn't exist?

There's an option (ipvirt) in Jaguar where you can tell it to print  
all of the virtual orbitals or a specific number. So the parser was  
previously looking for mocoeffs for high-energy virtual orbitals that  
weren't in the logfile.

Adam

[cclib-devel] Question about r588

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

Log:
"""Jaguar parser: Make mocoeffs dimensions be based on the size of
moenergies[0] and [1]; only for unrestricted right now. Doesn't break
any test files and fixes files where only some of the virtual orbitals
are printed."""

Does this mean that you're throwing away some of the mocoeffs that
you've parsed? Or do you simply mean that the parser was previously
looking for mocoeffs that didn't exist?

Noel

Re: [cclib-devel] ADF output error again

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

On Tuesday 20 of March 2007 22:53, Karol Langner wrote:
> On Tuesday 20 of March 2007 22:29, Adam Tenderholt wrote:
> > > OK, I see that now, but don't know how to fix it. I did just submit
> > > a little
> > > fix for the code that parses mocoeff, although I'm not sure I relly
> > > fixed
> > > anything (looks nicer, though).
> >
> > Nor do I. I'm a bit busy right now, but I'll keep it in the back of
> > my mind and hopefully think of a fix soon.
> >
> > Adam
>
> I have an idea. There is a "SYMMETRY, ELECTRONS" section in the output, in
> two places - the second one is after building the fragments or
> something(?). Anyways, it looks like this the second time around for Nuno's
> "Au2.out":
>
> =====================================
>  S Y M M E T R Y ,   E L E C T R O N S
>  =====================================
>
>  Symmetry: D(LIN)
>
>  Irreducible Representations, including subspecies
>  -------------------------------------------------
>  SIGMA.g
>  SIGMA.u
>  PI.g:x  PI.g:y
>  PI.u:x  PI.u:y
>  DELTA.g:x2-y2  DELTA.g:xy
>  DELTA.u:x2-y2  DELTA.u:xy
>  PHI.g:x3-3xy2  PHI.g:3x2y-y3
>  PHI.u:x3-3xy2  PHI.u:3x2y-y3
>
> ...which should work nicely for counting the number of irreducible
> representations, I think.
>
> I don't think I understand where the mocoeffs are read in for ADF,
> though..... the attribute, together with mosyms, is parsed when "Orbital
> Energies, all Irreps" is found on some line - and this, again, happens
> twice. As it turns out, the second one is not parsed (there's an 'and not
> hasattr(self, "mosyms")' addition to the parsing condition. Is this
> correct? I wonder, because these energies are different, and the MO
> coefficients are printed only once, after the second MO energies output.
> This is all because I'm not oriented much with ADF.
>
> Karol

After looking through the parser code a bit, I understand now that the first 
print-out is from the reate job and therefore is'nt parsed.

I commited a revision that parses the irrep subspecies from the output and 
stores them in a list called 'irreps' (each element one irrep). I also added 
a tweak for normalisedegenerates() and the part that parses mocoeffs and 
mosyms (only restricted variant now), so that any set of subspecies is used 
for repeating the parsed energies. A dict is created before that to add to 
mosyms, which is passed to normalisedegenerates()  as a optional argument. 
All the tests still pass, but if I broke something don't hesitate to revert 
this, since I'm not into ADF too much yet.

However, after these changes the jobs we have trouble with still don't get 
parsed. Notice that the number of SFOs in each irrep listed in the table with 
MO coefficients is not the same as that given in the section describing the 
SFOs (for example, 42 versus 16 for SIGMA.g in 'Au2.out'). I think this is 
the heart of the problem, at least  in this case, and I don't understand it.

Cheers,
Karol

-- 
written by Karol Langner
Fri Mar 23 13:41:36 CET 2007

Re: [cclib-devel] svn status

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

I manually set the property 'svn:ignore' on the other directories to avoid this.

On 23/03/07, Karol Langner <kar...@kn...> wrote:
> When I run 'svn status' in my cclib trunk, I get:
>
> ?      data/ADF/ADF2006.01
>
> This directory was created by the script that download the regression files.
> How come the other regression file paths don't appear here, only this one?
>
> Karol
>
> --
> written by Karol Langner
> Fri Mar 23 12:16:53 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] Fwd: CCL:G: ANN: cclib 0.7 released

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

---------- Forwarded message ----------
From: J=E9r=F4me Kieffer <jer...@te...>
Date: 23-Mar-2007 11:22
Subject: Re: CCL:G: ANN: cclib 0.7 released
To: bao...@gm...


Dear John,


>> Interresting ...
>> but it crashes on a Jaguar 6.5 out-file :(
>Schrodinger has just given cclib a year's licence for Jaguar 6.5.
>However, we haven't had any access to Jaguar for the last six months
>so, as you found, the parser is not quite 100% bug-free. :-)

I just tested it as I had a dozen of files to analyse ...
[results]$ ccget  -l TS-M-SSR-H.01.out
Attempting to parse TS-M-SSR-H.01.out
Traceback (most recent call last):
  File "/usr/bin/ccget", line 95, in ?
    main()
  File "/usr/bin/ccget", line 77, in main
    log.parse()
  File
"/usr/lib/python2.4/site-packages/cclib/parser/logfileparser.py", line
116, in parse
    self.extract(inputfile, fupdate=3Dfupdate, cupdate=3Dcupdate)
  File "/usr/lib/python2.4/site-packages/cclib/parser/jaguarparser.py",
line 151, in extract
    if line[41] =3D=3D "(":
IndexError: string index out of range



>
>Could you describe the error message that occurs, and  send me a .zip
>file of the input and output file that caused the problem? Please note
>that by sending me these files, you agree to place these files in the
>public domain (i.e. freely accessible to anyone). If you are not happy
>with this, please send me some other test file that exhibits the same
>problem, and which you *are* happy to place in the public domain.

I will do this =ABsoon=BB. You can imagine I am not allowd to send you the
files.


>> I wrote a wrapper to read =ABCAChe=BB CSF files, but it is neither
>> complete, nor =ABpublishable=BB as my code is rather ugly. Nevertheless
>> you could be interested in incorporating it in a futur release of CClib.
>We are always interested in expanding cclib. However, since none of
>the core developers have access to CAChe, you would have to get
>involved to maintain that code (I assume the code is written in
>Python?). If you are interested, we would be happy to help you get
>involved and 'show you the ropes'.

Here is the code ... (quick & dirty code)

>...the only problem is, after some googling I cannot find out whether
>CAChe is still available. It seems like CAChe Scientific by bought by
>Oxford Molecular which was bought by Accelrys...but I don't know what
>has happened to the CAChe software. Here is the Accelrys page:
>   http://www.accelrys.com/solutions/compchem/

CAChe is currently developped by Fujitsu and sold in Europe by a polish
company named FQS.
http://www.fqs.pl/chemistry/cache/overview




--
Jerome Kieffer