-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 05 February 2004 12:04, Miguel Howard wrote: > > Jmol-b6 has to option to draw more than one unit cell... but say, e.g., > > a 2x2x2 unit cell... would that be difficult to implement? > > I am not sure. > The graphics portion certainly would not be difficult. > You said that it was difficult for you to understand Fabian's code. Since > I don't understand the complexities of the geometry, if it was difficult > for you then it will be almost impossible for me.
Well, now that Jmol HEAD *can* show crystals, we no longer need Fabian's code... > As I understand it, the atoms in the other cells are reflections and > translations of the atoms in the unitcell. Atoms in the *same* cell *can be* symmetry related atoms... that depends... but for crystallographers it is easy to convert the symmetry space group to P1, meaning that no symmetry operations need to be applied anymore... And support for P1 is a very good start... Atoms in other cells are only related by translation along a or b or c or of any combination of these unit cell axes. > (I think that Peter previously > said that there were 243(?) types of transformations.) In any case, for a > given unitcell we should be able to construct transform matrices to > generate the siblings. I don't think it is that difficult either... but let's skip space groups for now... > Q: Egon, can you do the calculations (or explain how to do the > calculations) to transform the atoms from the unit cell into the > neighboring cells? Let me know where I need to put the code... > I wonder what is the right way to represent these extra cells/atoms in > memory. No, it would be much better to only store the atoms on the central unit cell... the atoms in other unit cells are only drawn not stored... > Two thoughts come to mind: > > 1. Do not create new atoms for the other cells > ---------------------------------------------- > We should be able to render the other cells by simply applying these > different transformation matrices to the unitcell. Agreed... and since these transformation is only a translation, it is very straight forward... > This has several benefits: > - no additional data structures to represent atoms. > - any coloring/animation/vibration of the unitcell atoms > would automatically be propogated to the 7 sibling cells. > - we could easily turn the other cells on/off with just a checkbox Jmol b6 lets the user define the size of the crystal box... > - it would be very cool > > Major disadvantage: > - less control over the rendering in the other cells. Agreed... > 2. Actually create new atoms for the other cells > ------------------------------------------------ > The other option is to apply these matrices to the unitcell atoms and > actually generate atoms for the other cells. > > The major disadvantage is that we would have to duplicate all the atom > data structures. These things are small, so that is not really a problem. > > I think the bigger problem is that script writers would have to manage all > those atoms. Yes, and atom ids might not be very clear... C27 in which cell? > But that is also an advantage. A script writer could control the rendering > in each cell independently. For example, the atoms in each cell could be > rendered in a different color ... to help with visualization. I don't think that's something we should offer now... I'm not sure wether such things are really needed... > If we did this, I think that we would say that each cell was a 'model', > using the .pdb terminology ... because there is already good scripting > support for selecting and displaying individual models. Ok, that might solve the problem I mentioned with C27... > In writing this, I have almost convinced myself that option #2 is better. > > What do you folks think? Crystallographers, is there serious need to have different rendering options for the different unit cells in a 2x2x2 crystal box (=8 unit cells)? Egon - -- [EMAIL PROTECTED] PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFAIia6d9R8I9Yza6YRAhq5AJ94nb93mEtQaHFljVLbeW3Cn7/6XQCgm71N lKUoO9O/3RikqYCTGNVtcIk= =9rT8 -----END PGP SIGNATURE----- ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Jmol-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-users
