[gmx-developers] parallelization

[David van der Spoel]

On Thu, 10 Jan 2002, Erik Lindahl wrote:

>I've been thinking about how to document stuff for quite a while too.
>One of our main problems isn't the documentation, though, but the
>very dirty and cross-dependent architecture of the source,partly due
>to the fortran heritage. My only concern is that we should stick to tools
>with a GPL license, or at least completely free ones.
Hmpf! There is no fortran heritage... But parts of grompp date back
to 1989 when I was first learning C (by programming MD with integrated
graphics on my 286).

>I think our best bet is to separate this into two task:
>
>1. Change the architecture of the code and make a nice & well-documented
>   layout for the future. This takes time, but I've started doing it.
>2. Document the code we have now, with the aim of making it more useable
>   rather than rewriting things.
Actually the documentation thingie just came up on slashdot, and people
were quite positive about doxygen. It is GPL as well and generates HTML or
Latex.

>I can give you access to the normal gromacs website so you can implement
>it there - of course you can also keep a local copy, but I think it's a
>good idea to have all our web material in one main gromacs.org site, so we
>can move it just by tarring the entire tree or even mirror the entire
>site. I'll send you the access stuff.
Let's keep everything in one place, but let Justin mirror it anyway.
There's probably automated software to do that somewhere on the net. The
whole thing is quite small, but it is nice to have a backup of the
ftp archive etc. as well as a mirror in north america.

>I've started to design modules, beginning with core things like
>neighborlists, neighborsearching and force calculation. We will stick to
>C (rather than C++), but still use the type of module interface common
>in object-oriented languages. Each functionality (like e.g.
>neighborsearching or the pull code) should ideally have one source file
>(or a couple if they are VERY large) and one header file with the 
>EXTERNAL DECLARATIONS ONLY - very well documented. Each such module should
>only depend on a well defined small set of submodules.
>An important lesson in this context is that it often pays to duplicate
>code; rather than having a complicated general routine to calculate simple
>things like center-of-mass it might be better to have a simple routine
>internally in a module - that way you avoid unnecessary dependencies.
Sounds good. Let's divide the work and do it.

>PS: Justin - In case you're interested there are now Monte-Carlo versions
>(no force calculation=faster) of all inner loops in CVS, including the
>assembly (SSE & 3DNow) and altivec ones. I'll also be adding SSE2 support
>(double precision) the next days, and then David & I will try to get 3.1
>out as a maintenance release.
>
>Do you have any idea of a general MC integrator?
And do you (Justin) want to implement and test it?


Groeten, David.
________________________________________________________________________
Dr. David van der Spoel, 	Biomedical center, Dept. of Biochemistry
Husargatan 3, Box 576,  	75123 Uppsala, Sweden
phone:	46 18 471 4205		fax: 46 18 511 755
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://zorn.bmc.uu.se/~spoel
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++