Gyuri wrote: |
Yes, I agree, that it could be more efficient within reactor and make life easier in some cases, but the order of the substrates can be important sometimes when you are building libraries and do not care to much about chemistry. However, we can add the automatic permutation of reactant order to the new higher level API. That will be a perfect place for that.
|
While we're on the subject of substrate array restrictions...
Consider the reaction of a RLi with an ester. Two equivalents of the R group from RLi are incorporated into the product, so the reaction definition includes three starting materials: Two RLi, plus the ester. However, the convention among organic chemists is to draw RLi just once. As a result, when I want to apply the ester reaction to the two substrates that a user drew in an MRV document, I need to do the following:
(1) Double each of the substrates in turn, to give the arrays {RLi, ester, RLi} and {RLi, ester, ester} OR {ester, RLi, ester} and {ester, RLi, RLi}.
(2) Permute each array to generate, {RLi, ester, RLi}, {RLi, ester, ester}, {RLi, RLi, ester}, {ester, RLi, ester}, {ester, RLi, ester}, {ester, ester, RLi}. (That's omitting duplicate permutations.)
(3) Submit each array to Reactor and see if it generates products.
I have similar problems if a user draws an excess number of substrates. Then I have to generate all of the possible arrays with fewer substrates.
There has GOT to be a faster way of doing this internally in Reactor.