Retrieving mapping from Reaction Automapping

[Daniel Lowe]

Is there currently a way to programmatically retrieve the mapping
IndigoObject.automap produces between atoms in the molecules of a
reaction using the Java API of Indigo 1.0.0?

As this method does not return a mapping object, methods like
IndigoObject.mapAtom do not seem to be applicable and while the
mappings appear in the rxn/smiles/depiction output I cannot
immediately see how to retrieve them directly.

[Mikhail Rybalkin]

Hello Daniel,

Thank you for pointing out that such functionality is missing. Indigo
1.0.0 doesn't have such functionality but I have prepared
Indigo-1.1-alpha1 release where such functionality was added. You can
download this release from our site: http://ggasoftware.com/download
Please note that there is a new section with unstable releases on that page.

In this Indigo version there are 3 new methods for reaction:
atomMappingNumber, setAtomMappingNumber, and clearAAM. With these
methods you can retrieve and modify reaction atom-atom mapping, and
clear it at all if necessary.

Code example is following:
IndigoObject rxn = indigo.loadReaction("CCCCCCC>>CCCCCCCO");

rxn.automap("discard");
System.out.println(rxn.smiles());

IndigoObject reactant1 = rxn.iterateReactants().next();
IndigoObject atom1 = reactant1.getAtom(0);

// atomMappingNumber returns 0 if there is no mapping on this atom
System.out.println(rxn.atomMappingNumber(atom1));

// You can remove mapping on this atom
rxn.setAtomMappingNumber(atom1, 0);
System.out.println(rxn.smiles());
// Or specity any other mapping number
rxn.setAtomMappingNumber(atom1, 3);
System.out.println(rxn.smiles());
// Or even remove all atom-atom mapping information
rxn.clearAAM();
System.out.println(rxn.smiles());

Let me know if something if working not as expected.

With best regards,
Mikhail Rybalkin

[Daniel Lowe]

Hi Mikhail,
Thank you for the very prompt addition. That is just what I need to
check whether all atoms in a reaction's product have been mapped.

Unrelated to this recent update as I was having the same problem
before I thought I would link you to a fatal error that seems to be
caused by Indigo but does not cause the Java program to fail; Possibly
as it occurs at the point of the Java program completing.
http://wwmm.ch.cam.ac.uk/~dl387/temp/hs_err_pid6268.log

Unfortunately this error seems to occur randomly. If I can produce a
test case that can reproduce it consistently I will post a proper bug
report.

Daniel

[Mikhail Rybalkin]

Daniel,

Glad to hear that addition is useful! And I forget to say that Indigo
mapping object cannot be used for reaction atom-to-atom mapping because
it is not restricted that all atom mapping numbers are unique. For
example automap for reaction C1CCCC1>>C1CCCC1.C1CCCC1 will produce
[CH2:1]1[CH2:5][CH2:4][CH2:3][CH2:2]1>>[CH2:1]1[CH2:5][CH2:4][CH2:3][CH2:2]1.[CH2:1]1[CH2:5][CH2:4][CH2:3][CH2:2]1.

Thank you very much for the bug report. We will try to fix that issue,
but can you describe with what Indigo objects are you working in order
to understand where to dig. We had similar issues with Java finalizers
before. Attached log contains only the information that this fatal error
occurred, but there is quite low additional information about the nature
of this bug. Could you describe in what way are you working with Indigo,
may some scenario or similar. Such information will be very helpful.

--
Mikhail

[Daniel Lowe]

I could sporadically reproduce the problem on code as simple as
public static void main(String[] args) {
Indigo indigo= Utils.indigo;
IndigoObject reaction = indigo.createReaction();
}

where Utils contains amongst other things
public static Indigo indigo = new Indigo();

Although I think it's the same as the previous log here is the log for
this crash http://wwmm.ch.cam.ac.uk/~dl387/temp/hs_err_pid3012.log

I could not reproduce the problem using:

public static void main(String[] args) {
Indigo indigo= new Indigo();
IndigoObject reaction = indigo.createReaction();
}

which leads me to think that it's in some way related to the way I'm
accessing this instance of Indigo.

On the topic of bugs i've found a small bug in the way foldhydrogens
interacts with the reaction mapper
Indigo indigo= new Indigo();
IndigoObject reaction = indigo.createReaction();
reaction.addProduct(indigo.loadMolecule("O=C1CCC[C@]2([H])C3C=CC(C3)
[C@@]21[H]"));//folding of hydrogens is required for successful
matching
reaction.addReactant(indigo.loadMolecule("C1C=CC=C1"));
reaction.addReactant(indigo.loadMolecule("O=C1CCCC=C1"));
reaction.foldHydrogens();
reaction.automap("discard");

gives "array: invalid index 12 (size=12)" assumedly as the number of
atoms in the reagents is recorded when they are added rather than
being queried when atom mapping occurs.
It can be worked around by folding the hydrogen in advance.

Daniel

[Daniel Lowe]

Going completely off topic; I also just noticed that

Indigo indigo = new Indigo();

indigo.setOption("render-output-format", "png");
new IndigoRenderer(indigo);

produces an error "option manager: Property "render-output-format" not
defined"
Whilst

Indigo indigo = new Indigo();

new IndigoRenderer(indigo);
indigo.setOption("render-output-format", "png");
works as expected.
To me it would actually make more sense for this option to be a
property of the IndigoRenderer but as you've hit your first release I
guess flippant changes to the API should be avoided.
I guess it's not technically a bug but it does seem odd that "new
IndigoRenderer(indigo)" actually mutates the indigo object by adding
new options to it.

[Mikhail Rybalkin]

Hello, Daniel

On the topic of bugs i've found a small bug in the way foldhydrogens
interacts with the reaction mapper

I have reproduced this bug with foldHydrogens and automap. We will try to fix soon.

As for fatal error with finalizers in Java I cannot reproduce this issue.
I have created:

public static void main(String[] args) {
    Indigo indigo= Utils.indigo;
    IndigoObject reaction = indigo.createReaction();
}

With Utils class with static Indigo object:

public static Indigo indigo = new Indigo();

But I cannot reproduce fatal error even after 2000 launches. Your computer configuration is almost the same as mine except that you have AMD processor and JDK 1.6.0_24, while I have JDK 1.6.0_25. I'll check this code on JDK 1.6.0_24 but I don't think that it will help. How often does such fatal error appear?

And returning to your note about options:

Indigo indigo = new Indigo();
indigo.setOption("render-output-format", "png");
new IndigoRenderer(indigo);

produces an error "option manager: Property "render-output-format" not
defined" Whilst
Indigo indigo = new Indigo();
new IndigoRenderer(indigo);
indigo.setOption("render-output-format", "png");
works as expected.

Such behavior was designed: there is Indigo instance with options collection and additional plugins (at this moment only renderer) that add options to the Indigo. IndigoRenderer is a plugin, but not an object in fact; it extends Indigo functionality.
This approach is arguable. As a consequence now it is not possible to use 2 renderers with different options. We know about such problems with options: you cannot use different options simultaneously in different threads; cannot temporary set some options, and etc. Some concept  of environment with options independent of Indigo instance can be useful, but  it should be discussed in details.
And maybe we will add some options for IndigoRenderer. Options for Indigo will be "global" but they could be overload by IndigoRenderer options.

--

With best regards,
Mikhail Rybalkin

[Daniel Lowe]

Thanks for the detailed response. As you can always have multiple
instances of indigo with their own renderers I don't see the lack of
ability of configure individual IndigoRenderer plugins as a
significant limitation.

The fatal error occurs about once in every 3 runs, but I think it
might be a subtle interaction between the other stuff which is
initialised in my Utils function and Indigo. Thus far the problem has
only presented upon the program's successful completion. I would not
bother continuing to debug this unless I can come up with a more
reproducible test case.
I don't actually have an AMD processor (Intel core2duo). I think that
might just be a quirk of the fact that I am running a 64-bit VM. I
suppose it would be worth checking whether I can reproduce the problem
under a 32-bit VM.

Daniel

> > this crashhttp://wwmm.ch.cam.ac.uk/~dl387/temp/hs_err_pid3012.log

[Daniel Lowe]

By the way if it is not a significant undertaking, would it be
possible for future alpha releases to include the Universal Java API?

[Mikhail Rybalkin]

> As you can always have multiple instances of indigo with their own
> renderers I don't see the lack of ability of configure individual
> IndigoRenderer plugins as a significant limitation.

The main limitation with multiple Indigo instances is that now you
cannot share objects between them. We are thinking how to add some
functionality to overcome this limitation in one the next versions.

> I don't actually have an AMD processor (Intel core2duo).

I have notices "windows-amd64" string in your crash log file:
http://wwmm.ch.cam.ac.uk/~dl387/temp/hs_err_pid3012.log
But it doesn't matter. Maybe this means something else.

> By the way if it is not a significant undertaking, would it be
> possible for future alpha releases to include the Universal Java API?

Yes, of course. I'll add the universal build on friday (maybe with some
bugs fixed).

[Mikhail Rybalkin]

Maybe I have an idea about this bug with finalizeres. Do you have static
classes instances that use Indigo? Because if you have then Indigo
dll-library might be unloaded before finalization of your static class
instance, and if that class use Indigo then it might be a problem. This
is just an idea.

On 6/23/2011 23:27, Daniel Lowe wrote:

[Daniel Lowe]

The Utils class in question is:
https://bitbucket.org/dan2097/patent-reaction-extraction/src/9d72c712ee5a/src/main/java/dan2097/org/bitbucket/utility/Utils.java
(yes I know that that static code block is hideous :-P)

Except within that class indigo is referred to by Utils.indigo (I
suppose using a getter would be more idiomatic Java...)

I'm not entirely sure whether I actually answered your question
though...

On Jun 23, 11:25 pm, Mikhail Rybalkin <rybal...@ggasoftware.com>

[Mikhail Rybalkin]

Hello Deniel,

I have publish indigo-1.1-alpha2 with universal.
Fixed:
1. foldHydrogens on [H][H] and molecules with isotopic hydrogens ([2H]C)
2. reaction layout for reactions with empty reactants
3. saving molecule with s-group into molfile format.
4. substructure matcher with special query with recursive smarts
beginning with hydrogen

A bit later after more testing this fixes will be integrated into the
stable branch, and more detailed announcement will be made.

Thank you for sending bug reports!

With best regards,
Mikhail Rybalkin