Hello folks!
I am working hard on high-scaling pmemd code, and in the course of the work
it became clear to me, due to large async i/o buffer and other issues, that
going to very high atom counts may require a bunch of extra work, especially
on certain platforms (BG/L in particular...). I posed the question below to
Dave Case; he suggested I bounce it off the list, so here it is. The crux
of the matter is how people feel about having an MD capability in pmemd for
systems bigger than 999,999 atoms in the next release. Please respond to
the dev list if you have strong feelings in either direction.
Thanks much! - Bob
----- Original Message -----
From: "Robert Duke" <rduke.email.unc.edu>
To: "David A. Case" <case.scripps.edu>
Sent: Tuesday, December 04, 2007 8:45 AM
Subject: How many atoms?
> Hi Dave,
> Just thought I would pulse you about how strong the desire is to go above
> 1,000,000 atom systems in the next release. I personally see this as more
> an advertising issue than real science; it's hard to get good
> statistics/good science on 100,000 atoms let alone 10,000,000 atoms.
> However, we do have competition. So the prmtop is not an issue, but the
> inpcrd format is, and one thing that could be done is to move to
> supporting the same type of flexible format in the inpcrd as we do in the
> new-style prmtop. Tom D. has an inpcrd format in amoeba that would
> probably do the trick; I can easily read this in pmemd but not yet write
> it (I actually have pulled the code out - left it in the amoeba version
> of course, but can put it back in as needed). I ask the question now
> because I am hitting size issues already on BG/L on something like
> cellulose. Some of this I can fix; some of it really is more
> appropriately fixed by running on 64 bit memory systems where there
> actually is a multi-GB physical memory. The problem is particularly bad
> with some new code I am developing, due to extensive async i/o and
> requirements for buffers that at least theoretically could be pretty big
> (up to natom possible; by spending a couple of days writing really
> complicated code I can actually handle this in small amounts of space with
> effectively no performance impact - but it is the sort of thing that will
> be touchy and require additional testing). Anyway, I do want to gauge the
> desire to move up past 999,999 atoms, and make the point that on something
> like BG/L, it would actually require a lot more work to be able to run
> multi-million atom problems (basically got to go back and look at all the
> allocations, make them dense rather than sparse by doing all indexing
> through lists, allow for adaptive minimal i/o buffers, etc. etc. - messy
> stuff, some of it sourcing from having to allocate lots of arrays
> dimensioned by natom).
> Best Regards - Bob
Received on Wed Dec 05 2007 - 06:07:30 PST
