[gmx-developers] New analysis library?
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
>> 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
>> analysis tools, etc.
> Sounds good.
> How about organizing stuff in four directories
> Obviously the distinction is not always clear. Should e.g. trjconv be
> 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
> development as well... (Or a programmers manual? Brrr....)
I'm trying to make things more modular inside the library, but it is
to only have to link with one or two libraries (with distinct
While I don't think we can separate things 100% (for performance
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
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
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
generation and created some graphics and first page for a hacker's
More information about the gromacs.org_gmx-developers