Re: [cclib-devel] nmo proposal

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

I hate reverting stuff, but it's not until you try something out that
you know for sure whether it's a good idea or not. If I was a real SVN
guru, I should be able to think 10 revisions ahead (like those chess
masters). :-)

Have a nice holiday. I'll try and get some of this stuff sorted out
over the next while.

Noel

On 22/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > In your original email below, you say that Jaguar doesn't always have
> > the same number of alpha orbitals as beta orbitals. I think you mean
> > that it doesn't print information on the same number of alpha orbitals
> > as beta orbitals. Just like GAMESS-UK, then, I think - they actually
> > have the same number of alpha and beta orbitals, but just the
> > information on them isn't there (this is speculation, but it is
> > certainly true for other programs).
>
> You are correct: in Jaguar, there are always the same number of alpha
> orbitals as beta orbitals. However, it doesn't always print the same
> number, esp if the ipvert=X option is enabled. In this case, it only
> prints X virtual orbitals which means that if homos[0] != homos[1]
> we'll get a different amount of information for the alpha orbitals
> compared to the beta orbitals.
>
> > If what I say is true, then I don't think it helps to redefine nmo as
> > the orbitals for which there is information in the log file. Instead,
> > we should just relax the constraint that len(moenergies)==nmo, and
> > that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs
> > on which we have M.O. energies, and len(mocoeffs) is the number of MOs
> > for which we have mocoeffs. For unrestricted calcs, we should perhaps
> > move to a list of rank 2 arrays for mocoeffs, which can be of
> > different sizes depending on how orbitals are described in the log
> > file: mocoeff = [ alphamocoeffs, betamocoeffs ].
>
> I would definitely support mocoeffs being a list of rank 2 arrays to
> address the fact that alphamocoeffs and betamocoeffs could be
> different sizes. I think it also means that we should change
> moenergies to reflect something similar (list of rank 1 arrays).
>
> > Overall, what I'm trying to say, is that we are ending up redefining
> > nmo to give a value which we can already find by looking at
> > len(moenergies) or len(mocoeffs). And now that we realise that for
> > GAMESS-UK these values are not always equal to each other, it makes
> > less sense than ever.
>
> I agree with you here. My original suggestion was made because
> alphamocoeffs and betamocoeffs would be different sizes, so i figured
> it was just easier to make the mocoeffs matrix as large as nbasis x
> nbasis, and adjust nmo so that we know which coefficients are "real".
>
> > We've both done some work on this already, but I'm worried that we're
> > following red herrings. I think we can solve the Jaguar problem
> > without doing this. Would the modifications I suggest be sufficient to
> > handle Jaguar files?
>
> In summary, yes, I think we can revert nmo back to it's original
> definition if we change the definition of mocoeffs and moenergies as
> outlined above. Since your the SVN guru, will you revert the nmo
> changes back?
>
> Adam
>
> P.S. I'm on holiday for the next few days without internet.
>
>