Correct some typos in workflows exercise

day-3/exercise-1-workflows.rst

@@ -305,7 +305,7 @@ Snakemake is written in python and also its syntax is basically a python dialect
            input: "lower1.txt"
 
 
-In snakemake rules are specified by the keyword ``rule`` followed by the rule name. Snakemake follows the indentantion style of python. You are not allowed to mix different styles (spaces and tabs) to indent line. Rules in snakemake have different directives such as ``input:``, ``output:`` and ``shell:``.  ``input:`` and ``output:`` require one or more files which will be used by the rule as input and output. The ``shell`` directive is where the code we would like to execute is located. We can also access our input and output inside the ``shell`` part of the rule with curly brackets ``{}``. In snakemake rules can be connected by the output of other rules (similar to ``GNU make``) directly through the rules object: ``rules.combine.output``. In practice this is a nice feature because the connection between the rules will stay intact even if you change the name of the output file in the combine rule.
+In snakemake rules are specified by the keyword ``rule`` followed by the rule name. Snakemake follows the indentation style of python. You are not allowed to mix different styles (spaces and tabs) to indent line. Rules in snakemake have different directives such as ``input:``, ``output:`` and ``shell:``.  ``input:`` and ``output:`` require one or more files which will be used by the rule as input and output. The ``shell`` directive is where the code we would like to execute is located. We can also access our input and output inside the ``shell`` part of the rule with curly brackets ``{}``. In snakemake rules can be connected by the output of other rules (similar to ``GNU make``) directly through the rules object: ``rules.combine.output``. In practice this is a nice feature because the connection between the rules will stay intact even if you change the name of the output file in the combine rule.
 
 Similar to GNU make we can have an ``all`` rule. As you can see, the ``all`` rules does not have an output. It only requires the ``lower1.txt`` file as ``input``.
 
@@ -419,7 +419,7 @@ First, let us see how our workflow looks when we extend it to use wildcards. The
    rule all:
            input: expand("lower{number}.txt", number=mynumbers)
 
-What has changed? The first line now contains a python list with all the values our wildcard can have. In this case ``1`` and ``2``. The inputs and output of the rules has changed as well: We need to somehow let snakemake now where the values of the wildcard need to be filled in. In this case the wildcard value is a part of the input directory name or the name of the output files. The name of the wildcard is ``{number}``. This uses the same *placeholder* syntax with ``{}`` as we have seen earlier.
+What has changed? The first line now contains a python list with all the values our wildcard can have. In this case ``1`` and ``2``. The inputs and output of the rules has changed as well: We need to somehow let snakemake know where the values of the wildcard need to be filled in. In this case the wildcard value is a part of the input directory name or the name of the output files. The name of the wildcard is ``{number}``. This uses the same *placeholder* syntax with ``{}`` as we have seen earlier.
 
 .. hint::
 
@@ -519,7 +519,7 @@ This does not automatically mean that the rule runs faster. It just means that s
 Nextflow
 --------
 
-Another, slightly different Workflow manager is `Nextflow <https://nextflow.io/>`_. It follows a slightly different paradigm than make and Snakemake and it uses a different terminology. Rules are called *processes* and different processes communicate through so-called *channels*. A *channel* is similar to a pipe in the Linux shell, but there is a bit more to it. If you are interested, you can look `here <https://www.nextflow.io/docs/latest/channel.html>`_ to learn more. One big difference to make and snakemake is that in Nextflow input and output of different *processes* do not necessarily have to be files. Rather, values can be passed between processes without writing intermediate results to files. This can be very nice to reduce the number of files but it can also make it more complicated if you are not familiar with piping. To make this nextflow example easier to compare with the same implementation in make and snakemake, we will create outputfiles for all intermediate steps. Nextflow is based on Java mainly using the `Apache Groovy <https://en.wikipedia.org/wiki/Apache_Groovy>`_ super-set. We are no experts with Nextflow, however we wanted to show you how it looks in case it is a system that you would like to pursue further. Here is how our workflow looks like:
+Another, slightly different workflow manager is `Nextflow <https://nextflow.io/>`_. It follows a slightly different paradigm than make and Snakemake and it uses a different terminology. Rules are called *processes* and different processes communicate through so-called *channels*. A *channel* is similar to a pipe in the Linux shell, but there is a bit more to it. If you are interested, you can look `here <https://www.nextflow.io/docs/latest/channel.html>`_ to learn more. One big difference to make and snakemake is that in Nextflow input and output of different *processes* do not necessarily have to be files. Rather, values can be passed between processes without writing intermediate results to files. This can be very nice to reduce the number of files but it can also make it more complicated if you are not familiar with piping. To make this nextflow example easier to compare with the same implementation in make and snakemake, we will create outputfiles for all intermediate steps. Nextflow is based on Java mainly using the `Apache Groovy <https://en.wikipedia.org/wiki/Apache_Groovy>`_ super-set. We are no experts with Nextflow, however we wanted to show you how it looks in case it is a system that you would like to pursue further. Here is how our workflow looks like:
 
 
 .. code-block:: bash
@@ -556,7 +556,7 @@ As you can see the syntax is a bit different to what we have seen so far. Let's
 
 The bash code inside the ``shell`` parts of the processes is almost the same to what we have seen. The only difference is that we need to escape values of bash variables with ``\$variable`` because Nextflow also uses the ``$`` sign to access its own variables.
 
-Differently to other managers we also have a directive called ``workflow``. You can think of this as the `all` rule in make or Snakemake. The difference to these rules is that in the Nextflow equivalent we have to specify how the workflow should be executed. As you can see we can use pipes ``|`` to connect different processes. This is used to connect the output of one channel with the input of the next one. 
+Differently to other workflow managers we also have a directive called ``workflow``. You can think of this as the `all` rule in make or Snakemake. The difference to these rules is that in the Nextflow equivalent we have to specify how the workflow should be executed. As you can see we can use pipes ``|`` to connect different processes. This is used to connect the output of one channel with the input of the next one. 
 
 .. admonition:: Exercise