Bob,
I thought maybe you were taking a well deserved vacation. It sounds like
it was a working vacation.
The apology is mine. In my usual verbose style, the guts of the problem
is in my third email. The square planar notation in the alkene SMILES is
throwing a monkey wrench into compare and find. All of this worked so
well in the examples we looked at that I missed the point that alkenes
were presenting this problem.
FYI, NIH translate recognizes these @SP# alkene SMILES, at least it
returns a molfile. Daylight Depict throws errors, but still renders a
structure.
Otis
Otis Rothenberger
chemagic.com
On 8/7/2010 5:19 PM, Robert Hanson wrote:
sorry -- was at the BCCE conference....
var i = {*}.atomIndex.max + 1;
select within(branch, {atomIndex = i}, {atomIndex=0});
What is the intent of that, Otis? I'm pretty sure that's the same as
select molecule=1
right?
Bob
On Wed, Aug 4, 2010 at 10:16 AM, Otis Rothenberger
<osrot...@chemagic.com <mailto:osrot...@chemagic.com>> wrote:
The following Jmol script works flawlessly with two small (C6 ish)
molecules as they undergo model kit editing in the same frame:
var sm = {*}.find('SMILES');var i = {*}.atomIndex.max + 1;select
within(branch, {atomIndex = i}, {atomIndex=0});var x =
{selected}.size;var y={*}.size;var z = y - x;var w = 'The models are
identical.';if (z != 0){var i = compare({selected},{not
selected},'SMILES',sm,'stddev');if (i == 'NAN'){w = 'The models
are NOT
identical.'};echo @w;}
I mean flawlessly, including stereochemistry.
With large models (e.g. some monoterpenes), the behavior of the script
is erratic - works once and stops; does not work at all, throwing a
script error after if (i == 'NAN'), or reporting incorrect comparison
results. To make sure that the assumption that I was making with the
opening var sm = {*}.find('SMILES') was correct, I rearranged the
script
to place this fragment in a more certain position:
var i = {*}.atomIndex.max + 1;select within(branch, {atomIndex = i},
{atomIndex=0});var sm = {selected}.find('SMILES');var x =
{selected}.size;var y={*}.size;var z = y - x;var w = 'The models are
identical.';if (z != 0){var i = compare({selected},{not
selected},'SMILES',sm,'stddev');if (i == 'NAN'){w = 'The models
are NOT
identical.'};echo @w;}
Same result.
Is this a matter of the compare function inherently "stressing out"
with model size, or is there a logic error in my script code. Things
seem to go erratic at about 20-30 total atoms.
definitely not. I've compared the entire ribosomal large subunit.
By way of example with two pulegone models, the first run of the
script
produces the models identical echo. After the edit of one model (H
to Cl
back to H, just to do an edit back to identical), I get the following
history:
sounds like a good test.
var sm = {*}.find('SMILES');
..SMILES for both models as though one...
var i = {*}.atomIndex.max + 1;
select within(branch, {atomIndex = i}, {atomIndex=0});
...same as select molecule=1, I think
27 atoms selected
var x = {selected}.size;
var y={*}.size;
var z = y - x;
var w = 'The models are identical.';
if (z != 0);
... true if there is more than one molecule, I think...
var i = compare({selected},{not selected},'SMILES',sm,'stddev');
script ERROR:
Otis
OK, one thing is that Jmol isn't numbering molecules correctly after
atoms are deleted. But that's not the problem here. What you seem to
be doing is using the compare command with SMILES -- meaning a
conformational search. A value of 0.0 for i would mean the two models
have the same configuration AND conformation. "NAN" would mean they
failed the SMILES match and so are nonidentical.
The way I was thinking to categorize two models is this:
var m1 = {molecule=1} # or whatever
var m2 = {molecule=2} # or whatever
# check molecular formulas
var sameMF = (m1.find("MF") == m2.find("MF"))
# get SMILES string for molecule 1
var smiles = m1.find("SMILES")
var smiles_enantiomer =
sm.replace("@@","!@").replace("@","@@").replace("!@@","@")
var smiles_nostereo = smiles.replace("@","")
# note: we can't just compare SMILES strings like we can molecular
formulas
# because SMILES strings here are not "cannonical" - but that is no
problem at all
# instead, we "find" the SMILES string for one model in the other.
Using "SMILES"
# here instead of "SMARTS" guarantees an exact search and not a
substructure search
var identical = sameMF && (m2.find("SMILES",smiles)> 0)
var configurationalIsomers = sameMF && !identical &&
(m2.find("SMILES",sm_nostereo) > 0)
var enantiomers = configurationalIsomers &&
(m2.find("SMILES",smiles_enantiomer) > 0)
var diastereomers = configurationalIsomers && !enantiomers
var constitutionalIsomers = sameMF && !identical &&
!configurationalIsomers
...but "molecule=2" won't work right now after you delete atoms. It's
fixed for Jmol 12.1.2 and Jmol 12.0.4
Bob
--
Otis Rothenberger
chemagic.com <http://chemagic.com>
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
<mailto:Jmol-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/jmol-users
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
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
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
