From: Peter Murray-R. <pm...@ca...> - 2003-10-05 19:39:03
|
At 11:08 05/10/2003 +0200, Miguel wrote: >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. Not necessarily. >Rather, the client Which client? One approach is the have a separate library that will generate the cartesian coordinates that need to be displayed. This then feeds the complete data structure into Jmol. This is what would have to be done for non-regular structures (e.g. MD simulations) >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. I agree it is nice to have a small display list and iterate over it with different operators. However you face the problem of what happens when users select atoms in the expanded set - you have to reverse the process. And when they want to measure distances between the sets >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. The classic method used by ORTEP and most programs since is to label 0,0,0 as 555 and add the translation. Thus a cell of -1, 0, 1 would be labelled as 456. This is tacky and based from FORTRAN days but it is widely used. > 2. I don't know what a 'space group' is. And the fact that there are 230 >of them sounds ominous. With that said ... A spacegroup is a way of arranging symmetry elements in space. Thus P1bar is spacegroup 2 and has 2 symmetry operators x,y,z -x, -y, -z it turns out that there are precisely 230 different ways (some are enantiomorphs). If the symmetry operators are given you don't have to worry about the SG. CIF files normally give the operators. If not you have to look them up and there are ambiguities there (there are different conventions for the axes which are not always evident from the symbol unless the Hall notation is used). >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 operations include: inversion (centre of symmetry) rotation about axes (which may not be aligned to cell axes) mirror planes glide planes (mirror + translation) screw axes (rotation + translation) inversion axes however if you simply apply the symmetry elements you don't have to worry about these. However you do still have to worry about overlapping atoms. For a unit cell of NaCl there are 27 atoms, but you would end up drawing about 500 each time instead. It is much cheaper to generate the unit cell once. Of course for organic molecules this is less of a problem but you can't tell beforehand. >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. The main problem arises in detecting polymeric structures and deciding when to stop trying to form a unique molecule P. |