Nico? What's the story on the Maven 13.1.14 release? Dave can't find it.
Dave, What would "getBondNode1" do that getBondPoint3f1(int bondIndex)
doesn't already? Isn't that the same?
Atom extends Point3fi implements JmolNode
so you can recast that as (Atom), (JmolNode), or (Point3fi) as well as
(org.jmol.util.P3), as it is there.
Right?
On Thu, Apr 18, 2013 at 10:19 AM, N David Brown <hubd...@gmail.com> wrote:
> Thanks for responding quickly, Bob.
>
> That's not relying on the JmolViewer interface though. I'm still hinging
> on the implementation details which counterbalances your suggestion to use
> the stable interface.
>
> Maybe you could add e.g. public JmolNode getBondNode1(i)?
>
> Still, thank you for this cast info. I'll convert to use JmolViewer now.
>
> I can't find 13.1.14 on Maven, nor can I find info of where it's released
> to. Those repos I've found only list 13.0.14 as most recent. Any links?
>
> Many thanks,
>
> Dave
>
>
> On 18 April 2013 15:16, Robert Hanson <hans...@stolaf.edu> wrote:
>
>> getBondPoint3fi actually returns the atom:
>>
>> return modelSet.getBondAtom1(i);
>>
>> so just recast it as (Atom) and you will have everything.
>>
>> Depending upon how demanding your operation is, the best way to get this
>> information is via getProperty(). This returns a structure for all sorts of
>> information. See http://chemapps.stolaf.edu/jmol/docs/misc and *info.txt
>> files therein. If this is not sufficient, then let's get what you need in
>> there.
>>
>>
>>
>>
>>
>> On Thu, Apr 18, 2013 at 7:42 AM, N David Brown <hubd...@gmail.com> wrote:
>>
>>> 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
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>
--
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
