Typos fix

Author: dieriver

docs/AppsArch.rst

@@ -25,14 +25,14 @@ When Alice needs to run a *local* quantum operation, it needs follow the process
 #. The QNodeOS layer receives the NetQASM subroutine, parses it and executes the quantum operations.
 #. To execute the quantum operations, the QNodeOS layer communicates with the Virtual Node layer, which is in charge
    of the final simulation of the quantum hardware.
-#. The execution is done using SimulaQron's *native interface*, transforming the QNodeOS server as a translation layer
+#. The execution is done using SimulaQron's *native interface*. This makes the QNodeOS server a translation layer
    between NetQASM and SimulaQron's native interface.
 
 In a scenario where more than one node is involved, it is required that the simulated quantum hardware to communicate
 with other node's quantum hardware (for example, to create EPR pairs). This is done at Virtual Node level; each Virtual
-Node instance keeps an open communication channel with its neighbours, so it can send signals and information to
-"remote" nodes. Additionally, this open communication channel is also required due to SimulaQron's distributed simulation
-nature. In this case, the general architecture can be seen in the following figure.
+Node instance keeps an open communication channel with its Virtual Node neighbours, so it can send signals and
+information to "remote" nodes. Additionally, this open communication channel is also required due to SimulaQron's
+distributed simulation nature. In this case, the general architecture can be seen in the following figure.
 
 .. image:: figs/general-arch-2-nodes.png
     :width: 700px
@@ -44,9 +44,10 @@ Backend Processes Interactions
 ------------------------------
 
 As explained in the previous section, SimulaQron requires a *backend* to be running when you are using quantum operations.
-Ths is done using the ``simulaqron`` CLI tool (in particular, the ``simulaqron start`` subcommand).
+The SimulaQron backend can be started by using the ``simulaqron`` CLI tool - in particular, the ``simulaqron start``
+subcommand.
 
-The ``simulaqron start`` subcommand makes the CLI tool to act as a *driver* whose only task is to spawn the backend
+The ``simulaqron start`` subcommand makes the CLI tool act as a *driver* whose only task is to spawn the backend
 processes. SimulaQron uses *2 backend processes per node*:
 
 * QNodeOS process: A server process that implements :doc:`the NetQASM Interface <NetQASM>`. The main purpose of this
@@ -65,7 +66,7 @@ the settings files are present in the current folder):
 The startup of the backend perform the following operations:
 
 #. The CLI tool (``simulaqron``) is invoked with the ``start`` subcommand. In this sense, the CLI tool becomes
-   the driver of the whole simulaqron network backend.
+   the driver of the whole SimulaQron network backend.
 #. The driver spawns the *virtual node* process for both Alice and Bob, and then it sleeps for a while to allow them
    to correctly initialize.
 #. When spawned, the virtual node processes setup the internals, and create a connection to *all* the quantum nodes
@@ -80,8 +81,8 @@ The startup of the backend perform the following operations:
    processes. This is needed since the QNodeOS processes will later send messages to the Virtual Node processes to
    execute the quantum operations contained in a NetQASM subroutine. Please note that QNodeOS processes *only* connect
    to their respective Virtual Node (Alice QNodeOS connect to and only to Alice Virtual Node process), so quantum
-   operations that will require update a qubit hosted by Alice will trigger a message between Virtual Nodes (i.e. the
-   underlying Virtual Node connection is transparent for QNodeOS processes).
+   operations that will require update a qubit hosted by a remote node will trigger a message between Virtual Nodes
+   (i.e. the underlying Virtual Node connection is transparent for QNodeOS processes).
 #. Once that each QNodeOS process is connected to their Virtual Node, they start listening to connections from the
    application layer.
 #. At this stage, the driver and all the spawned processes become daemons, and simply wait for activities in their
@@ -109,19 +110,18 @@ When the application process performs quantum operations, this is how they get e
    required argument (EPR Sockets, for example). By creating this object, the application process creates a TCP
    connection with the respective QNodeOS process.
 #. The application uses the ``connection`` object to create qubits, and apply quantum operations on the qubits.
-#. The application process *buffers* (stage) all these operations locally. This means that the quantum operations *are
-   not executed* immediately.
+#. The application process automatically *buffers* (stages) all these operations locally. This means that the
+   quantum operations *are not executed* immediately.
 #. At some point, the application process invokes ``connection.flush()`` method, signaling the NetQASM library to
    commit all the staged operations and send them for execution. To this end, the NetQASM library crates a *NetQASM
    subroutine* which contains all the staged operations. The subroutine is then serialized, and sent over the TCP
    connection to the QNodeOS process.
-#. After this, the NetQASM subroutine get deserialized in the QNodeOS process. This step allows the QNodeOS process
-   to understand all the involved operations.
+#. Once the QNodeOS process receives the NetQASM subroutine, the NetQASM subroutine get deserialized in the QNodeOS
+   process. This step allows the QNodeOS process to understand all the involved operations.
 #. For each quantum operation, the QNodeOS process proceeds with its execution. This step involves invoking the right
    remote calls on the Virtual Node process. Subsequentially (and due to SimulaQron distributed nature), executing one
    quantum operation might trigger executing other operation on remote quantum nodes. This makes the "local" Virtual
    Node process (the one that is executing the subroutine) to trigger other remote calls on remote nodes.
 #. Once that all the quantum operations have been executed, the QNodeOS process determines the execution result of the
    whole subroutine, and report it back to the application layer.
-#. With this result, the application process continues execuing the application program.
-
+#. With this result, the application process continues executing the application program.

docs/Troubleshooting.rst

@@ -1,7 +1,7 @@
 Troubleshooting SimulaQron
 ==========================
 
-This document aims to help you troubleshooting some situations that can arise while running simulaqron applications.
+This document aims to help you troubleshooting some situations that can arise while running SimulaQron applications.
 This documents assumes that you have read the :doc:`SimulaQron Overview <Overview>` and
 :doc:`SimulaQron Application Architecture <AppsArch>` before you proceed.
 
@@ -15,11 +15,11 @@ cannot be changed.
 
 Under this folder you will find:
 
-* *Driver log file*: Each time that you invoke que driver (``simulaqron start``), the driver will create a general log.
-  This file will be called ``simulaqron-driver-<pid>.log``, where "``<pid>``" is a number corresponding to the process
+* *Driver log file*: Each time that you invoke the driver (``simulaqron start``), it will create a general log. This
+  file will be called ``simulaqron-driver-<pid>.log``, where "``<pid>``" is a number corresponding to the process
   ID as reported by the OS.
 * *SimulaQron's QNodeOS and Virtual Node log files*: Once that the backend is running, the spawned QNodeOS and Virtual
-  Node processes will create a logs file named ``simulaqron-<qnos/vnode>-<node_name>-<pid>.log``. From the file name
+  Node processes will create logs file named ``simulaqron-<qnos/vnode>-<node_name>-<pid>.log``. From the file name
   you'll be able to identify if the log file corresponds to QNodeOS or Virtual Node process, the node name, and the
   process ID as reported by the OS.
 
@@ -31,7 +31,7 @@ How can I increase/decrease the verbosity of the log files?
 -----------------------------------------------------------
 
 By default, the log verbosity level is set to "warning". This means that the information shown in the logs only
-contains lines that are logged with severity "warning" or higher. YOu can increase the verbosity to see more debugging
+contains lines that are logged with severity "warning" or higher. You can increase the verbosity to see more debugging
 messages. To do so, edit your ``simulaqron_config.json`` file and change the "log_level" line from::
 
     "log_level": 30,
@@ -46,21 +46,21 @@ valid values of the log level that you can use in this field.
 
 .. warning:: **Do not forget** to change the log level back to the default value (30) **before** submitting your solution.
 
-After changing the log configuration, stop your application, stop SimulaQron backend, start SimulaQron backend and then
-start your application again.
+After changing the log configuration, stop your application, stop SimulaQron backend, and then start SimulaQron backend
+and your application again.
 
 
 How can I "follow" the log files on real time?
 ----------------------------------------------
 
-Unix systems (Linux and macOS) embed the ``tail`` tool that allows you to follow a file as it grows. This is useful to
-print a log file on the terminal, and keep "listening to" new updates as they are written on the file. To do so, run
+Unix systems (Linux and macOS) embed the ``tail`` tool that allows you to follow a text file as it grows. This is useful
+to print a log file on the terminal, and keep "listening to" new updates as they are written on the file. To do so, run
 the following command on a separate terminal::
 
     tail -f /my/log/file.log
 
 Adjust the ``/my/log/file.log`` path to match the file you want to follow on real time. This command will print on the
-terminal the last 10 lines of the file, and the will keep waiting for new lines to arrive. As soon as they arrive, they
+terminal the last 10 lines of the file, and it will keep waiting for new lines to arrive. As soon as they arrive, they
 will also be printed don the terminal.
 
 
@@ -73,27 +73,27 @@ This can happen for multiple reasons. We will try to address a few of them here.
 Another instance of the backend is still running
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The most common scenario arises when you are trying to run the application layer using a backend from "another version".
-This can happen when you update the port numbers in the ``simulaqron_networks.json`` file and you did not restart the
-backend after that.
+The most common scenario arises when you are trying to run the application layer using a backend from "another version"
+(or even another application). This can happen when you update the port numbers in the ``simulaqron_networks.json``
+file and you did not restart the backend after that.
 
-In this case try restarting simulaqron backend by running::
+In this case try restarting SimulaQron backend by running::
 
     simulaqron stop
 
-and then running the ``simulaqron start`` command as per the example or step of the lab you are currently following.
+and then run the ``simulaqron start`` command as per the example or step of the lab you are currently following.
 
-If after this the error persist, check the code of the application (usually alice and/or bob) and make sure that these
-file load the same ``simulaqron_settings.json`` and ``simulaqron_config.json`` files as the ```simulaqron start``
-command.
+If after this the error persist, check the code of the application (usually alice and/or bob implementations) and
+make sure that these file load the same ``simulaqron_settings.json`` and ``simulaqron_config.json`` files as the
+ones passed to the ``simulaqron start`` command.
 
 .. _exception-in-backend:
 
 Exceptions on the backend
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 When running the backend, the spawned processes are daemonized, meaning that if an exception happens there, it is not
-possible to see that on the terminal. When an exception happened in the backend, some of the TCP ports used to execute
+possible to see that on the terminal. When an exception happens in the backend, some of the TCP ports used to execute
 quantum operations are not properly open, and your application might be waiting for a connection or message that will
 never arrive.
 
@@ -107,16 +107,17 @@ more clues about what is happening.
 Protocol not implemented properly
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Another usual scenario where your application looks stalled is because of error when implementing classical messages
+Another usual scenario where your application looks stalled is because of errors when implementing classical messages
 interchange. In some cases, your client or server side application is waiting for the arrival of a message. Once it
 arrived, it reads the characters from the classical socket, and check if it the expected message or not.
 
 In this case, make sure that you properly check the expected string, and raise and exception or fail the execution if
-something unexpected happen. To this last end, you can use python asserts to aid you in that::
+something unexpected happen. In this last case, you can use python asserts to aid you in that::
 
     assert message == "expected"
 
-The line above will make whole program fail if ``message`` is not exactly the string ``expected``.
+The line above will make whole program fail if the variable ``message`` does not contain the exact the string
+``expected``.
 
 .. caution:: Killing a single process might leave some other processes (application nodes) still running in the
    background. This might lead to scenarios where subsequent execution might fail with connection errors. To fully
@@ -169,17 +170,17 @@ in their command line.
 In the example above, it is important to identify some information. The ``PID`` and ``COMMAND`` columns are the most
 important ones. We will use them to identify which processes can be terminated:
 
-* Processes that contain ``simulaqron start`` in their commandline, they are *SimulaQron backend-related processes*.
+* Processes that contain ``simulaqron start`` in their command line, they are *SimulaQron backend-related processes*.
 * Processes that are simply ``python myTest.py`` *are usually SimulaQron application processes*. Try to remember
   if you manually started these processes (or via the ``run.sh`` script) to correctly identify it.
-* All other processes on the list *are usually system processes*. **These processes need to left untouched**.
+* All other processes on the list *are usually system processes*. **These processes need to be left untouched**.
 
-Once that you have identified that you have some leftover processes from old executions, you can try two ways to stop
-these processes:
+Once that you have identified the processes that you want to terminate (usually leftover processes from old executions),
+you can try two ways to stop these processes:
 
 * Run ``simulaqron reset processes``. As explained in the :ref:`starting backend section <starting-backend>`, this
-  command can be used to forcefully stop any backend-related processes. If you run this command and run get the list
-  of python processes, you'll see that some of them are not there anymore::
+  command can be used to forcefully stop any backend-related processes. If you run this command and later run
+  ``ps aux | awk 'NR==1 || /python/'`` to get the list of python processes, you'll see that some of them disappear::
 
     $ simulaqron reset processes
     Are you sure you want to forcefully stop all the `simulaqron` processes? [y/N]: y
@@ -212,7 +213,8 @@ these processes:
     root        1723  0.0  0.0 114868 23364 ?        Ssl  08:15   0:00 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
     user       12561  0.0  0.0  11764  2360 pts/1    S+   11:26   0:00 awk NR==1 || /python/
 
-  You can see that we were able to kill the leftover SimulaQron application process (``python bobTest.py``).
+  You can see that we were able to kill the leftover SimulaQron application process (``python bobTest.py``), but also
+  the processes from the SimulaQron backend.
 
 .. note:: When running ``kill``, if you get errors like "kill: (<PID>) - No such process", you can safely ignore them.
    This error means that you specified a PID that was not valid. Recheck the process list ans try again.
@@ -223,7 +225,7 @@ How can I check if a port is taken or not?
 ------------------------------------------
 
 First of all, a running system is dynamic, so there's no guarantee that a port available now will still be available
-in 5 minutes more. Despite this, if you pick a port number (ranging from :math:`1` to :math:`65535`) cleverly enough,
+in in the future. Despite this, if you pick a port number (which range from :math:`1` to :math:`65535`) cleverly enough,
 it will most likely be available whenever you need it.
 
 In Linux, port numbers under :math:`1000` need sudo permissions to be used, so we highly recommend *not* to use them.
@@ -341,13 +343,13 @@ After installing this, try creating your virtual environment again.
 error: command 'x86_64-linux-gnu-g++' failed: No such file or directory
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This usually happens when installing simulaqron using pip *with the optional dependencies* (i.e.
+This usually happens when installing SimulaQron using pip *with the optional dependencies* (i.e.
 ``pip install "simulaqron[opt]"``), on a machine that does not have a C++ compiler. Please make sure that you install
 all the requirements by running::
 
     $ sudo apt-get install build-essential cmake vim git linux-headers-generic
 
-Then try to install simulaqron with the optional dependencies again.
+Then try to install SimulaQron with the optional dependencies again.
 
 
 macOS-specific errors
@@ -357,7 +359,7 @@ macOS-specific errors
 error: command 'x86_64-linux-gnu-g++' failed: No such file or directory
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This usually happens when installing simulaqron using pip *with the optional dependencies* (i.e.
+This usually happens when installing SimulaQron using pip *with the optional dependencies* (i.e.
 ``pip install "simulaqron[opt]"``), on a machine that does not have a C++ compiler. Please make sure that you install
 all the requirements by running::
 
@@ -381,13 +383,13 @@ On macOS, brew should install the development dependencies. You can always try t
 
     % brew reinstall python@3.12
 
-After this, try installing simulaqron again.
+After this, try installing SimulaQron again.
 
 
 'Compiler' object has no attribute 'dry_run'
 """"""""""""""""""""""""""""""""""""""""""""
 
-This error arises when trying to install simulaqron with the optional dependencies. One of them is
+This error arises when trying to install SimulaQron with the optional dependencies. One of them is
 `ProjectQ <https://projectq.ch/>`_, which is a rather old software, written in C++. Considering this, ProjectQ
 *needs to be compiled by pip* before installing it. Since ProjectQ is an old software, it relies on compilation
 tools that nowadays are not part of the pip compilation toolchain.
@@ -399,7 +401,7 @@ not create an isolated environment for compiling ProjectQ::
     $ pip install "git+https://github.com/ProjectQ-Framework/ProjectQ.git@v0.8.0" --no-build-isolation
 
 *On macOS systems*, we have also observed this error when compiling `QuTip <http://qutip.org/>`_. In this case, you
-can also instruct pip to compile Qutip with the older toolchain::
+can also instruct pip to compile Qutip and ProjectQ with the older toolchain::
 
     % pip install "setuptools<81" pybind11 Cython
     % pip install "git+https://github.com/ProjectQ-Framework/ProjectQ.git@v0.8.0" --no-build-isolation
@@ -414,4 +416,4 @@ can also instruct pip to compile Qutip with the older toolchain::
     **In macOS, these packages are compiled only for macOS 26 (Tahoe)**. Additionally, they require installing "libomp"
     from homebrew: ``brew install libomp``.
 
-Then you can try to install simulaqron with optional dependencies again.
+Then you can try to install SimulaQron with optional dependencies again.