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
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Reply via email to