From: Miguel H. <mt...@mt...> - 2004-02-24 16:57:02
|
Hens, I haven't heard from you for a while. Thank you for writing. > Here is my contribution on multiple structure files and animations, in > an attempt to clarify, but with the risk to confuse matters. > Chime supports multiple xyz-files (m-xyz) for animations. > One can display a particular frame number, and Chime returns in > AnimFrameCallback the number of the frame that is displayed during an > animation. Please confirm that the m-xyz is the *only* type of animation file that Chime supports. > This feature is important to us, for displaying -through JavaScript- > data (e.g. energy) that change from frame to frame. Correct. > A PDB-file can also contain several structures, "models", but I don't > think these are used for animations. In general, you are probably right. PDB files are not used much for animations. However, Jan Reichert pointed out a web site which does have some .pdb files which have individual frames stored as MODELs: http://molmovdb.mbb.yale.edu/molmovdb/ They are somewhat hard to find, but they call them 'interpolation as NMR format PDB file'. > You find this option in NMR-determined structures that are composed of > a 'bundle' of coordinate files. > These are similar structures that all fit within the boundaries > determined by NMR. Showing variation in a loop for instance. > Chime sports the command "nmrpdb=false|true|auto" to load such > pdb-files. I do not understand what this Chime command is supposed to do. Is it the case that when nmrpdb=false then only the first model is loaded? I cannot imagine what auto/true are supposed to do. > These models can be shown separately or on top of each other: "show > model all|identifier". I did not know that this existed in chime. But it is very useful for me to know. I assume that <identifier> in this context is the integer model number. Q: Is there some other way to identify a pdb MODEL, other than by model number? Q: In Chime, can you only show one model, or can you show several ... as in: model 2,3 ? > So there is a difference between the two. > M-xyz frames are shown in turn, nmr-pdb frames separately or on top of > each other. OK > In m-xyz files one (I) would like to transfer the display style to all > frames! I agree. That would be one of the benefits if trying to unify the two of them. That way we could use the "model" syntax on XYZ files and the "animation" features on nmrpdb files. > If a particular atomno is colored pink by a script, it should be pink > in all frames, etc. > In an nmr-pdb model this is not necessarily so, I think (anyone using > this feature?) You can use script selection commands to select atoms in specific models. It seems to me that you should be able to do exactly the same thing with a m-xyz file. > A vibration is a particular case of an m-xyz animation. Hmmm ... I used to think that, but I am beginning to think otherwise ... read on ... > In the discussion I noticed that people proposed to read and create > the vibrations directly from the Gaussian, Turbomole, MOPAC, etc > output. With so many QM-packages around this sounds like a lot of work > and not a real priority to me. Previous versions of Jmol and the CDK have a lot of the code for parsing these files. And I don't think that vibrations will be that difficult to do. And for me, they are cleaner and simpler to implement than animations. Primarily because they only have one frame. I think I can calculate the displacements based upon the vector information. It looks simpler to me than a full-fledged animation because I do not have to deal with multiple frames of atoms. I only have to deal with multiple frames of display. > At this stage of development I'd like to suggest that the Chime-like > animation control is included first. Oops! Well, we will see. :-) > One can use a program like MOLDEN or SYBYL (there are many more for > all platforms) to turn QM-vibrations into m-xyz files, and read those > into JMol. Good point. > Okay, now insert your "what do you mean by that". My questions are above. This was very helpful to me. Thanks! Miguel > Hens |