difference from JChem 5.2.6 to JChem 5.3.1

Consider the following reaction definition:

<?xml version="1.0" ?>

<MDocument>

  <MChemicalStruct>

    <reaction>

      <propertyList>

        <property dictRef="NAME" title="NAME">

          <scalar><![CDATA[Wittig reaction to cis alkene]]></scalar>

        </property>

       <property dictRef="EXCLUDE" title="EXCLUDE">

          <scalar><![CDATA[totalCharge(reactant(0)) < 0 || match(reactant(0), "[#6]N([#6])[F,Cl,Br,I]") || match(reactant(0), "FB(F)[#5,F]") || match(reactant(0), "[C,O]=S") || match(reactant(0), "OOC=O") || match(reactant(0), "C[Cl,Br,I]") || match(reactant(1), "[H][O,S][#6]") || match(reactant(1), "[H][C,O]N([H])[H]")]]></scalar>

        </property>

        <property dictRef="EXPLAIN_EXCLUDE" title="EXPLAIN_EXCLUDE">

          <scalar><![CDATA[In electrophilic substitution phosphorane can react with sec-amino halides, fluorinated borates, thiones, alkyl halides, oxidizing agents such as sulfoxides, peroxydes. Aldehydes and ketones can react with alkohols and thiols, primary amines or hydroxyamines.  ]]></scalar>

        </property>

      </propertyList>

      <reactantList>

        <molecule molID="m1">

          <atomArray

              atomID="a1 a2 a3 a4"

              elementType="O C C H"

              mrvMap="3 1 0 7"

              mrvQueryProps="0 0 a2 L,H,C:"

              x2="-16.625 -16.625 -17.958679121828034 -15.291320878171964"

              y2="2.566666603088379 1.0266666030883789 0.2566666030883783 0.25666660308837896"

              />

          <bondArray>

            <bond atomRefs2="a1 a2" order="2" />

            <bond atomRefs2="a2 a4" order="1" />

            <bond atomRefs2="a2 a3" order="1" />

          </bondArray>

        </molecule>

        <molecule molID="m2">

          <atomArray

              atomID="a1 a2 a3 a4 a5 a6 a7"

              elementType="P C H C C C C"

              mrvMap="5 2 4 6 0 0 0"

              mrvQueryProps="0 0 0 A: 0 0 0"

              x2="-7.241320687437101 -5.907641565609065 -5.9067498880308795 -4.818697122581782 -7.241320687437101 -8.728846459922266 -7.6399020168949825"

              y2="1.9366666269302368 1.1666666269302368 -0.3115050648253219 2.25561106995752 3.476666626930237 2.335247956388119 0.40114349898395085"

              />

          <bondArray>

            <bond atomRefs2="a1 a7" order="1" />

            <bond atomRefs2="a1 a5" order="1" />

            <bond atomRefs2="a1 a2" order="2" />

            <bond atomRefs2="a1 a6" order="1" />

            <bond atomRefs2="a2 a4" order="1" />

            <bond atomRefs2="a2 a3" order="1" />

          </bondArray>

        </molecule>

      </reactantList>

      <productList>

        <molecule molID="m3">

          <atomArray

              atomID="a1 a2 a3 a4 a5 a6"

              elementType="C C C C H H"

              mrvMap="1 2 6 0 7 4"

              mrvQueryProps="0 0 A: a2 L,H,C: 0"

              x2="6.3000006675720215 7.633679789400057 7.544818678032837 4.966321545743986 5.90141933811414 8.967358911228093"

              y2="0.5833333060145378 1.3533333060145378 2.8907674356235376 1.3533333060145383 -0.9041924664706273 0.5833333060145379"

              />

          <bondArray>

            <bond atomRefs2="a1 a5" order="1" />

            <bond atomRefs2="a1 a2" order="2" />

            <bond atomRefs2="a1 a4" order="1" />

            <bond atomRefs2="a2 a6" order="1" />

            <bond atomRefs2="a2 a3" order="1" />

          </bondArray>

        </molecule>

      </productList>

    </reaction>

  </MChemicalStruct>

</MDocument>

With substrates CCCC(=O)CC.CCC=P(c1ccccc1)(c1ccccc1)c1ccccc1, JChem 5.2.6 correctly predicts the products to be CCC\C(CC)=C/CC.CCC\C(CC)=C\CC, whereas JChem 5.3.1 incorrectly predicts them to be CC\C=C(/C)CC.CCC\C(C)=C\CC.  

If I modify the reaction definition to include the Ph3P=O product, then JChem 5.3.1 predicts the correct product.  But why the change in behavior?  I don't want to have to look through my hundreds of reaction definitions to find out which ones have missing mapped atoms.

Bob, you are right, result of a reaction should not change between versions because mapping is handled differently. We will fix this bug in JChem 5.3.3, and we will improve the handling of reaction mapping in next major version. Until then the workaround is to map the reactions manually.

Zsolt

As of JChem 5.3.4, this bug is still present.  When will you fix it?

Hi Bob,

Apologies, but I cannot give you any definite date or release/version info. Unfortunately we (end users) encountered far too many problems in reaction auto-mapping which cannot be resolved by individual fixes, thus we decided to redesign and re-implement the reaction auto-mapper, including the MCS search also applied during mapping. This will take longer time and we will not be able to accomplish these task by the next release (5.4, Q3 2010).

In the meantime, we recommend to manual check/map reactions - I admit it is inconvenient...

Regards

Miklos

It's more than inconvenient.  I have hundreds of reactions in my library, and I don't know exactly how to test each reaction for the presence of the bug.

Would it be possible to add a flag to use the old mapping algorithm?

We prefer to fix the current one than reverting back to an older version. 

BR

Miklos

I prefer it too, but I also prefer not having to check every one of my hundreds of reaction definitions.  So I plead with you to fix this problem sooner than Q3 2010.

This bug does not appear to have been fixed in JChem 5.4, even though it is now 4th quarter 2010.

CCCC(=O)CC.CCC=P(c1ccccc1)(c1ccccc1)c1ccccc1 -> CC\C=C(/C)CC.CCC\C(C)=C\CC with the reaction definition above.

Nothing in your documentation on orphan atoms alerts the programmer to this problem.

Any word on when this problem will be fixed?

Hi Bob, 

we have just released 5.4 (in Q4 :(, we did not manage to accomplish it in Q3 as planned).

And yes, it's Q4 2010, but we have not yet started the development/enhancement of automapper - we can start that perhaps around March...

Anyway, this reaction seems to be too complex to be automapped. And there are many of such reactions... This conclusion lead us to propose a new approach to reaction automapping. This will rely on a knowledge or rule base, which is a list of mapped generic reactions (like ester formation etc).

When a reaction has to be mapped in an automated way, this rule base is scanned first for a matching reaction schema. If found then maps are copied from the rule to the reaction (matching atoms are easy to map after that).

If there's no matching rule then the automapper (a new implementation!) is used as a fallback machinery. 

From user's perspective that means that in case if a reaction cannot be mapped by the automapper properly, the rule base has to be extended with a new rule. This requires the knowledge of the underlying reaction mechanism and the manual mapping of the reaction center using MSketch. The new rule is then saved in the rule based.

This will be supported by various convenience tool:

- the automapper will use an independent score to assess the correctness of the mapping,

- the automapper will hide the matching (not changing) atoms and bonds and highlight the reaction center,

- the manual mapping will be supported by an interactive tools: as the user keeps adding new atom-atom maps, the automapper uses this information to improve its guess, enabling the user to accept the mapping as early as possible without the need of mapping each and every atom manually.

Do you think this approach is feasible? 

Regards,

Miklos

It sounds like what you are proposing will work in desktop Reactor, but I don't think it will apply when I call Reactor from the API.

What I do know is that there was a time when I did not need to map every atom in a reaction definition, and now, if I don't, I sometimes get incorrect results.  

In fact, I prefer not to balance my reaction equations, because I often run a series of reactions, each on the products of the previous reactions.  If I balance my reaction equations, then I will end up subjecting lots of reaction coproducts to Reactor as well.  They will not do anything except use up much more time.

So, please restore the previous behavior.

mvargyas wrote:

Apologies, but I cannot give you any definite date or release/version info. Unfortunately we (end users) encountered far too many problems in reaction auto-mapping which cannot be resolved by individual fixes, thus we decided to redesign and re-implement the reaction auto-mapper, including the MCS search also applied during mapping. This will take longer time and we will not be able to accomplish these task by the next release (5.4, Q3 2010). In the meantime, we recommend to manual check/map reactions - I admit it is inconvenient... ... We prefer to fix the current one than reverting back to an older version.  ... we have just released 5.4 (in Q4 :(, we did not manage to accomplish it in Q3 as planned). And yes, it's Q4 2010, but we have not yet started the development/enhancement of automapper - we can start that perhaps around March...

Hi Miklos,

Given the amount of time it is taking for you to develop version 3 of a mapping algorithm, and given the fact that the reactions that worked with version 1 no longer work with version 2, and given the amount of work it will take to go through every one of our hundreds of reactions to find broken reactions, and given the fact that including every coproduct in a reaction is likely to slow down the performance of our program...

Will you please consider restoring version 1 of the mapping algorithm as an option within Reactor, until you can devise a version 3  that does not break reactions written under version 1?

-- Bob

Hi Bob, 

Your proposal sounds logical. However, I'm afraid, we cannot/do not intend to support alternate mappers in Reactor. 

I understand that the current solution causes problems for you and it is not sufficient for your application - though other reactions are handled better with this 2nd method...

What I can offer here and now for you (because you are far too important for us to let you down) is an invitation to take part in early testing and development of the new version. I can even imagine that (with some overhead and some extra work) you can integrate the new mapper in your application far before it is released...

The idea is: we send you a jar file (or you can download it) as well as an ant script with which you can run the test (with your data), generate a report which is basically an html file (an XML, but it's transformed to html by the ant script) and then you can open the html report in your browser. The report provides an overview of the success ratio, speed etc, and also enables you to check each individual reaction, and each internal mapping stages per each reaction. (We can do a quick webex or goto meeting to demonstrate it to give you some insight ...)

Your involvement in the development and testing would be beneficial for us and it it will ensure you that your reactions are handled as good as possible (or at least issues are identified well in advance).

What do you think?

regards

Miklos

This bug has been fixed. JChem 6.0 contains a new AutoMapper implementation, which maps correctly the reaction in the first post.

Sorry for the delay.