Both the freeBSD packages and ports for gnuplot are crap. Normal installation yeilds the frustrating problem of not finding libpng even when supplied with the absolute pathname to libpng.

Unique temporary filenames in php. Similar function with set prefix.

The popup window bits have been twiddled correctly to allow a unique popup window for each sql statement.

Fixed the quote issue in the Where input by turning the magic_quote_gpc php config value off in a local .htaccess file.

The plain installs of gromacs and fftw should be good to go on bazaar and cairo. I want to look over the installations tomorrow to make sure everything is how it should be.

I'm currently installing lam mpi version 7.0.2 on bazaar and cairo. Scripts have been written to automate the process. They are in the bin directory of their respective clusters.

The installation is now done. It took a good amount of time to finish. The source is in clustername/src/lam-7.0.2/ of both clusters and the installations are in clustername/software/lam-7.0.2/ .

I worked a bit with excluding directories with CVS checkout this afternoon. According to the FAQ and forums, the cannonical way to do this is with an alias, but this does not make me happy. Still working on a work around.

I've updated the bazaar cluster testing methodology with information about the processor cores. A short paragraph on the cache invalidation program was also included.

I've just finished the cache invalidating program (/cluster/home/mccoyjo/cacheinv/cacheinv). Right now it malloc()s the amount of the l1 data cache plus the l2 cache then writes integers to the new memory. Then it rewrites to the new memory once every second and gets out of the way by sleep()ing. This would probably work better with SIGALRM and SIGKILL to improve granularity and to properly free() the memory when the program is stopped.

The normalization document is going well (75%). As I've had little time to work on it today, I'm hoping to get it done tomorrow before our meeting. Only if there were more hours in the day...

Bazaar -- 1cpu fftw with i386 hacks
Molecule	Average Time (minutes)	ps/day	gromacs.org benchmark (normalized)	%difference
d.villin	12.47	1151.7	1602	28.37
d.lzm-cut	82.7	346.3	455	23.89
d.lzm-pme	82.13	348.7	312	-11.76
d.dppc	565.1	25.49	31	17.77
d.poly-ch2	15.65	461.7	660	30.04

Following is the results from the gmxbench run on the bazaar cluster using one processor and profiling. Note that there was definite evidence of FFTW being used in the PME run of lzm, which makes sense considering you cannot run PME calculations without having FFTW installed. These results are consistently and considerably below those given at gromacs.org. The only deviation in the degree of lower performance is the results from d.lzm-pme, which comes rather close to making the benchmark when normalized.

Molecule	Average Time (minutes)	gprof Time (minutes)	Average ps/hour	Average ps/day	gromacs.org benchmarks on PIII-800	Benchmarks Normalized to PIII-550	Was FFTW used (looking at gprof results)?
d.villin	13.597	12.0	44.1	1058.4	2330	1602	No
d.lzm-cut	94.39	82.8	12.7	304.8	662	455	No
d.lzm.pme	94.47	85.5	12.7	304.8	455	312	Yes
d.dppc*	643.2	524.3	.928	22.3	45	31	No
d.poly-ch2	21.08	14.24	14.25	342	960	660	No

*d.dppc results were taken from only 5 runs.

• The d.villin test is finished. d.dppc will finish around 7am on Tuesday, July 22nd. The other tests (including the rerun of d.poly-ch2) will finish tonight.
• Removed FFTW libraries that were not needed.
• Configured, compiled, and installed a new set of FFTW libraries looking for better performance (added --enable-i386-hacks).

• I am going to run 10 or so runs of villin profiled and combine the results to mitigate statistical sampling of gprof. Profile enabled FFTW libraries have also been installed in /cluster/bazaar/software/fftw_single_with_mpi_p. Scripting the process now.
• Spending more time reading both papers and code in order to better understand mdrun. It is reluctant to relinquish its secrets.

• Installed GROMACS with gprof'ing enabled and ran a few test runs. The results are in /cluster/project and are interesting. Seems that nothing in FFTW was ever called.
• Still trying to pan out the details of GROMACS' innerloop in order to produce a figure. I'm not quite sure if I'll be able to produce a figure with excruciating detail, but the innerlooop will be well described.

• FFTW is only used in GROMACS in PPPM and PME operations. When MPI is used, GROMACS allows FFTW to perform the parallelization. Right now it seems that GROMACS and FFTW do not both parallelize at the same time.
• Tight assembly code using advanced multimedia instruction sets (SSE, 3dNow) comprise the inner loop. The highest level of the inner loop can be seen in src/gmxlib/mkinl.c and is simply a set of nested loops that run if the corresponding calculation is to be performed. No FFTW to be found here.
• Now that GROMACS is installed in at least one form, I plan doing a few runs tonight. We'll see how that goes.
• Revising my notes into prose is the task for this evening. I hope to have my part of the document done before tomorrow morning. The figures I have in my notes will be xfig'd tomorrow morning before the meeting.

• The inner loop of the program is created dynamically and is separate from FFTW. Finding out how the parallelism is split between GROMACS and FFTW is still quite a mystery, but I have some good leads.
• The ring structure of GROMACS parallelization using MPI is slowly and reluctantly revealing its details. What I know know is that the parallelization is used as much for relaying status information between nodes on the ring as it is for passing calculated values and data.
• GROMACS' parallelization is done before any of the inner loop is called. It is parallelized a high level in the MD program (nearly the top).

• I found some informative papers written on GROMACS in response to the need of better information about the program. The results were surprising in that they supplemented what I knew quite well. I'll be spending the next day or two reading the papers in order to get a more rounded view of what's going on.
• One of the papers verified what I have been suspecting for a while now: most of the computation done by GROMACS has nothing to do with FFTW. More digging is required on this, though

• Added a GROMACS tutorial to the software outline page.
• Determined that GROMACS is using ring structure in its usage of MPI.
• I am almost done looking at the interaction between MPI and GROMACS and have a good idea on how GROMACS runs without MPI. This task has turned out to be more difficult than anticipated because GROMACS uses a dynamic method of constructing the code for its innerloop (look at src/gmxlib/mkinl_*.c). This extra layer of abstraction is adding a large extra layer of confusion.
• Next on the slate is looking at GROMACS' use of FFTW with and without MPI.