Hi Tim, If you just include the cdk-legacy package you should have the SMSD code. Or you can use the latest version: https://github.com/asad/SMSD. Note all the package/class names changed so is not a straight drop-in. That's actually why we deprecated the CDK version, it was going to be a non-trivial update either way.
Best, John On Sat, 23 Sept 2023 at 11:58, Egon Willighagen <egon.willigha...@gmail.com> wrote: > > Can you point us (well, John particularly) to the SMSD code you are using? > I think if he can find the time, he can make some suggestions on how to > replace it with more modern code. > > Egon > > On Sat, 23 Sept 2023 at 12:55, Tim Dudgeon <tdudgeon...@gmail.com> wrote: > >> Sorry for the late reply. I've been distracted. >> Sorry, I meant DepictionGenerator. CDKMolDepict is my class that's >> running this! Egon found it correctly. >> >> Regarding the version, yes, this is old code, and I can't remember all >> the details. >> I'm not able to update to the latest as I have a dependency on the >> deprecated org.openscience.cdk:cdk-smsd module. >> I did have a discussion some time ago with Egon about removing the >> dependency on the deprecated code, but we never got that resolved. >> So this means that I can only update to version 2.5. which I've now done. >> >> I still find problems with that version. For some reason that I can't >> recall I'm using: >> >> StructureDiagramGenerator g = new StructureDiagramGenerator(); >> g.generateCoordinates(mol); >> >> to do the layout prior to calling DepictionGenerator().depict(mol) >> >> This is causing me problems when handling 2D or 3D molfiles. >> I find I can work around it by doing IAtomContainer -> SMILES -> >> IAtomContainer, which works for now. >> I'll need to look more deeply at the code to work out better options. >> There's a lot going on like MCS alignment and highlighting. >> >> Thanks for your help. >> >> >> On Sat, Sep 23, 2023 at 10:45 AM Egon Willighagen < >> egon.willigha...@gmail.com> wrote: >> >>> If you have that discussion here, I can update >>> https://egonw.github.io/cdkbook/migration.html accordingly. >>> >>> Egon >>> >>> On Sat, 23 Sept 2023 at 11:43, John Mayfield < >>> john.wilkinson...@gmail.com> wrote: >>> >>>> Hi Tim, >>>> >>>> It looks like you're using 5 year old CDK 2.2, is that correct? >>>> >>>> build.gradle: >>>> > project.ext.set('cdkVersion', '2.2') >>>> >>>> It's likely just updating will fix the issue. It should be relatively >>>> seamless but let me know if there are any issues and I'll tell you how to >>>> fix it. >>>> >>>> On Sat, 23 Sept 2023 at 06:38, Egon Willighagen < >>>> egon.willigha...@gmail.com> wrote: >>>> >>>>> >>>>> Tim, >>>>> >>>>> I guess you are referring to >>>>> https://github.com/InformaticsMatters/squonk/blob/master/components/cdk-lib/src/main/groovy/org/squonk/cdk/io/CDKMolDepict.java >>>>> >>>>> I also looked at the molfile reading in CDKMoleculeIOUtils and it >>>>> looks correct to me, but the hydrogen adding may be a conflicting issue >>>>> here. What is the actual exception (stacktrace) you get? >>>>> >>>>> Like John set, removing the 3D coordinates should not be needed (the >>>>> CDK is designed to allow having both of them in parallel), but if you have >>>>> to, run .setPoint3d(null) on each atom. That should do the trick. >>>>> >>>>> Egon >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, 20 Sept 2023 at 12:05, John Mayfield < >>>>> john.wilkinson...@gmail.com> wrote: >>>>> >>>>>> I have no idea what CDKMolDepict is, a Knime thing? >>>>>> >>>>>> It's probably just not being updated. Testing the following on >>>>>> master/main works as expected (DepictionGenerator computes the 2D as >>>>>> needed, no need to clear the 3D): >>>>>> >>>>>> public static void main(String[] args) { >>>>>> String molfile = "\n" + >>>>>> " MJ231200 \n" + >>>>>> "\n" + >>>>>> " 5 4 0 0 1 0 0 0 0 0999 V2000\n" + >>>>>> " 0.9718 -0.1139 0.6193 O 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0\n" + >>>>>> " 0.9448 0.0189 -0.2285 S 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0\n" + >>>>>> " -0.0042 0.1584 -0.4371 C 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0\n" + >>>>>> " -0.2882 0.8589 -0.1053 C 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0\n" + >>>>>> " 1.1863 -0.8418 -0.6272 C 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0\n" + >>>>>> " 1 2 2 0 0 0 0\n" + >>>>>> " 2 3 1 0 0 0 0\n" + >>>>>> " 3 4 1 0 0 0 0\n" + >>>>>> " 2 5 1 0 0 0 0\n" + >>>>>> "M END\n"; >>>>>> IChemObjectBuilder bldr = SilentChemObjectBuilder.getInstance(); >>>>>> try (MDLV2000Reader mdlr = new MDLV2000Reader(new >>>>>> StringReader(molfile))) { >>>>>> IAtomContainer mol = mdlr.read(bldr.newAtomContainer()); >>>>>> new DepictionGenerator().depict(mol).writeTo("/tmp/tmp.svg"); >>>>>> } catch (IOException e) { >>>>>> throw new RuntimeException(e); >>>>>> } catch (CDKException e) { >>>>>> throw new RuntimeException(e); >>>>>> } >>>>>> } >>>>>> >>>>>> On Tue, 19 Sept 2023 at 18:15, Tim Dudgeon <tdudgeon...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> I'm using StructureDiagramGenerator.generateCoordinates() to >>>>>>> create a layout before using CDKMolDepict to generate images for >>>>>>> molecules, >>>>>>> and I've hit a problem when using molecules that already have 3D >>>>>>> coordinates as StructureDiagramGenerator.generateCoordinates() does not >>>>>>> generate a new 2D layout if 3D coordinates are present, and passing in a >>>>>>> molecule with 3D coordinates seems to make CDKMolDepict crash badly. >>>>>>> >>>>>>> So, what is the best way to clear the 3D coordinates for a molecule, >>>>>>> so that StructureDiagramGenerator.generateCoordinates() can do its job? >>>>>>> _______________________________________________ >>>>>>> Cdk-user mailing list >>>>>>> Cdk-user@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/cdk-user >>>>>>> >>>>>> _______________________________________________ >>>>>> Cdk-user mailing list >>>>>> Cdk-user@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/cdk-user >>>>>> >>>>> >>>>> >>>>> -- >>>>> Inherited disorders can be hard to interpret when multiple biomarkers >>>>> are involved. A network approach can help bring insight: >>>>> https://doi.org/10.1186/s13023-023-02683-9 >>>>> >>>>> -- >>>>> E.L. Willighagen >>>>> Department of Bioinformatics - BiGCaT >>>>> Maastricht University (http://www.bigcat.unimaas.nl/) >>>>> Blog: https://chem-bla-ics.blogspot.com/ >>>>> Mastodon: https://scholar.social/@egonw >>>>> PubList: https://orcid.org/0000-0001-7542-0286 >>>>> >>>> >>> >>> -- >>> Inherited disorders can be hard to interpret when multiple biomarkers >>> are involved. A network approach can help bring insight: >>> https://doi.org/10.1186/s13023-023-02683-9 >>> >>> -- >>> E.L. Willighagen >>> Department of Bioinformatics - BiGCaT >>> Maastricht University (http://www.bigcat.unimaas.nl/) >>> Blog: https://chem-bla-ics.blogspot.com/ >>> Mastodon: https://scholar.social/@egonw >>> PubList: https://orcid.org/0000-0001-7542-0286 >>> >> > > -- > Inherited disorders can be hard to interpret when multiple biomarkers are > involved. A network approach can help bring insight: > https://doi.org/10.1186/s13023-023-02683-9 > > -- > E.L. Willighagen > Department of Bioinformatics - BiGCaT > Maastricht University (http://www.bigcat.unimaas.nl/) > Blog: https://chem-bla-ics.blogspot.com/ > Mastodon: https://scholar.social/@egonw > PubList: https://orcid.org/0000-0001-7542-0286 >
_______________________________________________ Cdk-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
