On Oct 30, 2004, at 9:16 AM, Miguel wrote:
Q: What is the state of the NWChem and Gaussian readers?
I have added the interpretation of some input into properties in the Gaussian reader only. I'm not sure I am very happy with the loss of elegance of interpreting the files, so I would like to get your feedback before I start going down that road with the NWChem, and later some other computational output readers.
Before that, I was wondering about two more things (I am always wondering about something :-), because they may affect the implementation of the readers:
1) at one point in time the notion of an AtomSet as a class came up. Is that still something we should pursue? I think it allows for some better containment of the atomSetAtomCounts, atomSetNames, atomSetNumbers, and atomSetProperties. Probably the atoms, bonds and structures should be part of an AtomSet too, and it would require modification of the atom, bond, and structure iterators.
2) hierarchy of atomSets. We talked about the possibility to use the javax.swing.tree package (https://sourceforge.net/mailarchive/message.php?msg_id=9830074 ). This would allow us to have our AtomSetCollection be part of a tree structure. If we do that we may not need an AtomSet object, because each AtomSetCollection is really an AtomSet, but with the possibility to have sibblings and children that are also AtomSetCollections/AtomSets, which is what would make it into a collection. It still would require adjustments in the atom, bond, and structure iterators.
The reason these things stay in my mind is that when you read a large Gaussian file, e.g. RK_g03_opt.log (which is still really only a single geometry optimization and frequency analysis, so not too complex), you get so many models (22) of which 5 pairs are from the optimization and the rest are all frequency models. It would be nice to be able to have two branches for something like this: an optimization branch, consisting itself of two branches (Z-matrix orientation and standard orientation atomsets) and a frequency branch. Each of those separate branches could be animated, but the animation of a frequency branch does not make too much sense, because for those you would normally want to vibrate a particular atomset (= vibrational mode).
On the other hand a computational chemistry file could be considered to be a dump of sequential atomsets with some properties. The hierarchy or inter-relatedness between them is something that could be tricky to discern by the reader, so we would make our lives a whole lot harder this way...
I noticed something when scripting, which I assume is a feature (it is sort of nice): if you do frame x, with x > # models: you get to see all of them. If you have Vibrate turned on, you seem them all vibrating at the same time. That is neat. The question is what would one do when a hierachy of atomsets is present: each atomset has a set of frames associated (# children).
I am aware that I mainly think about computational chemistry output and not as much about PDB files, which I think is where a lot of AtomSetCollection implementation was based on, so my suggestions could make things quite a bit harder for other types of files. I am convinced that if that is the case you'll tell me :-).
I haven't checked, but I assume that the viewer uses the iterators to get to the contents of the model. I am not sure to what extend it would be feasible to have that know about hierarchy too...
Well, I am going to leave it with this long message (sorry).
Ren�
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
