From 87dfce723b8e916a41e3173f26c1897dbeb7889e Mon Sep 17 00:00:00 2001
From: Joeri Exelmans <joeri.exelmans@gmail.com>
Date: Sun, 15 Dec 2024 13:13:15 +0100
Subject: [PATCH] add TIPS + fix HTML

---
 assignment/doc/assignment.html | 33 +++++++++++++++++----------------
 1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/assignment/doc/assignment.html b/assignment/doc/assignment.html
index 5beaded..1aa013d 100644
--- a/assignment/doc/assignment.html
+++ b/assignment/doc/assignment.html
@@ -1,9 +1,5 @@
 <dtml-var simple_html_header>
 
-<html>
-<head><title>DEVS Assignment</title></head>
-<body>
-
 <h2 id="practical-stuff">Practical stuff</h2>
 <ul>
   <li> <b>Due Date:</b> Sunday 5 January 2025, before 23:59 (Blackboard's clock).</li>
@@ -101,15 +97,15 @@
     <li>Lock
       <ul>
         <li><b>capacity (int)</b>: Capacity of the lock. E.g., 3 or 2.</li>
-        <li><b>passthrough_duration (float)</b>: Time duration (in seconds) of the &quot;passthrough&quot;-procedure. This procedure conceptually involves closing the lock doors, changing the water level, and opening the lock doors on the other side, and the ships leaving the lock. In our simulation, it is only an amount of time during which the lock has zero remaining capacity, after which the ships are sent to the sink. For simplicity, there is no time delay between sending the ships to the sink, and the lock becoming available again (at original capacity).
+        <li><b>passthrough_duration (float)</b>: Time duration (in seconds) of the &quot;passthrough&quot;-procedure. This procedure conceptually involves closing the lock doors, changing the water level, and opening the lock doors on the other side, and the ships leaving the lock. In our simulation, it is only an amount of time during which the lock has zero remaining capacity, after which the ships are sent to the sink.
+          <p>For simplicity, there is no time delay between sending the ships to the sink, and the lock becoming available again (at original capacity).</p>
         <li><b>max_wait_duration (float)</b>: When a lock is completely filled up (zero remaining capacity), the &quot;passthrough&quot;-procedure starts immediately. The procedure may also start if the lock is non-empty, and a certain amount of time has passed since the <em>first</em> ship has entered the lock. This parameter is that amount of time.
         </li>
       </ul>
     </li>
   </ul>
 
-The specification of the semantics of the Atomic DEVS blocks is entirely deterministic. If you implement everything correctly, the system as-a-whole will behave 100% identical to the teacher's solution.
-</p>
+<p>The specification of the semantics of the Atomic DEVS blocks is entirely deterministic. If you implement everything correctly, the system as-a-whole will behave 100% identical to the teacher's solution.</p>
 
 <h3>Coupled DEVS</h3>
 <p>The system as a whole is modeled as a Coupled DEVS block. Its parameters are mostly passed as-is to the underlying Atomic DEVS blocks. They are:
@@ -140,6 +136,7 @@ The specification of the semantics of the Atomic DEVS blocks is entirely determi
   <li>Think of the interfaces of these blocks (input/output ports and their events) and the protocol spoken by them.</li>
   <li>Finally, in the CoupledDEVS block representing the entire system, you will have to make the right connections (which of course depends on the input/output ports that you have defined in your AtomicDEVS).</li>
 </ul>
+<p>An indication of the complexity: my own solution of the AtomicDEVS blocks is about 300 lines of code (including comments).</p>
 
 <h2 id="goal">Goal: Performance Analysis</h2>
 <p>Once you have implemented the system, we will do performance analysis, comparing combinations of the following parameter values:</p>
@@ -203,7 +200,7 @@ The specification of the semantics of the Atomic DEVS blocks is entirely determi
       <li>intTransition</li>
     </ul>
 
-    <p>This reflects the order in which the methods are called by the simulator:</p>
+    This reflects the order in which the methods are called by the simulator:
     <ul>
       <li>extTransition always has highest priority (can interrupt anything)</li>
       <li>timeAdvance is called before outputFnc</li>
@@ -213,21 +210,25 @@ The specification of the semantics of the Atomic DEVS blocks is entirely determi
   <li>Input/output port attributes start with 'in_' and 'out_'</li>
 </ul>
 
+<h2>Tips</h2>
+<ul>
+  <li>Test/debug your integrated solution with only one ship (set <b>num_ships</b> parameter to 1).</li>
+  <li>To observe the changing State in the PyPDVES debug output, write <tt>__repr__</tt>-methods for your State-classes.</li>
+</ul>
+
 <h2>Troubleshooting</h2>
 
 <p>Common mistakes include:
-<ul>
-  <li>did you forget to return <tt>self.state</tt> from intTransition or extTransition ?</li>
-  <li>did you accidentally write to <tt>self.x</tt> instead of <tt>self.state.x</tt> ?</li>
-  <li>did you modify the state in timeAdvance or outputFnc ? (<a href="#attention">NOT ALLOWED!!</a>)</li>
-</ul>
+  <ul>
+    <li>did you forget to return <tt>self.state</tt> from intTransition or extTransition ?</li>
+    <li>did you accidentally write to <tt>self.x</tt> instead of <tt>self.state.x</tt> ?</li>
+    <li>did you modify the state in timeAdvance or outputFnc ? (<a href="#attention">NOT ALLOWED!!</a>)</li>
+  </ul>
+</p>
 
 <h2>Extra Material</h2>
 <ul>
   <li>This assignment was inspired by the <a href="https://msdl.uantwerpen.be/git/jexelmans/joeriPDEVS/src/mosis24/examples/queueing">queueuing example</a>.</li>
 </ul>
 
-</body>
-</html>
-
 <dtml-var standard_html_footer>
\ No newline at end of file
