One additional question:
I can see how much simpler it could be to use JmolViewer.
But how do you identify which two atoms are on either side of a bond using
that class?
All I can see is getBondPoint3f1 and ..3f2 which only store x,y,z.
Dave
On 18 April 2013 13:27, N David Brown <hubd...@gmail.com> wrote:
> Oh by the way I'm using Jmol as a dependency, not developing its source
> directly.
>
> Hence why I'm using the Maven artifact rather than referencing trunk.
>
> The project will become open source later this year most likely, so any
> features you liked could be ported.
>
> Dave
>
>
> On 18 April 2013 13:25, N David Brown <hubd...@gmail.com> wrote:
>
>> 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 molsor
>>>> (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
