{ "version": "https://jsonfeed.org/version/1.1", "title": "chem-bla-ics", "description": "Chemblaics (pronounced chem-bla-ics) is the science that uses open science and computers to solve problems in chemistry, biochemistry and related fields.", "home_page_url": "https://chem-bla-ics.linkedchemistry.info/", "feed_url": "https://chem-bla-ics.linkedchemistry.info/2005/12/16/cdk-debug-classes-and-fixing.json", "icon": "https://chem-bla-ics.linkedchemistry.info/assets/images/chem-bla-ics_logo.png", "language": "en", "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286", "_orcid": "0000-0001-7542-0286" } ], "items": [ { "id": "https://doi.org/10.59350/6p49t-sj396", "url": "https://chem-bla-ics.linkedchemistry.info/2005/12/16/cdk-debug-classes-and-fixing.html", "title": "CDK Debug classes and fixing the ModelBuilder3D bug", "content_html": "

For some weeks now I have been thinking about bug 1309731:\n“ModelBuilder3D overwrites Atom IDs”. The ModelBuilder3D\nis a complex piece of source code, reusing many other parts of the CDK, including\natom type perception.

\n\n

Somewhere in October, however, I found that Taverna could not create 3D models and convert these into reasonable CML because the Atom ID’s were messed up. So the question is, where did the\nModelBuilder3D do this? Did it do this itself, or is it done by one of the other pieces of CDK that it uses? But due to the complex nature of this algorithm, it quickly became clear\nthat looking at the code was not going to solve it; there was too much code to look at.

\n\n

The solution was clear to me: use the [new data interfaces ](https://chem-bla-ics.linkedchemistry.info/2005/10/25/more-cdkinterfaces-updates.html).\nTo identify where the IDs where messed up, I only needed to write a DebugAtom class with a method that looked like:

\n\n
public void setID(String identifier) {\n  logger.debug(\"Setting ID: \", identifier);\n  super.setID(identifier);\n}\n
\n\n

And I would immediately at what stage the ID was overwritten.

\n\n

So I started this week to implement the DebugAtom and related classes.\nBy extending Atom, I could just add debugging stuff and reuse the code in that class. However, the DebugAtom can not extend DebugAtomType too then. And this is a pity,\nbecause all methods inherited by the Atom interface from AtomType, Isotope, Element and ChemObject interfaces could not be inherited from the DebugAtomType class.\nInstead, they now have to duplicate those bits of code.

\n\n

This is not a clean solution, as duplicate code is a known cause of bugs. So, the next step was to write JUnit tests for the new debug classes. And for this\nI wanted to reuse, i.e. extend, the tests for the default data classes. This required, however, changes to those test classes.

\n\n

The first thing that needed to be changed was that instantiation of data classes in the tests would now have to depend on the data classes being tested. A simple

\n\n
Atom atom = new Atom(\"C\");\n
\n\n

only makes sense when a specific Atom class was important. Fortunately, the new interfaces provide a solution for this: the ChemObjectBuilder implementations.\nThese allow to use the following syntax to replace the hard coded instantiation:

\n\n
Atom atom = builder.newAtom(\"C\");\n
\n\n

Therefore, I added a protected field to the AtomTest, which was instantiated in the setUp():

\n\n
protected ChemObjectBuilder builder;\npublic void setUp() {\n  builder = DefaultChemObjectBuilder.getInstance();\n}\n
\n\n

and use this builder to instantiate all test objects, as shows for the atom above.

\n\n

And then I can simply reuse this JUnit test by defining the DebugAtomTest like:

\n\n
public class DebugAtomTest extends AtomTest {\n  public DebugAtomTest(String name) {\n    super(name);\n  }\n\n  public void setUp() {\n    super.builder = DebugChemObjectBuilder.getInstance();\n  }\n\n  public static Test suite() {\n    return new TestSuite(DebugAtomTest.class);\n  }\n}\n
\n\n

The sources for these debug data classes tests are found in the new cdk.test.debug package.

\n\n

The number of JUnit tests for the CDK jumped from around 1250 to over 1500 tests right now. And if you think these new\ntests only test old code, because of all the super.bla() calls in the debug classes, you’re way off. I found bugs in the\nnew debug classes, but also many class cast bugs and several other problems in the real data classes!

\n\n

Anyway. Does this help fix the ModelBuilder3D bug? Yes, it does:

\n\n
$ grep \"Setting ID\" reports/result.modeling.builder3d.ModelBuilder3dTest.txt\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: carbon1\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: oxygen1\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: C\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: HC\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: HC\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: HC\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: O\norg.openscience.cdk.debug.DebugAtom DEBUG: Setting ID: HO\n
\n\n

This shows me where the Atom ID is overwritten to be something other than “carbon1”! I can now look at the rest of the\nresult.modeling.builder3d.ModelBuilder3dTest.txt file to see what the ModelBuilder3D was doing at the time,\nand which CDK class made the setID() call.

\n\n

I only needed to change this line in the JUnit test for the bug to generate the above debug lines:

\n\n
Molecule methanol = new Molecule();\n
\n\n

into

\n\n
Molecule methanol = new DebugMolecule();\n
", "summary": "For some weeks now I have been thinking about bug 1309731: “ModelBuilder3D overwrites Atom IDs”. The ModelBuilder3D is a complex piece of source code, reusing many other parts of the CDK, including atom type perception.", "date_published": "2005-12-16T00:00:00+00:00", "date_modified": "2024-03-23T00:00:00+00:00", "tags": ["cdk","cheminf"], "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286" } ] } ] }