renamed snippets folder for lesson 01

_episodes/01-02-batch-systems-101.md

@@ -49,25 +49,25 @@ The cluster in question here, is running a scheduling software called {{ site.wo
 A first exercise would be to submit a job that does nothing else but print "Hello World!".
 
 ~~~
-{% include /snippets/02/submit_hello_world_to_void.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_hello_world_to_void.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
 ~~~
-{% include /snippets/02/output_hello_world_to_void.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/output_hello_world_to_void.{{ site.workshop_scheduler }} %}
 ~~~
 {: .output}
 
 
 That worked out pretty well. The problem is, it's not very helpful and doesn't help Lola or anyone to do her job. But Lola wonders if the job really was executed on another node. She thinks of a little experiment to explore the scheduler a bit. 
 
 ~~~
-{% include /snippets/02/submit_hostname_experiment.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_hostname_experiment.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
 ~~~
-{% include /snippets/02/output_hostname_experiment.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/output_hostname_experiment.{{ site.workshop_scheduler }} %}
 ~~~
 {: .output}
 
@@ -76,12 +76,12 @@ If she repeats this command, over and over again, the output changes. So these c
 Individual commands are fine, but Lola knows from experience that very often her work requires her to do more complex tasks, i.e. to execute a couple of commands after one another. To simulate this, she writes a small script that can be run on the node that runs her job.  
 
 ~~~
-{% include /snippets/02/submit_hostname_date.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_hostname_date.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
 ~~~
-{% include /snippets/02/output_hostname_date.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/output_hostname_date.{{ site.workshop_scheduler }} %}
 ~~~
 {: .output}
 
@@ -100,7 +100,7 @@ OK, but Lola wonders where the output of the job goes. Is there a way to reliabl
 
 
 ~~~
-{% include /snippets/02/submit_with_output_hostname_date.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_with_output_hostname_date.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
@@ -121,7 +121,7 @@ Tue Mar  7 11:14:11 CET 2017
 The scheduler allows Lola to split the two and write them to individual files. For example like this:
 
 ~~~
-{% include /snippets/02/submit_with_output_and_error_hostname_date.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_with_output_and_error_hostname_date.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 

_episodes/01-03-advanced-job-scheduling.md

@@ -20,19 +20,19 @@ keypoints:
 While submitting more tests jobs, Lola observes that she always mirrors the current directory for a log file to appear. This sometimes takes awhile and sometimes this happens almost instantly. How does she know, if a job is running or not?
 
 ~~~ 
-{% include /snippets/02/submit_hostname_date_sleep.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_hostname_date_sleep.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
 Now Lola tries one of the monitoring commands, the she discovered in the manpages of her scheduletc/bash_completioner:
 
 ~~~
-{% include /snippets/02/monitor_hostname_date_sleep.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/monitor_hostname_date_sleep.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
 ~~~
-{% include /snippets/02/output_monitor_hostname_date_sleep.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/output_monitor_hostname_date_sleep.{{ site.workshop_scheduler }} %}
 ~~~
 {: .output}
 
@@ -50,22 +50,22 @@ All of these information might appear pointless when submitting only one job at
 Lola is quite happy with her progress so far. All of a sudden, she detects a mistake in one of her scripts. 
 
 ~~~
-{% include /snippets/02/submit_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
 
 No, that shouldn't happen! She doesn't want to wait 5 minutes for the job to complete. So Lola would love to cancel this job. 
 
 ~~~
-{% include /snippets/02/find_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/find_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
 For this, she needs to find job ID of the job that she would like to stop. With this, she can ask the scheduler to cancel her job.
 
 ~~~
-{% include /snippets/02/kill_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/kill_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 
@@ -80,7 +80,7 @@ Right before lunch on that day, Lola notices that more and more staff members of
 The documentation indicates that she can provide an estimate of the _wall time_ of her job to the scheduler. 
 
 ~~~
-{% include /snippets/02/submit_walltime_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_walltime_hostname_date_sleep300.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash}
 

_episodes/01-04-shared-filesystem.md

@@ -21,7 +21,7 @@ After all these first attempts to make use of the cluster, Lola wonders about so
 Lola comes up with a small example job, that collects information on the node that the jobs is run on and submits it.
 
 ~~~
-{% include /snippets/02/submit_node_info.{{ site.workshop_scheduler }} %}
+{% include /snippets/01/submit_node_info.{{ site.workshop_scheduler }} %}
 ~~~
 {: .bash }