cclib-devel — Developer's mailing list

Re: [cclib-devel] Molpro

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

On Tuesday 12 June 2007 12:23, Noel O'Boyle wrote:
> Looking at the boxes not ticked on the "development parsed data", I
> would say it needs some more work - for example, it's currently not
> usable by GaussSum or PyMOlyze. If you can create the input files, I
> can do some of this.

Since this post I've added alot of code to the Molpro parser (see 
http://cclib.sourceforge.net/wiki/index.php/Development_parsed_data for 
details), and most of the needed test files. So maybe it is time now to move 
it to the trunk and get it synched with the other tests?

-- 
written by Karol Langner
Mon Jul  9 09:47:24 EDT 2007

Re: [cclib-devel] Regression error and eggs

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

On 22/06/07, Noel O'Boyle <bao...@gm...> wrote:
> I'm trying to resolve a GaussSum bug report on the GAMESS parser, but
> I've just noticed that a regression has been introduced into this
> parser:
>
> """
> Are the GAMESS files ccopened and parsed correctly?
>   ..\data\GAMESS\basicGAMESS-US\C_bigbasis.out... parse error
> """
>
> In the course of tracking this down I've noticed a limitation (?) of
> the new egg system. Although I keep running "python setup.py install"
> on my new code, it doesn't seem to get installed even when I use
> "--force". What should I be doing Karol?

I think it's probably due to the fact that I 'updated' to an earlier
version of cclib, which didn't do all the egg stuff, but the egg
wasn't uninstalled, and it was used in preference to the installed
source of cclib. Anyway, the problem is revision 635, which I'm
reverting for the moment.

> Noel
>

[cclib-devel] Regression error and eggs

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

I'm trying to resolve a GaussSum bug report on the GAMESS parser, but
I've just noticed that a regression has been introduced into this
parser:

"""
Are the GAMESS files ccopened and parsed correctly?
  ..\data\GAMESS\basicGAMESS-US\C_bigbasis.out... parse error
"""

In the course of tracking this down I've noticed a limitation (?) of
the new egg system. Although I keep running "python setup.py install"
on my new code, it doesn't seem to get installed even when I use
"--force". What should I be doing Karol?

Noel

[cclib-devel] Goals for next release (was: Re: Molpro)

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

I thought I'd catalyze the discussion about the next release some more by 
starting this thread :). I changed some things on the wiki "Progress" page, 
perhaps that is the best place to get some clear goals for the next release?

Karol

-- 
written by Karol Langner
Fri Jun 15 19:08:25 CEST 2007

Re: [cclib-devel] data files not used in tests

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

I'm not too keen on this. The convention has been that files used to
develop the parsers are included in the basic folders, even if they're
no longer tested in the official tests. Usually if I'm working on (for
example) aobasis, I do:

ccget aobasis *.out

I have found this very useful, as the basic files contain several
variations of the same files. If these are moved to the regression
tests, it will no longer be possible to easily do this...

These are not very strong points, but I feel that we can keep cclib at
a higher quality by leaving them where they are for the moment. I
won't say that file size is not an issue...for example, cclib is
already too big for the Python cheeseshop. If we make it easier to get
particular attributes out of all of the test files, then I'll be happy
to move these to the regression suite. What do you think? Something
like "dataget.py aobasis Gaussian".

Noel


On 13/06/07, Karol Langner <kar...@kn...> wrote:
> There are number of data files in the */basic* paths that are not used in any
> tests. Shouldn't we move some of these files to the regression part in the
> interest of making the cclib package smaller? At least the ones that are not
> planned to be used in tests?
>
> The files are:
> data/ADF/basicADF2004.01/NH3.*
> data/ADF/basicADF2004.01/dvb_sp.*
> data/ADF/basicADF2004.01/dvb_sp_c.*
> data/ADF/basicADF2004.01/dvb_sp_d.*
> data/ADF/basicADF2004.01/dvb_sp_d.*
> data/ADF/basicADF2004.01/mo_sp.*
> data/GAMESS/basicGAMESS-US/C_bigbasis.*
> data/GAMESS/basicGAMESS-US/nh3_ts_ir.*
> data/GAMESS/basicPCGAMESS/CN_ir.*
> data/GAMESS/basicPCGAMESS/dvb_td.*
> data/Gaussian/basicGaussian03/C_bigbasis.*
> data/Gaussian/basicGaussian03/dvb_td.*
>
> --
> written by Karol Langner
> Wed Jun 13 09:56:25 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] atombasis in ADF

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

> I added a code snippet that parses the atom indices of BAS  
> functions into
> atombasis. That is probably not what is needed, though, since the  
> MOs in ADf
> are built from SFOs. Since SFOs can in general involve many atoms,  
> I'm not
> sure how this should be parsed?

 From the ADF manual (2004.01):

Create Runs:
BAS => (core-orthogonalization) => CBAS => (symmetry) =>  
(orthonormality) => LOW => (Fock diagonalization) => MO

Fragment mode:
FO (= MO from Fragment file) => (symmetry) => SFO => etc.

I take this to mean the following. During the create run, the BAS  
functions (primarily valence) are made orthogonal to core functions,  
which results in the CBAS functions. These are made symmetric and  
orgthogonal using the Lowdin approach. I believe at this point they  
are diagonal in the fock representation (as they are atoms). These  
(ie FOs) are then combined in the main calculation to make SFOs.

It's probably not trivial to go from SFO mocoeffs back to BAS  
functions because of this complicated procedure. I'm also not sure if  
we can assume, for example, that the primary '2 Px' BAS function is  
the same one that is referred to in the SFO section because of what  
goes on during the Create run. But this is all speculation, so maybe  
we should check it out in more detail.

Since the only reason we care about atombasis is generating molecular  
orbitals and density functions, it may make more sense to handle the  
TAPE* (checkpoint) files instead of trying to calculate this info  
from atombasis printed in logfiles. TAPE41, for instance, already  
contains electron density functions. If we decide to follow this  
route, we may want to consider also handling gaussian cube files, as  
well as any other volume data files.

Adam

[cclib-devel] atombasis in ADF

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

I added a code snippet that parses the atom indices of BAS functions into 
atombasis. That is probably not what is needed, though, since the MOs in ADf 
are built from SFOs. Since SFOs can in general involve many atoms, I'm not 
sure how this should be parsed?

- Karol

-- 
written by Karol Langner
Wed Jun 13 13:02:29 CEST 2007

Re: [cclib-devel] [IDEA]: list of test data files

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

Sure.

On 13/06/07, Karol Langner <kar...@kn...> wrote:
> I find the current way data files are assigned to test classes and parsers in
> the tests kind of akward. For example, GAMESS-US and PCGAMESS are mixed up in
> places. It makes sense to make a list of all the data files and the parser
> and classes they use in a single file, which is read by the test scripts. See
> the attached text file for an example that has the SP and Basis test
> assignments. You can see at a glance what files are used in which tests. If
> you like the idea, it's a minute to make the changes.
>
> --
> written by Karol Langner
> Wed Jun 13 10:22:47 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] broken gaussian file

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

scp myfiles my...@sh...:
move in the files into the appropriate location in
/home/groups/c/cc/cclib/ and make sure it has the right permission.

I wouldn't worry too much about the file name. I'd actually recommend
not renaming so that we can track it through emails and so on. Note
that some lines need to be added to regressionfiles.txt and possibly
regression.py.

Noel

On 13/06/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 12 June 2007 23:45, Adam Tenderholt wrote:
> > > Can you add these as regression files?
> >
> > Done.
>
> Two questions:
> 1) How do you upload regression files?
> 2) Could you change the names of these two to something more intuitive? Like
> FreqIOP7.33.1-H2 or something?
>
> --
> written by Karol Langner
> Wed Jun 13 08:58:37 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] [IDEA]: list of test data files

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

I find the current way data files are assigned to test classes and parsers in 
the tests kind of akward. For example, GAMESS-US and PCGAMESS are mixed up in 
places. It makes sense to make a list of all the data files and the parser 
and classes they use in a single file, which is read by the test scripts. See 
the attached text file for an example that has the SP and Basis test 
assignments. You can see at a glance what files are used in which tests. If 
you like the idea, it's a minute to make the changes.

-- 
written by Karol Langner
Wed Jun 13 10:22:47 CEST 2007

[cclib-devel] data files not used in tests

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

There are number of data files in the */basic* paths that are not used in any 
tests. Shouldn't we move some of these files to the regression part in the 
interest of making the cclib package smaller? At least the ones that are not 
planned to be used in tests?

The files are:
data/ADF/basicADF2004.01/NH3.*
data/ADF/basicADF2004.01/dvb_sp.*
data/ADF/basicADF2004.01/dvb_sp_c.*
data/ADF/basicADF2004.01/dvb_sp_d.*
data/ADF/basicADF2004.01/dvb_sp_d.*
data/ADF/basicADF2004.01/mo_sp.*
data/GAMESS/basicGAMESS-US/C_bigbasis.*
data/GAMESS/basicGAMESS-US/nh3_ts_ir.*
data/GAMESS/basicPCGAMESS/CN_ir.*
data/GAMESS/basicPCGAMESS/dvb_td.*
data/Gaussian/basicGaussian03/C_bigbasis.*
data/Gaussian/basicGaussian03/dvb_td.*

-- 
written by Karol Langner
Wed Jun 13 09:56:25 CEST 2007

Re: [cclib-devel] broken gaussian file

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

On Tuesday 12 June 2007 23:45, Adam Tenderholt wrote:
> > Can you add these as regression files?
>
> Done.

Two questions:
1) How do you upload regression files?
2) Could you change the names of these two to something more intuitive? Like 
FreqIOP7.33.1-H2 or something?

-- 
written by Karol Langner
Wed Jun 13 08:58:37 CEST 2007

Re: [cclib-devel] broken gaussian file

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

> Can you add these as regression files?

Done.

Adam

Re: [cclib-devel] Molpro

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

> Could you list the attributes that should be parsed in order for it  
> to be
> usable by GaussSum and PyMOlyze?

PyMOlyze uses mocoeffs and aonames at the very least for CSPA. Also  
needed are aooverlaps (for MPA, and possibly more), and atomcoords  
and atomnos  (for the fun graphical stuff).

Adam

Re: [cclib-devel] next release (was Molpro)

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

On Tuesday 12 June 2007 19:58, Adam Tenderholt wrote:
> > I'm pretty busy at the moment, and haven't had a chance to really
> > catch up with what you have been doing, but we should start thinking
> > about what's going to be in the next release and start focussing on
> > this...
>
> I too have been pretty busy and have just finally caught up on
> reading all of the post you two have made in the last several days.
> Not that I'll have loads of time in the coming weeks as I'm hopefully
> wrapping up another project and going to start writing, but I figured
> I should provide some of my thoughts... ;-)
I am starting new projects now, and I would like to use cclib for them since 
that has proved pretty effective.

> I agree that we should start talking about the next release. Some
> things for discussion (or clarification for me as I'm not quite sure
> where everything stands):
>
> 1) Is the parser refactoring completely finished? It looks to be
> successfully merged into trunk, but I haven't really played with it.
The refactoring is finished to the extent I was willing to work on it. Some 
more things could be done for sure (possibly using a ditionary of functions 
like we discussed), but I have no time for this now. Still, after what was 
done the parsers should be easier to maintain and expand, and the progress 
output is more unified.

> 2) Do we still want to support Numeric with this release? I've
> installed numpy on my computer, so I doubt I'd even notice a Numeric
> bug.
They eigenvalue solver in Numeric (LinearAlgebra, actually) does not work 
correctly on my computer. I'm not sure if this is just my machine, but it 
breaks the Lowdin Analysis method I recently added. I am all for dumping 
Numeric before the next release.

> 3) The molpro parser: It'd be nice to include another parser, but I
> agree with Noel that we shouldn't include it unless it is basically
> finished.
I think I can get it to an acceptable state (usable by GaussSum/PyMOlyze). 

> 4) The XML format that Karol brought up in another thread. What if we
> created another module (say 'format') that allows parser objects to
> be saved in various formats? cclib could support XML, JSON, commented
> checkpoint files, etc.
Noel already got me thinking about formats other than XML. In the long run it 
doesn't matter to me, I just need to have a comfortable way to store (chosen) 
output from various programs. Even better if it takes up less space than the 
output text files.

> 5) DOS plots. This is something I've been meaning to add back to
> PyMOlyze at some point, but since it's something that's also used in
> GaussSum, along with just being generally useful for random scripts,
> what do you think about including some code in the method module for
> this?
I've never used DOS before in my work but they are nice to look at :)

-- 
written by Karol Langner
Tue Jun 12 22:43:53 CEST 2007

Re: [cclib-devel] Molpro

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

On Tuesday 12 June 2007 18:23, Noel O'Boyle wrote:
> Looking at the boxes not ticked on the "development parsed data", I
> would say it needs some more work - for example, it's currently not
> usable by GaussSum or PyMOlyze. If you can create the input files, I
> can do some of this.
Could you list the attributes that should be parsed in order for it to be 
usable by GaussSum and PyMOlyze?

> I'm pretty busy at the moment, and haven't had a chance to really
> catch up with what you have been doing, but we should start thinking
> about what's going to be in the next release and start focussing on
> this...
I agree, that's where this thread is leading us. I try not to do anything 
serious without writing about it here and getting your input first.

-- 
written by Karol Langner
Tue Jun 12 22:40:14 CEST 2007

Re: [cclib-devel] data files and MANIFEST (was Re: cclib debs)

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

On Tuesday 12 June 2007 18:34, Noel O'Boyle wrote:
> On 11/06/07, Karol Langner <kar...@kn...> wrote:
> > On Monday 04 June 2007 13:17, Noel O'Boyle wrote:
> > > I'm not sure what you mean regarding the data files. They are
> > > currently installed by default, right?
> >
> > They weren't, now they are when using 'python setup.py install'.
>
> Great, although I don't think we're are going to distribute the
> regression files as part of the normal distribution. When I create the
> source distribution, I get a file of size 68MB. We will probably
> require users to download separately the log file distribution if they
> want to run regression.py fully.
Hmm... when I use 'python setup.py sdist' I get a *.tar.gz file around 6MB, 
without the regression files. Are you doing this under Windows? I haven't 
tried it, maybe the MANIFEST syntax has a slightly different meaning. I will 
try it under Windows when I get the chance.

-- 
written by Karol Langner
Tue Jun 12 22:37:35 CEST 2007

Re: [cclib-devel] how I use cclib

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

On Tuesday 12 June 2007 18:45, Noel O'Boyle wrote:
> On 06/06/07, Karol Langner <kar...@kn...> wrote:
> > There is another thing I wanted to share/discuss. I have a little thing I
> > use to store my output data in XML files, which is something that was
> > brought up before. It's not compatible with cclib in its present form,
> > since I have been using it with scripts I wrote before I knew about
> > cclib. I would like to base it on cclib objects, though. When I do this,
> > maybe it could be a starting point for adding a similiar functionality to
> > cclib.
>
> I see that resistance is futile. :-) Here are some ideas:
It's just an idea :) cclib has already made my processing output more 
efficient, so I am willing to contribute more to it.

> (1) pprint the attributes to a file. This can be evaluated in Python.
> (2) JSON it to a file (http://www.json.org/). This can be read by
> several languages (apart from Javascript), and is great for
> webservices (e.g. we can put a webservice on SF). In fact, according
> to http://effbot.org/zone/delicious-json.htm it can simply be
> evaluated in Python.
> (3) Don't use XML. Use something like Gaussian formatted checkpoint,
> but with comments in the file that describe what the data in the file
> is. E.g. the file format would be self-describing with units,
> descriptions of the data, description of the data format.
All good points. Of course, i will probably be a while before I have the time 
actually get into this.

-- 
written by Karol Langner
Tue Jun 12 22:11:30 CEST 2007

Re: [cclib-devel] next release (was Molpro)

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

> I'm pretty busy at the moment, and haven't had a chance to really
> catch up with what you have been doing, but we should start thinking
> about what's going to be in the next release and start focussing on
> this...

I too have been pretty busy and have just finally caught up on  
reading all of the post you two have made in the last several days.  
Not that I'll have loads of time in the coming weeks as I'm hopefully  
wrapping up another project and going to start writing, but I figured  
I should provide some of my thoughts... ;-)

I agree that we should start talking about the next release. Some  
things for discussion (or clarification for me as I'm not quite sure  
where everything stands):

1) Is the parser refactoring completely finished? It looks to be  
successfully merged into trunk, but I haven't really played with it.

2) Do we still want to support Numeric with this release? I've  
installed numpy on my computer, so I doubt I'd even notice a Numeric  
bug.

3) The molpro parser: It'd be nice to include another parser, but I  
agree with Noel that we shouldn't include it unless it is basically  
finished.

4) The XML format that Karol brought up in another thread. What if we  
created another module (say 'format') that allows parser objects to  
be saved in various formats? cclib could support XML, JSON, commented  
checkpoint files, etc.

5) DOS plots. This is something I've been meaning to add back to  
PyMOlyze at some point, but since it's something that's also used in  
GaussSum, along with just being generally useful for random scripts,  
what do you think about including some code in the method module for  
this?

That's all I can think of at the moment.

Adam

Re: [cclib-devel] how I use cclib

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

On 06/06/07, Karol Langner <kar...@kn...> wrote:
> There is another thing I wanted to share/discuss. I have a little thing I use
> to store my output data in XML files, which is something that was brought up
> before. It's not compatible with cclib in its present form, since I have been
> using it with scripts I wrote before I knew about cclib. I would like to base
> it on cclib objects, though. When I do this, maybe it could be a starting
> point for adding a similiar functionality to cclib.

I see that resistance is futile. :-) Here are some ideas:
(1) pprint the attributes to a file. This can be evaluated in Python.
(2) JSON it to a file (http://www.json.org/). This can be read by
several languages (apart from Javascript), and is great for
webservices (e.g. we can put a webservice on SF). In fact, according
to http://effbot.org/zone/delicious-json.htm it can simply be
evaluated in Python.
(3) Don't use XML. Use something like Gaussian formatted checkpoint,
but with comments in the file that describe what the data in the file
is. E.g. the file format would be self-describing with units,
descriptions of the data, description of the data format.

> - Karol
>
> --
> written by Karol Langner
> Wed Jun  6 21:25:58 CEST 2007
>

Re: [cclib-devel] data files and MANIFEST (was Re: cclib debs)

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

On 11/06/07, Karol Langner <kar...@kn...> wrote:
> On Monday 04 June 2007 13:17, Noel O'Boyle wrote:
> > I'm not sure what you mean regarding the data files. They are
> > currently installed by default, right?
> They weren't, now they are when using 'python setup.py install'.
Great, although I don't think we're are going to distribute the
regression files as part of the normal distribution. When I create the
source distribution, I get a file of size 68MB. We will probably
require users to download separately the log file distribution if they
want to run regression.py fully.

> Also, I added MANIFEST.in which is supposed to automatically take care of
> MANIFEST when building the source distirbution. I'm not removing manifest.py,
> though, because I don't know if  this works also on Windows (someone try?).
Seems to work very well. I'm not sure why I didn't do this in the
first place (perhaps not supported by Python 2.3??, or else I couldn't
figure it out).

> --
> written by Karol Langner
> Mon Jun 11 02:00:57 CEST 2007
>

Re: [cclib-devel] Molpro

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

Looking at the boxes not ticked on the "development parsed data", I
would say it needs some more work - for example, it's currently not
usable by GaussSum or PyMOlyze. If you can create the input files, I
can do some of this.

I'm pretty busy at the moment, and haven't had a chance to really
catch up with what you have been doing, but we should start thinking
about what's going to be in the next release and start focussing on
this...

Noel

On 11/06/07, Karol Langner <kar...@kn...> wrote:
> The parser is pretty mature. How many of the attributes would you say it
> should support in order for it to make in to the next release?
>
> On Monday 11 June 2007 17:32, Noel O'Boyle wrote:
> > Unless it going to make the next release, please don't merge it. At
> > release time, it's easy for me to make an error trying to remove all
> > references to a parser that isn't included.
> >
> > On 10/06/07, Karol Langner <kar...@kn...> wrote:
> > > Is there a reason for not merging the Molpro parser into trunk? Alot of
> > > attributes are parsed already, and I am willing to add a few more.
>
> --
> written by Karol Langner
> Mon Jun 11 17:41:24 CEST 2007
>

Re: [cclib-devel] broken gaussian file

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

Can you add these as regression files?

On 01/06/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 15 May 2007 11:01, Noel O'Boyle wrote:
> > On 07/05/07, Adam Tenderholt <a-t...@st...> wrote:
> > > One of my labmates has a Gaussian 98 frequency calculation that cclib
> > > chokes on. The issue is the assert nbasis == self.nbasis found on
> > > line 532 of the gaussian parser. For some reason, it says it uses 290
> > > basis functions at one point and then says there are 292 basis
> > > functions. It has the following route section:
> > >
> > > #P UBP86/LanL2DZ 5D 7F SCF(MaxCycle=500,conver=8) Pop=(NPA) Freq IOP
> > > (7/33=1) guess=read geom=check
> > >
> > > Have we seen this before? I have no idea what's going on and the 7/33
> > > IOP doesn't exist in the Gaussian 03 Documentation.
> >
> > It would be useful to have the actual input file, although I suspect
> > that that is not going to help much. Also the original input file for
> > the geometry optimisation, e.g. did the geo-opt use exactly the same
> > settings for basis set (there is a "guess=read" so it's possible that
> > this might have an effect)?
> >
> > The quick fix for your friend is to remove the second NBasis line from
> > the log file (note: I haven't tested this).
> >
> > The G98 docs are available on the web, but don't contain 7/33.
> > However, some googling shows that it is simply related to the output
> > of the force constant matrix.
> >
> > Actually, I now notice that the error occurs in the "Dens" section,
> > probably due to "DoDens=T"@3432, and there's a "ToCart=T". The
> > following matrix is 292x290 and is referred to as a transformation
> > matrix. So it sounds like there's a transformation from something to
> > Cartesian, which causes the basis set number to increase from 290 to
> > 292. This may be du to NBO or due to the fact that 5D and 7F were used
> > up till that point, and they cannot be applied to the density (??).
> >
> > What to do about this problem I'm not sure...if your colleague had
> > used iop(3/33=1,3/36=-1) and pop=full which figure would have been
> > used for the matrices? 290 or 292. I think we need to reproduce this
> > for dvb, and see what the consequences are for the data that we
> > extract.
>
> To sart off, there isn't much information out there about IOP 7/33, I found
> only this one thread on CCL:
> http://ccl.net/chemistry/resources/messages/2007/05/23.003-dir/index.html
>
> It would be nice to have the original input file (and the molecule in
> question), but since we don't I made some small tests and reproduced the
> parsing error.
>
> The basis set here is not an issue (I use STO-3G) - it's the combination of
> FREQ and IOP(7/33=1) for heavy atoms that changes the number of basis
> functions when printing the transition dipole moments in a cartesian frame. I
> haven't thought about a fix yet, but now we can at least try to make a
> regression file for this. Find attached: test_Cu2.com/log for the
> input/output files of this test. The output is for Gaussian98 - the same
> thing happens in G03, I checked.
>
> There is a (related) error for the same input combination in the case of
> lighter atoms. Find attached: test_H2.com/log - exactly the same input but H
> instead of Cu. I haven't even looked at this output, but it gives a different
> error when parsed than the test above.
>
> Maybe this will make fixing easier,
> Karol
>
> P.S. I esent this mail, 'cause the *.com attachments didn't go through before.
>
> --
> written by Karol Langner
> Fri Jun  1 18:52:10 CEST 2007
>
>

Re: [cclib-devel] Data files mistakenly classified as junk

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

Apologies - you're right. And that's a mistake. Thanks for spotting
this. I'll move these files onto the server, as soon as possible...

On 11/06/07, Karol Langner <kar...@kn...> wrote:
> I didn't notice it, and still can't.
>
> On Monday 11 June 2007 18:09, Noel O'Boyle wrote:
> > I could be wrong, but I thought that they were included in the regression
> > suite.
> >
> > On 11/06/07, Karol Langner <kar...@kn...> wrote:
> > > On Monday 11 June 2007 17:54, Noel O'Boyle wrote:
> > > > Karol,
> > > >
> > > > I couldn't help but notice that you junked all of my data files. Well,
> > > > not all, but some :-)
> > > >
> > > > I'll put these on the server instead. These are from the early days of
> > > > cclib, when we weren't putting things on the server so I didn't know
> > > > what to do with them. WinGAMESS files are different than those from
> > > > cclib so they are useful to have.
> > >
> > > Sorry :) that was my conclusion, since they aren't used in any tests now.
>
> --
> written by Karol Langner
> Mon Jun 11 18:11:50 CEST 2007
>

Re: [cclib-devel] Data files mistakenly classified as junk

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

I didn't notice it, and still can't.

On Monday 11 June 2007 18:09, Noel O'Boyle wrote:
> I could be wrong, but I thought that they were included in the regression
> suite.
>
> On 11/06/07, Karol Langner <kar...@kn...> wrote:
> > On Monday 11 June 2007 17:54, Noel O'Boyle wrote:
> > > Karol,
> > >
> > > I couldn't help but notice that you junked all of my data files. Well,
> > > not all, but some :-)
> > >
> > > I'll put these on the server instead. These are from the early days of
> > > cclib, when we weren't putting things on the server so I didn't know
> > > what to do with them. WinGAMESS files are different than those from
> > > cclib so they are useful to have.
> >
> > Sorry :) that was my conclusion, since they aren't used in any tests now.

-- 
written by Karol Langner
Mon Jun 11 18:11:50 CEST 2007