> I am curious why AMBER does not use MPI-IO routines for writing
> trajectory/restart data? The only reason I can imagine would be in regards
> to the padding issues with unformatted fortran files and portability. Is
> this it? A detailed explanation would be great to settle my curiosity.
...I am sure Bob or other's will chime in here, but it is question of
speed vs. complexity. To justify extra complexity, you have to first show
that I/O is limiting performance (or scaling efficiency) and that the more
complex I/O scheme overcomes this. If you only write every 1-5 ps, at low
processor counts, I/O is certainly not limiting. Writing every 0.1 ps - 1
ps can become limiting at higher processor counts (64 PEs and up) and
certainly will become an issue as we move to the next generation of
petascale machines and/or if you routinely run off NSF mounted disks
and/or if you run a really large system. We do worry about I/O
performance which is why you often see some of the AMBER folk running
benchmarks that actually write data at intervals that match (or more often
than) what people routinely use for production. Also, if I/O is currently
limiting, try out the NetCDF trajectory format as this is often less
compute intensive.
On the complexity front, AMBER supports runs without MPI and also supports
many flavors of MPI (which may or may not fully support MPI-IO). Also,
the solution does not have to involve MPI-IO; it can be more generic and
involve using local nodes (or sets of nodes or extra nodes different from
the computational nodes) outputing partial data to local resources, i.e.
avoiding the concept of the master doing all the I/O to take advantage of
fast/local disk, with post-processing to merge. The extra complexity
means that the scheme has to make sure the local resources are
persistent/available, etc. Although we may have to worry about this issue
"soon", there are bigger and more rate limiting problems that need to be
tackled first, such as improving the FFT/reciprocal scaling and load
balancing, etc., not to mention incorporating more features into PMEMD and
sander...
-- tom
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Jun 13 2007 - 06:07:24 PDT
