[gmx-users] What does it mean that particle decomposition does not support checkpointing?

[Andrew DeYoung]

Hi,

I am a Gromacs user (I'm running version 4.5.5).  I am not _at all_ an
experienced programmer, but I was looking through this redmine page about
"mdrun features to deprecate for 5.0":

http://redmine.gromacs.org/issues/1292

Near the top of that page (for issue #1292), it mentions particle
decomposition as a feature to deprecate for 5.0:

"1) Particle decomposition
Doesn't support checkpointing. Doesn't scale because it does not balance
load. Removing it will simplify a lot of conditionally executed code paths.
The main caveat is whether there are important algorithms whose
implementations still require it (see below)."

What does it mean that particle decomposition doesn't support checkpointing?

I use particle decomposition for my Gromacs simulations (in version 4.5.5),
and I also save checkpoints from mdrun every 15 minutes using the -cpo flag.
The resulting .cpt files seem to work fine -- at least "on the surface"; I
have not checked this in detail -- for doing a restart whenever my system
crashes.  

As a test, I took the final checkpoint file of a run.  Then, using the -t
flag in mdrun, I started a new simulation using that final checkpoint file.
After that new simulation finished, I used trjconv -dump 0 to dump the first
frame into a configuration file (in my case, a .g96 file).  I compared this
to the coordinates in the checkpoint file (as read by gmxdump -cp
checkpoint.cpt), and the coordinates in the dumped configuration and in the
checkpoint were the same up to the 0.00001 nm decimal place (since .g96
files and gmxdump output have different precision).  

So it seems that, at least in some ways, checkpointing is working even when
particle decomposition is used.  If so, then what does it mean in the above
redmine post that "particle decomposition doesn't support checkpointing"?
If not, why does my very quick, superficial check described in the previous
paragraph appear to be successful?

Thanks so very much for your time! 

Andrew DeYoung
Carnegie Mellon University