[gmx-developers] General Gromacs Development and Related Issues

[aherz]

Mark Abraham wrote:
> 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...

Sure.
>
>> *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 learning to do :

tDynArray<type> list;
list+=item;
for(int i=0;i<list.GetItemCount();i++)
{
    list[i].something...
}

Shouldn't be very hard. If you want to use transforms and algorithms or
do anything that requires the user to write OOP or templated code then a
lot of learning will be required.

>
>> *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.
>
I guess a lot of ppl who are interested in working on the code have a
physics or chemist kinda background. Also, in my experience, most ppl
who did some java while studying CS or the like will not be able to
design a proper class hierarchy or do any changes that require bigger
modifications of the existing design. Merely using a set of existing
objects is not very hard indeed. Still I think, a lot of ppl who might
be interested in contributing to gromacs might be scared away. On the
other hand, it is hard enough to understand the code now so it might not
make much of a difference to go OOP. Until this is decided and maybe
implemented the small fixes I suggested might make maintaining the
current code base a bit easier.

>> *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?
well..tint comments and code as it's usually done in an ide and keep the
indentation and formating as supplied (currently some code sections
are broken up into several boxes). Basically make it easily recognizable
as a code snippet.
>
>> 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.

Thx, will try that.
>
>>  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
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the www
> interface or send it to gmx-developers-request at gromacs.org.


thx,
alex