rename snippets in episodes

Author: tkphd

_episodes/12-cluster.md

@@ -119,7 +119,7 @@ For example, we can view all of the worker nodes with the `{{ site.sched.info }}
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/12/info.snip %}
+{% include {{ site.snippets }}/12/queue-info.snip %}
 
 There are also specialized machines used for managing disk storage, user authentication, and other
 infrastructure-related tasks. Although we do not typically logon to or interact with these machines
@@ -197,7 +197,7 @@ the computer has been restarted.
 > {: .solution}
 {: .challenge}
 
-{% include {{ site.snippets }}/12/explore.snip %}
+{% include {{ site.snippets }}/12/specific-node-info.snip %}
 
 > ## Compare Your Computer, the Head Node and the Worker Node
 >

_episodes/13-scheduler.md

@@ -98,7 +98,7 @@ to the scheduler, we use the `{{ site.sched.submit.name }}` command.
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/13/submit_output.snip %}
+{% include {{ site.snippets }}/13/basic-job-script.snip %}
 
 And that's all we need to do to submit a job. Our work is done -- now the scheduler takes over and
 tries to run the job for us. While the job is waiting to run, it goes into a list of jobs called 
@@ -110,7 +110,7 @@ the *queue*. To check on our job's status, we check the queue using the command
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/13/statu_output.snip %}
+{% include {{ site.snippets }}/13/basic-job-status.snip %}
 
 The best way to check our job's status is with `{{ site.sched.status }}`. Of course, running 
 `{{ site.sched.status }}` repeatedly to check on things can be a little tiresome. To see a real-time
@@ -179,7 +179,7 @@ and monitor it:
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/13/statu_name_output.snip %}
+{% include {{ site.snippets }}/13/job-with-name-status.snip %}
 
 Fantastic, we've successfully changed the name of our job!
 
@@ -202,7 +202,7 @@ stuck with your site's default resources, which is probably not what you want.
 
 The following are several key resource requests:
 
-{% include {{ site.snippets }}/13/stat_options.snip %}
+{% include {{ site.snippets }}/13/option-flags-list.snip %}
 
 Note that just *requesting* these resources does not make your job run faster! We'll talk more 
 about how to make sure that you're using resources effectively in a later episode of this lesson.
@@ -238,7 +238,7 @@ about how to make sure that you're using resources effectively in a later episod
 > {: .solution}
 {: .challenge}
 
-{% include {{ site.snippets }}/13/env_challenge.snip %}
+{% include {{ site.snippets }}/13/print-sched-variables.snip %}
 
 Resource requests are typically binding. If you exceed them, your job will be killed. Let's use
 walltime as an example. We will request 30 seconds of walltime, and attempt to run a job for two
@@ -269,9 +269,9 @@ Submit the job and wait for it to finish. Once it is has finished, check the log
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/13/long_job_cat.snip %}
+{% include {{ site.snippets }}/13/runtime-exceeded-job.snip %}
 
-{% include {{ site.snippets }}/13/long_job_err.snip %}
+{% include {{ site.snippets }}/13/runtime-exceeded-output.snip %}
 
 Our job was killed for exceeding the amount of resources it requested. Although this appears harsh,
 this is actually a feature. Strict adherence to resource requests allows the scheduler to find the
@@ -294,7 +294,7 @@ to change the walltime so that it runs long enough for you to cancel it before i
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/13/del_job_output1.snip %}
+{% include {{ site.snippets }}/13/terminate-job-begin.snip %}
 
 Now cancel the job with its job number (printed in your terminal). A clean return of your command
 prompt indicates that the request to cancel the job was successful.
@@ -306,9 +306,9 @@ prompt indicates that the request to cancel the job was successful.
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/13/del_job_output2.snip %}
+{% include {{ site.snippets }}/13/terminate-job-cancel.snip %}
 
-{% include {{ site.snippets }}/13/del_multiple_challenge.snip %}
+{% include {{ site.snippets }}/13/terminate-multiple-jobs.snip %}
 
 ## Other types of jobs
 
@@ -321,4 +321,4 @@ handle. A good example of this might be building a genome index for alignment wi
 [HISAT2](https://ccb.jhu.edu/software/hisat2/index.shtml). Fortunately, we can run these types of
 tasks as a one-off with `{{ site.sched.interactive }}`.
 
-{% include {{ site.snippets }}/13/interactive_example.snip %}
+{% include {{ site.snippets }}/13/using-nodes-interactively.snip %}

_episodes/14-modules.md

@@ -85,7 +85,7 @@ To see available software modules, use `module avail`
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/14/module_avail.snip %}
+{% include {{ site.snippets }}/14/available-modules.snip %}
 
 ## Loading and unloading software
 
@@ -102,13 +102,13 @@ so we can use it to tell us where a particular piece of software is stored.
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/14/which_missing.snip %}
+{% include {{ site.snippets }}/14/missing-python.snip %}
 
 We can load the `python3` command with `module load`:
 
-{% include {{ site.snippets }}/14/load_python.snip %}
+{% include {{ site.snippets }}/14/module-load-python.snip %}
 
-{% include {{ site.snippets }}/14/which_python.snip %}
+{% include {{ site.snippets }}/14/python-executable-dir.snip %}
 
 So, what just happened?
 
@@ -123,21 +123,21 @@ variables we can print it out using `echo`.
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/14/path.snip %}
+{% include {{ site.snippets }}/14/python-module-path.snip %}
 
 You'll notice a similarity to the output of the `which` command. In this case, there's only one
 difference: the different directory at the beginning. When we ran the `module load` command,
 it added a directory to the beginning of our `$PATH`. Let's examine what's there:
 
-{% include {{ site.snippets }}/14/ls_dir.snip %}
+{% include {{ site.snippets }}/14/python-ls-dir-command.snip %}
 
-{% include {{ site.snippets }}/14/ls_dir_output.snip %}
+{% include {{ site.snippets }}/14/python-ls-dir-output.snip %}
 
 Taking this to its conclusion, `module load` will add software to your `$PATH`. It "loads"
 software. A special note on this - depending on which version of the `module` program that is
 installed at your site, `module load` will also load required software dependencies.
 
-{% include {{ site.snippets }}/14/depend_demo.snip %}
+{% include {{ site.snippets }}/14/software-dependencies.snip %}
 
 ## Software versioning
 
@@ -154,9 +154,9 @@ Let's examine the output of `module avail` more closely.
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/14/module_avail.snip %}
+{% include {{ site.snippets }}/14/available-modules.snip %}
 
-{% include {{ site.snippets }}/14/gcc_example.snip %}
+{% include {{ site.snippets }}/14/wrong-gcc-version.snip %}
 
 > ## Using software modules in scripts
 >

_episodes/16-resources.md

@@ -99,7 +99,7 @@ get statistics about our job.
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/16/stat_output.snip %}
+{% include {{ site.snippets }}/16/account-history.snip %}
 
 This shows all the jobs we ran recently (note that there are multiple entries per job). To get
 info about a specific job, we change command slightly.
@@ -162,7 +162,7 @@ like the following (`Ctrl + c` to exit):
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/16/top_output.snip %}
+{% include {{ site.snippets }}/16/monitor-processes-top.snip %}
 
 Overview of the most important fields:
 
@@ -190,7 +190,7 @@ memory.
 ```
 {: .bash}
 
-{% include {{ site.snippets }}/16/free_output.snip %}
+{% include {{ site.snippets }}/16/system-memory-free.snip %}
 
 The key fields here are total, used, and available - which represent the amount of memory that the
 machine has in total, how much is currently being used, and how much is still available. When a