doc: highlight restart with a different number of ranks

doc/rst/users/config.rst

@@ -278,6 +278,16 @@ and specify a flush type like :code:`PTHREAD`::
   SCR_FLUSH_ASYNC=1
   SCR_FLUSH_TYPE=PTHREAD
 
+Restart with a different number of processes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To restart an application with a different number of processes than used to save the checkpoint,
+one must follow the steps listed in :ref:`scr-integration-restart-without`.
+Additionally, one should set the following::
+
+  SCR_FLUSH_ON_RESTART=1
+  SCR_FETCH=0
+
 .. _sec-descriptors:
 
 Group, store, and checkpoint descriptors

doc/rst/users/integration.rst

@@ -505,6 +505,8 @@ Under this mode, SCR flushes any cached checkpoint to the prefix directory durin
 and it configures its restart operation to use cache bypass mode so that :code:`SCR_Route_file`
 directs the application to read its files directly from the parallel file system.
 
+.. _sec-integration-restart-without:
+
 Restart without SCR
 ^^^^^^^^^^^^^^^^^^^
 

doc/rst/users/overview.rst

@@ -407,9 +407,17 @@ If SCR attempts but fails to load a checkpoint, it prints an error and
 it will attempt to load the next most recent checkpoint if one is available.
 
 By default, SCR fetches the checkpoint into cache and applies a redundancy scheme.
-To disable the fetch operation, set the :code:`SCR_FETCH` parameter to 0.
-If the fetch is disabled, SCR directs the application to read its
-checkpoint files directly from the prefix directory.
+This is useful on systems where failures are likely,
+since SCR may be able to restart the application from the cached checkpoint
+if the application fails before it writes its next checkpoint.
+One can configure SCR to avoid copying the checkpoint to
+cache by setting the :code:`SCR_FETCH_BYPASS` parameter to 0.
+This may provide for faster restart when reading from the cache is slow.
+
+An application may elect not to use SCR for restart.
+In this case, one should set the :code:`SCR_FETCH` parameter to 0.
+If the fetch is disabled, the application is responsible for
+identifying and reading its checkpoint.
 
 To withstand catastrophic failures,
 it is necessary to write checkpoints out to the parallel file system with some moderate frequency.