[Cdk-devel] Jmol v10 + CDK+CML

[Peter Murray-R. <pm...@ca...>]

At 13:03 30/01/2004 +0100, E.L. Willighagen wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I think there is little difference between an animation and a multi model
>structure... both are just sequences of models (unless we move things forward
>an store animations as one model, and a sequence of changes... *but* XYZ
>animations for example, *is* a sequence of models... less efficient, but the
>way chemical formats/program do things).

There are several different uses for multiple models.
- an set of coordinates for the same molecular system with a constant 
connection table. E.g. molecular dynamics. Here the use wants to show them 
in a given order with a given speed. Bonds are neither broken or created
- reactions. Here bonds are normally broken and made. Fragments may also 
appear and disappear during the reaction (although personally I support 
having them present in the file.) The bonds may be determined by the 
connection table or they may be calculated by CDK./Jmol. I think both are 
needed.
- the same molecule with different coordinates (e.g. the result of a 
conformational search)
- a list of different molecules (e.g. from a database search). There might 
be some requirement to align them in some way but not necessarily.

Finally there are compound molecules (e.g. protein+ligand+solvent)

>Only difference is, that animations have:
>- - a play button
>- - possible interpolation between two given frames to get a smoother 
>animation

These are very valuable. We are now at the stage where we can formally 
describe reactions in CML and are very interested in using Jmol for the 
display.

> > >> I also plan on taking another look at the high-level interface to the
> > >> CDK IO modules. I am wondering whether or not it is possible to define
> > >> a "CdkModelInterface" on top of all the file formats, something that
> > >> would define a cleaner separation between the file IO and the internal
> > >> CDK data structures. I also want to look into dynamic loading of the
> > >> file IO modules ... so that they are load-on-demand.
> > >
> > > Funnilu enough, CML does have such an intermediate layer... this makes
> > > it  possible to have multiple programs use the CML reader... This
> > > originally were  JChemPaint and Jmol, but they have been integrated...
> > > Later JOELib came along  and implements this intermediate layer... (see
> > > my CML parsing article in  Internet Journal of Chemistry..., ref on Jmol
> > > website, though in cvs only  yet: history/index.xml)...

CML is deliberately flexible and we would expect to provide designs for 
anything that Jmol requires to do. Examples would be welcome

> > >
> > > And, here comes the funny part, I would very much like to drop that
> > > intermediate layer ;) Because you need to maintain yet another internal
> > > representation of data...
> >
> > Hmmm ... I will take a look at this. I understand your desire to get rid
> > of another internal representation of data. But perhaps we can modify the
> > API so that it does less 'storing' and more 'responding' to calls for
> > data.
> >
> > This is a problem that I could be interested in working on.

Does this intermediate layer appear in the CML? If so how?

>It is interesting indeed. But also complex. I think this would be very nice
>once we can actually store things in the classes we have now... there are a
>few articles on chemical concepts as classes, but it's just a very complex
>material... and I think getting v10 out with same functionality as v9 and
>below, is more important at this moment...

We are actively working on holding chemical concepts in CML and the latest 
draft has about 70 concepts. They are detailed in Wiki form at 
http://wwmm.ch.cam.ac.uk/moin. Every XML element has associated Java code 
(in a bean-like fashion) and many have enhanced functionality through 
adapters (decorators). This enhancement is often provided by CDK 
functionality. So a typical sequence might be:

MoleculeEditor molEditor = 
MoleculeEditorImpl.getMoleculeEditor(cmlMolecule); // the molEditor 
provides additional functionality
molEditor.partitionIntoMolecules();    // converts internal cmlMolecule to 
cdkMolecule and uses CDK.partitionIntoMolecules
molEditor.addHydrogens();              // uses CDK adjustHydrogensToValency
molEditor.add2DCoordinates();        // uses CDK layout
cmlMolecule = molEditor.getMolecule(); // returns the CMLMolecule, after 
CDK modifications

The interface is (I hope) sufficiently general that other java libraries 
could also be used. The main problem is reconciling the new information 
from CDK without losing the information in the initial CML molecule. The 
transfer is made through XML strings - this adds a performance overhead but 
saves problems in losing information.

Early days but it seems to be working well. We have read in RXN files 
(which contain all reactants in a single Molfile), split them, added 
hydrogens, placed the hydrogens and may use the MaximalCommonSubgraph to do 
the mapping or reactants to products, though geometry is the best heuristic 
at present.

>Egon
>
>- --
>eg...@sc...
>PhD on Molecular Representation in Chemometrics
>Nijmegen University
>http://www.cac.sci.kun.nl/people/egonw/
>GPG: 1024D/D6336BA6
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (SunOS)
>
>iD8DBQFAGkf0d9R8I9Yza6YRAic/AJ0ZNsetEsUNx6z3j1IbiCQCTlQE1ACgurDx
>IXISlrilchgBmkElrAWDNik=
>=IBiz
>-----END PGP SIGNATURE-----
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Cdk-devel mailing list
>Cdk...@li...
>https://lists.sourceforge.net/lists/listinfo/cdk-devel

Peter Murray-Rust
Unilever Centre for Molecular Informatics
Chemistry Department, Cambridge University
Lensfield Road, CAMBRIDGE, CB2 1EW, UK
Tel: +44-1223-763069