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