Subject: CCL: Design/OO/standardization

From: Fabien Campagne <[email-masked]>
Date: Tue, 29 Jul 1997 11:55:08 +0100

I found that the discussion about Object Oriented design
and programming for Computational Chemistry software was
interesting and raised one or two point I'd like to
emphasize.

Development of software for Computational Chemistry
by researchers is usualy focused on new methodologies.
That's a matter of specialization: people who develop
and maintain scientific software have less time to use 
these software to applied research than people interested
in applications only. These two communities have distinct
needs: 
 method development community needs software easy to
extend and change, from their point of view, in order
they could try one idea they have in a few days, not
in a few months.. 
Code, if the idea is valuable, does not need, at that point,
to be portable, user-friendly, or whatever. Code needs 
to demonstrate, on a few examples, that the idea is 
valuable,.. no more.

 application community,.. well,.., would like to
work on a variety of hardware and operating systems,
from a microcomputer to a paralel computer, with a
fully validated software, that is very user-friendly 
and... free :-)

This two aspects of Computational Chemistry are quite
difficult to make live together. Usualy commercial
companies help to make the interface between new methods
and application people: they take a new method, add it
to their integrated environment and sell the result..
A few problem arise when such a company have to deal
with a software that was so poorly designed at the
begginning that it would be necessary to write it
again from scratch to make a good integration to their
product line. Very often if a software present this problem
and is big, the choice is to sell it as it is, with minor
enhancements (no more platform supported by the original
product, weak integration to the product line...).

In my opinion, design and standardisation may help the
three communities: new method development would make profit
of a better design (more on this at the end of this text),
commercial software integrators would be able to use the
flexibility induced by the design to better adapt the software
to application users. And these latter users will benefit
from an increased quality of the overall software (available 
through com. soft. int. or directly from the labs) and from shorter 
development times.

The "new methods community" needs access to third party developed
software so researchers won't loose time implementing again
what was alraeady done by others. That's exactly the same 
thing for software than for methods: I know nobody that
will claim again the discover of the conjugated gradient
minimisation method.. but a lot of people will tell you
they HAVE HAD TO implement it again for their own research
-- even though one hundred of these implementations may exist
around the world, written in fortran, C or something else --
The problem is not only the design. The problem is that
usualy, the interface, ie the way to reuse the implementation,
is not described properly.
Computer scientific community uses standardization commitees
that consist of experts in one field talking together until they
agree on a standard: ONE way to do something that meet experts
idea of what is important (performances, reusability, extensability..).
At the end of the standardization, the standard is documented and
, quite often, implemented. In fact, partial implementations helps
the discussions, demonstrating or invalidating one or another
design.
This may take some time (it usualy do) but the result is available to
everybody, clearly documented, and once available, anybody can build
on top of it.
What about standardizing interfaces for common algorithms ?
It seems to me that a minimization algorithm looks like
another and should be used the same way from the code
I'm writing (whatever the implementation I actually decide
to retain)
I mean: why should I change the part of the source code that
gives parameters for a minimization (max. number of steps,
threesold, system to minimize) if I decide to change the
minimization algorithm.
Couldn't we design our software so that algorithms are
parameters for algorithms (at compile time). Maybe an example
could be valuable here:

do_a_minimization<minimization_algorithm m> (system s){

 m.maxSteps(10000);
 m.threesold(0.0001);

 m.system(s);
 m.minimize();
}

there will be no need to change this code, if latter, I write
an application that uses this standard interface and 
like to do:
do_a_minimization<conjugated_gradient_minimization_algorithm>(my_sys);

or if I prefer:
do_a_minimization<newton_raphson_minimization_algorithm>(my_sys);

The implementation will be completely different of course from one
line to the other, while the source remain quite the same
(changes what need to be changed, no more).

That's just an idea of course, but what about thinking carefully
about such interfaces to common algorithms, document them,
implement the interfaces to our old -- but still worthwhile --
codes and use them while cheking new ideas (if the idea is
good, we'll create a standard for it latter..).

Taking this approach with an OO language may help the portability:
modules of the software that need to be changed for each platform
have to be isolated by the design, their type refined (inheritance
implied) for each plateform, and the right type (for target plateform)
used at compile time.

Well, I didn't go into technical details, but if anybody is interested
in taking part to technical discussions about such a standardization,
or have pointers/references to tentative of standardization (this means
at least two implementations sharing the same interface) relative
to Computational Chemistry software (personnal interest in molecular
modeling methods and algorithms), please email directly to me. I'll
summarize and maintain a few web pages about the results of the
discussions.

Fabien Campagne -- [email-masked] | Lab. de Chimie Theorique
phone: +33 (0)3 83 91 20 00  extension 3236 | Nancy, France.
           http://www.lctn.u-nancy.fr/viseur/FC.html