[Fsatom] CML for materials simulation
Peter Murray-Rust
pm286@cam.ac.uk
Mon, 20 Oct 2003 17:58:23 +0100
I include - with annotations - correspondence from the materials group in
UK we have been working with and some comments. This gives a goo idea of
the value of communal discussion in this area.
Points to notice are:
- the question about using a parser
- the use of SOAP (Axis) - XML glueware
In chronological order
> >
> >----- Original Message -----
> >From: "Peter Murray-Rust" <pm286@cam.ac.uk>
> >To: "Wolfgang Emmerich" <w.emmerich@cs.ucl.ac.uk>; "Sally Price"
> ><s.l.price@ucl.ac.uk>; "Richard Catlow" <rcatlow@ri.ac.uk>; "Kleese, K
> >(Kerstin)" <K.Kleese@dl.ac.uk>
> >Cc: "Ben Butchart" <b.butchart@cs.ucl.ac.uk>; <h.rzepa@imperial.ac.uk>
> >Sent: Monday, October 20, 2003 1:00 PM
> >Subject: Re: FW: CMLComp (CML for computational chemistry)
> >
> >
> > > At 23:55 19/10/2003 +0100, Wolfgang Emmerich wrote:
> > > >Dear Sally, Richard and Kerstin,
> > > >
> > > >Ben Butchart has already adopted CML for the next release as an
internal
> > > >representation of the polymorph prediction simulation of our
Materials
> > > >Simulation EPSRC Project.
> > >
> > > Thanks for the quick response.
> > >
> > > >I guess we ought to discuss this next Tuesday - most importantly what
> >input
> > > >we have for Peter on the future evolution of CMLComp...
> > >
> > >
> > >
> > > >Wolfgang
> > > >--
> > > >Dr. Wolfgang Emmerich
> > > >Reader in Distributed Software Engineering Direct: +44 20 7679
4413
> > > >UG Admissions Tutor Fax: +44 20 7387
1397
> > > >Dept. of Computer Science, UCL
W.Emmerich@cs.ucl.ac.uk
> > > >Gower St, London WC1E 6BT, UK
http://www.cs.ucl.ac.uk/staff/w.emmerich
> > > >
pmr reply
> > > CML is designed to be driven by community wishes... Some of it is
> > > "parallelisable" in that discrete work needs to be done for each
> >program/code.
> > >
> > > CMLComp is designed to support, or be extensible to support, the
> > > microscopic aspects of crystal structure computation. It can support,
cell
> > > dimensions, coordinate sets, energies, several solid-state properties,
> >etc.
> > > The approach is that someone "in charge of a code" will collaborate -
we
> > > will help on the design of the CML interpretation of the problem and
what
> > > extensions if any are required - and the actual implementation is done
by
> > > the code owner.
> > >
> > > Remembering that any new concept (XML element requires someone to
write
> > > code :-)) It is useful to draw some boundaries. At present CML does
not
> > > address:
> > > - macroscopic crystallography (habits, etc.) though this would
probably be
> > > fairly easy
> > > - polyhedral classification of extended solids (linked octahedra,
etc.)
> > > This need careful design
> > >
> > > it would be useful to have a rough list of the areas that do need
support
> > > so we can give some idea of how much extra needs creating. The idea of
> > > using FSATOM is to keep the discussion in one place as far as
possible.
> > > FSATOM has a Wiki which I am investigating which could be a useful
place
> >to
> > > store info.
> > >
> > > Please copy this to eminerals if appropriate
> > >
> > > Best
> > >
> > > P.
BenB...
> At 14:03 20/10/2003 +0100, Ben Butchart wrote:
> >Peter,
> >
> >I would like to clarify a couple of points. So far I have only used core
CML
> >(http://www.xml-cml.org/schema/cml2/core)
> >for representing atom coordinates and simple crystal properties (alpha,
> >beta, gamma, a, b, c, volume and lattice energy). I have not looked at
the
> >CMLComp schema yet. I have modified the schema slightly so that Axis can
> >cope with the type definitions in WSDL descriptions (e.g the Axis tools
> >didn't like the xsd Union contruct too much and some elements with
embedded
> >types were changed to named complex types).
====
>
> I haven't used Axis (I assume this is Apache's SOAP tool?) AFAIK the CML
> schemas are W3C compliant - they have been run through several tools. If
so
> it sounds as if Axis is not yet a full implementation.
>
> Have you been able to kludge round Union? Or do you simply have to remove
it?
>
> >The messages themselves are CML
> >core schema compliant despite these modifications.
>
> Messages == SOAP messages?
>
> >So far the executables
> >are not themselves CML enabled (GULP will be the first to support CML
> >directly). We are using XSLT stylesheets to convert SOAP messages to the
> >fixed format fortran input files.
>
> Excellent
>
> > A fair bit of chemical data is hardcoded
> >in the XSLT files meaning not all data is not sent in messages and does
not
> >need to be encoded in CML (yet). Parsing of output back into CML and SOAP
is
> >still done using Java objects (generated from WSDL and CML schema) for
the
> >moment.
>
> These java objects are presumably handcoded?
>
> >We are considering using Jumbo for parsing but we are still debating
> >whether a pattern matching language specific to crystalography might be
> >easier for scientists to get to grips with. I think it would be very
useful
> >at this stage for the scientists to get together and agree how they want
to
> >represent crystallographic data. I am avoiding modelling too much detail
for
> >the moment in CML and sticking to just basic crystal represnetations
until
> >we get more agreement about modeling complex properties.
>
> Jumbo is general and you shouldn't suffer very much by using it (BTW if
you
> want to use it there is a second version which is completely different
from
> the first.) JUMBO anticipates the structure of the final document and uses
> regular expressions to parse the output into that. If there are large
> chunks with very standard structure then it could be tuned to use those.
> JUMBO is capable of managing (say) triangular matrices split over several
> pages.
>
> >kind regards,
> >
> >Ben Butchart Phone: +44 207 679 3723
> >Research Fellow, Dept. of Computer Science Fax: +44 207 387 1397
> >University College London, Gower Street B.Butchart@cs.ucl.ac.uk
> >London WC1E 6BT, UK http://www.cs.ucl.ac.uk/staff/B.Butchart
> >
> >
Peter,
Sure. Go ahead. I need to check the union problem. I don't think it was a
problem with axis itself. Rather the tool I used to get Java stubs from wsdl
(Gwsdl2Java from www.globus.org). I'll go back and check out exactly what
the problem was. The java types were hardcoded. I added a constructor to the
stubs which took the output file as a parameter to initialize the object.
[PMR comments. This makes sense. I would have been surprised if the Apache
stuff had been lacking in functionality.]
regards,
Ben