[Jmol-users] pdb files + models + unit cells

[Miguel H. <mt...@mt...>]

Egon wrote:
> 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

One of the ways we want to extend the crystal functionality of Jmol is
by creating a multicell crystal of the user's dimensions. So we can look
at a unitcell or create an IxJxK multicell (... and it is going to be
'wicked' :-)

Once we do this, we will need a way to uniquely address each of these
unitcell copies. That will allow us to use the scripting language commands
to change the rendering of individual atoms/bonds within the multicell in
order to hilite special features.

I trust that there is a standard nomenclature/addressing scheme that is
used in the crystallography world.

Q: Unitcells are probably addressed by their fractional coordinates
[0,1,-1], correct?

Q: I don't want to go into too much detail on this yet, but can someone
tell me what the general scheme is for naming one of these reflection /
rotate / spacegroup copies that is within the unit cell ?


There are two pretty important places that we need to squeeze this in.
 1. the data structures
 2. the scripting language


Now, Jmol already has some support for holding more than 1 copy of the
same thing. PDB files have the concept of a 'model' that is supposed to
be multiple copies of what is fundamentally the same thing.

And, because of the PdbModel, the scripting language already has support
for addressing each of these models individually.


I would like to explore the idea of trying to reuse some of this
infrastructure to support two different things ... PdbModels AND
multicells

The obstacle that would prevent this reuse would be the presence of PDB
files that contain both CRYST1 and MODEL records.

It looks like to me that the PDB spec will not allow multiple models, each
of which has its own CRYST1 records (!Gracias a Dios!).

However, the spec looks like it would allow multiple models, all of which
fit within the same CRYST1 unitcell.

Q: Does someone know the answer to this? (Uhhh ... Rich?)


Q: Any other comments/observations?



Thanks,
Miguel