Hi Miguel,
On Oct 21, 2004, at 8:02 PM, Miguel wrote:
Rene wrote:What still confuses me is how the viewer knows which AtomSetIndex to
use to get the AtomSetName (through the JmolAdapter) in the case of a
pdb file, since the real AtomSetIndex associated with a particular atom
may be lost.
I am not sure exactly what your question is.
Sorry I was a bit vague here. Let me try again.
What I was getting at is that the PDB file seems to maintain its own atomSetNumber (which they call modelNumber and which you still want to apply as the value used in the Atom.modelNumber). Only if this number is a 1-based number and used consecutively we can uniquely map the atomSetNumber to the atomSetIndex (by subtracting 1).
In your previous message you wrote "Yes. PDB has explicit atomSetNumbers (they call them 'model numbers'). These values can be ARBITRARY integers."
So lets assume that our first atomSet (for which we have an atomSetIndex of 0) has an atomSetNumber of 100 defined in the pdb file. You suggested having two methods:
<quote who="miguel">
Yes. PDB has explicit atomSetNumbers (they call them 'model numbers').
These values can be arbitrary integers.
So, AtomSetCollection should have two methods.
newAtomSet() {
++atomSetCount;
currentAtomSetNumber = atomSetCount;
}newAtomSet(int atomSetNumber) {
++atomSetCount;
currentAtomSetNumber = atomSetNumber;
}
</quote>and the currentAtomSetNumber would be the atomSetNumber forced on the atoms that are added to the atoms[].
I assume that the second method one is to be used for the pdb files, since it allows me to set the currentAtomSetNumber to a non-sequential value...
If I am right in that assumption our atomSet with index 0 could have the currentAtomSetNumber set to 100. 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'.
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.
Question: How would we determine what to return in the getAtomSetNumber(atomSetIndex) unless we maintain another array of atomSetNumbers. 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.
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.
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.
Ren�
------------------------------------------------------- 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
