One more data point on this problem:
The following script returned what I will call traditional SMILES for
substituted alkenes up to and including 12.0.RC20
var sm = {*}.find('SMILES');echo @sm
Somewhere between 12.0.RC20 and 12.0.RC25_dev, the same code started to
return a SMILES with square planar notation. For (/E/)-2-butene:
C(C)=...@sp1h]c
Although I cannot find Daylight documentation on the use of @sp notation
in alkene context, the NIH translate server returns the above input as
ambiguous SMILES for 2-butene.
The scripts that I referenced in previous posts did, indeed, work up to
and including 12.0.RC20. With the above @sp notation, the scripts are
broken for substituted alkenes exhibiting geometric isomerism. Is
C(C)=...@sp1h]c intended or broken notation?
Otis
Otis Rothenberger
chemagic.com
On 8/4/2010 12:58 PM, Otis Rothenberger wrote:
OK, not flawlessly! The problem appears to be related to the square
planar SMILES notation returned by:
var sm = {*}.find('SMILES');echo @sm
This is true for simple alkenes where E/Z is an issue. I missed that
point previously. For pulegone, the following works with the SMILES
coming from JME:
var sm = 'C/C(C)=C\1CC[C@@H](C)CC1=O';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;}
If I use the model kit to change the pulegone models to isomenthone by
converting C=C to C-C, then the original code ( var sm =
{*}.find('SMILES');echo @sm ) works.
That localizes the problem, but I'm not sure how to deal with it. I'm
not sure that I understand how the @sp# notation is incorporated into
alkenes? The Daylight documentation that I checked is not clear on
this point.
Otis
Otis Rothenberger
chemagic.com
On 8/4/2010 11:16 AM, Otis Rothenberger 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.
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:
var sm = {*}.find('SMILES');
var i = {*}.atomIndex.max + 1;
select within(branch, {atomIndex = i}, {atomIndex=0});
27 atoms selected
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');
script ERROR:
Otis
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
