mesomerize directive dead in 5.5!

User 21b7e0228c

30-05-2011 07:52:08

Hi,


I found out yesterday that upgrading to 5.5.0 completely changed the behavior of my interactive standardizer! In particular, I used "mesomerize" in order to force unique rendering of the intermediate non-aromatic/Kekulé forms I'm working with for tautomer analysis. In worked relatively well in previous versions, but now - guess what? Even for methyl-naphtalenes it cannot decide on the unique double/single bond pattern. Try, for example this:


 


echo "NC(=S)NC1=C2C=CC=CC2=CC=C1" | standardize -c "mesomerize"
NC(=S)NC1=CC=CC2=CC=CC=C12


echo "NC(=S)NC1=CC=CC2=CC=CC=C12" | standardize -c "mesomerize"                                                                                  
NC(=S)NC1=C2C=CC=CC2=CC=C1


It just can't get decided!


Cheers!


Dragos

User 851ac690a0

01-06-2011 17:41:13

Hi,


Unfortunately the "creation of  Kekule structure"  from "aromatic structure"  never was a  "unique" step in our system. 


Please give us more details why is it important for you.


Jozsi

User 21b7e0228c

02-06-2011 06:56:52

Hi - yes, I know that Kekulization is not supposed to be unique. That's why you created the mesomerize directive for the standardizer - to convert different Kekule rendering modes (mesomeric states) back to one & only "canonical" mesomer form. That's what it did in previous Jchem versions. I need it because TAUTOMERS need to be generated on hand of Kekule forms, NOT on aromatized molecules - or else heterocycles cause troubles. However, if I submit kekülized methylnaphtalene to the tautomer plugin, it will find that there's nothing to tautomerize... but in the process it will CHANGE the double bond pattern. Therefore, it will tell me that... a new tautomer was found, and makes me waste time 'cause I need to kill it off manually. So, to prevent this - and without aromatizing - the solution was simple: I push both initial structure and tautomer output through the standardize -c "mesomerize" directive, making both smiles converge to a canonical mesomer, seeing that it's the same and being happy with it. But in 5.5, standardize -c "mesomerize" does no longer work properly. It's not that I expect Kekülization to lead to a uniqe smiles - it's the standardizer that needs to be fixed and restored to its proper functioning as witness in the "good old days" prior to 5.5 ;-)


Cheers!

ChemAxon e08c317633

02-06-2011 12:23:52

Dragos, I suggest you to use StandardizedMolSearch for duplicate checking, instead of SMILES. If you insist on using SMILES, then I can recommend using unique SMILES ("smiles:u"). Both solutions are much faster than generting the generic mesomer with Standardizer.


Zsolt

User 851ac690a0

02-06-2011 13:32:17

Hi Dragos,


I am not a wizard to bring back you into the "good old days",  but I try to fix a "bug" in the tautomerization and I hope the "taste of the old times"  will touch you again.


Thank you for reporting this problem which is included in the tautomer generation module.


Jozsi

User 21b7e0228c

02-06-2011 13:32:50

Not quite, because I'm not in any high thruput search scheme: I just need to know whether for ONE molecule at a time the suggested tautomers are different from the Keküle input structure that was fed to the tautomer generator. I need a Keküle structure to feed to the tautomer generator, one needs to explicitly dearomatize. So smiles:u won't do the job, since input is definitely not a smiles:u but a Keküle. Now ok, I may use the molsearch API, but that's an overkill - makes sense for a database screen, but not much for N=1 molecules.


Finally, all that ain't the really point here.  There is, or there was, a mesomerize option in standardizer, and it worked well in older versions. It is fine if you say "we'll discontinue to support that feature" because only one weird guy ever used it - that makes sense (if you say it clearly and change the doc)... but if you keep it in the soft, well, .. it's a bug! Can't help it! The issue is not high priority for me either, I just wanted to let you know that the "spanish cucumber" syndrome hit the standardizer 5.5 ;-) - meaning that the latest changes you made caused some "collateral damage" which might show up elsewhere in the soft too. As your latest efforts likely did not go into changing the mesomerizer, but they DID change the mesomerizer... huh, what else unintended did they change? But, as said - don't waste time on this because of me: I'm not under pressure to see it fixed.

User 851ac690a0

23-06-2011 09:28:59

Hi,


We will fix this in 5.7 version.


Jozsi