[Molecularmechanics] Recommendations for object oriented approaches / UML models

[Konrad Hinsen]

On Apr 4, 2006, at 16:39, Marc Baaden wrote:

> 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

That sounds like a good project, but already a major one, considering  
that it implies extending someone else's code.

> fairly low (computationnally efficient) level, so the intended
> implementation is likely to be in C++ (for several reasons that I

In other words, you want to use a common in-memory representation? As  
soon as you exchange data in files, the efficiency of the programming  
language becomes secondary.

> 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.

In my experience, language-independence of OO interfaces is not  
always a useful goal. OO languages vary widely in type checking,  
inheritance rules, attribute access control etc. A class hierarchy  
that is reasonable in one language is often clumsy to absurd in  
another one.

One example is XML handling in Python. Initially, people implemented  
DOM (the Document Object Model, originally designed for Java) in  
Python. But every Python programmer who got interested in XML and  
looked at DOM quickly found it "unpythonic". As a consequence, more  
Python-oriented interfaces were developed and are now rapidly gaining  
popularity (see for example ElementTree, http://effbot.org/zone/ 
element-index.htm, which will be included in the Python standard  
library starting with Python 2.5).

> 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

The physics won't change, but simulations deal with models, not with  
physics. Even within a rather narrow field such as molecular  
mechanics, models evolve. In a force field like CHARMM or AMBER, an  
atom has two parameters: an atom type for bonded and LJ interactions,  
and a charge for electrostatics. But in force fields that are now  
under development, we see polarizabilities and electronegativities in  
an attempt to improve the description of electrostatics beyond the  
old constant-point-charge model. Any object model that provides a  
"charge" attribute for an atom is therefore already too restrictive.

> 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 isn't, unfortunately. But you are welcome to join those of us who  
want to get there!

> It would also be very encouraging if there were approaches that allow
> to gradually adapt the complexity of the underlying model. What I mean

That is not particularly difficult in an OO approach. In fact, this  
is one of the strong points of OO.

> am not sure if this is straightforward with eg CML (which
> intrinsically seems a very appealing approach to me so far).

It is my understanding that nearly any information item in CML is  
optional, so this should be straightforward.

> Hm, why not -- officially the community is supposed to already have
> accepted these units...  If one decided to store SI units as default,

SI units are not very practical at the atomic scale, as you end up  
with huge powers of ten everywhere (don't forget human readability!).  
But I agree that one could well define a single unit (ideallly SI- 
derived) for each quantity as part of the specification for a file  
format. That is easier to handle for everyone than a flexible system  
in which any unit is permissible and every code needs to implement  
extensive unit conversion for reading files.

My personal favourite unit system is what I call "atomic-scale SI":  
nm, ps, g/mol (=amu), and their combinations (i.e. kJ/mol for  
energy). All these units are derived from SI units, and they can be  
used in SI-conforming formulas without the introduction of conversion  
factors.

Konrad.
--
---------------------------------------------------------------------
Konrad Hinsen
Laboratoire Léon Brillouin, CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: konrad.hinsen at cea.fr
---------------------------------------------------------------------