..and your time too!
On 18 April 2013 17:34, N David Brown <hubd...@gmail.com> wrote:
> Yes the cast works great, and thanks again for the information.
>
> What I'm saying is, the JmolViewer interface should provide a guarantee
> of that Atom type.
>
> So you could have e.g. public JmolNode getBondNode1 or public Atom
> getBondAtom1 was what I meant.
>
> That way you provide a guarantee so a developer being told "you should
> access Jmol through a JmolViewer" instance has all the info they need when
> they look at JmolViewer. Otherwise they have to search the mailing list
> to find you saying it here, search the wiki (if the info's there) or dig
> around Jmol source code. Or parse getProperty() output.
>
> I'm trying to save the next person the time it's taken me to find this out.
>
> Cheers,
>
> Dave
>
>
> On 18 April 2013 17:21, Robert Hanson <hans...@stolaf.edu> wrote:
>
>> 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/miscand
>>>> *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
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
