Re: [Jmol-users] Let's Not Forget PubChem

[Otis Rothenberger]

Already I break my promise!

Please note that I built a 1 second delay into the PubChem call. PubChem is not 
as slow as my page suggests. I’m just trying to keep enthusiastic fast drawing 
users from exceeding PubChem's 3 request per second red flag. This would not be 
a problem in a click to get the name app that uses this approach.

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On May 10, 2016, at 12:31 AM, Otis Rothenberger  wrote:
> 
> OK, I promise I’ll drop this subject after this note!

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Let's Not Forget PubChem

[Otis Rothenberger]

OK, I promise I’ll drop this subject after this note!

I put together a quick and dirty head to head JSME SMILES to IUPAC competition 
between Resolver and PubChem. I simply added PubChem IUPAC to Peter Ertl’s 
Resolver IUPAC test page:

http://chemagic.org/molecules/jsme9.htm

Don’t go bonkers with fast JSME drawing because you can break it! There are 
back to back AJAX calls, and with JSME’s AfterStructureModified callback, you 
can send out multiple AJAX calls real fast. Recalling that Resolver will go to 
PubChem for an IUPAC within the subset of PubChem that Resolver uses, the demo 
is an interesting study of this process.

If you use the single bond tool to slowly draw a convoluted alkane, I think you 
will find the Resolver usually throws up it’s hands first. For fun, I have 
PubChem reporting other ID’s. The Resolver results are in the JSME info window. 
The PubChem results are on the page under the JSME app.

For a real head to head competition treat, simply draw one cyclobutane ring, or 
one cyclooctane ring, or one cyclopenta-1,3-diene ring, or oct-1-yne, or 
spiro[2.2]pentane...

I’m just "sayin"

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On May 9, 2016, at 8:25 PM, Robert Hanson  wrote:
> 
> ps; adding
> 
> info = eval("JSON",x)
> 


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Let's Not Forget PubChem

[Robert Hanson]

ps; adding

info = eval("JSON",x)

much faster JSON parsing than just eval(x);


On Mon, May 9, 2016 at 6:39 PM, Otis Rothenberger 
wrote:

> Bob,
>
> They know it! They are the ones who pointed this out to me after my
> conventional JSON extraction failed on some compounds. They explained the
> necessity of this type of loop to me:
>
> var p = data.PC_Compounds[0].props;
> pubCid = data.PC_Compounds[0].id.id.cid;
> for (var i = 0; i < p.length; i++) {
> if (p[i].urn.label == "SMILES" && p[i].urn.name == "Isomeric") {pubSmi =
> p[i].value.sval;}
> if (p[i].urn.label == "InChI" && p[i].urn.name == "Standard") {pubInchi =
> p[i].value.sval;}
> if (p[i].urn.label == "InChIKey" && p[i].urn.name == "Standard")
> {pubInchiKey = p[i].value.sval;}
> if (p[i].urn.label == "IUPAC Name" && p[i].urn.name == "Systematic")
> {pubName = p[i].value.sval;}
> }
>
> I definitely got the impression that the compound to compound variation
> was by design. If not by design, then it must be related to the evolution
> of their system. Either way, they definitely know about it.
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> On May 9, 2016, at 7:16 PM, Robert Hanson  wrote:
>
> Then you should contact PubChem and get them to fix that.
>
>
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
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
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Let's Not Forget PubChem

[Otis Rothenberger]

Bob,

They know it! They are the ones who pointed this out to me after my 
conventional JSON extraction failed on some compounds. They explained the 
necessity of this type of loop to me:

var p = data.PC_Compounds[0].props;
pubCid = data.PC_Compounds[0].id.id.cid;
for (var i = 0; i < p.length; i++) {
if (p[i].urn.label == "SMILES" && p[i].urn.name == "Isomeric") 
{pubSmi = p[i].value.sval;}
if (p[i].urn.label == "InChI" && p[i].urn.name == "Standard") 
{pubInchi = p[i].value.sval;}
if (p[i].urn.label == "InChIKey" && p[i].urn.name == 
"Standard") {pubInchiKey = p[i].value.sval;}
if (p[i].urn.label == "IUPAC Name" && p[i].urn.name == 
"Systematic") {pubName = p[i].value.sval;}
}

I definitely got the impression that the compound to compound variation was by 
design. If not by design, then it must be related to the evolution of their 
system. Either way, they definitely know about it.

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On May 9, 2016, at 7:16 PM, Robert Hanson  wrote:
> 
> Then you should contact PubChem and get them to fix that.

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Let's Not Forget PubChem

[Robert Hanson]

On Mon, May 9, 2016 at 4:30 PM, Otis Rothenberger 
wrote:

> I’ve hinted at this before, but Pierluigi’s note gives me cause to be
> specific: Let’s not forget PubChem as a source of data other than 3d
> coordinates!
>
> Over the years, Jmol has become research and teaching powerful - no VERY
> powerful. Resolver was a logical partner for Jmol because it is also
> powerful. But let’s not forget PubChem. This is particularly true if your
> teaching interests are like mine: Basic general and organic chemistry small
> molecules. In this small molecule situation, many, if not most, molecules
> of interest are going to be in PubChem. So what? Well for one thing,
> important look-up information is curated in PubChem. This is really what
> Marcus was striving for with his name look-up index help request, and this
> is what resulted in the ill fated Volhardt project conducted by two hacks
> with copies of Volhardt in their hands.
>
> Getting PubChem data (e.g. curated calculated IUPAC names) is fast and
> easy:
>
>
> http://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/smiles/JSON?callback=corsPubChempcdM=CCOCCC
>
> Parsing is a bit of a hassle,



...I don't think so. JSON is a subset of Jmol scripting.



*$ x =
eval(load("http://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/smiles/JSON?callback=corsPubChempcdM=CCOCCC
"))$
print x.PC_Compounds[1].props.select("(value) where urn.label='IUPAC
name'")..1.sval*
1-ethoxypropane


*$ print x.PC_Compounds[1].props.select("(value) where
urn.label='InChI'")..1.sval*
InChI=1S/C5H12O/c1-3-5-6-4-2/h3-5H2,1-2H3

*$ print
x.PC_Compounds[1].props.select("(urn,value)").select("label,name,fval,sval,ival")*

 {
"ival"  :  1
   }
  {
"label"  :  "Compound"
"name"  :  "Canonicalized"
   }
  {
"fval"  :  19.9
   }
  {
"label"  :  "Compound Complexity"
   }
  {
"ival"  :  1
   }
  {
"label"  :  "Count"
"name"  :  "Hydrogen Bond Acceptor"
   }
  {
"ival"  :  0
   }
  {
"label"  :  "Count"
"name"  :  "Hydrogen Bond Donor"
   }
  {
"ival"  :  3
   }
  {
"label"  :  "Count"
"name"  :  "Rotatable Bond"
   }
  {
   }
  {
"label"  :  "Fingerprint"
"name"  :  "SubStructure Keys"
   }
  {
"sval"  :  "1-ethoxypropane"
   }
  {
"label"  :  "IUPAC Name"
"name"  :  "Allowed"
   }
  {
"sval"  :  "1-ethoxypropane"
   }
  {
"label"  :  "IUPAC Name"
"name"  :  "CAS-like Style"
   }
  {
"sval"  :  "1-ethoxypropane"
   }
  {
"label"  :  "IUPAC Name"
"name"  :  "Preferred"
   }
  {
"sval"  :  "1-ethoxypropane"
   }
  {
"label"  :  "IUPAC Name"
"name"  :  "Systematic"
   }
  {
"sval"  :  "1-ethoxypropane"
   }
  {
"label"  :  "IUPAC Name"
"name"  :  "Traditional"
   }
  {
"sval"  :  "InChI=1S/C5H12O/c1-3-5-6-4-2/h3-5H2,1-2H3"
   }
  {
"label"  :  "InChI"
"name"  :  "Standard"
   }
  {
"sval"  :  "NVJUHMXYKCUMQA-UHFFFAOYSA-N"
   }
  {
"label"  :  "InChIKey"
"name"  :  "Standard"
   }
  {
"fval"  :  1.3
   }
  {
"label"  :  "Log P"
"name"  :  "XLogP3-AA"
   }
  {
"fval"  :  88.08881
   }
  {
"label"  :  "Mass"
"name"  :  "Exact"
   }
  {
"sval"  :  "C5H12O"
   }
  {
"label"  :  "Molecular Formula"
   }
  {
"fval"  :  88.14818
   }
  {
"label"  :  "Molecular Weight"
   }
  {
"sval"  :  "CCCOCC"
   }
  {
"label"  :  "SMILES"
"name"  :  "Canonical"
   }
  {
"sval"  :  "CCCOCC"
   }
  {
"label"  :  "SMILES"
"name"  :  "Isomeric"
   }
  {
"fval"  :  9.2
   }
  {
"label"  :  "Topological"
"name"  :  "Polar Surface Area"
   }
  {
"fval"  :  88.08881
   }
  {
"label"  :  "Weight"
"name"  :  "MonoIsotopic"
   }


The data extraction from the JSONP above is tricky because these PubChem
> data files *are not consistent from compound to compound*.
>
>
Then you should contact PubChem and get them to fix that.

Bob
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] Let's Not Forget PubChem

[Otis Rothenberger]

I’ve hinted at this before, but Pierluigi’s note gives me cause to be specific: 
Let’s not forget PubChem as a source of data other than 3d coordinates!

Over the years, Jmol has become research and teaching powerful - no VERY 
powerful. Resolver was a logical partner for Jmol because it is also powerful. 
But let’s not forget PubChem. This is particularly true if your teaching 
interests are like mine: Basic general and organic chemistry small molecules. 
In this small molecule situation, many, if not most, molecules of interest are 
going to be in PubChem. So what? Well for one thing, important look-up 
information is curated in PubChem. This is really what Marcus was striving for 
with his name look-up index help request, and this is what resulted in the ill 
fated Volhardt project conducted by two hacks with copies of Volhardt in their 
hands.

Getting PubChem data (e.g. curated calculated IUPAC names) is fast and easy:

http://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/smiles/JSON?callback=corsPubChempcdM=CCOCCC

Parsing is a bit of a hassle, but PubChem was exceedingly helpful in this 
regard. Using the above URL, I had to use a server proxy in order to use AJAX. 
I know that’s not true for sdf direct, but in this case with AJAX it is true. 
Fortunately, PubChem supports JSONP, and the above URL becomes:

http://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/smiles/JSONP?callback=corsPubChempcdM=CCOCCC

No big deal, it’s sill AJAX. Notice that this is all between Jmol and PubChem 
only via Jmol SMILES.

Points:

1) PubChem IUPAC is db stored, but the data is OpenEye Scientific calculated 
IUPAC.
2) While Resolver does not calculate IUPAC, its does use PubChem lookup, BUT, 
BUT, BUT, Resolver is subject to PubChem usage constraints. These constrains 
are not trivial. No way PubChem (OpenEye) was the source of the query data from 
Resolver below (all upper case IUPAC). This is from Markus’ aforementioned 
index - not PubChem:

 https://cactus.nci.nih.gov/chemical/structure/CCC/iupac_name

3) The PubChem proxy route was unacceptable because PubChem black lists. With 
JSONP, each user is querying PubChem independent of your app and server.

Bottom Line: In my opinion, there is no question that PubChem IUPAC (and some 
other identifiers) SMILES —> Data queries could be more useful than Resolver to 
some Jmol users. There, I said it!

The data extraction from the JSONP above is tricky because these PubChem data 
files are not consistent from compound to compound. You must, therefore, 
iterate through the data in a loop to cherry pick what you want. If anyone 
wants this extraction code, I’d be happy to post it. It’s not lengthy code.

Otis


--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] fun with Jmol -- xxxx.find("chemical",...)

[Robert Hanson]

I note that JSmol now includes a client-side InChI calculator. See

http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm

for more.

Bob

On Mon, May 9, 2016 at 12:51 PM, Otis Rothenberger 
wrote:

> One more JSME point on this subject. The JSME call backs that I mentioned
> in this chain can handle the IUPAC dynamically as the structure is edited.
> Again, here are all the new callbacks:
>
> BeforePaste, AfterPaste, AfterStructureModified, AtomHighlight,
> BondHighlight, AtomClicked, BondClicked
>
> Any on these callbacks could be use to communicate with Resolver and place
> the IUPAC  directly in JSME - i.e. the info holder bottom left. The logical
> callbacks for IUPAC would be AfterStructureModified and/or AfterPaste.
> Returned ResolverData after AJAX can be shown via:
>
> document.JME.showInfo(ResolverData)
>
> VERY IMPORTANT RESOLVER POINT IN ALL OF THIS:
>
> Resolver is not calculating these IUPAC’s. It is looking them up! This
> goes back to the Herculean (to me) task of indexing all Volhardt compounds.
> In Markus’ own words from his again viewable blog:
>
>
> “We took great care during the implementation of the name index for this
> web service, however, we are aware of that it is far from perfect and has
> quite  few errors in it. Unfortunately, these errors are not easy to to
> find if you have to deal with millions of names and their proper assignment
> to the correct chemical structure. If you find any mistakes, please tell
> us. Our plan is to improve the name index over the time but we are of
> course happy about any contributions helpful for this process. Thanks!”
>
> And yes, he is talking about trivial AND IUPAC names above.
>
>
> Otis
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> On May 9, 2016, at 1:24 PM, Robert Hanson  wrote:
>
>
>
> On Mon, May 9, 2016 at 11:39 AM, Otis Rothenberger 
> wrote:
>
>> Hi Pierluigi-
>>
>> For reasons that I do not fully understand, OPSIN returns InChI - not
>> standard InChI. It does, however, return standard InChIKey! In general, I’d
>> be very nervous about comparing InChI strings created by different
>> resources.
>>
>>
> NCI Resolver returns both.  You just have to ask for the right one.
>
> https://cactus.nci.nih.gov/chemical/structure/biphenol/stdinchi
>
> not
>
> https://cactus.nci.nih.gov/chemical/structure/biphenol/inchi
>
> I made that correction in Jmol some time back.
>
> Jmol has a broad range of comparison functions that do exactly what you
> want to do. Take a look at the find() and compare() functions. Also note
> the JSME needs to be carefully set up to deliver the right sort of SMILES.
> See  jsmol/jsmetest.htm and jsmol/jsmetest2.htm in the distribution.
>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
>
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
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
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Message/print echo text?

[Robert Hanson]

You can get this from

x = show("state/echo")

also, if you know what you are looking for.

 set echo off;
  set echo ID "myecho" 0 0; echo "hmm";
  font echo 20.0 Serif Plain; color echo [xff];
  set echo top left; echo "OK";
  font echo 20.0 Serif Plain; color echo [xff];




On Mon, May 9, 2016 at 12:28 PM, Robert Hanson  wrote:

> getproperty shapeinfo is supposed to be delivering that, but it is not.
> Bug fix
>
> On Mon, May 9, 2016 at 11:53 AM, Eric Martz 
> wrote:
>
>> Is there a way to message or print (or show) the text currently displayed
>> at a named echo position?
>>
>> For example, something like
>>
>> set echo top left
>>
>> echo "1d66"
>>
>> message echo top
>>
>> but that message command doesn't work and I haven't found a method.
>>
>> Of course I can keep what I echo in a variable and use that, but before I
>> code it that way, I wondered if there is a more direct method.
>>
>> Thanks, Eric
>>
>>
>> --
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial!
>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>> ___
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Department of Chemistry
> 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, Department of Chemistry
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
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] DOCUMENTATION set echo

[Eric Martz]

Dear Bob,

Under "set echo"

section "scaling"

Is a red link to "set fontScaling true" but the link incorrectly goes to 
"#setmisc".

It should go to "#setlabels".

Thanks, Eric


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] fun with Jmol -- xxxx.find("chemical",...)

[Otis Rothenberger]

One more JSME point on this subject. The JSME call backs that I mentioned in 
this chain can handle the IUPAC dynamically as the structure is edited. Again, 
here are all the new callbacks:

BeforePaste, AfterPaste, AfterStructureModified, AtomHighlight, BondHighlight, 
AtomClicked, BondClicked

Any on these callbacks could be use to communicate with Resolver and place the 
IUPAC  directly in JSME - i.e. the info holder bottom left. The logical 
callbacks for IUPAC would be AfterStructureModified and/or AfterPaste. Returned 
ResolverData after AJAX can be shown via:

document.JME.showInfo(ResolverData)

VERY IMPORTANT RESOLVER POINT IN ALL OF THIS:

Resolver is not calculating these IUPAC’s. It is looking them up! This goes 
back to the Herculean (to me) task of indexing all Volhardt compounds. In 
Markus’ own words from his again viewable blog:


“We took great care during the implementation of the name index for this web 
service, however, we are aware of that it is far from perfect and has quite  
few errors in it. Unfortunately, these errors are not easy to to find if you 
have to deal with millions of names and their proper assignment to the correct 
chemical structure. If you find any mistakes, please tell us. Our plan is to 
improve the name index over the time but we are of course happy about any 
contributions helpful for this process. Thanks!”

And yes, he is talking about trivial AND IUPAC names above.


Otis
--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On May 9, 2016, at 1:24 PM, Robert Hanson  wrote:
> 
> 
> 
> On Mon, May 9, 2016 at 11:39 AM, Otis Rothenberger  > wrote:
> Hi Pierluigi-
> 
> For reasons that I do not fully understand, OPSIN returns InChI - not 
> standard InChI. It does, however, return standard InChIKey! In general, I’d 
> be very nervous about comparing InChI strings created by different resources.
> 
> 
> NCI Resolver returns both.  You just have to ask for the right one.
> 
> https://cactus.nci.nih.gov/chemical/structure/biphenol/stdinchi 
> 
> 
> not
> 
> https://cactus.nci.nih.gov/chemical/structure/biphenol/inchi 
> 
> 
> I made that correction in Jmol some time back.
> 
> Jmol has a broad range of comparison functions that do exactly what you want 
> to do. Take a look at the find() and compare() functions. Also note the JSME 
> needs to be carefully set up to deliver the right sort of SMILES. See  
> jsmol/jsmetest.htm and jsmol/jsmetest2.htm in the distribution.
> 
> 
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Message/print echo text?

[Robert Hanson]

getproperty shapeinfo is supposed to be delivering that, but it is not. Bug
fix

On Mon, May 9, 2016 at 11:53 AM, Eric Martz 
wrote:

> Is there a way to message or print (or show) the text currently displayed
> at a named echo position?
>
> For example, something like
>
> set echo top left
>
> echo "1d66"
>
> message echo top
>
> but that message command doesn't work and I haven't found a method.
>
> Of course I can keep what I echo in a variable and use that, but before I
> code it that way, I wondered if there is a more direct method.
>
> Thanks, Eric
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
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
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] fun with Jmol -- xxxx.find("chemical",...)

[Robert Hanson]

On Mon, May 9, 2016 at 11:39 AM, Otis Rothenberger 
wrote:

> Hi Pierluigi-
>
> For reasons that I do not fully understand, OPSIN returns InChI - not
> standard InChI. It does, however, return standard InChIKey! In general, I’d
> be very nervous about comparing InChI strings created by different
> resources.
>
>
NCI Resolver returns both.  You just have to ask for the right one.

https://cactus.nci.nih.gov/chemical/structure/biphenol/stdinchi

not

https://cactus.nci.nih.gov/chemical/structure/biphenol/inchi

I made that correction in Jmol some time back.

Jmol has a broad range of comparison functions that do exactly what you
want to do. Take a look at the find() and compare() functions. Also note
the JSME needs to be carefully set up to deliver the right sort of SMILES.
See  jsmol/jsmetest.htm and jsmol/jsmetest2.htm in the distribution.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] Message/print echo text?

[Eric Martz]

Is there a way to message or print (or show) the text currently 
displayed at a named echo position?


For example, something like

   set echo top left

   echo "1d66"

   message echo top

but that message command doesn't work and I haven't found a method.

Of course I can keep what I echo in a variable and use that, but before 
I code it that way, I wondered if there is a more direct method.


Thanks, Eric

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] fun with Jmol -- xxxx.find("chemical",...)

[Otis Rothenberger]

Hi Pierluigi-

For reasons that I do not fully understand, OPSIN returns InChI - not standard 
InChI. It does, however, return standard InChIKey! In general, I’d be very 
nervous about comparing InChI strings created by different resources.

In the realm of Chemical Identifiers, molfile and SMILES are native to Jmol. 
Recently, Bob added an InChI app that returns standard InChI. It’s REALLY NEAT, 
but it’s a bit tricky to use. For “in-house” InChI, Jmol is going to Resolver. 
In the realm of Chemical Identifiers, molfile, SMILES, and JMEfile are native 
to JSME.

While SMILES from different resources are variant, Bob implemented a process in 
Jmol that makes this point irrelevant! Jmol can communicate with JSME, 
Resolver, and your database with SMILES. It the latter case, it can compare 
SMILES it generates with SMILES in your database even if they were generated 
differently.

Other issues to consider: OPSIN sits at the “front door” of Resolver. When you 
use Resolver, you are really putting additional power into OPSIN 
(https://cactus.nci.nih.gov/blog/?p=1523). Note that OPSIN is perfectly happy 
with incorrect IUPAC names (http://opsin.ch.cam.ac.uk/opsin/5-chlorohexane.png)!

So I’m wondering if SMILES would not be a better choice for your comparison 
needs? For example:

1) Student draws JSME structure and enters (types) an IUPAC Name.
2) JSME SMILES is loaded into Jmol.
3) Student’s IUPAC Name is sent to Resolver for SMILES. Remember OPSIN at 
Resolver gets the 1st shot at reading this IUPAC name. All correctly structured 
names will be accepted.
4) Resolver returned SMILES is compared to Jmol SMILES.

Alternatively, and more simply if you are OK with leaving the student grading 
out, would be to make JSME do all the work. The act of the student entering 
their IUPAC would return the IUPAC name for the JSME SMILES of the structure 
they drew. The comparison would be visual. By the way, if you give Resolver 
5-chlorohexane, it simply says, “Ahem, I think you meant 2-chlorohexane” Or at 
least, you can make it say that!

I can make some code suggestion if you want to go either route.

Otis


--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On May 8, 2016, at 3:23 PM, Pierluigi Quagliotto 
>  wrote:
> 
> Dear Bob,
> 
> Last year I developed my teaching site:
> 
> http://www.iorgchem.unito.it 
> 
> I am trying to see if it is possible to implement the use of JSME as the 2D 
> editor, JSMol as the 3D viewer and OPSIN as the naming "resolver". Since I 
> am, however, a beginner as a programmer, I will have to test a lot the code I 
> will produce, in order to see if I can obtain something useful. Since in my 
> site the molecules used for quizzes are stored into a DB (prepared with 
> MolDB6), I could imagine at least two possibilities:
> 
> 1) to prepare one page in which students can use my DB with already available 
> molecules for which the SMILES and Inchi  are already present (calculated by 
> MolDB6 when molecules are inserted into the DB). When students submit a name 
> for the molecule, OPSIN would calculate the Inchi and by simple comparison 
> with the given Inchi, it would be possible to know if the answer is correct 
> or not.
> 
> 2) to prepare a page in which the user / student can draw its own molecule 
> and try to name it. In this case I would use directly JSmol to calculate the 
> Inchi. by comparison with the OPSIN derived Inchi, the user would obtain the 
> feedback about his answer.
> 
> 
> My question is about the JSMol capabilities. I looked at your definition of 
> the function of JSMol to obtain the Inchi. I would be certain that JSMol can 
> convert a SMILES into Inchi, without using the NCI resolver. Am I right about 
> this feature or the resort to NCI resolver is needed? This is a fantastic 
> resource, but only molecules inside to its DB can be found and named. My goal 
> would be to give everyone the possibility to find a name for a molecule, 
> within the capabilities of OPSIN. It would be also interesting, if this idea 
> could be implemented, to include OPSIN into the programs of the JSMol 
> release, obviously if the JSMol and OPSIN  licenses can agree each other.
> 
> This should be a definite way to give JSmol all the power for organic 
> chemistry teaching.
> 
> Sorry for my long message, I am quite "verbose"
> 
> Many thanks for your attention and your huge effort to develop a wonderful 
> piece of software! 
> 
> Pierluigi
> 
> 2016-03-24 14:48 GMT+01:00 Robert Hanson  >:
> Great, yes.
> 
> I use this feature in class a lot when  I am teaching organic chemistry.
> 
> On Thu, Mar 24, 2016 at 4:05 AM, Pierluigi Quagliotto 
> > wrote:
> Dear Bob,
> 
> many thanks!
> 
> I will update the JSMol version on my site and I will try to implement this 
> feature.
> 
> It should be