Re: [Cdk-devel] Re: Jumbo 4.3

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

Just back from an afternoon away...
At 15:01 25/04/2004 +0200, Egon Willighagen wrote:
>On Saturday 24 April 2004 12:57, Peter Murray-Rust wrote:
> > At 13:14 23/04/2004 +0200, E.L. Willighagen wrote:
> > >-----BEGIN PGP SIGNED MESSAGE-----
> > >Hash: SHA1
> > >
> > >On Friday 23 April 2004 13:06, E.L. Willighagen wrote:
> > > > BTW, is Jumbo4.3 ready for release? That is, can it be distributed with
> > > > CDK, so that I can update the CMLWriter?
> > >
> > >Just spoke with Stefan, the jars that are currently in CDK cvs...
> > > cmlAll.jar has the artistic license, but what about pmrlib.jar and
> > > base.jar? Also for version 4.3?
> >
> > I have copied in cdk-developers, Gemma, Billy and YY since they have all
> > been involved at times. Please everyone make suggestions
> >
> > We have a distrib on the Wiki:
> > http://wwmm.ch.cam.ac.uk/moin/CmlAtNesc
> > and download the ZIP file
> > This is all covered by Artistic but it doesn't explicitly include it in
> > every directory or module.
> >
> > ***We haven't released Jumbo4.3 as a standalone but will do so in a few
> > days (the reasons are not technical). *** Your experience will help
>
>Ok, I see next week wether I will pick up the zip from the above link, or 
>wait
>until 4.3 is out... BTW, are there many changes with 4.2?

Yes and no. The functionality has been rationalised. the main change is 
with the autogeneration, etc. Your enthusiasm has catalysed me to turn the 
tools into pseudocode.


> > There are 2/3 things to notice:
> > - there is  now a CIF reader. Since the Tools contain CifTool this needs to
> > be in jars. Jumbo is set up with jars like:
> > jars
> >          xerces
> >          saxon
> >          fop
> >          cif
> >          cdk
> >
> > cif needs to be in cif/lib/ciflib.jar and needs to be in .jumbo
> > configuration. The distrib as mounted has CIF in another directory.
> >
> > We have sometimes omitted the jars from the distrib as the package is too
> > large for some mailers and also we don't like keeping jars on CVS - it
> > because they sometimes get corrupted.
>
>Forgetting the -kb in the cvs add gives horror...

I am fairly sure we use -kb, but...

> > Note also that our jars are not the latest CDK jars. We would be happy for
> > you to try these.
>
>Yes, I tried to compile with the latest CDK jars... which failed... I'll see
>if I can make some patches to get it to compile with latest CDK...

OK - keep in touch

> > There are not many good examples for Tools and Legacy yet
> > so it isn't easy to test these (which is where the main interaction with
> > CDK comes). We are looking closely at workflow - this is now critical -
> > more next week.
> >
> > Feel free to package jumbo if required. Thus it could be sensible to have
> > pmrlib+base+cmlAll.jar as a single package jumbo.jar. Comments
>
>Yes, that would be nice... It's easier in our JavaDoc to state it depends on
>one jar than on three...

I think we should do this anyway.base+pmrlib+schema ==> jumbo

> > The key areas are:
> > - Does jumbo provide what CDK needs?
>
>I guess what we need most at this moment is CMLDOM... At least for writing we
>currently use it... BTW, a question about that... How can I set the namespace
>of a CMLNode? I want to root element to have the xmlns attribute when the
>user asks (*) for it...

Good question. the original PMRLib was before namespaces were tested. I 
suspect I have to fix this.


>*) using one of the IOSettings...
>
> > - we need better communication between Jumbo (in Tools) and CDK. The
> > current method of serializing to ASCII XML is probably an overhead
>
>CDK -> CML can be done using cdk/libio/Convertor
>
>The other way around can still only be done with the method you described
>above...
>
> > - we need a test suite. Billy is developing a workflow for converting CIF
> > and this will test quite a lot of CDK including:
> >
> > - joint the dots with covalent radii (NB I think Jmol may make rather too
> > many bonds here. I will post.to Jmol separately
> > - partition
> > - iteratively apply symmetry and repartition (Billy)
> > - add bond orders (we think we have a bug here but maybe the later versions
> > will change this)
>
>Yes, I think so...

OK

> > - manage atomic/molecule charge. INChI, CIF and MOPAC only have concept of
> > molecular charge. If they have atomic charges they convert to molecular
> > charge. Can CDK handle this?
>
>What do you mean with 'molecular charge'? That's the overal charge?

Yes.

> > - 2D layout (but ignore H atoms)
>
>That's implemented... but maybe not used by default.
>
>Now that I am able to compile Jumbo (for the first time without help from
>Gemma or YY  :), good job that 4.3! ), I will have a look at the classes that
>use CDK, and adapt it to use recent changes...

Thanks

> > This is workflow and it should not be expressed in a single monolithic
> > program. One approach is to write a declarative language, a bit like ANT.
> > We already have such a pseudocode in JUMBO - see distrib - which is
> > translated into several target languages
> >
> > <string name="file.root" read="sysin"/>
> > <file name="mols.cif" select="${cif.dir}/${file.root}.${cif.suffix}"/>
> > <fileset  name="mols" file="${mols.cif}" />
> > <foreach select="${mols}" name="cif">
> >    <cml name="cml" convert="CIF" select="${cif}"/>
> >    <joinTheDots name="${cml}" covalent="${covalent.file}"/>
> >    <splitMols name="splitMols" in="${cml}"/>
> >    <count use="${splitMols}" result="nMols"/>
> >      <output text="${cif} had ${nMols} molecules"/>
> >    <foreach select="${splitMols}" name="splitMol">
> >      <addBondOrder name="${splitMol}"/>
> >    </foreach
> > </foreach>
>
>Beautifull!

Good - I will post more later this week.

> > This is off-the-top-of-my-head but it shows the idea. We shall have a
> > clearer idea next week after we see workflow tools. They may have already
> > solved this.
>
>Egon

P.



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