[gmx-developers] Interface

[Erik Lindahl]

On Thu, 23 Aug 2001, David van der Spoel wrote:

Hi,

> After some requests from the CCL etc. I think it would be useful to
> consider creating a "clean" programming interface, so that e.g. graphics
> programs can link to the gromacs MD code in a simple way.
>

I've been thinking of this too. Or rather, I absolutely need it when
I go to the US to do bioinformatics, so I'm working on it ;-)

> The point is of course that we want to do it once and for all, so we
> probably would have to introduce a structure type which contains
> everything, like
>
> typedef struct {
>   ... stuff here ...
> } t_gromacs;

I'm not sure a catch-all structure is the best solution; the problem
is that we would break everything if a new version adds options, but
I do agree we should have considerably fewer structures than we have
now.

There are a couple of problems/decisions we face:

1. Should we keep both gmxlib and mdlib, or merge them?
   The source code can still live in several directories for
   readability even if we merge them to libgromacs.
   There are advantages with having separate libraries in some cases,
   but that assumes there is a clear distinction between them. Right
   now you basically have to include every single header to use
   any library (and our libraries are fairly small).

2. Improve the modularization. We simply use too many files. I'm
   as responsible as anyone else; it is for instance just stupid
   to separate the PME files in two libraries, two source files and
   at least two header files.
   The problem with this approach is that the header files are just
   cluttered with internal declarations. I *think* the ideal would
   be to have each source file as a clear module, and a small,
   well-documented corresponding header with only the external routines.

   We could still use some internal headers (i.e., non-installed),
   but they should be much fewer!

   Another advantage with this is that it should make the code
   much easier to understand for a novice hacker...

3. Decide what routines should go in the external interface. It should
   be very nice to ns routines, etc. available, but this means we'll
   have to impose some self-discipline and not break the interface by
   adding 'useful' parameters unless it is absolutely necessary.
   (Although I think that's realistic once we have the new
    parallelization and XML framework there :-)

   We should also keep the highest-level routines very simple; you
   should not have edit communication records, force records, input
   records and everything just to calculate the energy of one structure.


Actually, it's not a lot of coding work, and I'm willing to do most of it
since I need it myself, but we should probably agree on a setup for
the libraries and those things first...

Regards,

Erik

---------------------------------------------------------------------
Erik Lindahl, PhD                                erik at theophys.kth.se
Dept. Biophysical Chemistry, Groningen University, THE NETHERLANDS
Phone: +31 50 3634335    Fax: +31 50 3634800
(You can also reach me as lindahl at chem.rug.nl and lindahl at gromacs.org)
Hi! I'm a mutated .sig virus! Put me in ~/.signature to multiply me!