subject:"Re\: \[Jmol\-users\] JSME and SMILES"

Bob,
I realize that Jmol uses Ajax.  So I’ve been using Ajax all along.  This was my 
first time I wrote the Ajax HTML and JavaScript myself to communicate with 
server-side PHP code I also wrote myself.  So it felt different to me.
Jennifer







Jennifer Muzyka
H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
Centre College
600 West Walnut Street
Danville, KY  40422

jennifer.muz...@centre.edu
http://web.centre.edu/muzyka
http://organicers.org

859-238-5413
fax 859-236-7925






On Jul 22, 2016, at 10:10 AM, Robert Hanson 
mailto:hans...@stolaf.edu>> wrote:



On Fri, Jul 22, 2016 at 8:42 AM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:
InChI is very messy because there’s more than one version of the program that 
generates it.  So depending on what version you use, you get a different InChI. 
 That information about which version of the InChI rules you are using is an 
early part of the string.  The other problem with InChI is that the strings can 
be REALLY LONG, as in so long that it’s not possible to use them when you 
search Google.  That was another take-away from the course.

You do have to define the rules so that you get the sections right. Beyond 
that, I suppose it may be true, but not for simple molecules. Any changes by 
version would be for esoteric species (I am guessing.) What you are saying 
violates the whole premise of InChI. Do you have examples, Jennifer?

2. Quick Facts
2.1. What is an InChI?

InChI is an acronym for IUPAC International Chemical Identifier. It is a string 
of characters capable of uniquely representing a chemical substance and serving 
as its unique digital ‘signature’. It is derived solely from a structural 
representation of that substance in a way designed to be independent of the way 
that the structure was drawn. A single compound will always produce the same 
identifier.

[http://www.inchi-trust.org/technical-faq/]


You are using AJAX every time you use JSmol. All files are transmitted using 
AJAX, and within JSmol you can do AJAX as simply as


x = load("http://..";)


I don't see why you would need any server-side piece these days. It is 
certainly not "elegant" in my opinion. Elegant is

if ("my SMILES string".find("your SMILES string", "SMILES")) prompt "You're 
good to go!"


without any concern for where the strings come from. That's what JSmol does. No 
server required. Just make sure you are using  the right  options in JSME. See 
http://chemapps.stolaf.edu/jmol/jsmol/jsmetest2.htm


}

var JMEInfo = {
use: "HTML5"
  ,visible: true
  ,divId: "jmediv"
  ,options : "autoez;nocanonize"


}


Here's a note I have on that from an earlier jmol-users post:

JSME and 2D/3D -  It turns out that JSME has two modes of delivery of SMILES -- 
"canonize" and "nocanonize"...The problem is that "canonize" delivers aromatic 
symbols for rings that  are not huekel-aromatic -- all six carbons, for 
example, in benzoquinone. Jmol does this, too, but Jmol adds double bond 
indications as well, so ...c=cc=c The difference is significant -- Jmol's 
SMILES representations are interpretable by the NCI Resolver; JSME's "canonize" 
versions are not. So I  have to have JSME in nocanonize mode in order to 
convert 2D to 3D using the NCI Resolver.

Bob





--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] JSME and SMILES

Here’s the documentation that served as the reading for the fall 2015 OLCC
course on cheminformatics, from
http://olcc.ccce.divched.org/2015OLCCModule5P1#3.2
Because the layered structure of InChI allows one to represent a chemical
structure with a desired level of details, InChI software may generate
different InChI strings for the same molecule. This flexibility may be
regarded as an obstacle to standardization and interoperability. In response
to this concern, the standard InChI was introduced which contains the same
level of structural details and the same conventions for drawing perception, by
using standard option settings in InChI software. The standard InChI
representations begin with “InChI=1S/”, while the non-standard InChI begins
with “InChI=1/”. The digit “1” following “InChI=” is the current InChI version
number.

InChIKey

The length of an InChI string increases with the size of the corresponding
chemical structure, and it is very common that molecules with more than 100
atoms result in very long InChI strings, which are not appropriate to use in
internet search engines (such as Google, Yahoo, Bing, and so on). In addition,
these search engines do not care about case sensitivity nor special characters
used in InChI. To address this issue, the InChIKey was introduced for Internet
and database searching/indexing. It is a 27-character string derived from
InChI, using a hashing algorithm. Hashing is a one-way mathematical
transformation typically used to calculate a compact fixed length digital
representation of a much longer string of arbitrary length.

I guess I paid more attention to the phrase about “obstacle to standardization
and interoperability” than I did to the part about it being “molecules with
more than 100 atoms” having long InChI strings.
Jennifer

Jennifer Muzyka
H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
Centre College
600 West Walnut Street
Danville, KY 40422

jennifer.muz...@centre.edu
http://web.centre.edu/muzyka
http://organicers.org

859-238-5413
fax 859-236-7925

On Jul 22, 2016, at 10:10 AM, Robert Hanson
mailto:hans...@stolaf.edu>> wrote:

On Fri, Jul 22, 2016 at 8:42 AM, Jennifer L. Muzyka
mailto:jennifer.muz...@centre.edu>> wrote:
InChI is very messy because there’s more than one version of the program that
generates it. So depending on what version you use, you get a different InChI.
That information about which version of the InChI rules you are using is an
early part of the string. The other problem with InChI is that the strings can
be REALLY LONG, as in so long that it’s not possible to use them when you
search Google. That was another take-away from the course.

You do have to define the rules so that you get the sections right. Beyond
that, I suppose it may be true, but not for simple molecules. Any changes by
version would be for esoteric species (I am guessing.) What you are saying
violates the whole premise of InChI. Do you have examples, Jennifer?

2. Quick Facts
2.1. What is an InChI?

InChI is an acronym for IUPAC International Chemical Identifier. It is a string
of characters capable of uniquely representing a chemical substance and serving
as its unique digital ‘signature’. It is derived solely from a structural
representation of that substance in a way designed to be independent of the way
that the structure was drawn. A single compound will always produce the same
identifier.

[http://www.inchi-trust.org/technical-faq/]

You are using AJAX every time you use JSmol. All files are transmitted using
AJAX, and within JSmol you can do AJAX as simply as

x = load("http://..";)

I don't see why you would need any server-side piece these days. It is
certainly not "elegant" in my opinion. Elegant is

if ("my SMILES string".find("your SMILES string", "SMILES")) prompt "You're
good to go!"

without any concern for where the strings come from. That's what JSmol does. No
server required. Just make sure you are using the right options in JSME. See
http://chemapps.stolaf.edu/jmol/jsmol/jsmetest2.htm

}

var JMEInfo = {
use: "HTML5"
,visible: true
,divId: "jmediv"
,options : "autoez;nocanonize"

}

Here's a note I have on that from an earlier jmol-users post:

JSME and 2D/3D - It turns out that JSME has two modes of delivery of SMILES --
"canonize" and "nocanonize"...The problem is that "canonize" delivers aromatic
symbols for rings that are not huekel-aromatic -- all six carbons, for
example, in benzoquinone. Jmol does this, too, but Jmol adds double bond
indications as well, so ...c=cc=c The difference is significant -- Jmol's
SMILES representations are interpretable by the NCI Resolver; JSME's "canonize"
versions are not. So I have to have JSME in nocanonize mode in order to
convert 2D to 3D using the NCI Resolver.

Bob

--
W

Re: [Jmol-users] JSME and SMILES

2016-07-22 Thread Robert Hanson

On Fri, Jul 22, 2016 at 8:42 AM, Jennifer L. Muzyka <
jennifer.muz...@centre.edu> wrote:

> InChI is very messy because there’s more than one version of the program
> that generates it.  So depending on what version you use, you get a
> different InChI.  That information about which version of the InChI rules
> you are using is an early part of the string.  The other problem with InChI
> is that the strings can be REALLY LONG, as in so long that it’s not
> possible to use them when you search Google.  That was another take-away
> from the course.
>

You do have to define the rules so that you get the sections right. Beyond
that, I suppose it may be true, but not for simple molecules. Any changes
by version would be for esoteric species (I am guessing.) What you are
saying violates the whole premise of InChI. Do you have examples, Jennifer?

2. Quick Facts 2.1. What is an InChI?

InChI is an acronym for IUPAC International Chemical Identifier. It is a
string of characters capable of uniquely representing a chemical substance
and serving as its unique digital ‘signature’. It is derived solely from a
structural representation of that substance in a way designed to be
independent of the way that the structure was drawn. A single compound will
always produce the same identifier.

[http://www.inchi-trust.org/technical-faq/]

You are using AJAX every time you use JSmol. All files are transmitted
using AJAX, and within JSmol you can do AJAX as simply as

x = load("http://..";)

I don't see why you would need any server-side piece these days. It is
certainly not "elegant" in my opinion. Elegant is

if ("my SMILES string".find("your SMILES string", "SMILES")) prompt "You're
good to go!"

without any concern for where the strings come from. That's what JSmol
does. No server required. Just make sure you are using  the right  options
in JSME. See http://chemapps.stolaf.edu/jmol/jsmol/jsmetest2.htm

}var JMEInfo = {use: "HTML5"  ,visible: true  ,divId: "jmediv"
,options : "autoez;nocanonize"

}

Here's a note I have on that from an earlier jmol-users post:

JSME and 2D/3D -  It turns out that JSME has two modes of delivery of
SMILES -- "canonize" and "nocanonize"...The problem is that "canonize"
delivers aromatic symbols for rings that  are not huekel-aromatic -- all
six carbons, for example, in benzoquinone. Jmol does this, too, but Jmol
adds double bond indications as well, so ...c=cc=c The difference is
significant -- Jmol's SMILES representations are interpretable by the NCI
Resolver; JSME's "canonize" versions are not. So I  have to have JSME in
nocanonize mode in order to convert 2D to 3D using the NCI Resolver.

Bob
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] JSME and SMILES

InChI is very messy because there’s more than one version of the program that 
generates it.  So depending on what version you use, you get a different InChI. 
 That information about which version of the InChI rules you are using is an 
early part of the string.  The other problem with InChI is that the strings can 
be REALLY LONG, as in so long that it’s not possible to use them when you 
search Google.  That was another take-away from the course.

The reason I have been using server side lookup for the current page I’m 
developing is that I’m having students draw the starting material for a given 
reagent/product combination.  There are often numerous starting materials that 
are possible.  Going back to the server seemed much more elegant than trying to 
manage regular expressions on the variety of different SMILES or adding a 
second query to generate a complete list of other possible starting materials 
that would also work.  And it was cool to me because it forced me to finally 
learn how to do Ajax.
Jennifer






Jennifer Muzyka
H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
Centre College
600 West Walnut Street
Danville, KY  40422

jennifer.muz...@centre.edu
http://web.centre.edu/muzyka
http://organicers.org

859-238-5413
fax 859-236-7925






On Jul 22, 2016, at 9:28 AM, Robert Hanson 
mailto:hans...@stolaf.edu>> wrote:

It's a very odd use of the word "canonical." I'm surprised you came away with 
that understanding, because the fact that it is the way I describe is well 
documented and very important.

InChI is truly canonical, mostly because there is exactly one program/algorithm 
in the world that can create it. Now that that is available in JavaScript (and 
is in the JSmol distribution -- see 
http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm or in your jsmol folder of the 
distribution) there is no need for any server-side business for many 
applications.

InChI keys are just hashes of InChIs. I guess there is some possibility that 
they are not unique (two molecules can have the same hash code, just as any two 
ASCII strings can). For your purposes those would work as well.

I have not experimented with making hashes from inchi.js, but I am sure it is 
possible. It's a very simple process once you have the InChI key.

Bob


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] JSME and SMILES

2016-07-22 Thread Robert Hanson

It's a very odd use of the word "canonical." I'm surprised you came away
with that understanding, because the fact that it is the way I describe is
well documented and very important.

InChI is truly canonical, mostly because there is exactly one
program/algorithm in the world that can create it. Now that that is
available in JavaScript (and is in the JSmol distribution -- see
http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm or in your jsmol folder of
the distribution) there is no need for any server-side business for many
applications.

InChI keys are just hashes of InChIs. I guess there is some possibility
that they are not unique (two molecules can have the same hash code, just
as any two ASCII strings can). For your purposes those would work as well.

I have not experimented with making hashes from inchi.js, but I am sure it
is possible. It's a very simple process once you have the InChI key.

Bob


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] JSME and SMILES

Bob,
I was under the impression that canonical SMILES would be the same from one 
program to another, not just from the same program.  I participated in the Fall 
2015 OLCC on cheminformatics, and that’s what I remember us teaching the 
students.  So the distinction you are making is reasonable to me but a new idea.

It’s wonderful to hear that Jmol could convert the SMILES to InChI with such an 
easy process.  Can it also do InChIKey?  The cheminformatics guys made a big 
deal over that being better than InChI in the OLCC course.
Jennifer






Jennifer Muzyka
H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
Centre College
600 West Walnut Street
Danville, KY  40422

jennifer.muz...@centre.edu
http://web.centre.edu/muzyka
http://organicers.org

859-238-5413
fax 859-236-7925






On Jul 22, 2016, at 9:01 AM, Robert Hanson 
mailto:hans...@stolaf.edu>> wrote:

Hi, Jennifer.

"Canonical" SMILES just means that a given version of a given program will 
always report out the same string for a compound. Key words there are "same 
program" and "same version". So if you used an earlier version of a program to 
create a database of strings to compare, then you probably need to run through 
that set with any newer version of JSME and require users use that version.

In developing the SMILES capabilities of Jmol I decided not to even attempt 
canonicalization. It has not been important for any application I have seen, 
short of what you are doing -- database lookup. But for that you can use InChI 
keys. Jmol can deliver those either from the browser using inchi.js or by 
remote calls to the NCI Resolver.

If you have only 3000 compounds, you could set up a little 5-line script that 
will run in Jmol.jar that will probably take 10 minutes to convert all SMILES 
to InChI.

Bob

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] JSME and SMILES

2016-07-22 Thread Robert Hanson

Hi, Jennifer.

"Canonical" SMILES just means that a given version of a given program will
always report out the same string for a compound. Key words there are "same
program" and "same version". So if you used an earlier version of a program
to create a database of strings to compare, then you probably need to run
through that set with any newer version of JSME and require users use that
version.

In developing the SMILES capabilities of Jmol I decided not to even attempt
canonicalization. It has not been important for any application I have
seen, short of what you are doing -- database lookup. But for that you can
use InChI keys. Jmol can deliver those either from the browser using
inchi.js or by remote calls to the NCI Resolver.

If you have only 3000 compounds, you could set up a little 5-line script
that will run in Jmol.jar that will probably take 10 minutes to convert all
SMILES to InChI.

Bob
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] JSME and SMILES

2016-07-20 Thread Mike Casey

Hi Jennifer,

Otis makes very good general points about assessment in his last post.

I also have no expertise on running the Jmol checks on the server side.
However, your plan to make a second Ajax call to check the student solution
seems to deal with most of your concerns in that the correct answer is only
visible on the client side after the student has submitted an answer.  A
solution involving two Ajax calls, and using Jmol to do the SMILES
comparison, seems like a good option to my (inexperienced) eye.

Mike

Dr Mike Casey
School of Chemistry
UCD
Dublin
01 716 2420

On 20 July 2016 at 16:45, Otis Rothenberger  wrote:

> Jennifer,
>
> Bob may be able to point your tech guys in the right direction for setting
> up the server side Java App.
>
> However: I ran the large lecture section non-major course at ISU for years
> - 700+ students per semester. In the early days of the Web, we ran on-line
> homework with answers on the client side. To “hide” these answers we used
> obfuscation.
>
> With modern HTML5/JavaScript, the following obfuscation procedure comes to
> mind:
>
> 1) Using AJAX, put the answers directly into JavaScript variables.
>
> OK, some students will understand the JavaScript console to peek at
> variables. So…
>
> 2) Use JavaScript replace to mess up these variable strings. Don’t use
> simple direct string replace. Mess up (and un-mess up)  the answer strings
> with the most unreadable regular expressions that you can contrive.
>
> It’s not fool-proof, but then neither is the server.
>
> Related Pedagogic Thoughts: When I used graded on-line homework, we did
> not have secure testing centers. Colleagues would ask me why I bothered
> doing this. The answer was simple...
>
> 1) The homework grade was weighted so that the best it could do was to
> boost a cumulative grade about half a letter grade.
>
> 2) The homework was designed to prepare students for specific exam
> question types and specific important course material. Students who took
> this seriously, did well in other components of the course. Student
> feedback reinforced that this was working.
>
> 3) I really did not care if some students cheated! If an F got boosted to
> a D or a D got boosted to a C, so be it. Serious students benefited from
> the homework system.
>
> 4) While my students were non-science majors, an OChem question comes to
> mind. Of what value is a C grade in OChem when applying to Med School or
> Grad School?
>
> I guess what I’m trying to say here is don’t let a subset of students who
> may cheat taint the whole system. Just design things so that cheating
> carries a built in penalty and thus becomes irrelevant.
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> On Jul 20, 2016, at 8:39 AM, Jennifer L. Muzyka <
> jennifer.muz...@centre.edu> wrote:
>
> Thanks, Mike.  Your explanation finally helps me understand why Otis is so
> focused on having Jmol do the comparisons rather than going back to the
> database.  I didn’t get that until now.  The potential complication for me
> is that I’m hoping to eventually implement these questions in a graded
> homework system.  I realize that students are resourceful and having the
> SMILES in the page’s JavaScript would make it possible (not actually easy)
> for students to cheat.  So I’m reluctant to have the SMILES in the page.
> Is there a way to do the Jmol SMILES comparison on the server side?
> Jennifer
>
>
>
>
>
>
>
>
> On Jul 20, 2016, at 7:09 AM, Mike Casey  wrote:
>
> Hi Jennifer & Otis,
>
> I'm a relatively inexperienced programmer so please treat the following
> with caution.  However, FWIW, I use the approach that Otis is recommending
> (if I understand him correctly).  Users make selections, ajax is used once
> to retrieve all the data relevant to a problem of the appropriate type from
> a database (as a JSON object that is easy to work with in Javascript).  The
> structures drawn by the user in JSME are then checked by comparison of the
> user SMILES from JSME against the correct SMILES, retrieved from the
> database with the other problem data, using Jmol (which is in a hidden div
> on the page.  As Otis says, Jmol matches different SMILES strings from
> different sources as long as the structures are the same.  My site is not
> in the wild yet (it is a major upgrade of http://www.ucd.ie/chem/chemint/),
> but I would be happy to send the code to you if that would be helpful.
>
> Mike
>
>
> Dr Mike Casey
> School of Chemistry
> UCD
> Dublin
> 01 716 2420
>
> On 20 July 2016 at 01:58, Otis Rothenberger  wrote:
>
>> Jennifer,
>>
>> The student SMILES and the answer SMILES need to be compared on the
>> client (browser) side via JavaScript. The student answer SMILES is already
>> on the client side. All we would need is the answer SMILES there also.
>>
>> Having said this, I know that Bob H once mentioned running the Java app
>> on the server to do server side tasks, but running the Java app on the
>> server is way beyond my progr

Re: [Jmol-users] JSME and SMILES

2016-07-20 Thread Otis Rothenberger

Jennifer,

Bob may be able to point your tech guys in the right direction for setting up 
the server side Java App.

However: I ran the large lecture section non-major course at ISU for years - 
700+ students per semester. In the early days of the Web, we ran on-line 
homework with answers on the client side. To “hide” these answers we used 
obfuscation.

With modern HTML5/JavaScript, the following obfuscation procedure comes to mind:

1) Using AJAX, put the answers directly into JavaScript variables.

OK, some students will understand the JavaScript console to peek at variables. 
So…

2) Use JavaScript replace to mess up these variable strings. Don’t use simple 
direct string replace. Mess up (and un-mess up)  the answer strings with the 
most unreadable regular expressions that you can contrive.

It’s not fool-proof, but then neither is the server.

Related Pedagogic Thoughts: When I used graded on-line homework, we did not 
have secure testing centers. Colleagues would ask me why I bothered doing this. 
The answer was simple...

1) The homework grade was weighted so that the best it could do was to boost a 
cumulative grade about half a letter grade.

2) The homework was designed to prepare students for specific exam question 
types and specific important course material. Students who took this seriously, 
did well in other components of the course. Student feedback reinforced that 
this was working.

3) I really did not care if some students cheated! If an F got boosted to a D 
or a D got boosted to a C, so be it. Serious students benefited from the 
homework system.

4) While my students were non-science majors, an OChem question comes to mind. 
Of what value is a C grade in OChem when applying to Med School or Grad School?

I guess what I’m trying to say here is don’t let a subset of students who may 
cheat taint the whole system. Just design things so that cheating carries a 
built in penalty and thus becomes irrelevant.

Otis

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

> On Jul 20, 2016, at 8:39 AM, Jennifer L. Muzyka  
> wrote:
> 
> Thanks, Mike.  Your explanation finally helps me understand why Otis is so 
> focused on having Jmol do the comparisons rather than going back to the 
> database.  I didn’t get that until now.  The potential complication for me is 
> that I’m hoping to eventually implement these questions in a graded homework 
> system.  I realize that students are resourceful and having the SMILES in the 
> page’s JavaScript would make it possible (not actually easy) for students to 
> cheat.  So I’m reluctant to have the SMILES in the page.  Is there a way to 
> do the Jmol SMILES comparison on the server side?  
> Jennifer
> 
> 
> 
> 
> 
> 
> 
> 
>> On Jul 20, 2016, at 7:09 AM, Mike Casey > > wrote:
>> 
>> Hi Jennifer & Otis,
>> 
>> I'm a relatively inexperienced programmer so please treat the following with 
>> caution.  However, FWIW, I use the approach that Otis is recommending (if I 
>> understand him correctly).  Users make selections, ajax is used once to 
>> retrieve all the data relevant to a problem of the appropriate type from a 
>> database (as a JSON object that is easy to work with in Javascript).  The 
>> structures drawn by the user in JSME are then checked by comparison of the 
>> user SMILES from JSME against the correct SMILES, retrieved from the 
>> database with the other problem data, using Jmol (which is in a hidden div 
>> on the page.  As Otis says, Jmol matches different SMILES strings from 
>> different sources as long as the structures are the same.  My site is not in 
>> the wild yet (it is a major upgrade of http://www.ucd.ie/chem/chemint/ 
>> ), but I would be happy to send the code to 
>> you if that would be helpful.
>> 
>> Mike
>> 
>> 
>> Dr Mike Casey
>> School of Chemistry
>> UCD
>> Dublin
>> 01 716 2420
>> 
>> On 20 July 2016 at 01:58, Otis Rothenberger > > wrote:
>> Jennifer,
>> 
>> The student SMILES and the answer SMILES need to be compared on the client 
>> (browser) side via JavaScript. The student answer SMILES is already on the 
>> client side. All we would need is the answer SMILES there also.
>> 
>> Having said this, I know that Bob H once mentioned running the Java app on 
>> the server to do server side tasks, but running the Java app on the server 
>> is way beyond my programming skills.
>> 
>> With the power of modern JavaScript and HTML5, I’m not sure I see why the 
>> computer jocks are more comfortable with a second hit on the server. The 
>> fact is that the server cannot do the SMILES comparison as elegantly as 
>> Bob’s JSmol SMILES comparison, that is unless the Jmol Java App is run on 
>> the server. With the client side JavaScript/HTML5 power, it seems to me 
>> going back to the server is just going back to the server in order to go 
>> back to the server!
>> 
>> All of this, of course, is dependent on getting the answer S

Re: [Jmol-users] JSME and SMILES

2016-07-20 Thread Jennifer L. Muzyka

Thanks, Mike.  Your explanation finally helps me understand why Otis is so 
focused on having Jmol do the comparisons rather than going back to the 
database.  I didn’t get that until now.  The potential complication for me is 
that I’m hoping to eventually implement these questions in a graded homework 
system.  I realize that students are resourceful and having the SMILES in the 
page’s JavaScript would make it possible (not actually easy) for students to 
cheat.  So I’m reluctant to have the SMILES in the page.  Is there a way to do 
the Jmol SMILES comparison on the server side?
Jennifer








On Jul 20, 2016, at 7:09 AM, Mike Casey 
mailto:mike.ca...@ucd.ie>> wrote:

Hi Jennifer & Otis,

I'm a relatively inexperienced programmer so please treat the following with 
caution.  However, FWIW, I use the approach that Otis is recommending (if I 
understand him correctly).  Users make selections, ajax is used once to 
retrieve all the data relevant to a problem of the appropriate type from a 
database (as a JSON object that is easy to work with in Javascript).  The 
structures drawn by the user in JSME are then checked by comparison of the user 
SMILES from JSME against the correct SMILES, retrieved from the database with 
the other problem data, using Jmol (which is in a hidden div on the page.  As 
Otis says, Jmol matches different SMILES strings from different sources as long 
as the structures are the same.  My site is not in the wild yet (it is a major 
upgrade of http://www.ucd.ie/chem/chemint/), but I would be happy to send the 
code to you if that would be helpful.

Mike


Dr Mike Casey
School of Chemistry
UCD
Dublin
01 716 2420

On 20 July 2016 at 01:58, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:
Jennifer,

The student SMILES and the answer SMILES need to be compared on the client 
(browser) side via JavaScript. The student answer SMILES is already on the 
client side. All we would need is the answer SMILES there also.

Having said this, I know that Bob H once mentioned running the Java app on the 
server to do server side tasks, but running the Java app on the server is way 
beyond my programming skills.

With the power of modern JavaScript and HTML5, I’m not sure I see why the 
computer jocks are more comfortable with a second hit on the server. The fact 
is that the server cannot do the SMILES comparison as elegantly as Bob’s JSmol 
SMILES comparison, that is unless the Jmol Java App is run on the server. With 
the client side JavaScript/HTML5 power, it seems to me going back to the server 
is just going back to the server in order to go back to the server!

All of this, of course, is dependent on getting the answer SMILES into the 
working webpage.

Whichever route you go, that still leaves you with a database with some SMILES 
issues. Here’s a suggestion: How soon is Bob B’s cheminformatics course going 
into action again? Reconstructing your database entirely from Resolver (maybe 
PubChem) by an automated process would be a great real world project for one of 
the student teams. ( cc to Bob B)

Otis

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

On Jul 19, 2016, at 8:22 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
What you are describing is essentially how I handle the code for the page where 
students draw the product structure.  It's certainly doable for the starting 
material structure as well.  I would just need to work out the different query 
and JavaScript.  My computer science colleagues would probably consider that 
the brute force method, unlike the more elegant Ajax method that goes back and 
queries the database a second time.  Is there some advantage to keeping all of 
the code within the page rather than going back to the database?  Those use PHP 
and MySQL.
Jennifer

Sent from my iPad

On Jul 19, 2016, at 6:00 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

On your page, students make several choices to set up a problem. It appears 
that each choice does a GET and reloads the page from sever with appropriate 
page modification. How hard would it be to return the correct SMILES on each of 
these GETS?

Otis

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

On Jul 19, 2016, at 4:35 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
Other information in the database includes:  CAS RN, InChI, InChiKey, and 
ChemSpider ID.  I’m aware that the different sources for SMILES is a potential 
issue, having already dealt with that.  I’m also aware that compounds can have 
more than one CAS number and more than one ChemSpider ID even though I learned 
that CAS numbers were unique back when I was in college.  An unfortunate 
reality is that I don’t have all of the keys for every compound.  Another 
potential problem with the database is that I might not have removed all of the 
situatio

Re: [Jmol-users] JSME and SMILES

2016-07-20 Thread Jennifer L. Muzyka

Otis,
There are several possible different answer SMILES because there are several 
different possible starting materials that would give the same product, at 
least for most combinations of reagent and product.  I suspect that’s not a 
real issue with Jmol, but that’s why I started going back to query the database 
again.

The student who imported the additional 3800 compounds into the database was in 
the fall 2015 OLCC cheminformatics class.  I’m confident he used PubChem or 
other cheminformatics tools to build the table associated with the new 
compounds, although that wasn’t his project for the course.  It was something 
he did for fun, as he continues to develop the app for which he (and a buddy) 
won the prize in the NIST competition last fall.  He’s since graduated.  I’ll 
be there for the OLCC retreat before the BCCE and expect to offer the OLCC 
course again on Centre’s campus in spring 2017.
Jennifer








On Jul 19, 2016, at 8:58 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

The student SMILES and the answer SMILES need to be compared on the client 
(browser) side via JavaScript. The student answer SMILES is already on the 
client side. All we would need is the answer SMILES there also.

Having said this, I know that Bob H once mentioned running the Java app on the 
server to do server side tasks, but running the Java app on the server is way 
beyond my programming skills.

With the power of modern JavaScript and HTML5, I’m not sure I see why the 
computer jocks are more comfortable with a second hit on the server. The fact 
is that the server cannot do the SMILES comparison as elegantly as Bob’s JSmol 
SMILES comparison, that is unless the Jmol Java App is run on the server. With 
the client side JavaScript/HTML5 power, it seems to me going back to the server 
is just going back to the server in order to go back to the server!

All of this, of course, is dependent on getting the answer SMILES into the 
working webpage.

Whichever route you go, that still leaves you with a database with some SMILES 
issues. Here’s a suggestion: How soon is Bob B’s cheminformatics course going 
into action again? Reconstructing your database entirely from Resolver (maybe 
PubChem) by an automated process would be a great real world project for one of 
the student teams. ( cc to Bob B)

Otis

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

On Jul 19, 2016, at 8:22 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
What you are describing is essentially how I handle the code for the page where 
students draw the product structure.  It's certainly doable for the starting 
material structure as well.  I would just need to work out the different query 
and JavaScript.  My computer science colleagues would probably consider that 
the brute force method, unlike the more elegant Ajax method that goes back and 
queries the database a second time.  Is there some advantage to keeping all of 
the code within the page rather than going back to the database?  Those use PHP 
and MySQL.
Jennifer

Sent from my iPad

On Jul 19, 2016, at 6:00 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

On your page, students make several choices to set up a problem. It appears 
that each choice does a GET and reloads the page from sever with appropriate 
page modification. How hard would it be to return the correct SMILES on each of 
these GETS?

Otis

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

On Jul 19, 2016, at 4:35 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
Other information in the database includes:  CAS RN, InChI, InChiKey, and 
ChemSpider ID.  I’m aware that the different sources for SMILES is a potential 
issue, having already dealt with that.  I’m also aware that compounds can have 
more than one CAS number and more than one ChemSpider ID even though I learned 
that CAS numbers were unique back when I was in college.  An unfortunate 
reality is that I don’t have all of the keys for every compound.  Another 
potential problem with the database is that I might not have removed all of the 
situations where a single compound appeared more than once.  There are other 
things in the database (gifs, pdbs, jcamp spectra) for some compounds.
Jennifer





On Jul 19, 2016, at 4:22 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

The default is that JSME keeps explicit hydrogens to carbon, and these will 
show up in brackets. An option can be used to turn this off.

It sounds like you have a mix of SMILES that may have been created by options 
variations in the JSME implementations being used. That's a problem.

One more question, and then I'll do some more thinking. What other items or 
keys are in the database?

Otis

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

Re: [Jmol-users] JSME and SMILES

2016-07-20 Thread Mike Casey

Hi Jennifer & Otis,

I'm a relatively inexperienced programmer so please treat the following
with caution.  However, FWIW, I use the approach that Otis is recommending
(if I understand him correctly).  Users make selections, ajax is used once
to retrieve all the data relevant to a problem of the appropriate type from
a database (as a JSON object that is easy to work with in Javascript).  The
structures drawn by the user in JSME are then checked by comparison of the
user SMILES from JSME against the correct SMILES, retrieved from the
database with the other problem data, using Jmol (which is in a hidden div
on the page.  As Otis says, Jmol matches different SMILES strings from
different sources as long as the structures are the same.  My site is not
in the wild yet (it is a major upgrade of http://www.ucd.ie/chem/chemint/),
but I would be happy to send the code to you if that would be helpful.

Mike


Dr Mike Casey
School of Chemistry
UCD
Dublin
01 716 2420

On 20 July 2016 at 01:58, Otis Rothenberger  wrote:

> Jennifer,
>
> The student SMILES and the answer SMILES need to be compared on the client
> (browser) side via JavaScript. The student answer SMILES is already on the
> client side. All we would need is the answer SMILES there also.
>
> Having said this, I know that Bob H once mentioned running the Java app on
> the server to do server side tasks, but running the Java app on the server
> is way beyond my programming skills.
>
> With the power of modern JavaScript and HTML5, I’m not sure I see why the
> computer jocks are more comfortable with a second hit on the server. The
> fact is that the server cannot do the SMILES comparison as elegantly as
> Bob’s JSmol SMILES comparison, that is unless the Jmol Java App is run on
> the server. With the client side JavaScript/HTML5 power, it seems to me
> going back to the server is just going back to the server in order to go
> back to the server!
>
> All of this, of course, is dependent on getting the answer SMILES into the
> working webpage.
>
> Whichever route you go, that still leaves you with a database with some
> SMILES issues. Here’s a suggestion: How soon is Bob B’s cheminformatics
> course going into action again? Reconstructing your database entirely from
> Resolver (maybe PubChem) by an automated process would be a great real
> world project for one of the student teams. ( cc to Bob B)
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> On Jul 19, 2016, at 8:22 PM, Jennifer L. Muzyka <
> jennifer.muz...@centre.edu> wrote:
>
> Otis,
> What you are describing is essentially how I handle the code for the page
> where students draw the product structure.  It's certainly doable for the
> starting material structure as well.  I would just need to work out the
> different query and JavaScript.  My computer science colleagues would
> probably consider that the brute force method, unlike the more elegant Ajax
> method that goes back and queries the database a second time.  Is there
> some advantage to keeping all of the code within the page rather than going
> back to the database?  Those use PHP and MySQL.
> Jennifer
>
> Sent from my iPad
>
> On Jul 19, 2016, at 6:00 PM, Otis Rothenberger 
> wrote:
>
> Jennifer,
>
> On your page, students make several choices to set up a problem. It
> appears that each choice does a GET and reloads the page from sever with
> appropriate page modification. How hard would it be to return the correct
> SMILES on each of these GETS?
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> On Jul 19, 2016, at 4:35 PM, Jennifer L. Muzyka <
> jennifer.muz...@centre.edu> wrote:
>
> Otis,
> Other information in the database includes:  CAS RN, InChI, InChiKey, and
> ChemSpider ID.  I’m aware that the different sources for SMILES is a
> potential issue, having already dealt with that.  I’m also aware that
> compounds can have more than one CAS number and more than one ChemSpider ID
> even though I learned that CAS numbers were unique back when I was in
> college.  An unfortunate reality is that I don’t have all of the keys for
> every compound.  Another potential problem with the database is that I
> might not have removed all of the situations where a single compound
> appeared more than once.  There are other things in the database (gifs,
> pdbs, jcamp spectra) for some compounds.
> Jennifer
>
>
>
>
>
> On Jul 19, 2016, at 4:22 PM, Otis Rothenberger 
> wrote:
>
> Jennifer,
>
> The default is that JSME keeps explicit hydrogens to carbon, and these
> will show up in brackets. An option can be used to turn this off.
>
> It sounds like you have a mix of SMILES that may have been created by
> options variations in the JSME implementations being used. That's a problem.
>
> One more question, and then I'll do some more thinking. What other items
> or keys are in the database?
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> On Jul 19, 2016, at 4:01 PM

Re: [Jmol-users] JSME and SMILES

Jennifer,

The student SMILES and the answer SMILES need to be compared on the client 
(browser) side via JavaScript. The student answer SMILES is already on the 
client side. All we would need is the answer SMILES there also.

Having said this, I know that Bob H once mentioned running the Java app on the 
server to do server side tasks, but running the Java app on the server is way 
beyond my programming skills.

With the power of modern JavaScript and HTML5, I’m not sure I see why the 
computer jocks are more comfortable with a second hit on the server. The fact 
is that the server cannot do the SMILES comparison as elegantly as Bob’s JSmol 
SMILES comparison, that is unless the Jmol Java App is run on the server. With 
the client side JavaScript/HTML5 power, it seems to me going back to the server 
is just going back to the server in order to go back to the server!

All of this, of course, is dependent on getting the answer SMILES into the 
working webpage.

Whichever route you go, that still leaves you with a database with some SMILES 
issues. Here’s a suggestion: How soon is Bob B’s cheminformatics course going 
into action again? Reconstructing your database entirely from Resolver (maybe 
PubChem) by an automated process would be a great real world project for one of 
the student teams. ( cc to Bob B)

Otis

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

> On Jul 19, 2016, at 8:22 PM, Jennifer L. Muzyka  
> wrote:
> 
> Otis,
> What you are describing is essentially how I handle the code for the page 
> where students draw the product structure.  It's certainly doable for the 
> starting material structure as well.  I would just need to work out the 
> different query and JavaScript.  My computer science colleagues would 
> probably consider that the brute force method, unlike the more elegant Ajax 
> method that goes back and queries the database a second time.  Is there some 
> advantage to keeping all of the code within the page rather than going back 
> to the database?  Those use PHP and MySQL.
> Jennifer
> 
> Sent from my iPad
> 
> On Jul 19, 2016, at 6:00 PM, Otis Rothenberger  > wrote:
> 
>> Jennifer,
>> 
>> On your page, students make several choices to set up a problem. It appears 
>> that each choice does a GET and reloads the page from sever with appropriate 
>> page modification. How hard would it be to return the correct SMILES on each 
>> of these GETS?
>> 
>> Otis
>> 
>> --
>> Otis Rothenberger
>> o...@chemagic.org 
>> http://chemagic.org 
>> 
>> On Jul 19, 2016, at 4:35 PM, Jennifer L. Muzyka > > wrote:
>> 
>>> Otis,
>>> Other information in the database includes:  CAS RN, InChI, InChiKey, and 
>>> ChemSpider ID.  I’m aware that the different sources for SMILES is a 
>>> potential issue, having already dealt with that.  I’m also aware that 
>>> compounds can have more than one CAS number and more than one ChemSpider ID 
>>> even though I learned that CAS numbers were unique back when I was in 
>>> college.  An unfortunate reality is that I don’t have all of the keys for 
>>> every compound.  Another potential problem with the database is that I 
>>> might not have removed all of the situations where a single compound 
>>> appeared more than once.  There are other things in the database (gifs, 
>>> pdbs, jcamp spectra) for some compounds.
>>> Jennifer
>>> 
>>> 
>>> 
>>> 
>>> 
 On Jul 19, 2016, at 4:22 PM, Otis Rothenberger >>> > wrote:

 Jennifer,

 The default is that JSME keeps explicit hydrogens to carbon, and these 
 will show up in brackets. An option can be used to turn this off.

 It sounds like you have a mix of SMILES that may have been created by 
 options variations in the JSME implementations being used. That's a 
 problem.

 One more question, and then I'll do some more thinking. What other items 
 or keys are in the database?

 Otis 

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

 On Jul 19, 2016, at 4:01 PM, Jennifer L. Muzyka 
 mailto:jennifer.muz...@centre.edu>> wrote:

> Otis,
> 1200 of the compounds have SMILES that agree with the JSME version.  
> Those were generated by a buddy of mine.  Then when I found some 
> disagreed, I went through them one by one to fix the ones that disagree.  
> 
> The next 3800 came from some other source than JSME when one of my 
> students imported the compounds into the database.  Most of those are not 
> involved in reactions so those compounds might not be relevant.  I 
> anticipate that I would change them one by one if needed so that they 
> agree with JSME.  None of those have SMILES that look like the stuff with 
> brackets and H’s that JSME produces.  They tend to us

Re: [Jmol-users] JSME and SMILES

Otis,
What you are describing is essentially how I handle the code for the page where 
students draw the product structure.  It's certainly doable for the starting 
material structure as well.  I would just need to work out the different query 
and JavaScript.  My computer science colleagues would probably consider that 
the brute force method, unlike the more elegant Ajax method that goes back and 
queries the database a second time.  Is there some advantage to keeping all of 
the code within the page rather than going back to the database?  Those use PHP 
and MySQL.
Jennifer

Sent from my iPad

On Jul 19, 2016, at 6:00 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

On your page, students make several choices to set up a problem. It appears 
that each choice does a GET and reloads the page from sever with appropriate 
page modification. How hard would it be to return the correct SMILES on each of 
these GETS?

Otis

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

On Jul 19, 2016, at 4:35 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
Other information in the database includes:  CAS RN, InChI, InChiKey, and 
ChemSpider ID.  I’m aware that the different sources for SMILES is a potential 
issue, having already dealt with that.  I’m also aware that compounds can have 
more than one CAS number and more than one ChemSpider ID even though I learned 
that CAS numbers were unique back when I was in college.  An unfortunate 
reality is that I don’t have all of the keys for every compound.  Another 
potential problem with the database is that I might not have removed all of the 
situations where a single compound appeared more than once.  There are other 
things in the database (gifs, pdbs, jcamp spectra) for some compounds.
Jennifer





On Jul 19, 2016, at 4:22 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

The default is that JSME keeps explicit hydrogens to carbon, and these will 
show up in brackets. An option can be used to turn this off.

It sounds like you have a mix of SMILES that may have been created by options 
variations in the JSME implementations being used. That's a problem.

One more question, and then I'll do some more thinking. What other items or 
keys are in the database?

Otis

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

On Jul 19, 2016, at 4:01 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
1200 of the compounds have SMILES that agree with the JSME version.  Those were 
generated by a buddy of mine.  Then when I found some disagreed, I went through 
them one by one to fix the ones that disagree.

The next 3800 came from some other source than JSME when one of my students 
imported the compounds into the database.  Most of those are not involved in 
reactions so those compounds might not be relevant.  I anticipate that I would 
change them one by one if needed so that they agree with JSME.  None of those 
have SMILES that look like the stuff with brackets and H’s that JSME produces.  
They tend to use the slashes to indicate double bond stereochemistry and @ to 
indicate chirality at stereocenters.  (People who are more proficient 
programmers than I am could probably complete the task more rapidly by 
automating it.)

Now I’m adding new reactions to accompany the question type where students draw 
the starting material rather than the product, I’m adding new compounds one by 
one.  I’m getting the SMILES for each of those compounds from the JSME database.
Jennifer



On Jul 19, 2016, at 3:51 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

On the student side, Jmol and JSME would be working together. This is no big 
deal - very easy. The problem is server side.

Let me think about this. Some important points: Do your existing database 
SMILES have stereo chemistry - i.e. / \ and @ notation where appropriate? Are 
they all JSME SMILES? Is there a possibility that the database creators may 
have drawn explicit hydrogens on carbon in non-stereo contect?

Otis

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

On Jul 19, 2016, at 3:37 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
The SMILES database has about 5000 compounds in it.  I’m  confused about how 
JSmol works here.  Would there be a JSmol drawing interface rather than JSME?  
I guess I need to go read the Jmol documentation about how to get the SMILES 
stuff working.  Is there some automated process to get the Jmol versions of the 
SMILES to update the database?
Jennifer




On Jul 19, 2016, at 2:00 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

For the most part,  there is no cross application canonical SMILES. Daylight 
never released the technical details to their reduction to canonical algorithm. 
Consequ

Re: [Jmol-users] JSME and SMILES

Jennifer,

On your page, students make several choices to set up a problem. It appears 
that each choice does a GET and reloads the page from sever with appropriate 
page modification. How hard would it be to return the correct SMILES on each of 
these GETS?

Otis

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

> On Jul 19, 2016, at 4:35 PM, Jennifer L. Muzyka  
> wrote:
> 
> Otis,
> Other information in the database includes:  CAS RN, InChI, InChiKey, and 
> ChemSpider ID.  I’m aware that the different sources for SMILES is a 
> potential issue, having already dealt with that.  I’m also aware that 
> compounds can have more than one CAS number and more than one ChemSpider ID 
> even though I learned that CAS numbers were unique back when I was in 
> college.  An unfortunate reality is that I don’t have all of the keys for 
> every compound.  Another potential problem with the database is that I might 
> not have removed all of the situations where a single compound appeared more 
> than once.  There are other things in the database (gifs, pdbs, jcamp 
> spectra) for some compounds.
> Jennifer
> 
> 
> 
> 
> 
>> On Jul 19, 2016, at 4:22 PM, Otis Rothenberger  wrote:
>> 
>> Jennifer,
>> 
>> The default is that JSME keeps explicit hydrogens to carbon, and these will 
>> show up in brackets. An option can be used to turn this off.
>> 
>> It sounds like you have a mix of SMILES that may have been created by 
>> options variations in the JSME implementations being used. That's a problem.
>> 
>> One more question, and then I'll do some more thinking. What other items or 
>> keys are in the database?
>> 
>> Otis 
>> 
>> --
>> Otis Rothenberger
>> o...@chemagic.org
>> http://chemagic.org
>> 
>> On Jul 19, 2016, at 4:01 PM, Jennifer L. Muzyka  
>> wrote:
>> 
>>> Otis,
>>> 1200 of the compounds have SMILES that agree with the JSME version.  Those 
>>> were generated by a buddy of mine.  Then when I found some disagreed, I 
>>> went through them one by one to fix the ones that disagree.  
>>> 
>>> The next 3800 came from some other source than JSME when one of my students 
>>> imported the compounds into the database.  Most of those are not involved 
>>> in reactions so those compounds might not be relevant.  I anticipate that I 
>>> would change them one by one if needed so that they agree with JSME.  None 
>>> of those have SMILES that look like the stuff with brackets and H’s that 
>>> JSME produces.  They tend to use the slashes to indicate double bond 
>>> stereochemistry and @ to indicate chirality at stereocenters.  (People who 
>>> are more proficient programmers than I am could probably complete the task 
>>> more rapidly by automating it.)
>>> 
>>> Now I’m adding new reactions to accompany the question type where students 
>>> draw the starting material rather than the product, I’m adding new 
>>> compounds one by one.  I’m getting the SMILES for each of those compounds 
>>> from the JSME database.
>>> Jennifer
>>> 
>>> 
>>> 
 On Jul 19, 2016, at 3:51 PM, Otis Rothenberger  wrote:
 
 Jennifer,
 
 On the student side, Jmol and JSME would be working together. This is no 
 big deal - very easy. The problem is server side.
 
 Let me think about this. Some important points: Do your existing database 
 SMILES have stereo chemistry - i.e. / \ and @ notation where appropriate? 
 Are they all JSME SMILES? Is there a possibility that the database 
 creators may have drawn explicit hydrogens on carbon in non-stereo contect?
 
 Otis
 
 --
 Otis Rothenberger
 o...@chemagic.org
 http://chemagic.org
 
 On Jul 19, 2016, at 3:37 PM, Jennifer L. Muzyka 
  wrote:
 
> Otis,
> The SMILES database has about 5000 compounds in it.  I’m  confused about 
> how JSmol works here.  Would there be a JSmol drawing interface rather 
> than JSME?  I guess I need to go read the Jmol documentation about how to 
> get the SMILES stuff working.  Is there some automated process to get the 
> Jmol versions of the SMILES to update the database?
> Jennifer
> 
> 
> 
> 
>> On Jul 19, 2016, at 2:00 PM, Otis Rothenberger  
>> wrote:
>> 
>> Jennifer,
>> 
>> For the most part,  there is no cross application canonical SMILES. 
>> Daylight never released the technical details to their reduction to 
>> canonical algorithm. Consequently, uniqueness exists only within a given 
>> “copycat” application. I believe PubChem uses Open Eye SMILES. If you 
>> were comparing Open Eye unique SMILES to Open Eye unique SMILE, you 
>> could do a simple string comparison.
>> 
>> JSME is top notch in my opinion. I would not use any other online 
>> drawing software, but with JSME, you cannot have canonical (unique) 
>> SMILES AND stereochemistry. If you want simple string comparison, both 
>> SMILES (sever and student drawn) will have to be JSME without E/Z and 
>

Re: [Jmol-users] JSME and SMILES

Otis,
Other information in the database includes:  CAS RN, InChI, InChiKey, and 
ChemSpider ID.  I’m aware that the different sources for SMILES is a potential 
issue, having already dealt with that.  I’m also aware that compounds can have 
more than one CAS number and more than one ChemSpider ID even though I learned 
that CAS numbers were unique back when I was in college.  An unfortunate 
reality is that I don’t have all of the keys for every compound.  Another 
potential problem with the database is that I might not have removed all of the 
situations where a single compound appeared more than once.  There are other 
things in the database (gifs, pdbs, jcamp spectra) for some compounds.
Jennifer





On Jul 19, 2016, at 4:22 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

The default is that JSME keeps explicit hydrogens to carbon, and these will 
show up in brackets. An option can be used to turn this off.

It sounds like you have a mix of SMILES that may have been created by options 
variations in the JSME implementations being used. That's a problem.

One more question, and then I'll do some more thinking. What other items or 
keys are in the database?

Otis

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

On Jul 19, 2016, at 4:01 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
1200 of the compounds have SMILES that agree with the JSME version.  Those were 
generated by a buddy of mine.  Then when I found some disagreed, I went through 
them one by one to fix the ones that disagree.

The next 3800 came from some other source than JSME when one of my students 
imported the compounds into the database.  Most of those are not involved in 
reactions so those compounds might not be relevant.  I anticipate that I would 
change them one by one if needed so that they agree with JSME.  None of those 
have SMILES that look like the stuff with brackets and H’s that JSME produces.  
They tend to use the slashes to indicate double bond stereochemistry and @ to 
indicate chirality at stereocenters.  (People who are more proficient 
programmers than I am could probably complete the task more rapidly by 
automating it.)

Now I’m adding new reactions to accompany the question type where students draw 
the starting material rather than the product, I’m adding new compounds one by 
one.  I’m getting the SMILES for each of those compounds from the JSME database.
Jennifer



On Jul 19, 2016, at 3:51 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

On the student side, Jmol and JSME would be working together. This is no big 
deal - very easy. The problem is server side.

Let me think about this. Some important points: Do your existing database 
SMILES have stereo chemistry - i.e. / \ and @ notation where appropriate? Are 
they all JSME SMILES? Is there a possibility that the database creators may 
have drawn explicit hydrogens on carbon in non-stereo contect?

Otis

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

On Jul 19, 2016, at 3:37 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
The SMILES database has about 5000 compounds in it.  I’m  confused about how 
JSmol works here.  Would there be a JSmol drawing interface rather than JSME?  
I guess I need to go read the Jmol documentation about how to get the SMILES 
stuff working.  Is there some automated process to get the Jmol versions of the 
SMILES to update the database?
Jennifer




On Jul 19, 2016, at 2:00 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

For the most part,  there is no cross application canonical SMILES. Daylight 
never released the technical details to their reduction to canonical algorithm. 
Consequently, uniqueness exists only within a given “copycat” application. I 
believe PubChem uses Open Eye SMILES. If you were comparing Open Eye unique 
SMILES to Open Eye unique SMILE, you could do a simple string comparison.

JSME is top notch in my opinion. I would not use any other online drawing 
software, but with JSME, you cannot have canonical (unique) SMILES AND 
stereochemistry. If you want simple string comparison, both SMILES (sever and 
student drawn) will have to be JSME without E/Z and stereo chemistry. I’m 
almost certain that this has not changed since the "old doc" in the previous 
email. I think this means that you are going to have to use these explicit 
options in server and client JSME SMILE creation: noquery (this is default), 
noautoez, canonize (this is default), nostereo. I’d list all explicitly.

This probably not what you actually want, and that’s the absolute beauty of 
what Bob created in JSmol! With Bob’s approach, the cross application unique 
SMILES barriers do not matter. Bob took the expression “unique SMILES” and made 
it obsolete!

To do this (include stereochemistry via Bob’s approach

Re: [Jmol-users] JSME and SMILES

Jennifer,

The default is that JSME keeps explicit hydrogens to carbon, and these will 
show up in brackets. An option can be used to turn this off.

It sounds like you have a mix of SMILES that may have been created by options 
variations in the JSME implementations being used. That's a problem.

One more question, and then I'll do some more thinking. What other items or 
keys are in the database?

Otis 

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

> On Jul 19, 2016, at 4:01 PM, Jennifer L. Muzyka  
> wrote:
> 
> Otis,
> 1200 of the compounds have SMILES that agree with the JSME version.  Those 
> were generated by a buddy of mine.  Then when I found some disagreed, I went 
> through them one by one to fix the ones that disagree.  
> 
> The next 3800 came from some other source than JSME when one of my students 
> imported the compounds into the database.  Most of those are not involved in 
> reactions so those compounds might not be relevant.  I anticipate that I 
> would change them one by one if needed so that they agree with JSME.  None of 
> those have SMILES that look like the stuff with brackets and H’s that JSME 
> produces.  They tend to use the slashes to indicate double bond 
> stereochemistry and @ to indicate chirality at stereocenters.  (People who 
> are more proficient programmers than I am could probably complete the task 
> more rapidly by automating it.)
> 
> Now I’m adding new reactions to accompany the question type where students 
> draw the starting material rather than the product, I’m adding new compounds 
> one by one.  I’m getting the SMILES for each of those compounds from the JSME 
> database.
> Jennifer
> 
> 
> 
> 
> 
> 
> Jennifer Muzyka
> H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
> Centre College
> 600 West Walnut Street
> Danville, KY  40422
> 
> jennifer.muz...@centre.edu
> http://web.centre.edu/muzyka
> http://organicers.org
> 
> 859-238-5413
> fax 859-236-7925
> 
> 
> 
> 
> 
> 
>> On Jul 19, 2016, at 3:51 PM, Otis Rothenberger  wrote:
>> 
>> Jennifer,
>> 
>> On the student side, Jmol and JSME would be working together. This is no big 
>> deal - very easy. The problem is server side.
>> 
>> Let me think about this. Some important points: Do your existing database 
>> SMILES have stereo chemistry - i.e. / \ and @ notation where appropriate? 
>> Are they all JSME SMILES? Is there a possibility that the database creators 
>> may have drawn explicit hydrogens on carbon in non-stereo contect?
>> 
>> Otis
>> 
>> --
>> Otis Rothenberger
>> o...@chemagic.org
>> http://chemagic.org
>> 
>> On Jul 19, 2016, at 3:37 PM, Jennifer L. Muzyka  
>> wrote:
>> 
>>> Otis,
>>> The SMILES database has about 5000 compounds in it.  I’m  confused about 
>>> how JSmol works here.  Would there be a JSmol drawing interface rather than 
>>> JSME?  I guess I need to go read the Jmol documentation about how to get 
>>> the SMILES stuff working.  Is there some automated process to get the Jmol 
>>> versions of the SMILES to update the database?
>>> Jennifer
>>> 
>>> 
>>> 
>>> 
 On Jul 19, 2016, at 2:00 PM, Otis Rothenberger  wrote:

 Jennifer,

 For the most part,  there is no cross application canonical SMILES. 
 Daylight never released the technical details to their reduction to 
 canonical algorithm. Consequently, uniqueness exists only within a given 
 “copycat” application. I believe PubChem uses Open Eye SMILES. If you were 
 comparing Open Eye unique SMILES to Open Eye unique SMILE, you could do a 
 simple string comparison.

 JSME is top notch in my opinion. I would not use any other online drawing 
 software, but with JSME, you cannot have canonical (unique) SMILES AND 
 stereochemistry. If you want simple string comparison, both SMILES (sever 
 and student drawn) will have to be JSME without E/Z and stereo chemistry. 
 I’m almost certain that this has not changed since the "old doc" in the 
 previous email. I think this means that you are going to have to use these 
 explicit options in server and client JSME SMILE creation: noquery (this 
 is default), noautoez, canonize (this is default), nostereo. I’d list all 
 explicitly.

 This probably not what you actually want, and that’s the absolute beauty 
 of what Bob created in JSmol! With Bob’s approach, the cross application 
 unique SMILES barriers do not matter. Bob took the expression “unique 
 SMILES” and made it obsolete!

 To do this (include stereochemistry via Bob’s approach) you will also have 
 to make some options selections in JSME, but you will also be able to use 
 E/Z and stereochemistry.

 How large is your SMILES database?

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

> On Jul 19, 2016, at 1:23 PM, Jennifer L. Muzyka 
>  wrote:
> 
> Otis,
> The SMILES goes back to the MySQL database for comparison

Re: [Jmol-users] JSME and SMILES

Otis,
1200 of the compounds have SMILES that agree with the JSME version.  Those were 
generated by a buddy of mine.  Then when I found some disagreed, I went through 
them one by one to fix the ones that disagree.

The next 3800 came from some other source than JSME when one of my students 
imported the compounds into the database.  Most of those are not involved in 
reactions so those compounds might not be relevant.  I anticipate that I would 
change them one by one if needed so that they agree with JSME.  None of those 
have SMILES that look like the stuff with brackets and H’s that JSME produces.  
They tend to use the slashes to indicate double bond stereochemistry and @ to 
indicate chirality at stereocenters.  (People who are more proficient 
programmers than I am could probably complete the task more rapidly by 
automating it.)

Now I’m adding new reactions to accompany the question type where students draw 
the starting material rather than the product, I’m adding new compounds one by 
one.  I’m getting the SMILES for each of those compounds from the JSME database.
Jennifer






Jennifer Muzyka
H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
Centre College
600 West Walnut Street
Danville, KY  40422

jennifer.muz...@centre.edu
http://web.centre.edu/muzyka
http://organicers.org

859-238-5413
fax 859-236-7925






On Jul 19, 2016, at 3:51 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

On the student side, Jmol and JSME would be working together. This is no big 
deal - very easy. The problem is server side.

Let me think about this. Some important points: Do your existing database 
SMILES have stereo chemistry - i.e. / \ and @ notation where appropriate? Are 
they all JSME SMILES? Is there a possibility that the database creators may 
have drawn explicit hydrogens on carbon in non-stereo contect?

Otis

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

On Jul 19, 2016, at 3:37 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
The SMILES database has about 5000 compounds in it.  I’m  confused about how 
JSmol works here.  Would there be a JSmol drawing interface rather than JSME?  
I guess I need to go read the Jmol documentation about how to get the SMILES 
stuff working.  Is there some automated process to get the Jmol versions of the 
SMILES to update the database?
Jennifer




On Jul 19, 2016, at 2:00 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

For the most part,  there is no cross application canonical SMILES. Daylight 
never released the technical details to their reduction to canonical algorithm. 
Consequently, uniqueness exists only within a given “copycat” application. I 
believe PubChem uses Open Eye SMILES. If you were comparing Open Eye unique 
SMILES to Open Eye unique SMILE, you could do a simple string comparison.

JSME is top notch in my opinion. I would not use any other online drawing 
software, but with JSME, you cannot have canonical (unique) SMILES AND 
stereochemistry. If you want simple string comparison, both SMILES (sever and 
student drawn) will have to be JSME without E/Z and stereo chemistry. I’m 
almost certain that this has not changed since the "old doc" in the previous 
email. I think this means that you are going to have to use these explicit 
options in server and client JSME SMILE creation: noquery (this is default), 
noautoez, canonize (this is default), nostereo. I’d list all explicitly.

This probably not what you actually want, and that’s the absolute beauty of 
what Bob created in JSmol! With Bob’s approach, the cross application unique 
SMILES barriers do not matter. Bob took the expression “unique SMILES” and made 
it obsolete!

To do this (include stereochemistry via Bob’s approach) you will also have to 
make some options selections in JSME, but you will also be able to use E/Z and 
stereochemistry.

How large is your SMILES database?

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

On Jul 19, 2016, at 1:23 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
The SMILES goes back to the MySQL database for comparison rather than just 
running JavaScript within the browser.  The stuff in the database was all 
generated with JSME.  (So I’m confused about how adding Jmol to the mix will 
help.)  The “canonical” SMILES generated by JSME sure doesn’t look like the 
canonical SMILES provided in PubChem.  But maybe I’m actually getting SMARTS?  
I will go read the documentation you have pointed out.
Jennifer






On Jul 18, 2016, at 10:56 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

I knew this statement was out there. It took me a while to find the Web doc:

"public String JME.smiles()

returns a SMILES string of the current molecule(s) or reaction. For single 
molecule witho

Re: [Jmol-users] JSME and SMILES

Jennifer,

On the student side, Jmol and JSME would be working together. This is no big 
deal - very easy. The problem is server side.

Let me think about this. Some important points: Do your existing database 
SMILES have stereo chemistry - i.e. / \ and @ notation where appropriate? Are 
they all JSME SMILES? Is there a possibility that the database creators may 
have drawn explicit hydrogens on carbon in non-stereo contect?

Otis

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

> On Jul 19, 2016, at 3:37 PM, Jennifer L. Muzyka  
> wrote:
> 
> Otis,
> The SMILES database has about 5000 compounds in it.  I’m  confused about how 
> JSmol works here.  Would there be a JSmol drawing interface rather than JSME? 
>  I guess I need to go read the Jmol documentation about how to get the SMILES 
> stuff working.  Is there some automated process to get the Jmol versions of 
> the SMILES to update the database?
> Jennifer
> 
> 
> 
> 
> 
> 
> Jennifer Muzyka
> H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
> Centre College
> 600 West Walnut Street
> Danville, KY  40422
> 
> jennifer.muz...@centre.edu
> http://web.centre.edu/muzyka
> http://organicers.org
> 
> 859-238-5413
> fax 859-236-7925
> 
> 
> 
> 
> 
> 
>> On Jul 19, 2016, at 2:00 PM, Otis Rothenberger  wrote:
>> 
>> Jennifer,
>> 
>> For the most part,  there is no cross application canonical SMILES. Daylight 
>> never released the technical details to their reduction to canonical 
>> algorithm. Consequently, uniqueness exists only within a given “copycat” 
>> application. I believe PubChem uses Open Eye SMILES. If you were comparing 
>> Open Eye unique SMILES to Open Eye unique SMILE, you could do a simple 
>> string comparison.
>> 
>> JSME is top notch in my opinion. I would not use any other online drawing 
>> software, but with JSME, you cannot have canonical (unique) SMILES AND 
>> stereochemistry. If you want simple string comparison, both SMILES (sever 
>> and student drawn) will have to be JSME without E/Z and stereo chemistry. 
>> I’m almost certain that this has not changed since the "old doc" in the 
>> previous email. I think this means that you are going to have to use these 
>> explicit options in server and client JSME SMILE creation: noquery (this is 
>> default), noautoez, canonize (this is default), nostereo. I’d list all 
>> explicitly.
>> 
>> This probably not what you actually want, and that’s the absolute beauty of 
>> what Bob created in JSmol! With Bob’s approach, the cross application unique 
>> SMILES barriers do not matter. Bob took the expression “unique SMILES” and 
>> made it obsolete!
>> 
>> To do this (include stereochemistry via Bob’s approach) you will also have 
>> to make some options selections in JSME, but you will also be able to use 
>> E/Z and stereochemistry.
>> 
>> How large is your SMILES database?
>> 
>> --
>> Otis Rothenberger
>> o...@chemagic.org
>> http://chemagic.org
>> 
>>> On Jul 19, 2016, at 1:23 PM, Jennifer L. Muzyka 
>>>  wrote:
>>> 
>>> Otis,
>>> The SMILES goes back to the MySQL database for comparison rather than just 
>>> running JavaScript within the browser.  The stuff in the database was all 
>>> generated with JSME.  (So I’m confused about how adding Jmol to the mix 
>>> will help.)  The “canonical” SMILES generated by JSME sure doesn’t look 
>>> like the canonical SMILES provided in PubChem.  But maybe I’m actually 
>>> getting SMARTS?  I will go read the documentation you have pointed out.  
>>> Jennifer
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Jennifer Muzyka
>>> H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
>>> Centre College
>>> 600 West Walnut Street
>>> Danville, KY  40422
>>> 
>>> jennifer.muz...@centre.edu
>>> http://web.centre.edu/muzyka
>>> http://organicers.org
>>> 
>>> 859-238-5413
>>> fax 859-236-7925
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 On Jul 18, 2016, at 10:56 PM, Otis Rothenberger  
 wrote:
 
 Jennifer,
 
 I knew this statement was out there. It took me a while to find the Web 
 doc:
 
 "public String JME.smiles()
 
 returns a SMILES string of the current molecule(s) or reaction. For single 
 molecule without stereochemistry the SMILES is unique, unification is not 
 yet implemented for molecules with stereochemistry and for reactions.”
 http://www.molinspiration.com/jme/doc/jme_functions.html
 
 It’s an old doc, but I’m sure it still applies.
 
 Since canonize is the default in JSME, you’re going to have to select 
 nocanonize!
 
 Also, your current option setting sets the “query” option. That sets up 
 SMARTS mode. I don’t think that is what you want?
 
 Although it’s commented out in your current HTML, it looks like you are 
 set of for a simple string comparison. That’s not going to work. This is 
 where Bob’s JSmol .find approach comes into play - my previous email.
 
 I’ve been using a Jmol/JSME SMILES comparison for quite a while,

Re: [Jmol-users] JSME and SMILES

Otis,
The SMILES database has about 5000 compounds in it.  I’m  confused about how 
JSmol works here.  Would there be a JSmol drawing interface rather than JSME?  
I guess I need to go read the Jmol documentation about how to get the SMILES 
stuff working.  Is there some automated process to get the Jmol versions of the 
SMILES to update the database?
Jennifer






Jennifer Muzyka
H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
Centre College
600 West Walnut Street
Danville, KY  40422

jennifer.muz...@centre.edu
http://web.centre.edu/muzyka
http://organicers.org

859-238-5413
fax 859-236-7925






On Jul 19, 2016, at 2:00 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

For the most part,  there is no cross application canonical SMILES. Daylight 
never released the technical details to their reduction to canonical algorithm. 
Consequently, uniqueness exists only within a given “copycat” application. I 
believe PubChem uses Open Eye SMILES. If you were comparing Open Eye unique 
SMILES to Open Eye unique SMILE, you could do a simple string comparison.

JSME is top notch in my opinion. I would not use any other online drawing 
software, but with JSME, you cannot have canonical (unique) SMILES AND 
stereochemistry. If you want simple string comparison, both SMILES (sever and 
student drawn) will have to be JSME without E/Z and stereo chemistry. I’m 
almost certain that this has not changed since the "old doc" in the previous 
email. I think this means that you are going to have to use these explicit 
options in server and client JSME SMILE creation: noquery (this is default), 
noautoez, canonize (this is default), nostereo. I’d list all explicitly.

This probably not what you actually want, and that’s the absolute beauty of 
what Bob created in JSmol! With Bob’s approach, the cross application unique 
SMILES barriers do not matter. Bob took the expression “unique SMILES” and made 
it obsolete!

To do this (include stereochemistry via Bob’s approach) you will also have to 
make some options selections in JSME, but you will also be able to use E/Z and 
stereochemistry.

How large is your SMILES database?

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

On Jul 19, 2016, at 1:23 PM, Jennifer L. Muzyka 
mailto:jennifer.muz...@centre.edu>> wrote:

Otis,
The SMILES goes back to the MySQL database for comparison rather than just 
running JavaScript within the browser.  The stuff in the database was all 
generated with JSME.  (So I’m confused about how adding Jmol to the mix will 
help.)  The “canonical” SMILES generated by JSME sure doesn’t look like the 
canonical SMILES provided in PubChem.  But maybe I’m actually getting SMARTS?  
I will go read the documentation you have pointed out.
Jennifer






Jennifer Muzyka
H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
Centre College
600 West Walnut Street
Danville, KY  40422

jennifer.muz...@centre.edu
http://web.centre.edu/muzyka
http://organicers.org

859-238-5413
fax 859-236-7925






On Jul 18, 2016, at 10:56 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

I knew this statement was out there. It took me a while to find the Web doc:

"public String JME.smiles()

returns a SMILES string of the current molecule(s) or reaction. For single 
molecule without stereochemistry the SMILES is unique, unification is not yet 
implemented for molecules with stereochemistry and for reactions.”
http://www.molinspiration.com/jme/doc/jme_functions.html

It’s an old doc, but I’m sure it still applies.

Since canonize is the default in JSME, you’re going to have to select 
nocanonize!

Also, your current option setting sets the “query” option. That sets up SMARTS 
mode. I don’t think that is what you want?

Although it’s commented out in your current HTML, it looks like you are set of 
for a simple string comparison. That’s not going to work. This is where Bob’s 
JSmol .find approach comes into play - my previous email.

I’ve been using a Jmol/JSME SMILES comparison for quite a while, so don’t 
hesitate to ask if you need more specific information.

Otis

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

On Jul 18, 2016, at 4:22 PM, Otis Rothenberger 
mailto:osrot...@icloud.com>> wrote:

Jennifer,

You have to set SMILES settings in the JSME options part of your JSME set-up to 
invoke stereochemistry and E/Z. This page explains all of the options and the 
set up procedure:

http://peter-ertl.com/jsme/JSME_2015-06-14/doc.html

BUT, BUT,  it looks like you are doing SMILES comparisons, and with 
stereochemistry and E/Z invoked, I’m pretty sure JSME SMILES are not unique. 
The best way to compare SMILES is with JSmol. In the case of your page, you 
could hide JSmol on the page. Comparison can be done in JavaScript:

funct

Re: [Jmol-users] JSME and SMILES

Jennifer,

For the most part,  there is no cross application canonical SMILES. Daylight 
never released the technical details to their reduction to canonical algorithm. 
Consequently, uniqueness exists only within a given “copycat” application. I 
believe PubChem uses Open Eye SMILES. If you were comparing Open Eye unique 
SMILES to Open Eye unique SMILE, you could do a simple string comparison.

JSME is top notch in my opinion. I would not use any other online drawing 
software, but with JSME, you cannot have canonical (unique) SMILES AND 
stereochemistry. If you want simple string comparison, both SMILES (sever and 
student drawn) will have to be JSME without E/Z and stereo chemistry. I’m 
almost certain that this has not changed since the "old doc" in the previous 
email. I think this means that you are going to have to use these explicit 
options in server and client JSME SMILE creation: noquery (this is default), 
noautoez, canonize (this is default), nostereo. I’d list all explicitly.

This probably not what you actually want, and that’s the absolute beauty of 
what Bob created in JSmol! With Bob’s approach, the cross application unique 
SMILES barriers do not matter. Bob took the expression “unique SMILES” and made 
it obsolete!

To do this (include stereochemistry via Bob’s approach) you will also have to 
make some options selections in JSME, but you will also be able to use E/Z and 
stereochemistry.

How large is your SMILES database?

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

> On Jul 19, 2016, at 1:23 PM, Jennifer L. Muzyka  
> wrote:
> 
> Otis,
> The SMILES goes back to the MySQL database for comparison rather than just 
> running JavaScript within the browser.  The stuff in the database was all 
> generated with JSME.  (So I’m confused about how adding Jmol to the mix will 
> help.)  The “canonical” SMILES generated by JSME sure doesn’t look like the 
> canonical SMILES provided in PubChem.  But maybe I’m actually getting SMARTS? 
>  I will go read the documentation you have pointed out.  
> Jennifer
> 
> 
> 
> 
> 
> 
> Jennifer Muzyka
> H.W. Stodghill Jr. and Adele H. Stodghill Professor of Chemistry
> Centre College
> 600 West Walnut Street
> Danville, KY  40422
> 
> jennifer.muz...@centre.edu 
> http://web.centre.edu/muzyka 
> http://organicers.org 
> 
> 859-238-5413
> fax 859-236-7925
> 
> 
> 
> 
> 
> 
>> On Jul 18, 2016, at 10:56 PM, Otis Rothenberger > > wrote:
>> 
>> Jennifer,
>> 
>> I knew this statement was out there. It took me a while to find the Web doc:
>> 
>> "public String JME.smiles()
>> 
>> returns a SMILES string of the current molecule(s) or reaction. For single 
>> molecule without stereochemistry the SMILES is unique, unification is not 
>> yet implemented for molecules with stereochemistry and for reactions.”
>> http://www.molinspiration.com/jme/doc/jme_functions.html 
>> 
>> 
>> It’s an old doc, but I’m sure it still applies.
>> 
>> Since canonize is the default in JSME, you’re going to have to select 
>> nocanonize!
>> 
>> Also, your current option setting sets the “query” option. That sets up 
>> SMARTS mode. I don’t think that is what you want?
>> 
>> Although it’s commented out in your current HTML, it looks like you are set 
>> of for a simple string comparison. That’s not going to work. This is where 
>> Bob’s JSmol .find approach comes into play - my previous email.
>> 
>> I’ve been using a Jmol/JSME SMILES comparison for quite a while, so don’t 
>> hesitate to ask if you need more specific information.
>> 
>> Otis
>> 
>> --
>> Otis Rothenberger
>> o...@chemagic.org 
>> http://chemagic.org 
>>> On Jul 18, 2016, at 4:22 PM, Otis Rothenberger >> > wrote:
>>> 
>>> Jennifer,
>>> 
>>> You have to set SMILES settings in the JSME options part of your JSME 
>>> set-up to invoke stereochemistry and E/Z. This page explains all of the 
>>> options and the set up procedure:
>>> 
>>> http://peter-ertl.com/jsme/JSME_2015-06-14/doc.html 
>>> 
>>> 
>>> BUT, BUT,  it looks like you are doing SMILES comparisons, and with 
>>> stereochemistry and E/Z invoked, I’m pretty sure JSME SMILES are not 
>>> unique. The best way to compare SMILES is with JSmol. In the case of your 
>>> page, you could hide JSmol on the page. Comparison can be done in 
>>> JavaScript:
>>> 
>>> function compSmiles(key, ans) {
>>> key = key.replace(/\\/g, '');
>>> ans = ans.replace(/\\/g, '');
>>> return Jmol.evaluateVar(jmolApplet0. "'" + key + "'.find('SMILES','" + ans 
>>> + "') > 0");
>>> }
>>> 
>>> My quotes above are hard to read, so here’s the function with spaces to 
>>> emphasis the quotes:
>>> 
>>> function compSmiles(key, ans) {
>>> key = key.replace(/\\/g, '  ');
>>> ans

Re: [Jmol-users] JSME and SMILES