Peter, This was quite helpful. Although most of it was well beyond me, I think I got the gist of it :-)
My interpretation is that Jmol should stay away from this problem for the time being. Rather, the client should just go ahead and supply the atoms in the neighboring cells. I was looking for a simple/clean/efficient way to avoid building extra data structures for the adjoining cells ... but this no longer looks simple. A few thoughts: 1. From my perspective, the neighboring cells should each have a unique identifier. The atoms in that cell should inherit that identifier. That way, we can select and manipulate entire cells using the scripting commands. From my (naive) perspective it feels like 'chains' of a protein. 2. I don't know what a 'space group' is. And the fact that there are 230 of them sounds ominous. With that said ... If, for a given unit cell, you could provide me with a list of cartesian 3D translation vectors and reflection operations, then I think I could apply those transformations on-the-fly at rendering time. That way we could avoid building the data structures. The bonds between cells are a bit of a problem. But I assume this is a problem which we have today ... because we do not represent them at all (?). So we will need to come up with some mechanism to handle this. >>Then it seems to me that there is a better way to handle this. >>All one needs to do is repeat the same atoms, but translated to >> different positions in 3-space. > > This is necessary but may not be sufficient. The unit cell contains n > copies of the asymmetric unit - normally a single molecule. n depends on > the space group (of which there are 230) and ranges from 1 (P1) to 192 > (Fm3m). There should be n symmetry operators given for the system (of > which one is the identity operator x,y,z). These symmetry operators > must then all be applied to the contents of the asymmetric unit. In > general this will generate new atoms, although if rotation axes or > inversion centres are present some atoms will translate onto > themselves. > > As an example, take spacegroup P1bar (no 2). This contains two symmetry > operators, x,y,z, and -x, -y, -z. Suppose the molecule was given with > **fractional coordinates**: > C 0 0 0 > O 0.2, 0.3 -0.1 > > you would have to apply the second symmetry operation to get two new > atoms: C 0 0 0 > O -0.2, -0.3 0.1 > The first new atom overlaps (is identical to) the original carbon and so > can be omitted. The second O is bonded to the C, thus giving an O-C-O > molecule. > > You can then translate this by 1,0,0 0,0,2, -1,2,-2, etc to generate > new cells. > > note that all symmetry operations *must* be on fractional coordinates. > If you are given cartesian coordinates only then you cannot generate > fractional coordinates unless you are given the cell axes as vectors > (not just a,b,c,alpha, beta, gamma). > > If you do not generate symmetry equivalent molecules you will end up > large voids in the structure. > > Note also that it is possible that the molecule consists of polymers in > 1, 2, or 3 dimensions. This requires the generation of bonds between > molecules. > > We are currently writing code for this process and hope to have some > generic code. > > HTH > > P. > > > >>Are these offsets the corners of the unit cell box? If not, how does >> one calculate the offsets of the neighboring cells? > > > > >>It seems to me that we can render this to the screen without >> duplicating the data strutures. That is, I can render the same set of >> atoms, with all of the atoms offset by specific amounts. That will be >> much simpler, will take up much less memory, and be just as fast. >> >>Also, you can expand it to as many levels as you want ... we do not >> have to restrict it to 2x2x2. >> >>Finally, this should have a benefit in scripting. Any visual changes >> (color, size, hiding, etc) that are made to the atoms of the "true" >> cell will automatically be replicated to all the other "phantom" cells. >> >>Fabian & Egon ... does this sound right? >> >>Miguel >> >> >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Cdk-devel mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/cdk-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jmol-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jmol-developers -------------------------------------------------- Miguel Howard [EMAIL PROTECTED] c/Pe�a Primera 11-13 esc dcha 6B 37002 Salamanca Espa�a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US = home 011 34 923 27 10 82 12:00 noon Eastern US = cell 011 34 650 52 54 58 6:00 pm Spain -------------------------------------------------- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
