[gmx-developers] New analysis library?

Erik Lindahl lindahl at stanford.edu
Sun Feb 2 22:48:09 CET 2003

>> a function which will be called to write the output. This way it is
>> easy to
>> have everything in windows and avoid the command line completely.
> Like a built in xmgrace you mean?

Well, I didn't intend to go that far, although we could probably do 

Anyway, my first intention was basically to have a window where you
select input and output file options, and then have a log window or
percentage-bar showing the progress we normally write to stdout/stderr.

>> The separation between gmxlib and mdlib is also somewhat artifical
>> right now -
>> both of them depend on the other. Why don't we reorganize things into
>> two
>> libraries:
>> 1. libgmx.so - "core" simulation, I/O & manipulation routines that we
>> expect to
>>      use in lots of programs.
>> 2. libgmxutil.so (or whatever name you want) - all routines used for
>> viewers,
>>      analysis tools, etc.
> Sounds good.
> How about organizing stuff in four directories
> gmxlib
> gmxutil
> kernel
> analysis
> Obviously the distinction is not always clear. Should e.g. trjconv be 
> in
> kernel or analysis?
> On the other hand one could also consider making more modules, and
> forcing them to be more or less independent, as we discussed before;
> e.g. having a libneighborseaurch, libforces, libpme, etc.
> The problem here is that neighoursearching can call the force routines
> etc., but somewhat more transparent coding could be advantageous for 
> new
> development as well... (Or a programmers manual? Brrr....)

I'm trying to make things more modular inside the library, but it is 
still nice
to only have to link with one or two libraries (with distinct 

While I don't think we can separate things 100% (for performance 
reasons), it
shouldn't be too difficult to make the dependencies clearer. One way of 
the neighborsearching from innerloops would be to create neighborlists 
for the long-range interactions. This actually makes sense since we 
avoid calling
the innerloop routines multiple times too. The only possible drawback 
is that it
takes more memory, but this isn't a problem on today's computers. (and 
since we
have PME it doesn't make sense to have huge cutoffs like 3-4 nm 

A programmers manual is coming, or at least I've started to document 
the innerloop
generation and created some graphics and first page for a hacker's 
manual :-)



More information about the gromacs.org_gmx-developers mailing list