[Jmol-users] Useful Compare Operation with JME

[Otis R. <osr...@ch...>]

  I don't think this is a documented capability, but it seems to work 
well. It also may not be unexpected, but it pleasantly surprised me. If 
you draw two structures in a JME editor that is hooked to Jmol, then the 
following compare works when you parse the two JME SMILES in the 
original JME SMILES string:

var y = compare(smi1, smi2, 'ISOMER'); echo @y;

smi1 and smi2 are simply the JME SMILES fed to Jmol Script via 
JavaScript variables. While there are issues (aromatics, maybe 
others(?)) cross comparing JME and Jmol SMILES, this internal JME/JME 
seems to work as well as Jmol/Jmol comparisons.

My reason for this use of compare is related to an aldose SMILES mess 
(unrelated to Jmol) that I'm trying to clean up in our application. When 
I decided to generalize the approach, I only ran into one issue. In 
passing the JME SMILES from JavaScript to Jmol Script, I lost the "\" 
character in e/z alkenes. This was corrected by the following:

jmolScript("smi1 = '" + smils[0].replace(/\\/g, '\\\\') + "';")
jmolScript("smi2 = '" + smils[1].replace(/\\/g, '\\\\') + "';")

smils[0] and smils[1] are the JavaScript array variables resulting from 
a split of the original JME SMILES in the "." character.

While passing the actual models to Jmol is a comparison option, I found 
this direct approach allowed me to quickly check and edit structures 
with multiple chiral centers. In addition, UFF doesn't always get it 
right. Passing D-glucose from JME to Jmol (Fisher Projections) directly 
results in the rendering of D-galactose. The recently added NIH 
rendering does, however, get this correct.

Related Issue:
I'm going to check on this next point. I think the NIH molfile return on 
a name query is database directed (i.e. sometimes wrong). I think (and 
I'll check this) that the molfile return on a SMILES is computed.

Otis

-- 
Otis Rothenberger
chemagic.com