JChem 3.0.10 matching problem

Hi,





We are using JChem 3.0.10, and we're finding a structure is not matching to itself, and we're trying to figure out whether the problem is in our code or in JChem.





Both the target and the query are:

Code:

Marvin  09020508342D  11 11  0  0  0  0            999 V2000    -5.0000    4.7000    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0    -5.0000    3.0500    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0    -4.2855    4.2875    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0    -3.5711    3.0500    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0    -4.2855    3.4625    0.0000 C   0  0  1  0  0  0  0  0  0  0  0  0    -5.7145    3.4625    0.0000 C   0  0  2  0  0  0  0  0  0  0  0  0    -5.7145    4.2875    0.0000 C   0  0  2  0  0  0  0  0  0  0  0  0    -6.4290    4.7000    0.0000 O   0  0  0  0  0  0  0  0  0  0  0  0    -6.4290    3.0500    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0    -6.4290    2.2250    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0    -7.1434    3.4625    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0   1  7  1  0  0  0  0   1  3  1  0  0  0  0   7  6  1  0  0  0  0   6  2  1  0  0  0  0   2  5  1  0  0  0  0   5  3  1  0  0  0  0   5  4  1  1  0  0  0   6  9  1  1  0  0  0   7  8  1  6  0  0  0   9 10  1  0  0  0  0   9 11  1  0  0  0  0 M  END

We do a MolSearch() with the following parameters:


setStereoSearch(true),


setDoubleBondStereoMatchingMode(StereoConstants.DBS_ALL)


setExactChargeMatching(true);


setExactIsotopeMatching(true);


setExactRadicalMatching(true);





The result is that the query does not match the target. Any ideas why?

Hi Bob,





It works fine here, I tried with more different versions, including 3.0.10:

Code:

$ /cygdrive/h/install/jchem/jchem3.0.10/jchem/bin/jcsearch --exactChargeMatching:y --exactIsotopeMatching:y --exactRadicalMatching:y --DBAbsoluteStereo:A -t:p -q test.mol test.mol CC(C)[C@@H]1C[C@H](C)CC[C@H]1O

I just noticed that the chiral flag is off for the molecule. Are any of the following options set to some value?

Code:

setQueryAbsoluteStereo(), setTargetAbsoluteStereo()

Szabolcs

Szabolcs wrote:

Hi Bob, It works fine here, I tried with more different versions, including 3.0.10: Code: $ /cygdrive/h/install/jchem/jchem3.0.10/jchem/bin/jcsearch --exactChargeMatching:y --exactIsotopeMatching:y --exactRadicalMatching:y --DBAbsoluteStereo:A -t:p -q test.mol test.mol CC(C)[C@@H]1C[C@H](C)CC[C@H]1O I just noticed that the chiral flag is off for the molecule. Are any of the following options set to some value? Code: setQueryAbsoluteStereo(), setTargetAbsoluteStereo() Szabolcs

We don't set those values explicitly, but when we query them, both are true.





Can you try using the MOL file instead of the SMILES formula? We have checked, and the target MOL and the query MOL files are byte-by-byte identical.

Hi Bob,





I could reproduce the problem.





This is a search bug which has been fixed from JChem 3.0.13.





Please upgrade your JChem version.





Best regards,





Szilard

OK, we've upgraded to JChem 3.0.15. Now we have a new problem. The MOL file as target now fails to match to the same structure, but with all stereo bonds converted to regular bonds, as query.





This may be a problem with our own code. You used to have two tables in your JChem guide showing how bold, hashed, squiggly, and unspecified stereo bonds matched in target and query depending on one particular flag. One table was perfect diagonal; the other table had a match when the query stereo was squiggly or unspecified, regardless of target stereo. I can no longer find those two tables. I looked at http://www.chemaxon.com/jchem/doc/user/Query.html#stereobond.





How do we make JChem operate by the match pattern of the latter table? Our code assumes this match pattern. I believe we have set setExactStereoMatching() to false to get this match pattern.

bobgr wrote:

OK, we've upgraded to JChem 3.0.15. Now we have a new problem. The MOL file as target now fails to match to the same structure, but with all stereo bonds converted to regular bonds, as query.

I could not reproduce this problem using jchem 3.0.15. (Now I tried Szilard's test program, which seemed to be closer to your settings.)

bobgr wrote:

This may be a problem with our own code. You used to have two tables in your JChem guide showing how bold, hashed, squiggly, and unspecified stereo bonds matched in target and query depending on one particular flag. One table was perfect diagonal; the other table had a match when the query stereo was squiggly or unspecified, regardless of target stereo. I can no longer find those two tables. I looked at http://www.chemaxon.com/jchem/doc/user/Query.html#stereobond. How do we make JChem operate by the match pattern of the latter table? Our code assumes this match pattern. I believe we have set setExactStereoMatching() to false to get this match pattern.

Yes, the behaviour you would like corresponds to setExactStereoMatching(false). (I remember that table, too, but can't find it at the moment. I guess it was sent in an email, and was not part of the documentation.)





Do you have this behaviour with other stereo structures, too?





Szabolcs

Hi Bob,





Most likely you query is treated as absolute stereo (chiral flag), and your target is not.


Then you get the described matching behavior.





I suspect you call one of the following only for the query:





MolSearch.setQueryAbsoluteStereo(true);





or





Molecule.setAbsStereo(true)





You can find more information on the absolute stereo (chiral flag) setting here:





http://www.chemaxon.com/jchem/doc/user/Query.html#chiralflag





Best regards,





Szilard

I think I know what happened. The query was a 3D file, and the target was a 2D file, so they failed to match.





In fact, if I do a Clean in 3D, then draw (1R,2S,4R)-2-isopropyl-4-methylcyclohexanol with a hexagonal ring and bold and hashed wedges (see attached PNG file), both Marvin and JChem 3.0.15 fail to recognize that I've drawn the 1R,2S,4R stereoisomer. Turn on View R/S Labels and you'll see what I mean. Weird. If you then do Clean in 2D, the bold-hashed wedge information is lost.

Yes, that explains.





When the molecule has 3D coordinates, the wedges are totally ignored and all stereo information is calculated from the coordinates only.





We will discuss what we can do in the mixed 3D-wedge case. One possibility is to show warning (red underline) when a 3D molecule has wedged or hash bonds defined.





Best regards


Szabolcs

Szabolcs wrote:

We will discuss what we can do in the mixed 3D-wedge case. One possibility is to show warning (red underline) when a 3D molecule has wedged or hash bonds defined.

I don't think that's the best way to handle it. Suppose I draw a structure, clean it in 3D, then erase it, then draw a new structure. The fact that Marvin is now "thinking" in 3D should be of no concern to me.





Instead, I would suggest that if a wedge is used in 3D, the z coordinate of the atom at the business end of the wedge should simply be adjusted accordingly.

Unfortunately this is not that simple. I think the current behavior is fine, since when 3D coordinates are given there is no simple general way to adjust the coordinates according to the wedges. Removing them is the best behevior and a warning should be given that the extra (redundant) information has been removed. The other optional choice could be to read in the wedges and generate 2D coordinates. If the wedges and the 3D coordinates does not match then it is an error in the structure file.

bobgr wrote:

Szabolcs wrote: We will discuss what we can do in the mixed 3D-wedge case. One possibility is to show warning (red underline) when a 3D molecule has wedged or hash bonds defined. I don't think that's the best way to handle it. Suppose I draw a structure, clean it in 3D, then erase it, then draw a new structure. The fact that Marvin is now "thinking" in 3D should be of no concern to me. Instead, I would suggest that if a wedge is used in 3D, the z coordinate of the atom at the business end of the wedge should simply be adjusted accordingly.

The problem with that approach is that the user has no way of knowing that Marvin is going to discard the information that the user just took care to enter.





So I suggest the following:





(1) Show 2D or 3D in the upper-right corner of the MarvinSketch window to tell the user whether Marvin is thinking in 2D or 3D.





(2) Disallow wedged bonds when Marvin is thinking in 3D.





(3) Make it easier to switch between 2D and 3D. The Edit -> Clean function is not very intuitive a place to go. And what if I just want to project a 3D drawing into two dimensions without cleaning?





-- Bob

Bob,





I think this latter suggestion is feasible. We will implement the suggested features.





Best regards,


Szabolcs