Re: [Jmol-developers] atomSetCollection properties

[<rka...@ri...>]

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=20
Gaussian reader only. I'm not sure I am very happy with the loss of=20
elegance of interpreting the files, so I would like to get your=20
feedback before I start going down that road with the NWChem, and later=20=

some other computational output readers.

Before that, I was wondering about two more things (I am always=20
wondering about something :-), because they may affect the=20
implementation of the readers:

1) at one point in time the notion of an AtomSet as a class came up. Is=20=

that still something we should pursue? I think it allows for some=20
better containment of the atomSetAtomCounts, atomSetNames,=20
atomSetNumbers, and atomSetProperties. Probably the atoms, bonds and=20
structures should be part of an AtomSet too, and it would require=20
modification of the atom, bond, and structure iterators.

2) hierarchy of atomSets. We talked about the possibility to use the=20
javax.swing.tree package=20
(https://sourceforge.net/mailarchive/message.php?msg_id=3D9830074 ). =
This=20
would allow us to have our AtomSetCollection be part of a tree=20
structure. If we do that we may not need an AtomSet object, because=20
each AtomSetCollection is really an AtomSet, but with the possibility=20
to have sibblings and children that are also=20
AtomSetCollections/AtomSets, which is what would make it into a=20
collection. It still would require adjustments in the atom, bond, and=20
structure iterators.

The reason these things stay in my mind is that when you read a large=20
Gaussian file, e.g. RK_g03_opt.log (which is still really only a single=20=

geometry optimization and frequency analysis, so not too complex), you=20=

get so many models (22) of which 5 pairs are from the optimization and=20=

the rest are all frequency models. It would be nice to be able to have=20=

two branches for something like this: an optimization branch,=20
consisting itself of two branches (Z-matrix orientation and standard=20
orientation atomsets) and a frequency branch. Each of those separate=20
branches could be animated, but the animation of a frequency branch=20
does not make too much sense, because for those you would normally want=20=

to vibrate a particular atomset (=3D vibrational mode).

On the other hand a computational chemistry file could be considered to=20=

be a dump of sequential atomsets with some properties. The hierarchy or=20=

inter-relatedness between them is something that could be tricky to=20
discern by the reader, so we would make our lives a whole lot harder=20
this way...

I noticed something when scripting, which I assume is a feature (it is=20=

sort of nice): if you do frame x, with x > # models: you get to see all=20=

of them. If you have Vibrate turned on, you seem them all vibrating at=20=

the same time. That is neat. The question is what would one do when a=20
hierachy of atomsets is present: each atomset has a set of frames=20
associated (# children).

I am aware that I mainly think about computational chemistry output and=20=

not as much about PDB files, which I think is where a lot of=20
AtomSetCollection implementation was based on, so my suggestions could=20=

make things quite a bit harder for other types of files. I am convinced=20=

that if that is the case you'll tell me :-).

I haven't checked, but I assume that the viewer uses the iterators to=20
get to the contents of the model. I am not sure to what extend it would=20=

be feasible to have that know about hierarchy too...

Well, I am going to leave it with this long message (sorry).

Ren=E9