cclib-devel Mailing List for cclib

Which Jaguar version are you looking at? I think my colleague just  
used the basis functions she normally uses for her calcs when she ran  
the Jaguar 6.0 calcs.

Also, as I recall, the MO coeffs aren't printed for the Jaguar 4.2  
files, but I may be mistaken.

Adam

On Jan 31, 2007, at 6:35 AM, Karol Langner wrote:

> The only thing I can imagine right now is that there is an additional
> contraction, or that the linear combination is summed somewhat  
> differently
> than normal. I don't use the program myself, so I don't have the  
> means to ask
> the Jaguar people, as I understand you must have a liscence to do so.
>
> Karol
>
> On Wednesday 31 of January 2007 15:28, you wrote:
>> Yes, there are problems with gbasis for Jaguar. First I want to  
>> finish
>> volume.py, though. I'll come back to this though and we can talk it
>> through. If you have any ideas in the meantime I'd be happy to hear
>> them.
>>
>> On 31/01/07, Karol Langner <kar...@kn...> wrote:
>>> Hi,
>>>
>>>  I'm wondering about the basis sets output by Jaguar... they have me
>>> stumped, since the contraction coefficients for the SP gaussian
>>> primitives are totally different than those given by GAMESS and  
>>> Gaussian.
>>>
>>>  Compare the STO-3G function for carbon that I found in the cclib  
>>> test
>>> logfiles.
>>>
>>> Gaussian:
>>>  S   3 1.00       0.000000000000
>>>       0.7161683735D+02  0.1543289673D+00
>>>       0.1304509632D+02  0.5353281423D+00
>>>       0.3530512160D+01  0.4446345422D+00
>>>  SP   3 1.00       0.000000000000
>>>       0.2941249355D+01 -0.9996722919D-01  0.1559162750D+00
>>>       0.6834830964D+00  0.3995128261D+00  0.6076837186D+00
>>>       0.2222899159D+00  0.7001154689D+00  0.3919573931D+00
>>>
>>> Jaguar:
>>>              s    j
>>>              h    c  i       n
>>>              e    o  s       f
>>>              l    n  h       s
>>>   atom       l    t  l  l    h          z              coef
>>> rcoef --------    ---  --- -- --  ---     ----------      ----------
>>>  --------- C1          1    3  0  1    0      71.6168373        
>>> 0.1543290
>>>      2.7078144 C1          2   -1  0  1    0      13.0450963
>>> 0.5353281       2.6188802 C1          3   -1  0  1    0        
>>> 3.5305122
>>>     0.4446345       0.8161906 C1          4    2  2  1    1
>>> 2.9412494      -0.2956454      -0.4732386 C1          5   -4  2   
>>> 1    1
>>>     0.6834831       1.1815287       0.6329949 C1          6    2  
>>> -1  2
>>> 2       2.9412494       0.2213487       1.2152952 C1          7    
>>> -6 -1
>>> 2    2       0.6834831       0.8627064       0.7642102  
>>> C1          8    1
>>>  1  1    1       0.2222899       1.0000000       0.2307278  
>>> C1          9
>>>   1 -1  2    2       0.2222899       1.0000000       0.2175654
>>>
>>> The coefficient for the S shells are the same, but the ones for  
>>> SP are
>>> not. Does anybody know how to explain this, and eventually how to
>>> interconvert? I assume that the STO-3G functions used in both  
>>> programs
>>> are identical, so it should be possible. Or, where should I ask  
>>> about
>>> this? Maybe this is the reason why there's no gbasis attribute  
>>> for the
>>> Jaguar parser yet?
>>>
>>> Karol
>
> -- 
> written by Karol Langner
> Wed Jan 31 15:32:18 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

On Friday 26 of January 2007 09:00, Noel O'Boyle wrote:
> Both myself and Adam are also thinking of our own programs, which will
> also need to be adjusted. They will already have to be changed
> slightly to deal with the redefinition of mocoeffs and a couple of
> other attributes.
>
> What this adds up to is that if nobody disagrees, this will be the
> first thing we'll do after the next release.
>
> Noel

One more thing: from Numeric 24.2 onwards, there generally is supposed to be 
no major problems with passing numpy arrays to Numeric. There was a thread 
about this a couple of days ago on the Numpy-discussion mailing list.

I'm not pushing for the conversion to be sooner, just wanted to make sure you 
know that your cclib-dependent programs will probably still work fine after a 
cclib upgrade if they are not upgraded themselves.

Karol

-- 
written by Karol Langner
Wed Jan 31 17:01:12 CET 2007

The first priority is figuring out the H coefficients...here's the
current situation for STO-3G:

PyQuante

basis_data = [
   14     None,
   15     [#H
   16     ('S',[
   17         (3.425251, 0.154329),
   18         (0.623914, 0.535328),
   19         (0.168855, 0.444635),
   20         ]),
   21     ],

The normalised coefficients for the primitives (each on their own) are:
    0.2769
    0.2678
    0.0835


GAMESS-UK

exponents, then contraction coefficients

 h


                14   1s      19        3.425251       0.276934  (    0.154329  )
                14   1s      20        0.623914       0.267839  (    0.535328  )
                14   1s      21        0.168855       0.083474  (    0.444635  )

Jag 4.2

 H6          1    2  0  1   25       3.4252509       0.2405014       0.4315658
 H6          2   -1  0  1   25       0.6239137       0.8342385       0.4173916
 H6          3    1  0  1   25       0.1688554       1.0000000       0.1877355

Normalised coefficients
 H6          1    S   26       3.425251     0.431566
 H6          2    S   26       0.623914     0.417392
 H6          3    S   26       0.168855     0.187735


GAMESS

H

     13   S      37             3.4252509    0.154328967295
     13   S      38             0.6239137    0.535328142282
     13   S      39             0.1688554    0.444634542185

PC-GAMESS

 THE CONTRACTED PRIMITIVE FUNCTIONS HAVE BEEN UNNORMALIZED
 THE CONTRACTED BASIS FUNCTIONS ARE NOW NORMALIZED TO UNITY

 H

  22   S   31       3.425251    0.276934 (  0.154329)
  22   S   32       0.623914    0.267839 (  0.535328)
  22   S   33       0.168855    0.083474 (  0.444635)


G03

 Atom H7       Shell    12 S   3     bf   27 -    27
-4.468771508880          1.536663462131          0.000000000000
      0.3425250914D+01  0.1543289673D+00
      0.6239137298D+00  0.5353281423D+00
      0.1688554040D+00  0.4446345422D+00

The only thing I can imagine right now is that there is an additional 
contraction, or that the linear combination is summed somewhat differently 
than normal. I don't use the program myself, so I don't have the means to ask 
the Jaguar people, as I understand you must have a liscence to do so.

Karol

On Wednesday 31 of January 2007 15:28, you wrote:
> Yes, there are problems with gbasis for Jaguar. First I want to finish
> volume.py, though. I'll come back to this though and we can talk it
> through. If you have any ideas in the meantime I'd be happy to hear
> them.
>
> On 31/01/07, Karol Langner <kar...@kn...> wrote:
> > Hi,
> >
> >  I'm wondering about the basis sets output by Jaguar... they have me
> > stumped, since the contraction coefficients for the SP gaussian
> > primitives are totally different than those given by GAMESS and Gaussian.
> >
> >  Compare the STO-3G function for carbon that I found in the cclib test
> > logfiles.
> >
> > Gaussian:
> >  S   3 1.00       0.000000000000
> >       0.7161683735D+02  0.1543289673D+00
> >       0.1304509632D+02  0.5353281423D+00
> >       0.3530512160D+01  0.4446345422D+00
> >  SP   3 1.00       0.000000000000
> >       0.2941249355D+01 -0.9996722919D-01  0.1559162750D+00
> >       0.6834830964D+00  0.3995128261D+00  0.6076837186D+00
> >       0.2222899159D+00  0.7001154689D+00  0.3919573931D+00
> >
> > Jaguar:
> >              s    j
> >              h    c  i       n
> >              e    o  s       f
> >              l    n  h       s
> >   atom       l    t  l  l    h          z              coef           
> > rcoef --------    ---  --- -- --  ---     ----------      ----------     
> >  --------- C1          1    3  0  1    0      71.6168373       0.1543290 
> >      2.7078144 C1          2   -1  0  1    0      13.0450963      
> > 0.5353281       2.6188802 C1          3   -1  0  1    0       3.5305122  
> >     0.4446345       0.8161906 C1          4    2  2  1    1      
> > 2.9412494      -0.2956454      -0.4732386 C1          5   -4  2  1    1  
> >     0.6834831       1.1815287       0.6329949 C1          6    2 -1  2   
> > 2       2.9412494       0.2213487       1.2152952 C1          7   -6 -1 
> > 2    2       0.6834831       0.8627064       0.7642102 C1          8    1
> >  1  1    1       0.2222899       1.0000000       0.2307278 C1          9 
> >   1 -1  2    2       0.2222899       1.0000000       0.2175654
> >
> > The coefficient for the S shells are the same, but the ones for SP are
> > not. Does anybody know how to explain this, and eventually how to
> > interconvert? I assume that the STO-3G functions used in both programs
> > are identical, so it should be possible. Or, where should I ask about
> > this? Maybe this is the reason why there's no gbasis attribute for the
> > Jaguar parser yet?
> >
> > Karol

-- 
written by Karol Langner
Wed Jan 31 15:32:18 CET 2007

Yes, there are problems with gbasis for Jaguar. First I want to finish
volume.py, though. I'll come back to this though and we can talk it
through. If you have any ideas in the meantime I'd be happy to hear
them.

On 31/01/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  I'm wondering about the basis sets output by Jaguar... they have me stumped,
> since the contraction coefficients for the SP gaussian primitives are totally
> different than those given by GAMESS and Gaussian.
>
>  Compare the STO-3G function for carbon that I found in the cclib test
> logfiles.
>
> Gaussian:
>  S   3 1.00       0.000000000000
>       0.7161683735D+02  0.1543289673D+00
>       0.1304509632D+02  0.5353281423D+00
>       0.3530512160D+01  0.4446345422D+00
>  SP   3 1.00       0.000000000000
>       0.2941249355D+01 -0.9996722919D-01  0.1559162750D+00
>       0.6834830964D+00  0.3995128261D+00  0.6076837186D+00
>       0.2222899159D+00  0.7001154689D+00  0.3919573931D+00
>
> Jaguar:
>              s    j
>              h    c  i       n
>              e    o  s       f
>              l    n  h       s
>   atom       l    t  l  l    h          z              coef            rcoef
> --------    ---  --- -- --  ---     ----------      ----------       ---------
>  C1          1    3  0  1    0      71.6168373       0.1543290       2.7078144
>  C1          2   -1  0  1    0      13.0450963       0.5353281       2.6188802
>  C1          3   -1  0  1    0       3.5305122       0.4446345       0.8161906
>  C1          4    2  2  1    1       2.9412494      -0.2956454      -0.4732386
>  C1          5   -4  2  1    1       0.6834831       1.1815287       0.6329949
>  C1          6    2 -1  2    2       2.9412494       0.2213487       1.2152952
>  C1          7   -6 -1  2    2       0.6834831       0.8627064       0.7642102
>  C1          8    1  1  1    1       0.2222899       1.0000000       0.2307278
>  C1          9    1 -1  2    2       0.2222899       1.0000000       0.2175654
>
> The coefficient for the S shells are the same, but the ones for SP are not.
> Does anybody know how to explain this, and eventually how to interconvert? I
> assume that the STO-3G functions used in both programs are identical, so it
> should be possible. Or, where should I ask about this? Maybe this is the
> reason why there's no gbasis attribute for the Jaguar parser yet?
>
> Karol
>
> --
> written by Karol Langner
> Wed Jan 31 14:00:32 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
>

Hi,

 I'm wondering about the basis sets output by Jaguar... they have me stumped, 
since the contraction coefficients for the SP gaussian primitives are totally 
different than those given by GAMESS and Gaussian.

 Compare the STO-3G function for carbon that I found in the cclib test 
logfiles.

Gaussian:
 S   3 1.00       0.000000000000
      0.7161683735D+02  0.1543289673D+00
      0.1304509632D+02  0.5353281423D+00
      0.3530512160D+01  0.4446345422D+00
 SP   3 1.00       0.000000000000
      0.2941249355D+01 -0.9996722919D-01  0.1559162750D+00
      0.6834830964D+00  0.3995128261D+00  0.6076837186D+00
      0.2222899159D+00  0.7001154689D+00  0.3919573931D+00

Jaguar:
             s    j
             h    c  i       n
             e    o  s       f
             l    n  h       s
  atom       l    t  l  l    h          z              coef            rcoef
--------    ---  --- -- --  ---     ----------      ----------       ---------
 C1          1    3  0  1    0      71.6168373       0.1543290       2.7078144
 C1          2   -1  0  1    0      13.0450963       0.5353281       2.6188802
 C1          3   -1  0  1    0       3.5305122       0.4446345       0.8161906
 C1          4    2  2  1    1       2.9412494      -0.2956454      -0.4732386
 C1          5   -4  2  1    1       0.6834831       1.1815287       0.6329949
 C1          6    2 -1  2    2       2.9412494       0.2213487       1.2152952
 C1          7   -6 -1  2    2       0.6834831       0.8627064       0.7642102
 C1          8    1  1  1    1       0.2222899       1.0000000       0.2307278
 C1          9    1 -1  2    2       0.2222899       1.0000000       0.2175654

The coefficient for the S shells are the same, but the ones for SP are not. 
Does anybody know how to explain this, and eventually how to interconvert? I 
assume that the STO-3G functions used in both programs are identical, so it 
should be possible. Or, where should I ask about this? Maybe this is the 
reason why there's no gbasis attribute for the Jaguar parser yet?

Karol

-- 
written by Karol Langner
Wed Jan 31 14:00:32 CET 2007

On Tuesday 30 of January 2007 17:39, Adam Tenderholt wrote:
> >> I have however, a different idea. What if .parse() were defined
> >> for the
> >> generic class LogFile, and it did all the "generic" things, and
> >> also called
> >> self.extract(), which would contain the "for line in
> >> self.inputfile" loop
> >> that is specific to each parser (effectively replacing the
> >> current.parse()).
> >> This way, we would have only one function more and all the
> >> benifits, and
> >> again no change for the user.
> >
> > Indeed, I prefer this too.
>
> I agree that this is a good idea. I also think ccopen and others
> should check to see if the logfile exists, and if not, print an error/
> warning about it.
>
> Adam

Well, to start this I added a parse() method to the LogFile class and renamed 
parse() to extract() in the parsers. Take a look if the general idea is 
suitable. If so, we can start moving things to the generic method.

I checked all the tests and regression tests - nothing broken.

Karol

-- 
written by Karol Langner
Wed Jan 31 00:38:48 CET 2007

This sounds very interesting. I am involved in a Python project called
cclib, http://cclib.sf.net, which sounds like it has several of the
same aims, although it currently does not parse Gaussian formatted
checkpoint files.

I would be interested in knowing exactly what the aims of your project
are, and whether there is some way we could work together.

Noel

>   I have seen recently that the Gaussian formatted checkpoint file
> format is not (yet) supported by OpenBabel. I have already programmed a
> parser (in Python), which can extract the following data :

>  1) geometry
>  2) Hessian
>  3) Raman / Raman optical activity data :
>   a) derivatives of the polarizability tensor (alpha)
>    b) derivatives of the optical rotation tensor (G')
>    c) derivatives of the D-Q polarizability tensor (A)

>  4) Infrared / vibrational circular dichroism data :
>   a) Derivatives of the electric dipole moment (APT)
>    b) Derivatives of the magnetic dipole moment (AAT)

>  It would be not a big problem to contribute a C++ code for OpenBabel. Tell me if someone still needs the support
> for the format and what exactly is desired. The Python code will be published (under GNU GPL) soon on sourceforge.net
> as a part of a library for visualizing vibrational Raman optical activity (VROA) data.


>  With best regards,
>  Maxim Fedorovsky.

>> I have however, a different idea. What if .parse() were defined  
>> for the
>> generic class LogFile, and it did all the "generic" things, and  
>> also called
>> self.extract(), which would contain the "for line in  
>> self.inputfile" loop
>> that is specific to each parser (effectively replacing the  
>> current.parse()).
>> This way, we would have only one function more and all the  
>> benifits, and
>> again no change for the user.
>
> Indeed, I prefer this too.

I agree that this is a good idea. I also think ccopen and others  
should check to see if the logfile exists, and if not, print an error/ 
warning about it.

Adam

Was this issue resolved in the end?

On 23/01/07, Adam Tenderholt <a-t...@st...> wrote:
> I have added some more code for the CDA method. It now reproduces the
> numbers (well, still off by a factor of two and am hopefully going to
> hear back from Frenking about this soon) that the C++ version of CDA
> gives. I have also created a wiki page on how to use it: http://
> cclib.sourceforge.net/wiki/index.php/Charge_Decomposition_Analysis
>
> I haven't tested my implementation against a "real" molecule with an
> appreciable number of basis functions, nor I have tested it against
> unrestricted S > 0 systems or fragments.
>
> 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
>

On 30/01/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 30 of January 2007 09:04, Noel O'Boyle wrote:
> > Some thoughts: The final conversion of attributes to arrays may be
> > different in each case, and so cannot be shared across parsers. Any
> > additional shared code, e.g. final progress update, should be called
> > from the end of the .parse(), rather than having the user call it.
>
> Can you give an example of when the conversion of attributes to arrays would
> be different between two parsers? I thought the idea was for attributes to be
> the same for all parsers.

The net effect is the same, but in some cases the attribute is created
as an array in the main loop, in others it is built up incremently as
a list of lists, and then converted afterwards, outside the loop. Also
found outside the loop are instances where if a particular attribute
has not been set, it is set to a default value.

But after thinking a bit, I guess you're right, the conversion code at
least can be moved into a common function. If moenergies is already an
array, and you try to convert it, it doesn't cause any harm.

> As to calling the function(s) I'm proposing, I wasn't thinking exactly what
> you said - calling them from the beginning/end of .parse(). The user sees no
> changes here.
>
> I have however, a different idea. What if .parse() were defined for the
> generic class LogFile, and it did all the "generic" things, and also called
> self.extract(), which would contain the "for line in self.inputfile" loop
> that is specific to each parser (effectively replacing the current.parse()).
> This way, we would have only one function more and all the benifits, and
> again no change for the user.

Indeed, I prefer this too.

Noel

On Tuesday 30 of January 2007 09:04, Noel O'Boyle wrote:
> Some thoughts: The final conversion of attributes to arrays may be
> different in each case, and so cannot be shared across parsers. Any
> additional shared code, e.g. final progress update, should be called
> from the end of the .parse(), rather than having the user call it.

Can you give an example of when the conversion of attributes to arrays would 
be different between two parsers? I thought the idea was for attributes to be 
the same for all parsers.

As to calling the function(s) I'm proposing, I wasn't thinking exactly what 
you said - calling them from the beginning/end of .parse(). The user sees no 
changes here.

I have however, a different idea. What if .parse() were defined for the 
generic class LogFile, and it did all the "generic" things, and also called 
self.extract(), which would contain the "for line in self.inputfile" loop 
that is specific to each parser (effectively replacing the current.parse()). 
This way, we would have only one function more and all the benifits, and 
again no change for the user.

Karol

Karol

-- 
written by Karol Langner
Tue Jan 30 09:43:45 CET 2007

I would now modify my earlier quote slightly...if you are working on a
new parser just create a new branch of the trunk and start hacking -
don't worry about removing the bridges, and other modules, which is
what I suggest below.

On 29/01/07, Karol Langner <kar...@kn...> wrote:
> On Monday 29 of January 2007 23:14, you wrote:
> > Hi Karol,
> >
> > Noel and I decided it made sense to move Molpro (and any new parsers)
> > to their own branch for development until they are stable and ready
> > for inclusion in a release. We discussed it on a previous thread
> > awhile back, but under a different name. Here is the relevant text
> > from Noel:
> >
> > "...I was suggesting that development for new parsers should be done
> > on a branch, e.g. the molpro parser branch. This would only have
> > tests and data files for
> > molpro, for instance, and wouldn't contain the bridges, methods, etc.
> > modules, so that development would be more focused (and the only
> > changes would be parser related). Since Jaguar is slated for
> > inclusion in the next release, I think it'd be easier at this stage
> > to leave it on the trunk and do the final development there."
>
> OK - I'll dig into the archives when needed.
>
> > Out of curiosity, what parser are you thinking of adding?
> >
> > Adam
>
> I was thinking about Molcas. Maybe also mpqc when I have more time, for fun.
>
> Karol
>
> --
> written by Karol Langner
> Mon Jan 29 23:39:46 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
>

Some thoughts: The final conversion of attributes to arrays may be
different in each case, and so cannot be shared across parsers. Any
additional shared code, e.g. final progress update, should be called
from the end of the .parse(), rather than having the user call it.

On 29/01/07, Karol Langner <kar...@kn...> wrote:
> It occurred to me that it might be beneficial to have two functions in the
> LogFile class that should be called before and after logfiles of any type are
> parsed. For instance, when working the GAMESS parser, I saw there was no
> final progress update and conversion of attributes to arrays. With these
> functions, that won't happen for any new parsers, changes can be made for all
> of them in one place, and the code will be clearer.
>
> Basically, everything in the parse() function of a parser before the "for line
> in inputfile" loop would go i nthe first function, and everything after in
> the second. As far as I can tell, there are no differences here between
> parsers, so is there a reason not to do this?
>
> To do this, however, inputfile, nstep, and oldstep (maybe something else,
> also?) need to be parser attributes.
>
> If this seems like a good idea, I'd be happy to do the necessary changes in a
> few days.
>
> Karol
>
> --
> written by Karol Langner
> Tue Jan 30 00:26:31 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
>

It occurred to me that it might be beneficial to have two functions in the 
LogFile class that should be called before and after logfiles of any type are 
parsed. For instance, when working the GAMESS parser, I saw there was no 
final progress update and conversion of attributes to arrays. With these 
functions, that won't happen for any new parsers, changes can be made for all 
of them in one place, and the code will be clearer.

Basically, everything in the parse() function of a parser before the "for line 
in inputfile" loop would go i nthe first function, and everything after in 
the second. As far as I can tell, there are no differences here between 
parsers, so is there a reason not to do this?

To do this, however, inputfile, nstep, and oldstep (maybe something else, 
also?) need to be parser attributes.

If this seems like a good idea, I'd be happy to do the necessary changes in a 
few days.

Karol

-- 
written by Karol Langner
Tue Jan 30 00:26:31 CET 2007

I think it's a good idea. :o)

On Jan 29, 2007, at 3:12 PM, Karol Langner wrote:

> Hi all,
>
>  I started placing pages in categories on the wiki, as I go along  
> reading, for
> example:
> http://cclib.sourceforge.net/wiki/index.php/Category:Parsed_data
>
>  Hope that's OK.
>
> Karol
>
> -- 
> written by Karol Langner
> Tue Jan 30 00:10:19 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

I just noticed there was no page describing cclib on Wikipedia, so I started 
one:
http://en.wikipedia.org/wiki/Cclib

-- 
written by Karol Langner
Tue Jan 30 00:22:19 CET 2007

Hi all,

 I started placing pages in categories on the wiki, as I go along reading, for 
example:
http://cclib.sourceforge.net/wiki/index.php/Category:Parsed_data

 Hope that's OK.

Karol

-- 
written by Karol Langner
Tue Jan 30 00:10:19 CET 2007

On Monday 29 of January 2007 23:14, you wrote:
> Hi Karol,
>
> Noel and I decided it made sense to move Molpro (and any new parsers)
> to their own branch for development until they are stable and ready
> for inclusion in a release. We discussed it on a previous thread
> awhile back, but under a different name. Here is the relevant text
> from Noel:
>
> "...I was suggesting that development for new parsers should be done
> on a branch, e.g. the molpro parser branch. This would only have
> tests and data files for
> molpro, for instance, and wouldn't contain the bridges, methods, etc.
> modules, so that development would be more focused (and the only
> changes would be parser related). Since Jaguar is slated for
> inclusion in the next release, I think it'd be easier at this stage
> to leave it on the trunk and do the final development there."

OK - I'll dig into the archives when needed.

> Out of curiosity, what parser are you thinking of adding?
>
> Adam

I was thinking about Molcas. Maybe also mpqc when I have more time, for fun.

Karol

-- 
written by Karol Langner
Mon Jan 29 23:39:46 CET 2007

Hi Karol,

Noel and I decided it made sense to move Molpro (and any new parsers)  
to their own branch for development until they are stable and ready  
for inclusion in a release. We discussed it on a previous thread  
awhile back, but under a different name. Here is the relevant text  
from Noel:

"...I was suggesting that development for new parsers should be done  
on a branch, e.g. the molpro parser branch. This would only have  
tests and data files for
molpro, for instance, and wouldn't contain the bridges, methods, etc.  
modules, so that development would be more focused (and the only  
changes would be parser related). Since Jaguar is slated for  
inclusion in the next release, I think it'd be easier at this stage  
to leave it on the trunk and do the final development there."

Out of curiosity, what parser are you thinking of adding?

Adam

Hi all,

I'm wondering - why is there a separate branch for developing the Molpro 
parser? And also, if I'd want to add a parser for another program, would the 
procedure be to do it first in a new branch?

Karol

-- 
written by Karol Langner
Mon Jan 29 23:05:04 CET 2007

testMP.py is a better idea

...please find attached some code I threw together yesterday...you
don't have to use it, of course.

On 29/01/07, Karol Langner <kar...@kn...> wrote:
> Hi again,
>
>  I'd like to add appropriate tests for the MP2 data that is parsed. Should I
> place that in testSP.py or should make a new module testMP.py?
>
> Karol
>
> --
> written by Karol Langner
> Mon Jan 29 06:41:42 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
>

Hi again,

 I'd like to add appropriate tests for the MP2 data that is parsed. Should I 
place that in testSP.py or should make a new module testMP.py?

Karol

-- 
written by Karol Langner
Mon Jan 29 06:41:42 CET 2007

Well, ah, you know...how about "when it's ready"? :-)

I'd like to see a working CDA and electron density in the next
release, as I think it's about time we had a good portfolio of
algorithms.

I'd estimate the next release will take place at the end of March.
However, the point of cclib is not to create more deadlines and
pressure on us, so this date can move in any direction.

Let's put up on the wiki a list of things to do for the next release,
and things to do after that. The following page seems like a good
place to put stuff and should probably be updated in any case:
    http://cclib.sourceforge.net/wiki/index.php/Progress

> > What this adds up to is that if nobody disagrees, this will be the
> > first thing we'll do after the next release.
>
> Incidentally, is there a planned release date?
>
> Karol
>
> --
> written by Karol Langner
> Fri Jan 26 13:35:42 CET 2007
>

On Friday 26 of January 2007 09:00, Noel O'Boyle wrote:
> Both myself and Adam are also thinking of our own programs, which will
> also need to be adjusted. They will already have to be changed
> slightly to deal with the redefinition of mocoeffs and a couple of
> other attributes.

Didn't think about that.

> What this adds up to is that if nobody disagrees, this will be the
> first thing we'll do after the next release.

Incidentally, is there a planned release date?

Karol

-- 
written by Karol Langner
Fri Jan 26 13:35:42 CET 2007