CC'ing the list for their reference.
Thanks for this info Bob, the detail's great.
It sounds like it's fairly safe to use nodes for normal atoms in the first
input model.
I'm using Maven dependencies so am working with 13.0.14, the most recent
artifact I could find.
Thanks for the tip on JmolViewer being the preferred approach. I'll stop
referencing Viewer if I can and request those additional abstracts if
required.
Thanks too for the getMolecules() info - though looking at the code simply
calling this won't change moleculeCount therefore the ModelCollection will
return the same molecules array?
You said firstAtomIndex is just a pointer. So I can assume that some
JmolMolecule
mol is composed of nodes from nodes[mol.firstAtomIndex] up to and *excluding
*nodes[mol.firstAtomIndex + mol.atomList.cardinality()]?
Many thanks,
Dave
On 18 April 2013 12:42, Robert Hanson <hans...@stolaf.edu> wrote:
It's a little more general than that. In Jmol, modelset.Molecule objects
> are just covalent-bond-based sets of modelset.Atom objects created only if
> requested by the user. They serve no other purpose.
>
> Each Jmol window/applet involves one viewer.Viewer, and each Viewer
> corresponds to one modelset.Modelset. The basic modelset.Atom object
> (extends JmolNode) is everything atom-like. Each Atom object is part of one
> and only one modelset.Model, and each Model is a contiguous set of Atoms,
> although I think in principle it could be disjoint. (This is why, to date,
> you can only build new Atoms in the last Model. But I haven't tackled more
> than that.)
>
> Overall, one modelset.Atoms[] array lists all the atoms present for each
> Viewer, (some of which may have been selectively and irreversibly deleted
> by the user). There are also Shape objects that may or may not point to
> atoms, depending upon their type.
>
> For simple single-model files, a Jmol Model corresponds to the file data.
> File formats that support multiple models -- xyz, mol, cif, pdb, and many
> others -- create multiple Model objects, contributing Atom objects in a
> linear fashion to modelset.Atoms[].
>
> If a file is loaded using just FILE or using FILE APPEND and "set
> appendNew TRUE" (the default), or its loading would create more than one
> model, then the Atoms[] array is appended, and one or more new Model
> objects is created. In all other cases, the last Model object is extended.
>
> So, to answer your questions....
>
>
> On Thu, Apr 18, 2013 at 3:27 AM, N David Brown <hubd...@gmail.com> wrote:
>
>> Ok thanks Bob.
>>
>> Here are some final questions to determine a consistent approach to
>> analysing molecules input as a unique atom set regardless of the source
>> data format.
>>
>> If the answer to each is "yes" then I'm good to go.
>>
>> Hopefully this'll be useful to others trying to use the viewer molecules
>> from Java.
>>
>> 1.
>>
>> Is it true that every input data file regardless of format will
>> create just one set of JmolNode instances?
>>
>> Sort of. JmolNode was created to simplify the Atom object and abstract
> out only what was needed for SMILES processing. Each file loaded appends
> Atom objects to modelset.AtomCollection.atoms[].
>
>
>>
>> 1.
>> 2.
>>
>> ..so every JmolMolecule present in JmolMolecule[] mols =
>> viewer.getModelSet().getMolecules() will always reference the same
>> JmolNode[]
>> nodes?
>>
>> Yes. Note that viewer.modelSet.getMolecules() will regenerate modelSet's
> private molecules array. (I just checked in a slight modification of
> modelSet.BondCollection that makes that private so that one doesn't
> accidentally access it when it is null.)
>
>>
>> 1.
>> 2.
>>
>> ..and JmolMolecule#firstAtomIndex indicates the first atom in
>> JmolMolecule#nodes, and the end index (one beyond last atom) is
>> either (i) determined by same property of the next member of mols or
>> (ii) if no next member exists all remaining atoms are included in the
>> current molecule?
>>
>>
> JmolMolecule#firstAtomIndex is just a pointer to that. Most important is
> JmolMolecule.atomList, which is a bit set
> (util.BS) covering viewer.modelset.atoms. These atoms will all be in the
> same modelset.Model.
>
>
>
>>
>> 1.
>>
>> I tried using the JmolMolecule#atomCount property but it seems to
>> often be zero.Dave
>>
>>
> Right. Initially an instance of util.JmolMolecule is only created in a
> rudimentary fashion -- involving creating atomList and allowing atom
> selection using SELECT and related commands. Only after public String
> getMolecularFormula(boolean includeMissingHydrogens) is called is that
> field populated. That's because it might include implicit hydrogens
> (primarily for SMILES). If you want to know how many Atom objects are in
> the molecule, just use atomList.cardinality().
>
> If you are more interested in "all the files generated by loading a file"
> then take a look at Model, not JmolMolecule.
>
> Also, I might point out that although there are many public methods in
> org.jmol.modelset classes, none of these are really "public". They are
> public only because they are in a different package than Viewer. If you are
> embedding Jmol in an application, you are advised to access all of this
> through the JmolViewer interface. If that doesn't work, we add new abstract
> methods to JmolViewer as needed. It's probably reasonably safe to access
> the public Viewer classes without the interface, but I do change those
> method names and signatures periodically. JmolViewer is much more stable.
>
> I'm presuming you are using trunk Jmol (Jmol 13.1.15_dev). If not, as a
> developer, you should use the trunk, not a branch. The current trunk will
> become a branch probably before the end of May.
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Chemistry Department
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
