Re: [cclib-devel] nmo proposal

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

Adam,

I've been thinking about this a bit more and I feel that we've moved
too far from the original problem, especially now that it's becoming
less and less clear what the value of nmo should be in particular
cases.

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

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

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.

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?

Noel

On 24/10/06, Adam Tenderholt <a-t...@st...> wrote:
> Some quantum chemistry programs (eg. Jaguar) don't always have the
> same number of alpha orbitals as beta orbitals. Therefore, I propose
> that we change nmo from an integer to a list of integers like
> mocoeffs currently is. This would also mean in these cases, mocoeffs
> should have dimension (1 or 2, nbasis, nbasis) as nmo should always
> be less than or equal to nbasis. Comments?
>
> If this change is agreed upon, then I say we implement this after the
> 0.6 release so as to keep merging bugfix changes easy; alternatively,
> we could create a 0.8 trunk where these changes can be made.
> (Speaking of which, is there a timeframe for the 0.6 release? The ADF
> errors have been fixed as near as I can tell so regression.py passes
> all of the tests and only errors on the one ADF file which is missing
> MO info.)
>
> Adam
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>