Re: [cclib-devel] three things

On Thu, 2006-04-06 at 09:06 -0700, Adam Tenderholt wrote:
> > I've been thinking some more about this and now I think that we should
> > avoid Classes altogether, as this has been our method until now (e.g.
> > for molecular orbitals we have symmetries and coefficients as separate
> > attributes, for vibrations, we have raman intensity, and symmetry as
> > separate items, etc.). We can uses atomcoords, atomnos, atomXXXX, etc.
> > Or reduce 'atom' to 'at', or just 'a'.
> 
> Sounds reasonable.
> 
> > For the moment, I propose atomcoords (as we already have atomnos). If
> > you agree, we can add this to our specification (in the docstring of
> > logfileparser.py).
> 
> So atomcoords will be a list of array[2] (with dimensions natom x 3)?
> The list will be length 1 for single point calcs, and however long for
> geometry optimizations?

Yes, it'll be as you say if I understand you correctly. Remember that we
will be using Numeric arrays, and that atomcoords.shape should give
(n,m,3) where n is 1 for an sp (>=1 for a geoopt), m is the number of
atoms. Since it's not efficient/easy to extend Numeric arrays when
reading through a file, I find it better to just convert it from lists
to an array at the end of the file (see the GAMESS/Gaussian parsers).

> Adam
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel