CDK-R / cdkr

Integrating R and the CDK
https://cdk-r.github.io/cdkr/
42 stars 27 forks source link

More robust iload.molecules() in case of NoSuchAtomTypeException #8

Closed sneumann closed 12 years ago

sneumann commented 12 years ago

Hi,

another problem occurs for other exceptions:

Error in .jcall(.jnew("org/openscience/cdk/ChemObject"), "Lorg/openscience/cdk/interfaces/IChemObjectBuilder;", : org.openscience.cdk.exception.NoSuchAtomTypeException: The AtomType Se.2 could not be found

Can these be caught with rJava ? And an option added to iload.molecules() to just jump over them, because we can't do anything with them anyway ?

Yours, Steffen

rajarshi commented 12 years ago

I think there was an issue with catching Java exzceptions in R - I have to revisit that. Can you send an example file to test on?

On Wed, Feb 22, 2012 at 10:38 AM, sneumann < reply@reply.github.com

wrote:

Hi,

another problem occurs for other exceptions:

Error in .jcall(.jnew("org/openscience/cdk/ChemObject"), "Lorg/openscience/cdk/interfaces/IChemObjectBuilder;", : org.openscience.cdk.exception.NoSuchAtomTypeException: The AtomType Se.2 could not be found

Can these be caught with rJava ? And an option added to iload.molecules() to just jump over them, because we can't do anything with them anyway ?

Yours, Steffen


Reply to this email directly or view it on GitHub: https://github.com/rajarshi/cdkr/issues/8

Rajarshi Guha NIH Chemical Genomics Center

sneumann commented 12 years ago

Actually, with

## iterate over a large file
moliter <- iload.molecules(chebifile, type="sdf",
                           aromaticity = FALSE, typing = FALSE, skip=TRUE)

the problem is not anymore in the iteration through the file, but I get them further down in my script when trying to obtain the fingerprint.

chebifp[i] <- get.fingerprint(mol, type = "standard") ## Exception with Se.2

I am using ftp://ftp.ebi.ac.uk/pub/databases/chebi/SDF/ChEBI_complete.sdf.gz (unzipped first, of course)

Yours, Steffen

rajarshi commented 12 years ago

The latest version in github fixes this (if you want to see exceptions set verbose=TRUE in the call to get.fingerprint