[Molecularmechanics] Recommendations for object oriented approaches / UML models

[Marc Baaden]

Thanks for the wealth of comments!

Konrad Hinsen said:
>> What exactly is your goal? Do you want to write software, find
>> software ready to use, glue together different software, define an
>> interchange standard, or yet something else?

The initial goal is to glue together different software (some widely
used packages as well as in-house code) in a modular way by defining
and implementing an interchange standard. This should happen at a
fairly low (computationnally efficient) level, so the intended
implementation is likely to be in C++ (for several reasons that I
won't go into right now). In a second phase we might want to add new
modules/software. Some of this might be "lighter" code and the OO
framework should be accessible by a language of choice (eg python,
java, ..). This was one of the aspects that made UML appear very
appealing to me: use one model and then decline for the different
implementations.

>> I am not sure that formal approaches such as UML, which were
>> developed
>> for big software projects, are well adapted to scientific computing,
>> which is characterized by fast change and small development groups.

I was hoping that there could be a common "subset" of primitives (like
mentioned by Peter, see below) where no fast change happens as the
physics won't change. But you are right, there is also the application
specific part of the model which has to be included. I guess in my
particular case this makes still sense as I am aiming at a general
framework rather than a specific implementation.

Peter Murray-Rust:
>> it is important to have running code. Designs without code are of
>> limited value. They are usually overcomplex.

I agree. But I'm coming from a slightly different direction: trying to
setup new code I hope to find out whether I can build on something
existing rather than add another incantation of a "Yet Another
Personal View on How Molecules Can be Represented on a Computer". I am
sort of looking for an RFC or "Current Best Practice" but maybe the
field is just not there yet.

It would also be very encouraging if there were approaches that allow
to gradually adapt the complexity of the underlying model. What I mean
is that for the start I'll only need to manipulate basic things like
coordinates and forces (ignoring eg atom types and such details as
this is already handled by the applications that I try to glue
together) but at some point there will certainly be a need to extend
this. It would be ideal to only have to adopt the relevant subset of
objects/classes/primitives and be able to add complexity later on. I
am not sure if this is straightforward with eg CML (which
intrinsically seems a very appealing approach to me so far).

>> in physical science we can probably create context-independent
>> primitives. Thus <molecule>, <crystal>, <matrix>, etc. can have
>> semantics which is independent of the application.

Right, and my feeling is that having a UML model for these primitives
could provide some generic standards for any OO implementations.

>> Even "atomic velocities" require units - we cannot force the
>> community
>> to adopt SI everywhere.

Hm, why not -- officially the community is supposed to already have
accepted these units...  If one decided to store SI units as default,
one could always write a "GetVelocityInAtomicUnits" public method to
access the actual velocity in the desired units. Or am I missing an
important point here?

>> So as part of the solid state work we are extending CML to address
>> primitive structures that may be useful in - say - molecular
>> dynamics. The atoms, their positions, delta positions, velocities,
>> accelerations, constraints, etc. all have to be carefully
>> represented. After that we can then construct something - probably
>> not
>> in CML - which describes a trajectory

That sounds very promising. I wish you a successful meeting!
Marc


  Marc Baaden