Re: [Cdk-devel] Re: [Jmol-developers] cdk class hierarchy

[E.L. W. (Egon) <eg...@sc...>]

On Friday 29 August 2003 21:36, Fabian Dortu wrote:
> > Now a Crystal is not a Molecule. Therefore, it cannot be contained in a
> > SetOfMolecules. Therefore, it must be handled differently. But it seems
> > that there is only one Crystal in a ChemModel, so I suppose that
> > simplifies things somewhat down the crystal branch.
>
> However, a crystal is in theory infinite in space. When we want to show
> it on the screen we (the user) chose to represent only a part of the
> crystal. In a sens, the part of the crystal can be considered as a
> molecule. In Jmol a CrystalFile extends a ChemFile because it was easier
> for me to access the ChemFile fields afterwards. A better implementation
> would be (maybe) to have CrystalFile not extending ChemFile but being at
> the same level. Then, an instance (in the sens of a limited part) of the
> crystal would become an instance of a ChemFile. This was a rapid
> though....

As briefly described in the reply on Miguel's original message in this thread, 
I think that the Jmol Crystal should exactly be a CDK crystal... I agree with 
Fabian analysis about the infinateness of the Crystal, and that's a very 
valuable view on the crystal world...

I see the Iterator taking care of generating Atoms to render... The Crystal 
object will only contain the atoms in the assymetric unit cell... All other 
atoms in the crystal can be deduced from translation along the principle
unit cell axes, or by unit cell symmetry... The Iterator will also take care 
that atoms are displayed at the right position... just like the current 
Crystal code does...

A energy minimization of the crystal lattice would thus be as ChemFile 
containing one ChemSequence, containing X ChemModels (one for each step, + 
one for the starting structure?), and each ChemModel containing one Crystal.

Egon 

-- 
PhD Molecular Representation in Chemometrics
Dept. Analytical Chemistry
http://www-cac.sci.kun.nl/people/egonw.html