On Saturday 21 February 2004 18:53, Miguel Howard wrote: > I thought that I had sent this earlier ... but I haven't received any > responses and I found it in my DRAFTS folder :-) > > --- > > Egon (and others), > > Here is my confusion/concern. I will try to play it back ... correct me > if I get something wrong. > > Some files have multiple copies of the 'asymmetric unit' in order to > turn the symmetry into P1. Each of these copies is a 'connected set' of > atoms, also known as a 'molecule'.
Right. > Sometimes these molecules are not packed into the unitcell ... their CGs > are outside the unitcell box. That because the symmetry operations in terms of 'x +0.5bla' can place the molecule outside the unit cell... it's common to have it translated into the unit cell afterwards... > Therefore, you would like to move each of > these molecules independently into the unit cell ... in order to *pack* > them more nicely. > > Q: Is everybody with me? I am, and I agree. > I think that you believe that this is the correct algorithm and that it > should always be applied whenever any file with unitcell data is loaded. > > When Egon and I talked about this online I said that I was very > uncomfortable with this. I think that Jmol should be a rendering program > that faithfully reproduces whatever is in the file. It is bad enough that > for PDB files we have to shift the atoms to put them inside the unitcell > box. I now understand that you think we should actually 'rearrange' > things that are in the file ... and I am very nervous. ... Well... it's difficult if the file just lists the symmetry operation to know what the 'author' of the file meant... (recurring problem...), but I think what it normally means and means in general is this: a symmetry operation that acts on a asymmetric part of the unit cell describes the other symmetry related part of the same unit cell. And this means that if this operation places it outside the unit cell, it has to be translated back into that cell. ---- end def ---- And, I don't think there is currently any chemical file format (except graphics based, like Pov, SVG, VRML) that provide any means to store information on how things should be displayed, either crystallographic format, or other chemical format. To make a slight adjustment to this... 2D chemical formats normally do store this information... or at least some part of it... just 2D coords already is some display option. Anyway, I think we should not worry about this, and interpret the symmetry operations as above. *But*, this does not mean that we might choose to display a P1 specified crystal as is in the file, and use a script command to force them into the unit cell... > You gave me a good demonstration of why this is valuable. And I > understand what you are trying to accomplish. But I continue to have > concerns as to whether or not this is the correct algorithm to apply to > *all* files that contain a unitcell data. > > For example, it looks like to me that Patrick's PDB files > http://macxray.chem.upenn.edu/pack131.html > http://macxray.chem.upenn.edu/smith.html > http://macxray.chem.upenn.edu/cells/cell9903.html > > have a lot of copies hanging outside the unitcell. If I blindly apply > the 'molecule-by-molecule' algorithm then I think I am going to put all > of those copies inside the unitcell box ... and Patrick is going to be > sad :-( Ok, what's important here is to find some notice of wether just one unit cell is stored in the file... (e.g. f1.cephalo), or more than one, e.g. the above examples... Not sure if there is some trigger in the PDB file that could signal this... will have a look at the PDB sources on monday.... (remind me if I forget...) > Q: Still with me? yes, think so... > With that background, let's look at the old messages: > > On Thursday 19 February 2004 19:34, mth wrote: > >> Rich wrote: > >> >> They need > >> >> to be moved independently into the unitcell in order to get the > >> > >> correct effect. > >> > >> > Well...not really, but.... > > Rich says that they do not need to be moved independently, because their > neighbors will 'fill in the blanks' > > >> >> Q: When does *everything* get moved as a group? > > > > Adding new unit cells to do unit cell box? > > Egon says that we move all the atoms when we replicate the unitcell to > form a multicell. > > That is true, but that is not the 'moving' that I am asking about. I am > asking about 'taking the center of all the atoms as a group' and > shifting that ... as with samples/crystals/3CRO.pdb > > >> >> Q: When do things get moved to the group, but only on a > >> >> molecule-by-molecule basis? > > > > When you want to display one unit cell only and want to keep the sets > > (molecules) connected... > > I think what Egon means is that we want to *pack* the unitcell, even > though the data file contained unpacked copies of the asymmetric unit. > > >> >> Q: Should this 'moving to the unitcell box' be automatic at load > >> > >> time, or under user command? > >> > >> > It is mathematically correct to take the atoms of the asymmetric > >> > >> unit (those that comprise the structure model) and apply all the > >> symmetry elements of the space group. This generates a unit cell. > >> > >> OK, that makes sense. > > > > Ok, but that part is not covered yet... > > We got a little confusion here. > > These terms are getting too overloaded, so I am going to adopt a new > term. The 'unitcell cage' is the wireframe rendering that I draw around > the unitcell. > > What I was trying to ask was: Is it always the case that we want to move > the asymmetric unit to inside the unitcell cage? And if there are > multiple copies of the asymmetric unit (molecules) then do we always > want to pack them into the unitcell cage? Yes, if only one unit cell is in the file and non P1 symmetry. Possibly, if only one unit cell and P1 symmetry. No, if more than one unit cell is in the file. > Let's look at two examples: > > 3CRO.pdb has the asymmetric unit outside the unitcell cage. Does anyone > ever want to see it that way? No, one unit cell, P1, while possibly, this is a clear situation where it should be translated... especially, because it is just one unit cell, and it clearly cannot display (without unit cell duplication by Jmol itself) any interactions with molecules from surrounding unit cell. > They way that it is in the file ... the > way that *I* am most comfortable displaying it (most comfortable because > I am faithfully reproducing the junk that is in the file) > > Egon, your f1.cephalo file has 4 copies of the asymmetric unit. Do you > *never* want to be able to display your crystal in its unpacked form. Well never... in principle this again is one unit cell, but P1... so possibly the file does intend to display some packing information, but the file doesn't in any way, so I would say (and this is what I would prefer) it again to place all asymmetric parts into the unit cell cage... > In writing this, I think I have answered my own question. I don't think > that I should move anything into the unitcell cage. By default, I render > what is in the file. Right... my point too. And I believe that when symmetry operations are given *and* only one unit cell is given in the file, then 'packed' is meant... > To pack things into the unitcell cage the user is going to have to send > a script command which will do the packing. Yes, that's perfect as a backup option. > That is my position. If you disagree then you will have to convince me > ;-) Just tried to do so. > >> > The problem is > >> > that to the person *viewing* this collection of atoms it may not be > >> > >> the view which best expresses the nature of the > >> packing/interactions. At that point molecules associated with other > >> unitcells are added to form the nicest picture. > > I think that Rich was saying that people like to see the packed form, > but he is talking about achieving it in a different way. > > >> Yes, I understand how that would work. > > > > In my vision, Jmol scripts will take care of this in the end (in > > pseudo script commands) > > > >> show unitbox 3 3 3 > >> hide atoms 56 - 99 > >> show h bonds between atoms 5-9 > >> show h bonds between atoms 11-20 > >> set vanderwaals on > >> color atoms 77-5 # steric hindering > > Egon says that we can do this with scripting. And he is right. > > But there is a slight difference in what Egon and Rich are talking > about. Rich is talking about about doing this to *form* a (over)packed > unitcell. I think that Egon is assuming that we are starting with a > packed unitcell, because we packed it as soon as the file got read. Well, given the above guidelines, which should be fine as a default, maybe this adjustment: the possible for the second option, can be a no, if we would add the first command to the above script (still pseudo script ;): pack unitcell show unitbox 3 3 3 hide atoms 56 - 99 show h bonds between atoms 5-9 show h bonds between atoms 11-20 set vanderwaals on color atoms 77-5 # steric hindering > >> > The way this was often done for molecular entities was to generate > >> > >> all the molecules in the unit cell plus all those 1 unit cell to each > >> side and then keep only those molecules with atoms inside the cell > >> boundaries of the origin cell. At the expense of having more that the > >> exact number of symmetry copies you got the complete view of the > >> packing. > > > > I think this will be covered by the scripting commands... we will > > probably need some syntax for atom naming 76[0,0,0] to de note the > > 76th atom in a unit cell 0,0,0... > > > > BTW, Miguel, does the scripting language allow selecting of molecules, > > by first partioning into connectes sets, add (by Jmol) labels to > > those sets and then select them with a script command? Something > > > > like: > >> load samples/f1.cephalo > >> partition > >> select m1 > >> color red > > Effectively, yes. > > I am going to post another question regarding the interactions of models > and unitcells in pdb files. > > >> OK. I can see that you would end up with 'extra' copies hanging off > >> of all of the edges. > >> You know that we hope to implement a 'multicell', so that would also > >> help a a bit. > > > > Indeed. Combine the multicell with scripting already available makes > > very much possible in making custom views... > > OK. > > >> > Some programs give you a finer level of control by allowing you to > >> > >> specify which symmetry operator plus translation is to be applied to > >> the asymmetric unit. But this is usually only done to generate > >> specific figures to illustrate particluar packing aspects. > >> > >> Not sure I understood all that ... but doesn't sound like a viable > >> option. > > > > Right, again, I think scripting will take care of this... > > > > Once we have symmetry operations available too, we can apply these by > > scripting too... combine this with selecting one molecule from the > > unit cell ... > > > >> > For Jmol I'd probably pick the default action to be to display all > >> > >> molecules which have their (unweighted) centre of gravity within the > >> unit cell. > >> > >> OK, that code works today (although it is *not* unweighted cg -- > >> another discussion topic) > > > > I think the unweighted) centre of gravity is simply the geometric > > center of the molecule, right? > > I don't think so. I will post a separate question about this. Yes, please do... we is curious about the difference... Egon ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Jmol-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-users
