[gmx-developers] General Gromacs Development and Related Issues

[Mark Abraham]

herz wrote:
> Hi Guys,
> 
> After having worked with the code and the wiki for a while I wanted to
> point out a few problems and suggestions that might make life a bit
> easier while not requiring too much work...
> 
> I'd suggest:
> 
> *allow loading and saving of structs (currently only lists of ints/reals
>  etc are supported)

I presume you mean to/from .tpr files...

> *use a library that supports dynamic arrays (so new more srenew)
>  maybe using C++ and a template aware impl (STL or so) would be nice;
>  a lot of (error prone) code is simply used to realloc data structures

I agree that moving away from C-style self-managed data structures is a 
good thing, however there is a learning curve associated with the use of 
such libraries (templated or not). I think the learning curve is 
worthwhile. With STL, much of the time one *can* do old-style looping 
over STL dynamic arrays with overloaded [] operators and such like, or 
one can use more powerful constructs that can sometimes illustrate the 
intent of the algorithm better by hiding the implementation cruft.

> *the data structures for the topology etc are a bit confusing
>  (especially with the large amount of int arrays where it's hard to figure
>  out what they contain). it would be nice to collect together all the
>  things that belong together in some descriptive structs (so all atom
>  type data like lj params, mass etc are in one place/struct). I
>  understand that the runtime data structures (like mdatoms) need a
>  different layout to be efficient with SSE assembly but the only reason I
>  can see that the non runtime structures are spread out so much is that
>  it is currently not possible to save and load structs to and from the
>  tpr file.
> 
> *I would no go so far as to suggest moving everything to OOP (I'd only
>  use some pre made things like the dynamic array) because most
>  inexperienced programmers shy away from OOP and feel a lot more at home
>  with plain C.

In my opinion, that depends not so much on their experience of 
programming, but where they acquired that experience. Anybody coming 
through a university computer science course in the last decade (or 
more) has experience of OOP. A self-taught computational chemist hacker 
would probably only be happy with the punch cards they first learned how 
to use :-P (Or maybe FORTRAN20...) Oddly, I'm a programmer with no 
formal training who's much happier with OOP complexity than spending his 
life segfaulting while (mis-)managing C data structures.

> *Eventually, the data structure "documentation" I created in the wiki
>  should probably be merged into a doxygen type documentation embedded
>  into the code

Indeed.

> *I cannot watch my wiki edits because email verification doesn't work (I never get any veryfication email)

True. http://wiki.gromacs.org/index.php/Special:Recentchanges is linked 
from the front page, which can be useful to see what has been going on 
lately.

> *Joining the different mailing lists is not working properly, I mostly end up receiving 
>  all mails twice or not at all

Works fine for me - has done for years.

> *It would be nice if the <code></code> tag inside the wiki was used to format tint the contained code
>  block

That should be possible. It does actually change the background colour 
and font at the moment. What did you have in mind?

> Finally a few questions:
> 
> *What is the recommented way to add/remove source files from the makefiles?
> 
>  I'm having massive problems with this. It seams editing the Makefile.am files triggers automake
>  which in turn messes up my configure script completely (build fails afterwards because libtool   
>  doesn't recognize the --mode=compile switch).
>  Currently I can work only with the Makefile.am comeing with the original tar.gz. 
>  I'm running the latest versions of automake (1.10) and the rest of em (libtool,autoconf etc).

So when you've edited a Makefile.am, run automake yourself in the 
top-level directory by hand (or use the bootstrap script described here 
http://wiki.gromacs.org/index.php/Compiling_CVS), then configure however 
you want to, and you should be fine.

The behaviour you observe above is actually a good thing - if someone 
edits Makefile.am then various dependencies should get observed and the 
whole tree should rebuild itself. It seems that the re-configure isn't 
working properly (but you haven't described it well enough for me to be 
sure). If so, it's probably not worth fixing, since there is the above 
work-around.

>  I saw on the gromacs homepage somewhere that there is a "special version" of automake for gromacs?
>  It wasn't accessable without a password.

IIRC there's a version supplied somewhere, but it's not some custom-made 
thing.

>  So currently I cannot even copy the source from one folder to another (this apparently triggers    automake somehow) without breaking my build.

Updating timestamps triggers Makefile actions in the normal way.

>  There is some rather sparse info in the wiki but it would be nice to have a guide on how to add/remove files from the project and how to rebuild the configure script properly.

As above, I think editing any Makefile.am files, doing your relevant 
operations, then running automake and configure should lead to no problems.

Mark