Miguel wrote:
Egon and Miguel,
OK, let's get symmetry in. I'm going to commit the new Symmetry.java so
you can see it. First commit won't link to it.
We're going to need to do some reorganizing to get symmetry to work
properly:
Bob,
Q: What is the current status on this?
Application of symmetry for CIF files is working in bob200603. You can
investigate it at
http://www.stolaf.edu/people/hansonr/jmol/test/proto/sym.htm
This directory contains several data files and the prototype jar files.
I plan to maintain it indefinitely, since it looks like it will be a
while before we integrate this all into the trunk, and, besides, I think
it makes sense to have a variety of versions on line we can test against.
I have not implemented the capability to define the number of unit cells
to generate. Only one unit cell is created.
The cell is "packed" with atoms so as to avoid the unwieldly sort of
atom positions generated by glides. (I don't think I've ever seen a
program generate the actual raw glide positions in the next unit cell.
My first try did that, and it looked terrible.)
Interestingly, though, because the CIF files tend to include
full-molecule atom sets (some atoms outside the unit cell so bonds are
generated) these look really good. The first N atoms will always be the
file-defined atoms (and should probably be selectable later); then an
additional variable number of atoms are ones that have been generated by
the symmetry operations. The trick is that the symmetry operations are
"overly redundant" so it is possible that one particular atom position
in the unit cell will be generated multiple times. I've built in a check
for this, and of course symmetry-defined positions that would put a new
atom where an atom already is are ignored.
Symmetry.java is a general-use class that should be able to be used by
any file reader that includes symmetry designations in the form
x, 1/2-y, x-z
or
x, 0.5-y, x-z
I've added it to the trunk, because it does no harm and provides the
basis for reader work.
1) The "notionalUnitCell" needs to be made atomSet-dependent, not
atomSetCollection-dependent. That is, in CIF files, each data set can
have its own space group and symmetry. Right now the assumption is that
the FILE has a symmetry and spacegroup.
I want to see what this looks like in the data file ...
Q: Is there a sample file that demonstrates this?
see http://www.stolaf.edu/people/hansonr/jmol/test/proto/maleic.cif
2) Egon, we need to clear up what happens when a _data line is found in
a CIF file.
2) Same goes for "coordinatesAreFractional" - this isn't a file-specific
quantity.
3) Obviously this has implications for showing the unit cell and for
transforming the coordinates -- this must be done frame-by-frame, not
file-by-file.
My idea is to use atomSetAuxiliaryInfo for this sort of thing rather
than building all new structures for whatever sort of information such
as this comes along. The advantage there, besides a general collection
point, is that when we getProperty("auxiliaryInfo") all this useful
information will be retrieved.
I initially thought that it would be better to have specialized data
structures and API calls for "fundamental" model data.
But putting this data into auxiliaryInfo would make it more easily
accessible to client programs (Java and JavaScript).
Right, that's implemented now in bob200603. Very simple. But it needs
the modelAuxiliaryInfo, not just modelSetAuxiliaryInfo. I see that other
message and will read next.
Routines would look FIRST in the
auxiliary info for "superceding" symmetry information and only if that
is not found use the current information.
I don't understand what you are saying here.
To me it semed simplest if notionalUnitcell is defined both for the
atomSetCollection (--> modelSet.auxiliaryInfo) in cases where there
aren't multiple models, and for atomSet (--> model.auxiliaryInfo) in
cases where there are. Thay way I didn't have to go back and change ALL
of the file readers -- just CIF. (It's possible that PDB needs this
update as well, though.)
If we move the unit cell data into auxiliaryInfo then we should switch
completely to using that method.
Your choice. File readers involved include:
CIF, CML, PDB, and SHELX
Other ideas?
I have some general questions/thoughts about how we structure
auxiliaryInfo. I'll send a separate message.
How do you want to divide this task?
I am interested in setting the ground-rules and API for auxiliaryInfo.
Bob, you are the man to add support for symmetry, space-groups, and
crystal-growing.
I have been thinking about the 'crystal-growing' problem off-and-on for
several years, but my ideas are still quite vague.
OK, I'll start a user thread on that to get ideas of needs. My feeling
is that it all has to be done at file load time,
unless you want to implement some sort of atom addition/removal
mechanism. (I'm guessing you do NOT want to do that!) The basic idea
would be - indicate at file load all the cells you want; later you can
display or not. One thing that comes to mind is a new sort of
"connected()" selection option -- something like "chain" but for general
molecules -- that would select all atoms "in the same molecule" as some
particular atom set.
But I don't know how to pass information to a file reader that specifies
HOW to read the file (and generate the multiple unit cells). One might
naively say "do that later" but the maleic.cif file shows that to be
impossible -- all atoms must be in place prior to the next model
reading, so the application of multiple unit cells must be PRIOR to
action in Frame. At least that is what I conclude.
Bob
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
