I have a simple workflow as follows - note that this is for illustration purposes only and my actual workflow is somewhat more complex, but has the same problem:
SDF Reader->SDF Properties Extraction->SDF to CDK->OpenBabel (converting from SDF to SMILES)->SMILES to CDK->2D Coordinates->Interactive Table.
What I find is that the SMILES to CDK node times out on many of the compounds. I estimate about 80% fail due to timeout. I've tried conversion of the column using Molecule Type Cast, but the same result applies. Also, I've turned the timeout limit up to 5 s.
I have a simple workflow as follows - note that this is for illustration purposes only and my actual workflow is somewhat more complex, but has the same problem:
SDF Reader->SDF Properties Extraction->SDF to CDK->OpenBabel (converting from SDF to SMILES)->SMILES to CDK->2D Coordinates->Interactive Table.
What I find is that the SMILES to CDK node times out on many of the compounds. I estimate about 80% fail due to timeout. I've tried conversion of the column using Molecule Type Cast, but the same result applies. Also, I've turned the timeout limit up to 5 s.
That is a known issue in the Smiles parser from the CDK release we are using in KNIME. If the molecules contain fused ring systems, ring perception takes quite a long time. They recently changed this but they haven't made another release yet.
BTW you do not need the SDF->CDK node in the above example.
The Molecule Type Cast node does nothing more than changing the type of DataCells in one column (e.g. from String to Smiles). It does not do anything with its contents. This node was once quite handy before the File Reader was not able to read Smiles directly.
I found a work-around for my more complicated workflow. I delay conversion to SMILES until the very end and use the CDK to SMILES node then. Previously I was converting to SMILES up front using OpenBabel and then trying to convert those SMILES to 2D Coordinates. By generating the 2D first, and THEN generating the SMILES, it seems to behave nicely.