Problem with arrangeMolecules()

Hi,

I am using Jchem Java API 5.11.2.  When I process attached 006.mol through below code, I get undesirable rearrangement (it is shown in attached PDF).  Is there a way for this rearrangement to be prevented?  Thanks for any help.

Best,

Andrew

MolImporter mi = new MolImporter(infile);

        Molecule mol = mi.read();

        MolBond[] originalBonds = mol.getBondArray();

        MoleculeGraph[] frags = mol.findFrags(

                                            SelectionMolecule.class,

                                            MoleculeGraph.FRAG_KEEPING_MULTICENTERS);

        for (int i=0; i<frags.length; ++i) frags.sortBondsAccordingTo(originalBonds);

Hi,

It looks like a bug. Thanks for the report, we will fix it.

János

Thank you for the quick reply and confirming the issue.

Best,

Andrew

Can you provide an estimate as to when a bug fix might be available?  Or if any work-arounds exist?  Many thanks, Andrew

Hi

Can you explain what do you want to do with this code?

János

Hi,

The code causing the problem is simply meant to spatially arrange the fragments of any particular structure.  The bond sorting step is required to maintain the order in which bonds are drawn (this becomes important for bicyclo's, for example).

Thanks,

Andrew

Hi,

We try to fix it in the next few weeks. 

I dont have any idea for a workaround. Maybe you can use Cleaner.clean in case of molecules with only 1 fragment.

János

Thank you for suggestion .. we tried it, but it looks like we'll have to wait for the bug fix.

Best regards, Andrew

Hi,

I have another idea: can you just expand the molecule after import and contract after doing the work?

I mean:

        MolImporter mi = new MolImporter(infile);
        Molecule mol = mi.read();
        mol.expandSgroups();

        MolBond[] originalBonds = mol.getBondArray();

        MoleculeGraph[] frags = mol.findFrags(
                SelectionMolecule.class,
                MoleculeGraph.FRAG_KEEPING_MULTICENTERS);

        for (int i=0; i<frags.length; ++i) frags.sortBondsAccordingTo(originalBonds);

        CleanUtil.arrangeMolecules(frags, 2, -1);
        mol.contractSgroups();

        System.out.println(MolExporter.exportToFormat(mol, "mol"));

Another solution if you just contract the Sgroupsafter the import.

Is it a usable workaround for you?

Hi,

Thank you for the suggestion .. I am sorry for my delay .. I have been sick.

mol.contractSgroups() resolves the problem in this case.  Can you explain why it is needed here?  If I load the original mol file (006.mol) into MarvinSketch, the super atoms are already contracted, so I'm confused as to why this call would be necessary or what it is doing .. I'd need to understand that because for processing, I won't be able to always just contract all S-groups; I'd prefer to leave them in the state that the chemist drew them.

Thanks for the ongoing help.

Andrew

Hi,

There are 3 different sgroup states: contracted, expanded and gui contracted. This last state is a wrong design, because its like "expanded, but in the gui its like contracted". For example the getAtomCount() method says there is 10 atoms in the molecule but the gui shows only the 1 superatom. And this state preserve the atom coordinates. When you import a molecule from MDL molfile, the result will be in this state. This cause a lot of problems.

So if you expand or contract the molecule you will get the good result, only this liminality state cause problem.

May we can do some conversion during the arrangeMolecules, but I'm afraid, it will cause more misunderstanding.

Janos

Thank you for explanation .. it _is_ confusing .. smile.

If I understand, then it would work to check each super atom group in the molecule .. if group is in "GUI contracted" state, then I fully contract the super atom group before I arrange the molecule.  Does that seem good?

Can you tell me how to test each super atom group if it is in "GUI contracted" state?

Thanks, Andrew

Yes, I think this will be work for you (Sgroup.XSTATE_XC is the "gui contracted " state):

for(Sgroup sg : mol.getSgroupArray()) {

if(sg.getXState() == Sgroup.XSTATE_XC && sg instanceof SuperatomSgroup) {

((SuperatomSgroup) sg).contract(0);

}

}

Janos

Thank you for this reply .. I will test it out .. and the only aspect of the structure that I will lose when I contract a super atom group in this way is the original expanded coordinates that the user drew before they contracted the group .. is that accurate?

And maybe you lost the original atom idexes too. You can preserve the coordinates with the Expandable.LEAVE_COORDS_UNCHANGED parameter in the contract method.

Janos

Hi,

I have been testing this work-around, and it works very well so far .. but I am unable to see a change to the user-drawn (expanded) super atom coordinates after I perform full contract(0) .. can you provide a mol file of an example that will change?

Thanks, Andrew

Hi,

Sorry for the delay, I was on holiday. I think contract wont affect the coordinates, expand will. If you open the attached file, there are some atom collisions. If you contract and expand it with 0 options, the collision will be fixed.

Janos

I hope you had a good vacation!  It is better than being sick .. smile.

Thank you for the example.

I have some questions about problems I am having with testing contracted superatom groups.  I have attached bn.java and bn.mol.

When I perform superatom contract(0) [line 45], then I get exceptions thrown later.  If which_one==1 [line 68], then exception will be thrown at line 72; otherwise it will be thrown at line 78.  Can you explain these exceptions?

Thanks, Andrew

Hi,

Thanks, hope you feel yourself better now.

The problem is that you use a method in Sgroup, and it deosn't care about superatom and contracted state, etc.

So except this two lines:

mol2 = new Molecule();
Sgroup m2sg = sg.createMolecule(mol2);

use this one:

mol2 = sasg.createMolecule();

I think this will work for you.

Janos

Thank you .. yes, I am feeling better … smile.

If I use just

mol2 = sasg.createMolecule();

then I get exception thrown:

java.lang.ArrayIndexOutOfBoundsException: -1

        at chemaxon.struc.MoleculeGraph.getAtom(Unknown Source)

        at chemaxon.struc.Sgroup.getAtom(Unknown Source)

        at chemaxon.struc.sgroup.SuperatomSgroup.createMolecule(Unknown Source)

        at bn.Process(bn.java:73)

        at bn.main(bn.java:24)

Nothing else changed in your code? It works for me. Can you try this java file?

Which version of Marvin are you using?

Janos

Hi,

Yes .. I get the error using your bn.java

java.lang.ArrayIndexOutOfBoundsException: -1

        at chemaxon.struc.MoleculeGraph.getAtom(Unknown Source)

        at chemaxon.struc.Sgroup.getAtom(Unknown Source)

        at chemaxon.struc.sgroup.SuperatomSgroup.createMolecule(Unknown Source)

        at bn.Process(bn.java:76)

        at bn.main(bn.java:24)

Hi,

I'm not sure, but it is possible. Can you update your API?

Janos

Hi,

Sorry for another delay .. we were updating the API and doing more testing etc.

Updating to latest API (14.10.13.0) seems to get rid of the createMolecule() bug/issue described above.

However, I'm confused by another aspect.

If I run the below code against a mol file with GUI contracted super atoms (for example, bn.mol from this thread), and then save the result as a new mol file.  If I then process that new/revised mol file, the code also finds GUI contracted super atoms.  Shouldn't the super atoms be fully contracted in the new mol file from the initial processing?  Why is that state not retained in the mol file created after fully contracting the super atoms?

Thanks for the ongoing help.

Best, Andrew

    public void Process() throws Exception {

        MolImporter mi = new MolImporter(infile);

        Molecule mol = mi.read();

        for(Sgroup sg : mol.getSgroupArray()) {

            if(sg.getXState() == Sgroup.XSTATE_XC && sg instanceof SuperatomSgroup) {

                System.err.println("contracting");

                ((SuperatomSgroup) sg).contract(0);

            }

        }

        System.out.println(mol.toFormat("mol"));

    }

Hi,

I'm checking the mdl io, but I think the in the mol file there are no expansion states, and we always import the groups as GUI contracted. I will give you a more accurate answer soon.

Janos

Hi,

I've checked it. There are expanded and contracted state in the mol file. Our export import the expanded state as expanded and the contracted state as gui contracted (XC).So your contracted groups will be imported as XC.

The XSTATE and the contract-expand method are not in synch, so if you want to export it in expanded form, you should call the setXState(Sgroup.XSTATE_X) method before or after expand.

Janos

Thank you for this information.  Best, Andrew