[gmx-developers] New analysis library?

[Erik Lindahl]

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

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

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 
separating
the neighborsearching from innerloops would be to create neighborlists 
even
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 
anymore).

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 :-)

Cheers,

Erik