Re: [cclib-devel] nmo proposal

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

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