> If I am right in that assumption our atomSet with index 0 could have > the currentAtomSetNumber set to 100.
Yes, this can be the case > Since the atomIterator only allows > access to the fields in the Atom as they are now, i.e., the modelNumber > (=currentAtomSetNumber), there would be no way that the viewer can > determine that for the atoms that are drawn (currentAtomSetNumber = > 100) an atomSetIndex of 0 needs to be used to get the name or > properties of the atomSet. To make this possible we need to maintain a > mapping of the atomSetNumber to that atomSetIndex for file that provide > us with 'modelNumbers'. The viewer is already maintainin this mapping between modelNumber <-> modelIndex It builds this mapping by watching the modelNumbers go by as the atoms are read and the data structures are built. These data structures are independent of the 'lightweight' data structures built as part of the SmarterJmolAdapter. Within the JmolViewer world, the atoms are already storing modelIndex instead of modelNumber. > But maybe it isn't as bad, since you suggest further down the line (see > comment after next) > >> Let's try this: >> >> The JmolAdapter provides: >> >> getAtomSetCount() >> getAtomSetNumber(atomSetIndex) >> getAtomSetName(atomSetIndex) >> getAtomSetProperties(atomSetIndex) > > If we are going to implement the Properties, we could put the > atomSetNumber and atomSetName as in the Properties, and only deal with > an array of Properties. On the other hand it would require a lookup to > get to that, so that would be less efficient. Maybe you are right. Once we get the Properties going we could consider eliminating the explicit methods to obtain the atomSetNumber and atomSetName. > Question: How would we determine what to return in the > getAtomSetNumber(atomSetIndex) unless we maintain another array of > atomSetNumbers. Yes, we will put this array in the AtomSetCollection class. > Since our index works on the atomSetIndex, I am > wondering whether we really need an > int getAtomSetIndex(int atomSetNumber) > to determine the atomSetIndex to be used to obtain the atomSetName for > that particular atomSet. The viewer already has this mapping. It constructs it from the modelNumbers that are in the atoms as they go by. Now that we have put these methods in the JmolAdapter, we are going to switch that and have the viewer get this data (along with atomSetNames ... and atomSetProperties) from the JmolAdapter. >> each atom has an atomSetNumber associated with it. >> >> Atoms display based upon their atomSetNumber. >> >>> On an aside, the atomSetNumber for an atom in a pdb file does not >>> associate it with a particular frame in an animation as it obviously >>> does for something like the NWChemReader? >> >> A model in a pdb file and a frame in a NWChem file are the same. > > This would suggest that the modelNumber in the pdb file are sequential, > starting with 1 and not really arbitrary. If that is the case we won't > have a problem. No ... pdb model numbers are completely arbitrary integers ... as are many other 'numbers' in pdb files. But the animation is based upon modelIndex (atomSetIndex) ... and is independent of the model number. But the viewer system already works on modelIndex, and doesn't really care what the modelNumbers are. >> Each atom has a model number associated with it. > > The modelNumber, which we enforce to be the current atomSetNumber. > >> At render time, the atoms know whether or not they should be rendered >> by looking at the displayedModelNumber. I misspoke here. The viewer Atoms store modelIndex and look at displayModelIndex. Miguel ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
