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