I'd suggest to change the message to be more instructive in terms of what the user has to do, i.e. add a line along the lines of "Remove any caches before taking checkpoints" or similar. 

Great idea... I think it needs a little refinement though.

In some sense it might be preferable to have a warning rather than a fatal error, since it's not *generating* the checkpoint that's bad, it's *using* the checkpoint.  E.g., I can see someone doing a long simulation run to gather data and accidentally leaving checkpointing enabled, and they might be frustrated if their job dies when they had no intention of using the checkpoint.

I can see the objection that few people bother to read the warning messages though.

It might be nice if we could print a warning and then also do something to the checkpoint itself to make it unusable.  I don't know if just injecting a random string into the .ini file would make it unparseable or not.  Another possibility would be to actually create a valid checkpoint section for the cache, then add an unserialize() method that calls fatal() if it finds a corresponding checkpoint section.  That latter approach would only work if the cache config and names lined up between the checkpoint generating and using runs, though, so the former would be preferable IMO if it works.

And more trivially: it's a fatal() not a panic(), since it's a user error and not an unthinkable code path.