GitHub build 207

Author: actions-user

Connection_manager.html

@@ -99,10 +99,10 @@
 
   <section id="connection-manager">
 <span id="id1"></span><h1>Connection Manager<a class="headerlink" href="#connection-manager" title="Link to this heading"></a></h1>
-<p>To use a data transport layer in your simulator, the first thing you have to do it to call <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">DTL::create()</span></code> in
+<p>To use a data transport layer in your simulator, the first thing you have to do is to call <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">DTL::create()</span></code> in
 the <code class="docutils literal notranslate"><span class="pre">main</span></code> function of your code. This will trigger the creation of the <strong>DTLMod connection manager</strong> and an instance
 of a <a class="reference internal" href="app_API.html#concept-dtl"><span class="std std-ref">DTL</span></a> object.</p>
-<p>The connection manager is a <strong>daemon</strong> SimGrid actor (i.e., an simulated process running in the background and
+<p>The connection manager is a <strong>daemon</strong> SimGrid actor (i.e., a simulated process running in the background and
 automatically killed when the simulation ends) that runs on the first host declared in your platform description. This
 daemon actor takes the newly created <a class="reference internal" href="app_API.html#concept-dtl"><span class="std std-ref">DTL</span></a> object as argument.</p>
 <p>Once started, the connection manager creates two SimGrid message queues (i.e., a rendez-vous point between actors
@@ -118,7 +118,7 @@
 <p>Conversely, if it gets a <strong>disconnection request</strong>, meaning that an actor in your simulator called
 <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">DTL::disconnect()</span></code>, the connection manager checks whether this actor was still connected. If it was not, it
 advises you to check your code logic. Otherwise, the connection manager removes the actor from the list of the active
-connections, puts an acknowlegment to the disconnecting actor in the second message queue, and waits for the next
+connections, puts an acknowledgment to the disconnecting actor in the second message queue, and waits for the next
 request.</p>
 <p>Note that if during the execution of your simulator all your actors disconnect themselves from the DTL you will receive
 a harmless message warning you that there is <strong>no active connection</strong> at the moment. However, the connection manager

Engines.html

@@ -108,7 +108,7 @@
 <li><p><code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">close()</span></code></p></li>
 </ul>
 </div></blockquote>
-<p>However, this simple API hides more complex behaviors that depend on the engine type (i.e., File or Staging) and of
+<p>However, this simple API hides more complex behaviors that depend on the engine type (i.e., File or Staging) and on
 whether these functions are called on the publisher or subscriber side. In this section, we describe the internal
 behavior of the File and Staging engines.</p>
 </section>

Inside_File_engine.html

@@ -113,7 +113,7 @@
 mechanisms.</p>
 <section id="on-the-publisher-side">
 <h2>On the publisher side<a class="headerlink" href="#on-the-publisher-side" title="Link to this heading"></a></h2>
-<p>The first publisher to call to <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">begin_transaction()</span></code> marks that a new <a class="reference internal" href="app_API.html#concept-transaction"><span class="std std-ref">Transaction</span></a> is in progress
+<p>The first publisher to call <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">begin_transaction()</span></code> marks that a new <a class="reference internal" href="app_API.html#concept-transaction"><span class="std std-ref">Transaction</span></a> is in progress
 and increments an internal transaction counter. Then, from the second transaction using that File engine only, the
 publishers check whether the previous transaction is over. To this end, the publishers are blocked on a <strong>condition
 variable</strong>, until all the <strong>write activities</strong> from that transaction are completed. Once the publishers are unblocked,
@@ -124,7 +124,7 @@ <h2>On the publisher side<a class="headerlink" href="#on-the-publisher-side" tit
 the name of the <a class="reference internal" href="app_API.html#concept-stream"><span class="std std-ref">Stream</span></a>) to write them. With the <strong>default File transport method</strong>, each publisher
 creates and writes to a file called <code class="docutils literal notranslate"><span class="pre">data.i</span></code>, where <code class="docutils literal notranslate"><span class="pre">i</span></code> is the unique index of the publisher.</p>
 <p>The most important call is thus that to <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">end_transaction()</span></code> where the I/O activities are created and started.
-In this function, each publisher goes over all the write operation it registered during the different calls to the
+In this function, each publisher goes over all the write operations it registered during the different calls to the
 <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">put()</span></code> functions made in this transaction, and creates the corresponding simulated I/O activities by calling
 the <code class="docutils literal notranslate"><span class="pre">File::write_async()</span></code> function of the
 <a class="reference external" href="https://github.com/simgrid/file-system-module">FSMod file system module</a>. These calls are made in <strong>detached</strong> mode,
@@ -136,21 +136,21 @@ <h2>On the publisher side<a class="headerlink" href="#on-the-publisher-side" tit
 <p>The last action performed in <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">end_transaction()</span></code> is only done by the <strong>last publisher</strong> to call the function.
 This actor marks the <a class="reference internal" href="app_API.html#concept-transaction"><span class="std std-ref">Transaction</span></a> as over, increments an internal counter of completed transactions, and
 most importantly, notifies subscribers to that Stream that this transaction is complete. Note that the fact that a
-transaction is complete and the subscribers are notified does not mean that the corresponding I/O actictivites (i.e.,
+transaction is complete and the subscribers are notified does not mean that the corresponding I/O activities (i.e.,
 writing into files) are complete and that the subscribers can start reading the files to get Variables. However, it
-means that the publishers have all the publishers have determined what and where to write and that the subscribers are
+means that all the publishers have determined what and where to write and that the subscribers are
 allowed to use this information to create their I/O activities (i.e., reading from files) as explained in the
 <a class="reference internal" href="#file-sub-side"><span class="std std-ref">On the subscriber side</span></a> section.</p>
 <p>To determine which publisher is the last to call the <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">end_transaction()</span></code> function, DTLMod relies on a
-synchronization barrier for all the publishers using this Engine. This barrier is created in the very first to
+synchronization barrier for all the publishers using this Engine. This barrier is created on the very first call to
 <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">end_transaction()</span></code>.</p>
 <p>The last operation performed on the publisher side of a File Engine is to <strong>close</strong> the engine by calling the
-<code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">close()</span></code> function. The publishers first have to wait for the completion of the I/O activities strated by the
+<code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">close()</span></code> function. The publishers first have to wait for the completion of the I/O activities started by the
 last transaction performed on this engine, i.e., they are blocked on a condition variable and wait to be notified of
 the respective completion of these activities. Then the last publisher to call the <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">close()</span></code> function actually
 closes the Engine, as well as all the opened files on the simulated file system. Finally, if the
 <code class="xref cpp cpp-func docutils literal notranslate"><span class="pre">set_metadata_export()</span></code> function has been called for the <a class="reference internal" href="app_API.html#concept-stream"><span class="std std-ref">Stream</span></a> that created the Engine, this
-publisher export a summary of all the I/O operations performed during the lifetime of the Engine.</p>
+publisher exports a summary of all the I/O operations performed during the lifetime of the Engine.</p>
 </section>
 <section id="on-the-subscriber-side">
 <span id="file-sub-side"></span><h2>On the subscriber side<a class="headerlink" href="#on-the-subscriber-side" title="Link to this heading"></a></h2>

Inside_Staging_engine.html

@@ -110,7 +110,7 @@
 <li><p>When a publisher <strong>puts</strong> a variable into a stream, it asynchronously waits for data requests (using
 zero-simulated-cost message queues) from any subscriber that opened that stream;</p></li>
 <li><p>When a subscriber <strong>gets</strong> (a subset of) this variable from the stream, it computes which publishers own pieces
-of its local view of the variable and send them each a request to put the corresponding pieces, defined by offsets
+of its local view of the variable and sends them each a request to put the corresponding pieces, defined by offsets
 and element counts, in dedicated mailboxes (resp. message queues);</p></li>
 <li><p>When publishers end their transaction, they asynchronously put the requested pieces in these mailboxes (resp.
 message queues). DTLMod then simulates the corresponding data exchanges, and may possibly force actors to wait for

Installing_DTLMod.html

@@ -115,9 +115,9 @@
 <dl class="simple">
 <dt>C++ compiler</dt><dd><p>Install a version recent enough to support the C++17 standard.</p>
 </dd>
-<dt>Python 3</dt><dd><p>DTLMod should build without Python which is only needed by the regression tests of the python API.</p>
+<dt>Python 3</dt><dd><p>DTLMod should build without Python, which is only needed for the regression tests of the Python API.</p>
 </dd>
-<dt>cmake</dt><dd><p>The minimal recommended version is v3.12</p>
+<dt>cmake</dt><dd><p>The minimum recommended version is v3.12</p>
 </dd>
 <dt>boost mandatory components (at least v1.48)</dt><dd><ul class="simple">
 <li><p>On Debian / Ubuntu: <code class="docutils literal notranslate"><span class="pre">apt</span> <span class="pre">install</span> <span class="pre">libboost-dev</span></code></p></li>
@@ -151,7 +151,7 @@ <h3>Getting the source<a class="headerlink" href="#getting-the-source" title="Li
 <span class="gp">$ </span><span class="nb">cd</span><span class="w"> </span>..
 </pre></div>
 </div>
-<p>To benefit of the latest developments, get the current git version and recompile it as with stable archives.</p>
+<p>To benefit from the latest developments, get the current git version and recompile it as with stable archives.</p>
 <div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span>git<span class="w"> </span>clone<span class="w"> </span>https://github.com/simgrid/DTLMod.git
 <span class="gp">$ </span><span class="nb">cd</span><span class="w"> </span>DTLMod
 <span class="gp">$ </span>mkdir<span class="w"> </span>build
@@ -170,12 +170,12 @@ <h3>Testing your build<a class="headerlink" href="#testing-your-build" title="Li
 <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">unit_tests</span></code>. You can then run them with <code class="docutils literal notranslate"><span class="pre">./unit_tests</span></code>. Additionally, the Python API can also be tested as
 follows:</p>
 <div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span><span class="nb">cd</span><span class="w"> </span>test/python
-<span class="gp">$ </span>python<span class="w"> </span>unit_tests_python.pymkdir<span class="w"> </span>build
+<span class="gp">$ </span>python<span class="w"> </span>unit_tests_python.py
 <span class="gp">$ </span><span class="nb">cd</span><span class="w"> </span>-
 </pre></div>
 </div>
-<p>We run both test suites on every commit as part of a <strong>github action</strong> and the results can be found
-<a class="reference external" href="https://github.com/simgrid/DTLMod/actions">there</a>.</p>
+<p>We run both test suites on every commit as part of a <strong>GitHub Action</strong> and the results can be found
+<a class="reference external" href="https://github.com/simgrid/DTLMod/actions">here</a>.</p>
 </section>
 <section id="python-specific-instructions">
 <h3>Python-specific instructions<a class="headerlink" href="#python-specific-instructions" title="Link to this heading"></a></h3>

Introduction.html

@@ -106,9 +106,9 @@
 <span id="intro-concepts"></span><h1>Introduction<a class="headerlink" href="#introduction" title="Link to this heading"></a></h1>
 <section id="what-is-dtlmod">
 <h2>What is DTLMod<a class="headerlink" href="#what-is-dtlmod" title="Link to this heading"></a></h2>
-<p>A <strong>data transport layer</strong> can is the central component in a <strong>publish-subscribe system</strong>, that connects applications
-that produce data objects to those which consume them, moves these data objects, and keeps track of metadata.</p>
-<p>The figure below shows a generic data transport layer and introduces the terminology by DTLMod.</p>
+<p>A <strong>data transport layer</strong> is the central component in a <strong>publish-subscribe system</strong> that connects applications
+that produce data objects to those that consume them, moves these data objects, and keeps track of metadata.</p>
+<p>The figure below shows a generic data transport layer and introduces the terminology used by DTLMod.</p>
 <a class="reference internal image-reference" href="_images/DTL-overview.png"><img alt="_images/DTL-overview.png" class="align-center" src="_images/DTL-overview.png" style="width: 80%;" /></a>
 <br><br><p>On the publisher side, one or more applications (e.g., large-scale physics simulations) produce data, represented by
 multiple <strong>variables</strong>, and publish them to the DTL within a <strong>transaction</strong> using a specific <strong>stream</strong>. On the
@@ -134,7 +134,7 @@ <h2>What DTLMod allows you to do<a class="headerlink" href="#what-dtlmod-allows-
 <a class="reference external" href="https://simgrid.org/doc/latest/Tutorial_MPI_Applications.html">SMPI</a></p></li>
 <li><p><strong>Compare</strong> the behavior and performance, at scale, of different data transport configurations and study the
 effects of resource allocation strategies on performance.</p></li>
-<li><p><strong>Explore</strong> “what-if” scenarios in which you can scale of alter the performance your computing and storage
+<li><p><strong>Explore</strong> “what-if” scenarios in which you can scale or alter the performance of your computing and storage
 infrastructure, inject delays or failures, or modify the structure of your in situ workflow.</p></li>
 </ul>
 </dd>
@@ -148,7 +148,7 @@ <h2>Anatomy of a project that uses DTLMod<a class="headerlink" href="#anatomy-of
 <li><p>A set of <strong>processes</strong> that simulate the logic of each component of an in situ workflow using either the S4U API of
 SimGrid or as part of a full-fledged MPI parallel application, in combination with the API of DTLMod for everything
 related to data transport.</p></li>
-<li><p>A <strong>simulated computing and storage infrastructure</strong> which consists in a description (in either XML or C++) of the
+<li><p>A <strong>simulated computing and storage infrastructure</strong> which consists of a description (in either XML or C++) of the
 hardware (e.g., compute nodes, network links, disks) of this distributed system.</p></li>
 <li><p>A <strong>deployment</strong> of the defined processes. To simulate their execution on the simulated infrastructure, you have to
 describe how they are deployed on individual computing resources.</p></li>

Logging.html

@@ -209,7 +209,7 @@ <h2>Activating logging categories<a class="headerlink" href="#activating-logging
 we refer you to the
 <a class="reference external" href="https://simgrid.org/doc/latest/Configuring_SimGrid.html#format-configuration">SimGrid documentation</a>.</p>
 <p>Finally, <code class="docutils literal notranslate"><span class="pre">--log=no_loc</span></code> hides the source locations (file names and line numbers) from where the logs are produced.</p>
-<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span>./my_simulator<span class="w"> </span>--log<span class="o">=</span>mycat.threshold:debug<span class="w"> </span>--log<span class="o">=</span>mycat.fmt:%m<span class="w"> </span>--no-loc
+<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span>./my_simulator<span class="w"> </span>--log<span class="o">=</span>mycat.threshold:debug<span class="w"> </span>--log<span class="o">=</span>mycat.fmt:%m<span class="w"> </span>--log<span class="o">=</span>no_loc
 </pre></div>
 </div>
 <p>To configure and activate a logging category from your simulator code, use the following function (declared in

New_project.html

@@ -104,7 +104,7 @@
 <span id="start-new-project"></span><h1>Start a new project<a class="headerlink" href="#start-a-new-project" title="Link to this heading"></a></h1>
 <p>It is not advised to modify the source code of DTLMod directly, as it would make it difficult to upgrade to the next
 version of the library. Instead, you should create your own working directory somewhere on your disk (e.g.,
-<code class="docutils literal notranslate"><span class="pre">~home/MySimulator/</span></code>), and develop your simulate in there.</p>
+<code class="docutils literal notranslate"><span class="pre">~/MySimulator/</span></code>), and develop your simulator there.</p>
 <section id="building-your-project-with-cmake">
 <h2>Building your project with CMake<a class="headerlink" href="#building-your-project-with-cmake" title="Link to this heading"></a></h2>
 <p>Here follows a <code class="docutils literal notranslate"><span class="pre">CMakeLists.txt</span></code> file that you can use as a starting point for your DTLMod-based project. It builds a