I found the place where the bug is; now trying to figure out why it is doing
it. .
On Sat, Aug 7, 2010 at 4:38 PM, Otis Rothenberger <osrot...@chemagic.com>wrote:
> 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 Rothenbergerchemagic.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>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
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> --
> 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 Challengehttp://p.sf.net/sfu/RIM-dev2dev
>
>
> _______________________________________________
> Jmol-users mailing
> listjmol-us...@lists.sourceforge.nethttps://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
>
>
--
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
