new pages for global vs local scratch

Author: bdu-birhanu

docs/data_management/cheaha_storage_gpfs/global_scratch.md

@@ -1,24 +1,13 @@
-# Scratch Directories
+# Global/User Scratch
 
-Scratch directories provide temporary, high-performance storage for data used in active computations. There are two types of scratch space:
-
-- User Scratch: is available on login nod and also shared across compute nodes.
-- Local scratch: is available only on individual compute nodes.
-
-Scratch Directories are meant for short-term storage of intermediate or in progress data and should not be used for long-term retention.
+Global/User Scratch, also known as network scratch, provides temporary, high-performance storage for data used in active computations. It is available on login nodes and also shared across compute nodes, making it suitable for data that needs to be accessed during jobs running on multiple nodes. Each user has access to this directory at `/scratch/$USER` or `$USER_SCRATCH`. Use it directory to store very large datasets or temporary pipeline intermediates for a short period of time while running your jobs. The maximum amount of data a single user can store in network scratch is 100 TB at any given time.
 
 <!-- markdownlint-disable MD046 -->
 !!! important
 
     Starting January 2023, scratch data will have limited retention. See [Scratch Retention Policy](#policies-and-expectations) for more information.
 <!-- markdownlint-enable MD046 -->
 
-## User Scratch
-
-All users have access to a large, temporary, work-in-progress directory for storing data, called a scratch directory in `/scratch/$USER` or `$USER_SCRATCH`. Use this directory to store very large datasets or temporary pipeline intermediates for a short period of time while running your jobs. The maximum amount of data a single user can store in network scratch is 100 TB at once.
-
-Network scratch is available on the login node and each compute node. This storage is a GPFS high performance file system providing roughly 1 PB of storage. If using scratch, this should be your jobs' primary working directory, unless the job would benefit from local scratch (see below).
-
 <!-- markdownlint-disable MD046 -->
 !!! warning
 

docs/data_management/cheaha_storage_gpfs/index.md

@@ -2,8 +2,8 @@
 
 The Cheaha storage, also known as GPFS (General Parallel File System), is a distributed file system designed for managing dynamic data and serves as a storage solution on Cheaha. We provide the following Cheaha storage solutions.
 
-- [User Data and Home Directories](./individual_directories.md): These directories are automatically provided to every Cheaha user upon account creation. They are intended for storing important program files, scripts, small input datasets, critical results, and files you use often.
-- [Project Directories](./project_directories.md): A shared storage space for files related to a research team. Accessible from any login or compute node by group members. Use it to store scripts, datasets, results, and other files that need to be shared among collaborators. Project directories can be accessed via the path `/data/project/<alloaction-name>`.
+- [User Data and Home Directory](./individual_directories.md):These directories are automatically created for every Cheaha user upon account setup. They are intended for storing essential program files, scripts, small input datasets, critical results, and frequently used files.
+- [Project Directory](./project_directories.md): A shared storage space for files related to a research team. Accessible from any login or compute node by group members. Use it to store scripts, datasets, results, and other files that need to be shared among collaborators.
 - [Global Scratch](./global_scratch.md): A global scratch is a scratch space that is common to all compute nodes, and are available through `/scratch/<BlazerID>` path or `$USER_SCRATCH` environment variable on Cheaha.
 - [Local Scratch](./local_scratch.md): A local scratch is a temporary storage specific to the compute node your job runs on, and it can be accessed through `/scratch/local/$SLURM_JOB_ID` or via the `$LOCAL_SCRATCH` environment variable on Cheaha.
 - [Temporary Files (`/tmp/` Directory)](./temporary_files.md): This directory is provided for short-term file storage, and is local to each node, and it can be accessed via `/tmp` or `$TMPDIR` environment variable on Cheaha.

docs/data_management/cheaha_storage_gpfs/individual_directories.md

@@ -13,7 +13,7 @@ In contrast, the user data directory ($USER_DATA) is designed for storing:
 - Data and results specific to your individual research projects
 - Files accessible only to you
 
-Both $HOME and $USER_DATA have a quota limit of 5TB. For larger data or intensive workflows, consider using [scratch](./global_scratch.md) space and/or [project directories](./project_directories.md) for storing, moving, and analyzing data.
+The combined storage quota for $HOME and $USER_DATA is 5 TB. For larger data or intensive workflows, consider using [scratch](./global_scratch.md) space and/or [project directory](./project_directories.md) for storing, moving, and analyzing data.
 
 ## How Much Space Do I Have Left?
 

docs/data_management/cheaha_storage_gpfs/local_scratch.md

@@ -1,8 +1,8 @@
 # Local Scratch
 
-Each compute node has a local scratch directory that is accessible via `/local/`. We recommend creating a subdirectory `/local/$USER/` to simplify data management avoid confusing your files for those of others working on the same node. You can further separate data needed for different jobs you are running with the subdirectory `/local/$USER/$SLURM_JOB_ID`.
+Local scratch is temporary, high-speed storage located on individual compute nodes and accessible only on the node where a job runs, making it ideal for large intermediate files needed for single-node computations. Each compute node has a local scratch directory that is accessible via `/local/`. We recommend creating a subdirectory `/local/$USER/` to simplify data management avoid confusing your files for those of others working on the same node. You can further separate data needed for different jobs you are running with the subdirectory `/local/$USER/$SLURM_JOB_ID`.
 
-If your job performs a lot of file I/O, the job should use local scratch rather than `$USER_SCRATCH` to ensure adequate performance and avoid impacting other users. When using local scratch, file reading and writing stays on the node doing the processing, freeing up network resources for other tasks. It's important to recognize that most jobs run on the cluster do not fall under this category. However, any work that requires frequent disk access or high-bandwidth disk access are good candidates for using local scratch.
+If your job performs a lot of file I/O, the job should use local scratch rather than [global scratch](./global_scratch.md) to ensure adequate performance and avoid impacting other users. When using local scratch, file reading and writing stays on the node doing the processing, freeing up network resources for other tasks. It's important to recognize that most jobs run on the cluster do not fall under this category. However, any work that requires frequent disk access or high-bandwidth disk access are good candidates for using local scratch.
 
 At this time you will need to make local scratch subdirectories yourself with `mkdir -p /local/$USER` and `mkdir -p /local/$USER/$SLURM_JOB_ID`. Note that `$SLURM_JOB_ID` is only defined within a job context. If you need to keep files separated among jobs, use `/local/$USER/$SLURM_JOB_ID`. If you need to share files on one node among multiple jobs use `/local/$USER/` instead.
 
@@ -12,7 +12,7 @@ Some known examples of tasks benefiting from local scratch, not an exhaustive li
 - Large-scale genome annotation.
 - Reading/writing hundreds of thousands or more files in a single job.
 
-If you are using `amperenodes` and the A100 GPUs, then you should use local scratch for your data to ensure adequate GPU performance. Using `$USER_SCRATCH`, or other network file locations, will starve the GPU of data, resulting in poor GPU performance. For more information please see [Ensuring IO Performance With A100 GPUs](../../cheaha/slurm/gpu.md#ensuring-io-performance-with-a100-gpus).
+If you are using `amperenodes` and the A100 GPUs, then you should use local scratch for your data to ensure adequate GPU performance. Using global scratch, or other network file locations, will starve the GPU of data, resulting in poor GPU performance. For more information please see [Ensuring IO Performance With A100 GPUs](../../cheaha/slurm/gpu.md#ensuring-io-performance-with-a100-gpus).
 
 <!-- markdownlint-disable MD046 -->
 !!! important