Memory errors and instability after nightly update

The new nodes, icons and sub-groups are fantastic!

But...

Yesterday I installed the nightly build successfully, and all was well, but today, testing in more detail, I keep getting problems after running or during running the substructure matcher:

1.  Knime simply 'bombs' out, without any warning mid-run

2.  Subsequent nodes or saves fail with 'unable to create new thread' errors

3.  The node appears to run, but the console says:

WARN IndigoSubstructureMatcherNodeModel indigo error while matching: target key='60' query key='Suzuki': array: reserve(): no memory

Checking, and their is plenty of memory available to Knime.

Also, I notice that aromatization is a little weak on rings contaning pyridone-type N-C(=O) groups?

Thanks

Steve

Hello Steve,

How many molecules are in the tables and what nodes are you using? Could you also try to set "write to disk" strategy on the Memory Management tab? I think I know the cause and we will try fix this issue.

And could you also confirm that the stable version has no such behavior?

> Also, I notice that aromatization is a little weak on rings contaning pyridone-type N-C(=O) groups?

It is a limitation of Indigo's [de]aromatisation algorithms: it doesn't treat atoms with external double bonds (like in O=C1NC=CC=C1) as aromatic. Such improvement of our aromatization algorithm is planned.

Best regards,
Mikhail

Mikhail

I was running a table of 60 reactions through against 14 substructure queries as SMARTS strings.  I tried saving tables to disk, but this did not help.

thanks

Steve

Steve,

As your dataset is small, the probem is not connected with the memory. So I think that the problem can be reproduced on a single reaction and a query reaction. Could you try to minimize the dataset and send us an example of the workflow? If you can share the whole dataset that we can check it by our own.

Best regards,
Mikhail

Mikhail,

 

I think the following query reaction SMARTS is causing the problem:

[N;!H0:1].[F,Cl,Br][S:2](~[O:3])(~[O:4])[#6,#7:5]>>[N:1][S:2](~[O:3])(~[O:4])[#6,#7:5]

It converts OK using a query reaction to indigo node, but seems to cause knime to exit ungracefully when the substructure query node executes.

Any thoughts?

Steve

Steve,

I tried to reproduce your problem, but the

 executes successfully. Does it work without any problems on your machine? If yes, could you try to extend this workflow to reproduce the problem?

Best regards,

Michael Kvyatkovskiy.

Michael,

Thanks - your workflow ran fine (and mine still did not!) even after a totally fresh re-install of KNIME.

Then, I tried to adapt yours to match mine - and added a Reaction Automapper node between the Reaction to Indigo and Substructure Matcher nodes.  At this point, the automapper ran OK, and the first time I executed the substructure node, Knime vanished again.  I reloaded, and re-ran, and this time the console error re-emerged:

WARN IndigoSubstructureMatcherNodeModel indigo error while matching: target key='Row263' query key='Row1': array: reserve(): no memory

At this point, reaction/structure rendering also stops working properly, and resetting/re-running the substructure matcher node results in KNIME disappearing without warning, as previously.

So, my guess is that it in some way relates to the combination or automapper and substructure matcher nodes?

Steve

Steve,

I reproduced your problem. We will try to fix it as soon as possible. Thank you for the error report!

Best regards,

Michael Kvyatkovskiy.

Phew!!!  Thanks Michael - glad it is not just something quirky about my installation!

Steve

Dear Steve,

Many thanks for the given example. We have fixed the reactiong substructure matcher. The memory issue was resolved in the version 1.1.0.201202272004 (nightly). The given workflow now works without memory leaks.

With best regards,

Alexander