cclib-devel

[cclib-devel] broken gaussian file

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

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.

Adam

Re: [cclib-devel] broken gaussian file

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

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.

> Adam
>
>
> -------------------------------------------------------------------------
> 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

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

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] 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] broken gaussian file

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

> Can you add these as regression files?

Done.

Adam

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

[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
>