At 03:48 06/09/2006, Bob Hanson wrote: >Egon and Nico and others -- > >I'm quite excited about this space group business and Jmol.
So am I. >Probably >some of these methods should be ported to the CDK, as they will have >quite general interest. Certainly. In fact I think this should be done as a general Blue Obelisk resource as it's so important. Other wise we run the risk of different variant implementations in Jmol, CDK, JUMBO, Openbabel, etc. It doesn't really alter the work to be done, simply how it is packaged. So if we have, say, BOSG (Blue Obelisk Space Groups) then it could comprise: * definitive and tutorial material * lookup tables (e.g. for HM-> Hall) * Hall2SymOp generating code. This might have to be ported to C++ as well and possibly also FORTRAN for The solid state community * other utility routines. This has the advantage that the information is only held once so that bugs in lookup table are mended for everyone simultaneously >The three classes are: > > HallInfo -- parses and inteprets Hall symbols, > generating the associated matrices > > SymmetryOperation -- extends Matrix4f; parses and > generates "x,y,z" lists and matrices Note that the use of x/12 is restricted to crystallography. In principle the matrix translations elements can be anything (although they won't generate a spacegroup). The spacegroup is generated by applying an infinite number of translation matrixes to the spacegroup type. I can see that Hall matrices could be used for lower dimensionality problems (e.g. surfaces and fibres) where some of the periodic translations are omitted. This is why CML uses real numbers in the 4*4 matrices > SpaceGroup -- overall container for a space group; > generates full operation list; looks up > symbol names; identifies unique axis; This is formally a spacegroup type, I think > does the actual atom coordinate operations > The atom coordinate operations require knowledge of the structure and that can be held in many ways. It might apply when there is a clear externalized data structure like CIF or CML. But there is also the problem of how the periodic translations are actually applied so I would omit this operation. >Q: Do you think we should set it up so that the list of 600+ space >groups is read by Jmol from an external source only if/when it needs it? Yes. (I would prefer to see Jmol us a BO spacegroup routine for this purpose) >Q: What's the proper way to do that -- would it be included in the >distribution as a TXT file? It can be held in CML iif this is useful. It can probably also be held in CIF with implicit semantics. I don't like TXT files if they can be avoided >Q: Would Jmol read this automatically when it needed to? Or would we >have some sort of DATA command that might read other data types as well. >(Color schemes?) Or might we just set it up as a script file and use the >mechanism already in place -- something like: This is a general Jmol question - I would prefer to see as much generic functionality as possible normalised in BO resources as: * it avoids multiple sources (e.g. we should only have one periodic table within all BO software. That is certainly my intention for JUMBO, though I haven't actually done it. It makes things like covalent radii much more normalised * we use the same algorithms for bonding, bond orders, etc. So if atoms are bonded by default in Jmol then they should be in JUMBO and CDK * we use the same colour schemes etc. etc. Jmol has done massive work in this area and there is a lot in there that we can benefit from. As you know we are meeting in SF next week. Christoph will not be drinking beer... >#_data spacegroup >.... >.... >.... >#_end data > >so that it all can be in a script file? > >Syd, what do you know about the format of this sort of data? Do other >programs read that data in a standard format? Perhaps XML? There is a lot of similar stuff in solid state programs, especially GULP, CASTEP< SIESTA< DL_POLY, etc. There would be a great advantage to having symmetry normalised across them. I don't think it's difficult P. Peter Murray-Rust Unilever Centre for Molecular Sciences Informatics University of Cambridge, Lensfield Road, Cambridge CB2 1EW, UK +44-1223-763069 ------------------------------------------------------------------------- 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
