diff --git a/Latex/abstract.tex b/Latex/abstract.tex
index 57cf6e67e6482d72b873d553317a9e570b04da78..de257937871291592078c3fdeb9319db141993d9 100644
--- a/Latex/abstract.tex
+++ b/Latex/abstract.tex
@@ -1,3 +1,2 @@
\section{Abstract}\raggedbottom
-Maximizing photosynthetic outcomes is one of many different objectives of a plant. In this thesis we present and evaluate a method to predict an optimal venation pattern for leafs based on the minimal number of leaf cells that have to be transformed into vein cells to supply the entire leaf with nutrients and water. The model only focuses on the number of cells and disregards other aspects of the vascular system, like the vein hierarchy. To implement this model we used a special variant of the Minimum Dominating Set Problem which we implemented using Integer Linear Programming. We call this variant to model the vascular system the Minimum Connected rooted $k$-hop Dominating Set Problem. Our results show that our implementation is not capable of solving larger instances in a reasonable amount of time. In comparison to an implementation in Answer Set Programming our implementation performs worse using the instances that represent plant leafs. We present a detailed comparison between both versions and tested instances of different structure and size. We analyzed why the Integer Linear Programming implementation performs bad on the leaf graphs. The tests also revealed that on randomly generated graphs the Integer Linear Programming implementation outperformed the Answer Set Programming implementation.
-\pagebreak
+Maximizing photosynthetic outcome is one of many different objectives of a plant. In this thesis we present and evaluate a method to predict an optimal venation pattern for leafs based on the minimal number of leaf cells that have to be transformed into vein cells to supply the entire leaf with nutrients and water. The model only focuses on the number of cells and disregards other aspects of the vascular system, like the vein hierarchy. To implement this model we use a special variant of the Minimum Dominating Set Problem which we implemented using Integer Linear Programming. We call this variant to model the vascular system the Minimum Connected rooted $k$-hop Dominating Set Problem. Our results show that our implementation is not capable of solving larger instances in a reasonable amount of time. In comparison to an implementation in Answer Set Programming our implementation performs worse using the instances that represent plant leafs. We present a detailed comparison between both versions and tested instances of different structure and size. We analyzed why the Integer Linear Programming implementation performs bad on the leaf graphs. The tests also reveal that on randomly generated graphs the Integer Linear Programming implementation outperformes the
\ No newline at end of file
diff --git a/Latex/acknowledgement.tex b/Latex/acknowledgement.tex
new file mode 100644
index 0000000000000000000000000000000000000000..b97aeee15bae9634c83c6f251d78415c037c9ba2
--- /dev/null
+++ b/Latex/acknowledgement.tex
@@ -0,0 +1,2 @@
+\section{Acknowledgement}
+I would like to express my gratitude to Prof. Gunnar Klau for giving me the opportunity to write this bachelor thesis and for his support and feedback. I would also like to thank Eline van Mantgem for her invaluable advice and support during the weekly meetings. Finally I would like to thank Sven Schrinner and Philipp Spohr for their extensive feedback that they gave me shortly before the deadline.
\ No newline at end of file
diff --git a/Latex/anhang.tex b/Latex/anhang.tex
index fb904ceedbf06661bc2936ccccd59358c6f98ad2..87b664fc206b74211d4cb11f5de9001e476788fe 100644
--- a/Latex/anhang.tex
+++ b/Latex/anhang.tex
@@ -2,12 +2,12 @@
\appendix
\section{Appendix}
-\subsection*{Full Tables} \label{anhang:zusatz1}
+\subsection*{Full Tables} \label{appendix:tables}
\subsubsection*{ILP}
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
GNM\_ 50\_ 122 & 1 & 66 & 0.034878 & 11\\
GNM\_ 50\_ 245 & 1 & 9 & 0.07 & 7\\
@@ -56,48 +56,48 @@
\begin{table}[H]
\centering
\begin{tabular}{l cccccccccccc}
- name & k & \# lazily added constraints & optimal & runtime(s)\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
- GNM\_ 50\_ 122 & 2 & 67 & 11 & 0.03795\\
- GNM\_ 50\_ 245 & 2 & 9 & 7 & 0.066219\\
- GNM\_ 50\_ 368 & 2 & 0 & 1 & 0.008017\\
- GNM\_ 50\_ 490 & 2 & 0 & 1 & 0.002605\\
- GNM\_ 50\_ 612 & 2 & 0 & 1 & 0.002223\\
- GNM\_ 50\_ 735 & 2 & 0 & 1 & 0.002411\\
- GNM\_ 50\_ 858 & 2 & 0 & 1 & 0.002486\\
- GNM\_ 50\_ 980 & 2 & 0 & 1 & 0.002173\\
- GNM\_ 50\_ 1102 & 2 & 0 & 1 & 0.012025\\
- GNM\_ 50\_ 1225 & 2 & 0 & 1 & 0.001756\\
- GNM\_ 100\_ 495 & 2 & 6 & 4 & 0.108993\\
- GNM\_ 100\_ 990 & 2 & 12 & 2 & 0.060489\\
- GNM\_ 100\_ 1485 & 2 & 0 & 1 & 0.022559\\
- GNM\_ 100\_ 1980 & 2 & 0 & 1 & 0.004219\\
- GNM\_ 100\_ 2475 & 2 & 0 & 1 & 0.004791\\
- GNM\_ 100\_ 2970 & 2 & 0 & 1 & 0.044863\\
- GNM\_ 100\_ 3465 & 2 & 0 & 1 & 0.004259\\
- GNM\_ 100\_ 3960 & 2 & 0 & 1 & 0.004273\\
- GNM\_ 100\_ 4455 & 2 & 0 & 1 & 0.003927\\
- GNM\_ 100\_ 4950 & 2 & 0 & 1 & 0.003468\\
- GNM\_ 250\_ 3112 & 2 & 0 & 2 & 0.270981\\
- GNM\_ 250\_ 6225 & 2 & 28 & 1 & 0.101028\\
- GNM\_ 250\_ 9338 & 2 & 0 & 1 & 0.17136\\
- GNM\_ 250\_ 12450 & 2 & 0 & 1 & 0.031756\\
- GNM\_ 250\_ 15562 & 2 & 109 & 1 & 0.257635\\
- GNM\_ 250\_ 18675 & 2 & 0 & 1 & 0.035879\\
- GNM\_ 250\_ 21788 & 2 & 0 & 1 & 0.030358\\
- GNM\_ 250\_ 24900 & 2 & 0 & 1 & 0.024402\\
- GNM\_ 250\_ 28012 & 2 & 0 & 1 & 0.018999\\
- GNM\_ 250\_ 31125 & 2 & 0 & 1 & 0.016561\\
- GNM\_ 500\_ 12475 & 2 & 0 & 2 & 1.123904\\
- GNM\_ 500\_ 24950 & 2 & 0 & 1 & 0.663096\\
- GNM\_ 500\_ 37425 & 2 & 0 & 1 & 0.228299\\
- GNM\_ 500\_ 49900 & 2 & 0 & 1 & 0.272308\\
- GNM\_ 500\_ 62375 & 2 & 0 & 1 & 0.29011\\
- GNM\_ 500\_ 74850 & 2 & 0 & 1 & 0.249534\\
- GNM\_ 500\_ 87325 & 2 & 0 & 1 & 0.250321\\
- GNM\_ 500\_ 99800 & 2 & 0 & 1 & 0.170296\\
- GNM\_ 500\_ 112275 & 2 & 0 & 1 & 0.148031\\
- GNM\_ 500\_ 124750 & 2 & 0 & 1 & 0.119448\\
+ GNM\_ 50\_ 122 & 2 & 67 & 0.03795 & 11\\
+ GNM\_ 50\_ 245 & 2 & 9 & 0.066219 & 7\\
+ GNM\_ 50\_ 368 & 2 & 0 & 0.008017 & 1\\
+ GNM\_ 50\_ 490 & 2 & 0 & 0.002605 & 1\\
+ GNM\_ 50\_ 612 & 2 & 0 & 0.002223 & 1\\
+ GNM\_ 50\_ 735 & 2 & 0 & 0.002411 & 1\\
+ GNM\_ 50\_ 858 & 2 & 0 & 0.002486 & 1\\
+ GNM\_ 50\_ 980 & 2 & 0 & 0.002173 & 1\\
+ GNM\_ 50\_ 1102 & 2 & 0 & 0.012025 & 1\\
+ GNM\_ 50\_ 1225 & 2 & 0 & 0.001756 & 1\\
+ GNM\_ 100\_ 495 & 2 & 6 & 0.108993 & 4\\
+ GNM\_ 100\_ 990 & 2 & 12 & 0.060489 & 2\\
+ GNM\_ 100\_ 1485 & 2 & 0 & 0.022559 & 1\\
+ GNM\_ 100\_ 1980 & 2 & 0 & 0.004219 & 1\\
+ GNM\_ 100\_ 2475 & 2 & 0 & 0.004791 & 1\\
+ GNM\_ 100\_ 2970 & 2 & 0 & 0.044863 & 1\\
+ GNM\_ 100\_ 3465 & 2 & 0 & 0.004259 & 1\\
+ GNM\_ 100\_ 3960 & 2 & 0 & 0.004273 & 1\\
+ GNM\_ 100\_ 4455 & 2 & 0 & 0.003927 & 1\\
+ GNM\_ 100\_ 4950 & 2 & 0 & 0.003468 & 1\\
+ GNM\_ 250\_ 3112 & 2 & 0 & 0.270981 & 2\\
+ GNM\_ 250\_ 6225 & 2 & 28 & 0.101028 & 1\\
+ GNM\_ 250\_ 9338 & 2 & 0 & 0.17136 & 1\\
+ GNM\_ 250\_ 12450 & 2 & 0 & 0.031756 & 1\\
+ GNM\_ 250\_ 15562 & 2 & 109 & 0.257635 & 1\\
+ GNM\_ 250\_ 18675 & 2 & 0 & 0.035879 & 1\\
+ GNM\_ 250\_ 21788 & 2 & 0 & 0.030358 & 1\\
+ GNM\_ 250\_ 24900 & 2 & 0 & 0.024402 & 1\\
+ GNM\_ 250\_ 28012 & 2 & 0 & 0.018999 & 1\\
+ GNM\_ 250\_ 31125 & 2 & 0 & 0.016561 & 1\\
+ GNM\_ 500\_ 12475 & 2 & 0 & 1.123904 & 2\\
+ GNM\_ 500\_ 24950 & 2 & 0 & 0.663096 & 1\\
+ GNM\_ 500\_ 37425 & 2 & 0 & 0.228299 & 1\\
+ GNM\_ 500\_ 49900 & 2 & 0 & 0.272308 & 1\\
+ GNM\_ 500\_ 62375 & 2 & 0 & 0.29011 & 1\\
+ GNM\_ 500\_ 74850 & 2 & 0 & 0.249534 & 1\\
+ GNM\_ 500\_ 87325 & 2 & 0 & 0.250321 & 1\\
+ GNM\_ 500\_ 99800 & 2 & 0 & 0.170296 & 1\\
+ GNM\_ 500\_ 112275 & 2 & 0 & 0.148031 & 1\\
+ GNM\_ 500\_ 124750 & 2 & 0 & 0.119448 & 1\\
\end{tabular}
\caption[Minimum Connected rooted $2$-hop Dominating Set Results on the random graphs]{Minimum Connected rooted $2$-hop Dominating Set Results on the random graphs}
\end{table}
@@ -105,48 +105,48 @@
\begin{table}[H]
\centering
\begin{tabular}{l cccccccccccc}
- name & k & \# lazily added constraints & optimal & runtime(s)\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
- GNM\_ 50\_ 122 & 3 & 0 & 2 & 0.01651\\
- GNM\_ 50\_ 245 & 3 & 0 & 1 & 0.005787\\
- GNM\_ 50\_ 368 & 3 & 0 & 1 & 0.007788\\
- GNM\_ 50\_ 490 & 3 & 0 & 1 & 0.002089\\
- GNM\_ 50\_ 612 & 3 & 0 & 1 & 0.002541\\
- GNM\_ 50\_ 735 & 3 & 0 & 1 & 0.00202\\
- GNM\_ 50\_ 858 & 3 & 0 & 1 & 0.001855\\
- GNM\_ 50\_ 980 & 3 & 0 & 1 & 0.00213\\
- GNM\_ 50\_ 1102 & 3 & 0 & 1 & 0.012196\\
- GNM\_ 50\_ 1225 & 3 & 0 & 1 & 0.001661\\
- GNM\_ 100\_ 495 & 3 & 0 & 1 & 0.026969\\
- GNM\_ 100\_ 990 & 3 & 0 & 1 & 0.022669\\
- GNM\_ 100\_ 1485 & 3 & 0 & 1 & 0.022822\\
- GNM\_ 100\_ 1980 & 3 & 0 & 1 & 0.004204\\
- GNM\_ 100\_ 2475 & 3 & 0 & 1 & 0.006448\\
- GNM\_ 100\_ 2970 & 3 & 0 & 1 & 0.044946\\
- GNM\_ 100\_ 3465 & 3 & 0 & 1 & 0.004356\\
- GNM\_ 100\_ 3960 & 3 & 0 & 1 & 0.004163\\
- GNM\_ 100\_ 4455 & 3 & 0 & 1 & 0.004094\\
- GNM\_ 100\_ 4950 & 3 & 0 & 1 & 0.003533\\
- GNM\_ 250\_ 3112 & 3 & 14 & 1 & 0.141794\\
- GNM\_ 250\_ 6225 & 3 & 28 & 1 & 0.106819\\
- GNM\_ 250\_ 9338 & 3 & 51 & 1 & 0.205765\\
- GNM\_ 250\_ 12450 & 3 & 82 & 1 & 0.03714\\
- GNM\_ 250\_ 15562 & 3 & 109 & 1 & 0.267159\\
- GNM\_ 250\_ 18675 & 3 & 0 & 1 & 0.036207\\
- GNM\_ 250\_ 21788 & 3 & 0 & 1 & 0.042911\\
- GNM\_ 250\_ 24900 & 3 & 0 & 1 & 0.038669\\
- GNM\_ 250\_ 28012 & 3 & 0 & 1 & 0.023179\\
- GNM\_ 250\_ 31125 & 3 & 0 & 1 & 0.020695\\
- GNM\_ 500\_ 12475 & 3 & 0 & 1 & 0.634489\\
- GNM\_ 500\_ 24950 & 3 & 68 & 1 & 0.947696\\
- GNM\_ 500\_ 37425 & 3 & 118 & 1 & 0.288719\\
- GNM\_ 500\_ 49900 & 3 & 0 & 1 & 0.405276\\
- GNM\_ 500\_ 62375 & 3 & 0 & 1 & 0.544754\\
- GNM\_ 500\_ 74850 & 3 & 0 & 1 & 0.265611\\
- GNM\_ 500\_ 87325 & 3 & 0 & 1 & 0.270045\\
- GNM\_ 500\_ 99800 & 3 & 0 & 1 & 0.404701\\
- GNM\_ 500\_ 112275 & 3 & 0 & 1 & 0.205316\\
- GNM\_ 500\_ 124750 & 3 & 0 & 1 & 0.225787\\
+ GNM\_ 50\_ 122 & 3 & 0 & 0.01651 & 2\\
+ GNM\_ 50\_ 245 & 3 & 0 & 0.005787 & 1\\
+ GNM\_ 50\_ 368 & 3 & 0 & 0.007788 & 1\\
+ GNM\_ 50\_ 490 & 3 & 0 & 0.002089 & 1\\
+ GNM\_ 50\_ 612 & 3 & 0 & 0.002541 & 1\\
+ GNM\_ 50\_ 735 & 3 & 0 & 0.00202 & 1\\
+ GNM\_ 50\_ 858 & 3 & 0 & 0.001855 & 1\\
+ GNM\_ 50\_ 980 & 3 & 0 & 0.00213 & 1\\
+ GNM\_ 50\_ 1102 & 3 & 0 & 0.012196 & 1\\
+ GNM\_ 50\_ 1225 & 3 & 0 & 0.001661 & 1\\
+ GNM\_ 100\_ 495 & 3 & 0 & 0.026969 & 1\\
+ GNM\_ 100\_ 990 & 3 & 0 & 0.022669 & 1\\
+ GNM\_ 100\_ 1485 & 3 & 0 & 0.022822 & 1\\
+ GNM\_ 100\_ 1980 & 3 & 0 & 0.004204 & 1\\
+ GNM\_ 100\_ 2475 & 3 & 0 & 0.006448 & 1\\
+ GNM\_ 100\_ 2970 & 3 & 0 & 0.044946 & 1\\
+ GNM\_ 100\_ 3465 & 3 & 0 & 0.004356 & 1\\
+ GNM\_ 100\_ 3960 & 3 & 0 & 0.004163 & 1\\
+ GNM\_ 100\_ 4455 & 3 & 0 & 0.004094 & 1\\
+ GNM\_ 100\_ 4950 & 3 & 0 & 0.003533 & 1\\
+ GNM\_ 250\_ 3112 & 3 & 14 & 0.141794 & 1\\
+ GNM\_ 250\_ 6225 & 3 & 28 & 0.106819 & 1\\
+ GNM\_ 250\_ 9338 & 3 & 51 & 0.205765 & 1\\
+ GNM\_ 250\_ 12450 & 3 & 82 & 0.03714 & 1\\
+ GNM\_ 250\_ 15562 & 3 & 109 & 0.267159 & 1\\
+ GNM\_ 250\_ 18675 & 3 & 0 & 0.036207 & 1\\
+ GNM\_ 250\_ 21788 & 3 & 0 & 0.042911 & 1\\
+ GNM\_ 250\_ 24900 & 3 & 0 & 0.038669 & 1\\
+ GNM\_ 250\_ 28012 & 3 & 0 & 0.023179 & 1\\
+ GNM\_ 250\_ 31125 & 3 & 0 & 0.020695 & 1\\
+ GNM\_ 500\_ 12475 & 3 & 0 & 0.634489 & 1\\
+ GNM\_ 500\_ 24950 & 3 & 68 & 0.947696 & 1\\
+ GNM\_ 500\_ 37425 & 3 & 118 & 0.288719 & 1\\
+ GNM\_ 500\_ 49900 & 3 & 0 & 0.405276 & 1\\
+ GNM\_ 500\_ 62375 & 3 & 0 & 0.544754 & 1\\
+ GNM\_ 500\_ 74850 & 3 & 0 & 0.265611 & 1\\
+ GNM\_ 500\_ 87325 & 3 & 0 & 0.270045 & 1\\
+ GNM\_ 500\_ 99800 & 3 & 0 & 0.404701 & 1\\
+ GNM\_ 500\_ 112275 & 3 & 0 & 0.205316 & 1\\
+ GNM\_ 500\_ 124750 & 3 & 0 & 0.225787 & 1\\
\end{tabular}
\caption[Minimum Connected rooted $3$-hop Dominating Set Results on the random graphs]{Minimum Connected rooted $3$-hop Dominating Set Results on the random graphs}
\end{table}
@@ -204,48 +204,48 @@
\begin{table}[H]
\centering
\begin{tabular}{l cccccccccccc}
- name & k & optimal & runtime(s)\\
+ name & k & runtime(s) & optimal\\
\hline
- GNM\_ 50\_ 122 & 2 & 5 & 0.025\\
- GNM\_ 50\_ 245 & 2 & 1 & 0.030\\
- GNM\_ 50\_ 368 & 2 & 1 & 0.036\\
- GNM\_ 50\_ 490 & 2 & 1 & 0.036\\
- GNM\_ 50\_ 612 & 2 & 1 & 0.038\\
- GNM\_ 50\_ 735 & 2 & 1 & 0.046\\
- GNM\_ 50\_ 858 & 2 & 1 & 0.047\\
- GNM\_ 50\_ 980 & 2 & 1 & 0.049\\
- GNM\_ 50\_ 1102 & 2 & 1 & 0.052\\
- GNM\_ 50\_ 1225 & 2 & 1 & 0.048\\
- GNM\_ 100\_ 495 & 2 & 4 & 0.084\\
- GNM\_ 100\_ 990 & 2 & 2 & 0.098\\
- GNM\_ 100\_ 1485 & 2 & 1 & 0.111\\
- GNM\_ 100\_ 1980 & 2 & 1 & 0.143\\
- GNM\_ 100\_ 2475 & 2 & 1 & 0.151\\
- GNM\_ 100\_ 2970 & 2 & 1 & 0.174\\
- GNM\_ 100\_ 3465 & 2 & 1 & 0.188\\
- GNM\_ 100\_ 3960 & 2 & 1 & 0.206\\
- GNM\_ 100\_ 4455 & 2 & 1 & 0.220\\
- GNM\_ 100\_ 4950 & 2 & 1 & 0.213\\
- GNM\_ 250\_ 3112 & 2 & 2 & 0.521\\
- GNM\_ 250\_ 6225 & 2 & 1 & 0.652\\
- GNM\_ 250\_ 9338 & 2 & 1 & 0.737\\
- GNM\_ 250\_ 12450 & 2 & 1 & 0.867\\
- GNM\_ 250\_ 15562 & 2 & 1 & 0.972\\
- GNM\_ 250\_ 18675 & 2 & 1 & 1.141\\
- GNM\_ 250\_ 21788 & 2 & 1 & 1.221\\
- GNM\_ 250\_ 24900 & 2 & 1 & 1.305\\
- GNM\_ 250\_ 28012 & 2 & 1 & 1.453\\
- GNM\_ 250\_ 31125 & 2 & 1 & 1.519\\
- GNM\_ 500\_ 12475 & 2 & 2 & 2.314\\
- GNM\_ 500\_ 24950 & 2 & 1 & 2.770\\
- GNM\_ 500\_ 37425 & 2 & 1 & 3.236\\
- GNM\_ 500\_ 49900 & 2 & 1 & 3.702\\
- GNM\_ 500\_ 62375 & 2 & 1 & 4.218\\
- GNM\_ 500\_ 74850 & 2 & 1 & 4.799\\
- GNM\_ 500\_ 87325 & 2 & 1 & 5.456\\
- GNM\_ 500\_ 99800 & 2 & 1 & 6.199\\
- GNM\_ 500\_ 112275 & 2 & 1 & 6.268\\
- GNM\_ 500\_ 124750 & 2 & 1 & 6.522\\
+ GNM\_ 50\_ 122 & 2 & 0.025 & 5\\
+ GNM\_ 50\_ 245 & 2 & 0.030 & 1\\
+ GNM\_ 50\_ 368 & 2 & 0.036 & 1\\
+ GNM\_ 50\_ 490 & 2 & 0.036 & 1\\
+ GNM\_ 50\_ 612 & 2 & 0.038 & 1\\
+ GNM\_ 50\_ 735 & 2 & 0.046 & 1\\
+ GNM\_ 50\_ 858 & 2 & 0.047 & 1\\
+ GNM\_ 50\_ 980 & 2 & 0.049 & 1\\
+ GNM\_ 50\_ 1102 & 2 & 0.052 & 1\\
+ GNM\_ 50\_ 1225 & 2 & 0.048 & 1\\
+ GNM\_ 100\_ 495 & 2 & 0.084 & 4\\
+ GNM\_ 100\_ 990 & 2 & 0.098 & 2\\
+ GNM\_ 100\_ 1485 & 2 & 0.111 & 1\\
+ GNM\_ 100\_ 1980 & 2 & 0.143 & 1\\
+ GNM\_ 100\_ 2475 & 2 & 0.151 & 1\\
+ GNM\_ 100\_ 2970 & 2 & 0.174 & 1\\
+ GNM\_ 100\_ 3465 & 2 & 0.188 & 1\\
+ GNM\_ 100\_ 3960 & 2 & 0.206 & 1\\
+ GNM\_ 100\_ 4455 & 2 & 0.220 & 1\\
+ GNM\_ 100\_ 4950 & 2 & 0.213 & 1\\
+ GNM\_ 250\_ 3112 & 2 & 0.521 & 2\\
+ GNM\_ 250\_ 6225 & 2 & 0.652 & 1\\
+ GNM\_ 250\_ 9338 & 2 & 0.737 & 1\\
+ GNM\_ 250\_ 12450 & 2 & 0.867 & 1\\
+ GNM\_ 250\_ 15562 & 2 & 0.972 & 1\\
+ GNM\_ 250\_ 18675 & 2 & 1.141 & 1\\
+ GNM\_ 250\_ 21788 & 2 & 1.221 & 1\\
+ GNM\_ 250\_ 24900 & 2 & 1.305 & 1\\
+ GNM\_ 250\_ 28012 & 2 & 1.453 & 1\\
+ GNM\_ 250\_ 31125 & 2 & 1.519 & 1\\
+ GNM\_ 500\_ 12475 & 2 & 2.314 & 2\\
+ GNM\_ 500\_ 24950 & 2 & 2.770 & 1\\
+ GNM\_ 500\_ 37425 & 2 & 3.236 & 1\\
+ GNM\_ 500\_ 49900 & 2 & 3.702 & 1\\
+ GNM\_ 500\_ 62375 & 2 & 4.218 & 1\\
+ GNM\_ 500\_ 74850 & 2 & 4.799 & 1\\
+ GNM\_ 500\_ 87325 & 2 & 5.456 & 1\\
+ GNM\_ 500\_ 99800 & 2 & 6.199 & 1\\
+ GNM\_ 500\_ 112275 & 2 & 6.268 & 1\\
+ GNM\_ 500\_ 124750 & 2 & 6.522 & 1\\
\end{tabular}
\caption[Minimum Connected rooted $2$-hop Dominating Set Results on the random graphs using ASP]{Minimum Connected rooted $2$-hop Dominating Set Results on the random graphs using ASP}
\end{table}
@@ -253,48 +253,48 @@
\begin{table}[H]
\centering
\begin{tabular}{l cccccccccccc}
- name & k & optimal & runtime(s)\\
+ name & k & runtime(s) & optimal\\
\hline
- GNM\_ 50\_ 122 & 3 & 2 & 0.022\\
- GNM\_ 50\_ 245 & 3 & 1 & 0.029\\
- GNM\_ 50\_ 368 & 3 & 1 & 0.032\\
- GNM\_ 50\_ 490 & 3 & 1 & 0.039\\
- GNM\_ 50\_ 612 & 3 & 1 & 0.041\\
- GNM\_ 50\_ 735 & 3 & 1 & 0.040\\
- GNM\_ 50\_ 858 & 3 & 1 & 0.041\\
- GNM\_ 50\_ 980 & 3 & 1 & 0.048\\
- GNM\_ 50\_ 1102 & 3 & 1 & 0.051\\
- GNM\_ 50\_ 1225 & 3 & 1 & 0.053\\
- GNM\_ 100\_ 495 & 3 & 1 & 0.082\\
- GNM\_ 100\_ 990 & 3 & 1 & 0.101s\\
- GNM\_ 100\_ 1485 & 3 & 1 & 0.119\\
- GNM\_ 100\_ 1980 & 3 & 1 & 0.140\\
- GNM\_ 100\_ 2475 & 3 & 1 & 0.163\\
- GNM\_ 100\_ 2970 & 3 & 1 & 0.172\\
- GNM\_ 100\_ 3465 & 3 & 1 & 0.186\\
- GNM\_ 100\_ 3960 & 3 & 1 & 0.214\\
- GNM\_ 100\_ 4455 & 3 & 1 & 0.227\\
- GNM\_ 100\_ 4950 & 3 & 1 & 0.223\\
- GNM\_ 250\_ 3112 & 3 & 1 & 0.529\\
- GNM\_ 250\_ 6225 & 3 & 1 & 0.657\\
- GNM\_ 250\_ 9338 & 3 & 1 & 0.782\\
- GNM\_ 250\_ 12450 & 3 & 1 & 0.885\\
- GNM\_ 250\_ 15562 & 3 & 1 & 0.967\\
- GNM\_ 250\_ 18675 & 3 & 1 & 1.114\\
- GNM\_ 250\_ 21788 & 3 & 1 & 1.263\\
- GNM\_ 250\_ 24900 & 3 & 1 & 1.323\\
- GNM\_ 250\_ 28012 & 3 & 1 & 1.489\\
- GNM\_ 250\_ 31125 & 3 & 1 & 1.510\\
- GNM\_ 500\_ 12475 & 3 & 1 & 2.297\\
- GNM\_ 500\_ 24950 & 3 & 1 & 2.714\\
- GNM\_ 500\_ 37425 & 3 & 1 & 3.250\\
- GNM\_ 500\_ 49900 & 3 & 1 & 3.719\\
- GNM\_ 500\_ 62375 & 3 & 1 & 4.513\\
- GNM\_ 500\_ 74850 & 3 & 1 & 4.786\\
- GNM\_ 500\_ 87325 & 3 & 1 & 5.305\\
- GNM\_ 500\_ 99800 & 3 & 1 & 5.845\\
- GNM\_ 500\_ 112275 & 3 & 1 & 6.490\\
- GNM\_ 500\_ 124750 & 3 & 1 & 6.802\\
+ GNM\_ 50\_ 122 & 3 & 0.022 & 2\\
+ GNM\_ 50\_ 245 & 3 & 0.029 & 1\\
+ GNM\_ 50\_ 368 & 3 & 0.032 & 1\\
+ GNM\_ 50\_ 490 & 3 & 0.039 & 1\\
+ GNM\_ 50\_ 612 & 3 & 0.041 & 1\\
+ GNM\_ 50\_ 735 & 3 & 0.040 & 1\\
+ GNM\_ 50\_ 858 & 3 & 0.041 & 1\\
+ GNM\_ 50\_ 980 & 3 & 0.048 & 1\\
+ GNM\_ 50\_ 1102 & 3 & 0.051 & 1\\
+ GNM\_ 50\_ 1225 & 3 & 0.053 & 1\\
+ GNM\_ 100\_ 495 & 3 & 0.082 & 1\\
+ GNM\_ 100\_ 990 & 3 & 0.101s & 1\\
+ GNM\_ 100\_ 1485 & 3 & 0.119 & 1\\
+ GNM\_ 100\_ 1980 & 3 & 0.140 & 1\\
+ GNM\_ 100\_ 2475 & 3 & 0.163 & 1\\
+ GNM\_ 100\_ 2970 & 3 & 0.172 & 1\\
+ GNM\_ 100\_ 3465 & 3 & 0.186 & 1\\
+ GNM\_ 100\_ 3960 & 3 & 0.214 & 1\\
+ GNM\_ 100\_ 4455 & 3 & 0.227 & 1\\
+ GNM\_ 100\_ 4950 & 3 & 0.223 & 1\\
+ GNM\_ 250\_ 3112 & 3 & 0.529 & 1\\
+ GNM\_ 250\_ 6225 & 3 & 0.657 & 1\\
+ GNM\_ 250\_ 9338 & 3 & 0.782 & 1\\
+ GNM\_ 250\_ 12450 & 3 & 0.885 & 1\\
+ GNM\_ 250\_ 15562 & 3 & 0.967 & 1\\
+ GNM\_ 250\_ 18675 & 3 & 1.114 & 1\\
+ GNM\_ 250\_ 21788 & 3 & 1.263 & 1\\
+ GNM\_ 250\_ 24900 & 3 & 1.323 & 1\\
+ GNM\_ 250\_ 28012 & 3 & 1.489 & 1\\
+ GNM\_ 250\_ 31125 & 3 & 1.510 & 1\\
+ GNM\_ 500\_ 12475 & 3 & 2.297 & 1\\
+ GNM\_ 500\_ 24950 & 3 & 2.714 & 1\\
+ GNM\_ 500\_ 37425 & 3 & 3.250 & 1\\
+ GNM\_ 500\_ 49900 & 3 & 3.719 & 1\\
+ GNM\_ 500\_ 62375 & 3 & 4.513 & 1\\
+ GNM\_ 500\_ 74850 & 3 & 4.786 & 1\\
+ GNM\_ 500\_ 87325 & 3 & 5.305 & 1\\
+ GNM\_ 500\_ 99800 & 3 & 5.845 & 1\\
+ GNM\_ 500\_ 112275 & 3 & 6.490 & 1\\
+ GNM\_ 500\_ 124750 & 3 & 6.802 & 1\\
\end{tabular}
\caption[Minimum Connected rooted $3$-hop Dominating Set Results on the random graphs using ASP]{Minimum Connected rooted $3$-hop Dominating Set Results on the random graphs using ASP}
\end{table}
diff --git a/Latex/ba.pdf b/Latex/ba.pdf
index 30902a24088f85729d9ccb063564a1afa1d34b2f..288692c98cd5c09d56384de58b81d0b3ecff38b6 100644
Binary files a/Latex/ba.pdf and b/Latex/ba.pdf differ
diff --git a/Latex/ba.tex b/Latex/ba.tex
index 54cceaaa351563c189443cbd40957597d4355323..8288c84f1c967f10a470874defb6aaed59a7308e 100644
--- a/Latex/ba.tex
+++ b/Latex/ba.tex
@@ -87,6 +87,7 @@
\input{results}
\input{discussion}
\input{conclusion}
+\input{acknowledgement}
\input{anhang}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/Latex/bilder/graphs_illustration-eps-converted-to.pdf b/Latex/bilder/graphs_illustration-eps-converted-to.pdf
index 9eaaa8133e4a3be4e9659b8ee93495652bd56923..656380dee86bce450fa62b1aec9ffe8731d8de1f 100644
Binary files a/Latex/bilder/graphs_illustration-eps-converted-to.pdf and b/Latex/bilder/graphs_illustration-eps-converted-to.pdf differ
diff --git a/Latex/bilder/graphs_illustration.eps b/Latex/bilder/graphs_illustration.eps
index 4e0bb67c4687cb091c3e641e4fdbb63b79315883..f3c5b18ca7fd7a2298900634614587ff1ab53aef 100644
--- a/Latex/bilder/graphs_illustration.eps
+++ b/Latex/bilder/graphs_illustration.eps
@@ -1,10 +1,10 @@
%!PS-Adobe-3.0 EPSF-3.0
%%Creator: cairo 1.15.10 (http://cairographics.org)
-%%CreationDate: Wed Aug 12 22:52:31 2020
+%%CreationDate: Sun Aug 16 06:32:13 2020
%%Pages: 1
%%DocumentData: Clean7Bit
%%LanguageLevel: 2
-%%BoundingBox: 30 125 562 834
+%%BoundingBox: 30 124 562 834
%%EndComments
%%BeginProlog
50 dict begin
@@ -64,14 +64,14 @@
/cairo_imagemask { imagemask cairo_flush_ascii85_file } def
%%EndProlog
%%BeginSetup
-%%BeginResource: font CMR10
-%!PS-AdobeFont-1.0: CMR10 003.002
-%%Title: CMR10
+%%BeginResource: font CMR17
+%!PS-AdobeFont-1.0: CMR17 003.002
+%%Title: CMR17
%Version: 003.002
%%CreationDate: Mon Jul 13 16:17:00 2009
%%Creator: David M. Jones
%Copyright: Copyright (c) 1997, 2009 American Mathematical Society
-%Copyright: (<http://www.ams.org>), with Reserved Font Name CMR10.
+%Copyright: (<http://www.ams.org>), with Reserved Font Name CMR17.
% This Font Software is licensed under the SIL Open Font License, Version 1.1.
% This license is in the accompanying file OFL.txt, and is also
% available with a FAQ at: http://scripts.sil.org/OFL.
@@ -81,12 +81,12 @@
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0 ]readonly def
/FontName /f-0-0 def
-/FontBBox {-40 -250 1009 750 }readonly def
+/FontBBox {-33 -250 945 749 }readonly def
/PaintType 0 def
/FontInfo 9 dict dup begin
/version (003.002) readonly def
-/Notice (Copyright \050c\051 1997, 2009 American Mathematical Society \050<http://www.ams.org>\051, with Reserved Font Name CMR10.) readonly def
-/FullName (CMR10) readonly def
+/Notice (Copyright \050c\051 1997, 2009 American Mathematical Society \050<http://www.ams.org>\051, with Reserved Font Name CMR17.) readonly def
+/FullName (CMR17) readonly def
/FamilyName (Computer Modern) readonly def
/Weight (Medium) readonly def
/ItalicAngle 0 def
@@ -123,263 +123,238 @@ f983ef0097ece61cf3a79690d73bfb4b0027b78229ecae63571dca5d489f77bdeee69161ac65b8
d9bf15a1d35b3bfa43ade27c55337a53e8117722f41ae71510be6095ec8fcc4480cf4d4b3c8a65
dec16f24a875f2c200388e757c8d066a3bd39db828e62e2d3d19908b221b8f5b58f7a6a2ebb901
d705aee915d9f92114c59f6a9124885e77bd754ad8dacd1e7fa44ef6a4733c0ef482d5f4f7788b
-0d58fe7cceea728243b0a6d07c975363fe2f68dc120d39bc1437b4ac6e91b4f1adcd675ae140b6
-f59a96ca858bbd5c861ee4d4da5cd8c0810bbf81fb77d72f04692826e26e06411cd5bf235072b9
-a22bff0b022257caea6b35a80f6584f84fb25d2b12b487b122a82e32ffef3260f9ade779b4795d
-3c56adfeb29c4e258b2d9f9a28e54efd9bb6a98778a6cc09348657ae5c4f1cbd6a6657b6960225
-2e89f0dc72dc41fa2151c8680593116af44bb56979d80ae7eb28ed92dd5211a953ef3956453d15
-90fb10f8f053d924da5eedf7ba9ae7eef8e88adc91b40f9aa66111521e97affc76678b95a94c1b
-10498274d41eb5dce6c800cfc2b1daaded801c27fd5b57ddf20a4e7acceb6ec82bdcc67f5ec5b6
-9221de716f66d38f37d936a4379b1ef049d22ff23aeaea253f840f67cde55a9c0449f09f5c0144
-ebd1be42eb4dc7654dea77f4821c36b37e6367f23bfd70288ebc289858ae641a75597dc3453bed
-fea0eb27f30b6dfd61e07ec4ab199fea4c2f59d6f6b04bf3f8356318f0ed8e1e663838237ef143
-fee4ccc3540ea39b05197d2d9c149a2a71569b89e3526966b4860666d7394635cec4328c5e453a
-59e314fb4aee07dd60c6ce98b1c7e0fa4983414f17c728d92a27a7c1402b6bc51e3a9474e312be
-1e6d5b802895af8e46ae6dfe64ff5e41bc52a3648091f713c7f4021c9ee000cbfd06faae97bae0
-55c337de33c9cd0c6f45c4918db239e6e63d795f44b9d097118d083b6d6ebe2062308845affa58
-d04bfccbfa3d1f3b4d086f1e362357eda652158996fb06cf39ebc15946fd58e6040e2150803bb9
-d9156133cec43034651f6a759639393fe2cc6d608730180c4ff6fe77346eda3b4b747bdddcd33a
-9c81236a22c18964c1a3dc6b47a384cf48f9dcda4481ac84ee0234b1825028609526349bd3bebd
-3275055bdb3d52e2595512a9d803f68a9237ef9f933f367f4cf21bc4aa61ae6222051ca394db85
-b9bcd0c78e7cff1b38db843b76e9eb828fdefef5790cd372d971e5bb8ab00df0cc66afb0fc526d
-9e6a4d1bceaf99078466dbcc1d96c22b022ee2b84ec839a896acfbc1baf7cbdbc883b8dcd3368d
-579e95d20124d58a0d8e896eaa9ca2dcd4d3f084aa237af69c9a958ae0129ed065740b556cbbd6
-7695d32b1ac85b0f26bb974bd8468f058a619486ce6fc45b074a6541d409eb725ff3af49d5ae3b
-d896d1d6bd78746535a61e265056b9dca3c637dbf690b539ec8fe181acf0ec5edced82868355e0
-8d64edd445413bf367c817170006d3dcc6a9a7288531311a44035d457837b97044fb3beda4503e
-e5820e5532bb9304e8c83201f9c46a1d6739b2da74d046a75a60ca064cafe82168bd87e88005cf
-a68f9db5faf2f75f0d7bfdba7ccedf205bb6c7361a62e619af888a9e753f1522d7094e5a9bc206
-cbce76f0b6a1d85a2b93789aa0cb3105e43acaf226d61764d6962dbb1ecb372fc27ab8e79763d8
-3df97805bc70614355bdc853942f8f4d271b54b3c475b27d7f5985dd84b14c22480a6b156b9a81
-2adc8ec155bf922fba301815ac958e68109c186984b28592719e1579e7510fc5b0429b577f83b8
-aa4e11a93291dcd14a1ff76cc5e54de58ae4b399f086c0c8283d938d5f4254f37e43aac99f49cf
-259036817690e55f09e8c20ee7e627cd38a0ca9d7a574a816238478497dffedb41bc0a56b7eba0
-9b58a4d8d5711b931598873b73f54a94cb7db62a78b590a189c0b83d7bcc665ae203d5669c721b
-b4c34ba9b85388afde9502da1ad77994941dfb0c8d9673fe3801ed7b646a3f7b86c87e2a5234b0
-2507e05189732e574b7f2294b59c2945666bca518a71b9b5c34f823217326b827cb5c75195caf9
-b93dfff259bf3e0ca4b2c6bee5860851ea5ecef377689a76b98c4e81e8f17067f47439f0fc5194
-d5a0a1959d1e71c88eed68a2b915e56b38c00507921917cb41bcdfcbb6e041d80b1e06a41e974c
-ae2bed5381d03bb4e1f2117d109277de28efe7bebcca40d687561b073614d885440c9130c12643
-1c95e73f4c7a9d2c9ea5a86e1f9ace968bd2db67c0900ecf65dfe8eddd61a11c285867c06a4557
-ed0ad36fce2e0192435bece4fd8d7cfc355c6c019ca83dc0c9290e10d0f166ff639ee6fdef87ad
-b19fdf0215f52da1ed5eb65876fb24c0ded82ec96814c0f8afbc1db375051bdabae230a873df8b
-5b55e6c006e6f7b6334287820ba8f20d65b01155c9032d6393ea04d967e4106ee05423610be003
-033e86cc7f177df3e49dc911d5cad22495e430ee44d9fa74960ce44ff6867327dd3985c0f7f456
-b049bbe721f07a2eb9149a44f06086ff1391a6e2bd4a5278ff89beed802bab6f81a8d4c25f1759
-7beafb760a318ea610b5f145274a2b3aa611858529712d404991ea274f2270452da3b68d891699
-43ba7686e3019263133290796975cb035b2e6169b8621e7136990ab699d1c89fa0e94551191523
-fd1a69cda50cf8aded596f56dfa218cccc84acda3226a0451e87ff0e44fe54f52b37a59220fb13
-5473a469ea525805de37d223c18319139185b97fc2ea83356ef7799081d1e2a97d89f977de1458
-9ca8446cd692fdf2419459618475c952f389db09c0749798af8397ac3e11d4e7302e39ac34ca03
-df273851301a1ae9b226e84fe2e0b65131299516bd64aa90efe39f280591af10c90b652ae14e80
-cc1201b4109629558e83b83483d4dd57e0857ae0dfcd5a64b5cc36c1f28ddc752ac1d1bcfde5f5
-b1511a3e6b30d835186f38e35215a328d396db7c634aad187428b23f68d013bd6b8ac2d7ff93a1
-d399c360245641c2200021b9f8dd69304f74616ea2dda34144fc11ec42b09af21134c2c7fbf153
-4abd44083021d4ba466e732a1fab596e9f6afd4874ceefad852697601ad8f15aa5d59e20c11e25
-b8fcf60d6138d6e72a8f4cf154c97bf5990595c479ba3a2f96dd65396d54a42b209ca55d3eb21c
-be6c44f0780d2c43fcddddea5a65ee645aacbef909a155b55247a4dbd5d59e7d0fc8c20a219344
-312a1d86cb69662d2c7cf928f6d817ba34ff554890aef5afe8b01db6537b9725b88cff02db92e7
-87b593a6491f930eda75143528147e0341763f3f8b9794a0dee7a4889530c765a8e665f58c9334
-0c99a098250ef663f3158ea3e6dccfef4212909a5c5c23e2d61189d23d69e8bc366c947019c230
-5017afc9d36c6e8c560efaa4093c944a4457698c5f5de74374ffdd24cb5e6d24a04b531793be80
-2d5ae400e2b068a62252c678f4547fba7c677e634cc76a0373124d65ce68dd5d085841569a2f8e
-9c9b71ed1b3794e6f899d6f3cf7b6eee7f33a285abc190b8f17454b084c8a83a7c64cb899733eb
-e3ea8d710bf15470c8699b265b4d3714870776f16ae4a5402c0a40070a16114298a51c1646f6cd
-e88114626af0e4cae0ff7384d863891521eac6f31a5cd295cc0c0e7d59de52de04bf5238156f4c
-e33cd4897cc482ae5ad1826628529ce5a6a5e6a55aca0b20b657cdf5e57c5a73f96f93622c6cf5
-00bcd7e6922bc3ca96bba05fea0b0ff7ddcac109be83fa8934851e9be9bd3109192202eab1c77b
-0c86d1ff97e3b8732fdbb9eecd2a547e3a1cc4402d8f1d213c98890afb12ce908ea3cec9d2e7b5
-bce47c25c32ef337c45f3ee522f5cc76d1505ded96156f80bf6c8e2cf5c3f28898c2f7cedcad10
-f6dc5c45ff4979906b2fd4db0d9435bd85ff5b78e78e441d140ab53db156f4c6402f716ed7ab7c
-5617ae1d1a22bfa5bbc89dddcf9f14feb699d206e1345b793185d2907babe65547a9a17f8b0ce7
-18d98db6039357616cc44be309ec11368ac4d965927773cdaf50ed2d48e692b2a3b31521bad488
-bf684f01e3506733b27eddbb5d0d6d3d8e65a5e1bc745e1eec0547984018419179b38d42e30997
-94341d97885f230300ec6fa06b18c17a1fa77dc186886492d150df1440db4efae287f2f2a4ecbc
-f0683eedea3f78b1b68fc1911cbf2625185f73c141dbc9674e7affff580b4a0296073f5b6505e4
-d63a4a736bc3b794809e801860ce4691a57eb02c0947efc1de4bed3962346769c613f240db1574
-368b28f186b608bb99da33ae1b3c266e49d58ae67a462fcf2e6bfed1ac1ffcc24c9752ea793f60
-923f7579d2b8ef9860975e6a80d5f9637d594a9567f8a2d1e15ccb1edd3d502972c969ee42f57d
-74500d30170904a463d659af0d96ee6fed9f4c7fa0c7800ebb2ed3b78c3f095d18068f96573a03
-3ef343c07bca94dd9897af2830b6a40086c1e8945b26f8baedb8c0af3371060ce18cf8d8693738
-c15c2eb95a4f7f7a37e82abff54ce8d19524e45379c92bee3ae74131231fb175d96fbe54274a88
-135fc74d9f429b9794912a8d157c0ce5045f3b16a4bc78811f1007c96eaef9bbd706533a7ad804
-11e4a3adb0bdbc27a94632d00a5a561df53e0c63a0c17d9df09ada247b420b524135e9e7c34699
-8993f716f41a8601099fb2cbad6f760245a1b52e1f8c45fb5379021a64ee55e368f1e2d704bc41
-76d8e1a1f034a631aa520c6039639207386175c7913af1aeeb95f1c6f995387a454c25e6f78af6
-0ec1d34e0fa0bb4bb8b9417b5d8c59d31bbd89cebd28c490d8436128eaa23c69816af90a4622b8
-2a030514aa5eb2865f5fc5247dbfef5be641da1448376de08544b9902118a5259175d547a87932
-6510c732848d4e5d6d4569021cffaf8be720fc9b73df8a0b8be87eb08c3a2cdeb28d6acc63694c
-a9cbd263838f26a9f538d85fa00cb23f053094977019ff9a935d627668bf9e94eac831d09da176
-27b4a4f4b6a790273ec536a5d8f66f478bbacaf17382f7a3e9257e554ed267eb03cd70b80359ae
-7667c44c0c9411a2ee41a9b0a6a12418a37e6e814069df72d0534d6bd5631f158a3fed39fe33e4
-d97f5b8d0133f8d67b92c72466cb2b82def502a67fa8a37ea4473056da8b1a1c589960957b0e1f
-e2316dabbb150f8f8be2c4da45e4014cdbb22df11a9fa8b85278ac7f0a6f75996a7eba0e524eda
-ab6ca54ec3b3dade7c9edd4ac5eba9087cfd542cdccdb9410202ea1c5dfd4abfc5c0e1c0ec8224
-6a93f453389bdef4fe8a94f9aa5b492ae04400c73f55f67ad0b02f092d87e10bc9f14ad36c3e8c
-c6519bd9ac63f795a51f61a9877cc56e8d87e1078a1562332869ec5d52bc95be2923ce6e9ab07c
-7b9ce0382a5afc60a44693aa58cfd33baa0415f5c8afc239125af4452c3a0010fef23c70df02d5
-d1fee6d23fcbd6b59137ef773e877df1e42eccd49373383b53556929650002a51973c5cb12eb66
-96f8d09086c7a0818b7372d1d17fea577704df4eaa121e0271b9459d57e1fd89a3db3d4c75c620
-79c3cadf03ef97d04c5a4cc5e608ef1599afb139ad7fe73fda41b81dc0cd9fbf93834f9ba7fb12
-38e895e9da72f1bbb8ff581c45a14a39981170d15d4e04022a9aa5a2aef9f6d38d68df4bff98a3
-71296a4e9ebdd2feb5bb616bde6c9a4647901613239b815ded225e3408799fa2f73d7be239cf11
-494c456dcdb4d618d21d19d81879bfacb55ef117fdfdd0d5f66bc97fbd7c6aeffc84d196359698
-e9f36512d6cc42775d1adabf6c99b4f4a232579106d27801f76a71f0770168e40a85403af26be1
-4ba533ec0551c3b18ea8ee97c57f9faeb4192419978ee50242ad61347104fab8f4260f518922ae
-10276c55fd46ea3d4f6471207910d77c8db13e391124b50453b60fbb4e4f15855fa03ac4c3a5e0
-f6cdb7995b1118bc4c9bd2f869682bfb9be20d917cf997d4c2000abd5e11e2dbd79c9c8b7685a1
-7943a2de2ac4cc60a50cafb37baf863aa8b8350d7dbb1b52c2d3652745ce06b1193d2785073f5c
-668c4a117d268d839d41e497165a50d08c3292fbd174411692a3b744da54986d1ef767d6bea6a5
-f437e5fb61f7581c72fa8df1f51909443be412c321c9e1fd626b345b705dc4a8017eb0d8cb61cf
-e5f3f80f796bba6fc7502bb925a33915953141c4444698a18663eeb95e492f20542eef84b047ac
-52a439bc794ccd488ee9b25bc467ed09a418256bc0c14a808f007231fbf97efc1881425ddb64fd
-6c170debd330257427c9d8b53dbde875aec06196cb8f0d33bf10b681605a02e750feadb3196bb3
-ec2c251e5f549c2fb6c91fb32c1bba3c9af6ce30cb6b71cc2ba681231b1b521619b863addda93f
-bae29f8c7a439415d22bb35f59608609cd13d22612cbc6aeb6601b37a6c9f09eb1eb8f60f12134
-956e456db374fdd7a93302dc2fa405641d09fe7c28314b08e4fc9de9294b2caacb8f8673647ea3
-2571bd33996045e3a3a6ebd1315c3c0c91fce65dbba1d1dc730bfbf02a1d5b16c74a8e5841450a
-24fb0d87108469267cd21aea77cdd8b317629be24dca7fbaabd757acf62f5733cde3c4f6d138ac
-ee93de18cb485c9178214351fa3f0a44ed41a3f7de68816b7fef6c2869af4f677f3f358533afb7
-d4f090c65f0358bb63e52d2c4878d2ea0620d1fddce9b8bc22e99bcb711de2d4086cc2950ed2fc
-50508e3aa0c15b109a3221caa9cbd6be368bc6b7a7033656d9ffc85f729d4bff1c18b00e78b5eb
-5c9cf181906885c45e315b2aba41d3cdf32f0cf301dd4eb4bf9b28c0a4d429fc84aa97633a6bba
-6ab0f43f61d0f6fa9a35256ef7bcd8fb934fa1c035a8ae3b600920b608ebb40850e4c7e3564572
-675ccc7002cc2029bb963d87385c2aaedd472a224f92187298652ba268336df3bc28b33441c1a8
-985bfe71eb30e33ee83f738123d76f94308a1a2f2f549d40b7ff6d97ed87b1989dc12aad21ba8b
-c42b2c361c50e44b74ec9db17061db171b932c910397d42c1d6a305299545952ff8ab117bff8e2
-bc2e52e7ffdf6cb64d61aef2e79481ce9a1915b207c58c4dda3d71172cd99883a27078693831a0
-7ac70c67e1eecc1dd5b3dbd0f7b445a167e77f54ecd3f88a4622771c55c53c9cb58631b60374fc
-4e6ff1ff4a26dabbc2ae562a124333c2822e4b52598cf5b4d5292df4b06800d9689c04ecd895d1
-7847d93faa68b508e524b39321aff9e749343638acab6cc92af4b447b87c3798277b3e83341988
-8cda9aeeb978ffbdda27b6628fff08a55fc41f646741d092148a2e149cb295f283b9c3a6ee040a
-ecf8a895dde8dd46908ff65a57f7cabe8dd42fbd82206e77cc64aba562e6d21726a63f5a75c4f7
-fce6a8bcd6523bc18679cf3730bcf4f1ecf3cd00d8bf63af271164211a34e3beb928abe1a06def
-8b2de826c893604c5f375c7c254c4a2a797fc1ef11b38ce154a5b337c453a307e501929d361a66
-aa0ec59243a64f8cdc31f57ec829093184386859fe4b6792265a6b32d03cf1c81e583addc7bada
-c25c98fd44a3796e33e53e9b2019d0d8c6ba3685019e67d931b5a817b2ce47a88be668bd45dac0
-5199d05b5f02de05455bf2cdd48f2b93b50edea9a5e0c871f8ac1665fedcd0bab330ee628e3df4
-514d679aa059ab3c1da74e2590354028facc543cfdbba7f90010a2aa33b7329faaa0df1c555e03
-b71f153a5cae8a5f9738bc5c53da38544cc23c785088062e05e3896956986b6210d343068b5106
-361486b7545b0547ca15f44369b663cfbb015bf312eaed766c1afb8a49609dccf84429ad244ba9
-bda8e7c8486ecfde9f4ecd69fd346986678026968855b8820383b0dc16ef600eb513433961d693
-0545f8cf0eb3b959d906c0b5b648e6ac3b2e33afbc0288b81ee909c1c6481a612e81e11ca79532
-197ad099d11a2258bb34cde121ecf57d0aa46a40f6d4ac2b193fef9d03f08f1b437be1dddce4b5
-f333c699271d8c32a3ed2d2011027463c64edc51b5d3fc0462ac49664f7e865546654275b55b91
-33d2cd4ff4eac08af89596ba113440201754364cc313d83d481291f5d324440d17434ba38ae08c
-30967a3b9bd4024a1a082214e3e33d36d47c6de264b0935df4b878333886845ccaa039d51c7ec8
-11ee55fc992e5070555bc5c67ebc6a93eebac765017942e8779a517c4d604062113bafa9765e06
-47786f038fb6d4a764abed79e47c136cda2987e523e32fc6264640052f7f9a7cf334c4e5ad44bf
-7f3e8dd8f17780474e6051e8ede7afc39d9b0aa333f9080633e5054dea93615afbfdd29a541712
-749e5a5b5853aa7b9b0c7ba996d517c1d53c1da1185aedd29039d71d9bc9af135276c81e047c56
-e4f98c8c73a33daa0a1c99a0e0898b1bd8457cb2d9785bdc00f19c1a2dad557200c80a7dd4a91f
-6e4979154d98437d6b35ca9e393c67cc8a2909ad47e9618f42fbf5baaf05e56e422a2b7b424373
-c3c28c310f15aea54d5a23e4af65880f14ea206835b94420beadb6e065bc693aa01d8b1dece2ec
-14f88a4b57dc39af18b4e27f0c6875727d9eecc572cb6db04b96fea52e20dad9a162a814ab025f
-c998ace7f8a4cb9c067ea1e5cebd1d570610cbcd3c21e0a1025ab2d5548fe6133745bdab0ebe8b
-3eb36e6e325aedac9d72dc7ab6f3134fa7448cf5a9de43a5d8e9b9bedfc940fd1b7b2fbc1aad5b
-1acb2ebbfe5ff28014636516c6190c96811f399ab37333488765e12b94e4eae180845eff7b7f10
-11b332ce4982a6e06a50395453a2a0ebcc7e875a6496716e939a60ea65666e8f4acb8c8e52d76d
-9e7a10ec53d83cbd79fd38adf1d15d6a0c404fe4f2c943d1274b2d81a1f956c521a1dddc6b3933
-5d4ae86c74fed07cb86786a6d564643ab2cd1ff77d971800e3cda261af606f2797635afbab5976
-8409b2b700de9e9245943a23e20a1c4d3e49355e80028b1138a4e0d911fd47f68ebf491ec59192
-fc2f32b8e5e2bcef8282ac40b6f0e85cdbba16467ceb2abb37cf8b71665f3add17ba3f0ddaf127
-3803fe0279725720b9ad790a53d4dcd1488779d774dc9b085b7720ba5949abf50bcff513171a91
-c584a4bb64ef2ea43d7c1f226bcfbd28ce82378310d492615e11bd4ae21c544983cb6a2b7b0649
-2177451c915fd5c35771aa693ff0e9e0f6fffc86a7427b6382e516245ab08153ac6f6c88cda675
-39fc8ce1d0c49a56ba829a1f4ae226accec2f1c0b014e2b65b5568b975f682e8e15f366ce98acb
-92bd637db29a2d1a8f52d9abe53fe0d790578ec532f6a00f3d1906fe22b8c7870ab72dd04eacaf
-3d4dd57dd3fca76d147932e58403b34c167787164f6bf67ee3acd902c70f622b24707588103d3b
-bcc7a5e6695368efb1225a1ac5a094bad9c0636ac2644c1956f325b10951389abe6ab60356e0bf
-c9f2b41efe28f830562887fd5083948ec65746f7bbaf95a1e53d440769b85546a815a9d0a6b3d0
-ca6546ab045cc4dd1f80c12f5d00845cc2fa21bbc80999f830dcd0995552e2129e387d05aca931
-8c09c86a3cb68f2e972324d484b4116880c5687f7f3fdf0c07d30fb6e3ca06f1f5f5dc372da9a4
-00f2809c6e91a207d1747355c2e81d825ba064391afda0d3d389e7ad07428ec956d92c021072e6
-2d4a3e047906724c1edac7c7a817a0afba9874f562c9cfee1a9a720cc063c529a2e3eba2971761
-69fbef06b1391631b6435a74415091d2ddb826b603288c28cd80e538ed08065935a731eadbb724
-a0bb88d4546118daac1c29d1146f6966ff7efe6166ef27a9f6fbedf0feb04181ab819aa5a3ba40
-da37f9cfd5381c6042171459800a068efddf2cb3002965862e2c6d238c988c64584c3688ac2881
-41cfc6fb42373d801f7ab2695ecf4accaf5c621876631bf525e4b827dfc175667ca9cb228b04e0
-89baf67b822a654874785f46ab4ed2d9534c913b680b3cbde0834f6199c0375a0af0bb0bd9e370
-18ee8da33f8bc1feff322b65cac9b4c64c0fcd273a50dd0a5444d00a0f6882f610189e322c9bed
-50c2d1638e4cfa1a35e11d4262e9a10bf2545a62d89bbf6dc9fb59bb70ae2c0bc089123e4c2d09
-772658704ddbcafd24e944b539a9e2b31ee9027dbf3a51f7624d1e7b4b8865b9f24da2cc683262
-49f38525f48d500fb3cc9f45f571c44b9395a9ffde275e6f5836c56771ae8f6b2220abdad7ba92
-ae826641e53d8e1cc26d8d084dc3eed60fc95f8d6fc8f930cf486519d8ca78097a36e28ec9dd73
-9a8e5473b844fc19b6546b781651cc6abeca7c0bf5dd430c7856d540b61473d51a7b8a41cef102
-12c4f72cec52578b6cb953fffdc5bd76492816bae82dcca71a0ee35bf2767e396e6949987b5eb9
-d396bbab38ec101f58640a536ae90ba70a332f425fb093da1b44738d0af8b32d4ecdee917c6053
-7b8f99fe2c28ca5c1386bb420d74132ce366aceffca433bab41d0f4940b5327ec70c1438b4c1aa
-4e12107d2e70d8f57a19e5a293f4c0c3b6ae63f41d5bb4fd6514649ef45cefea0dc7f085c01d7a
-bc2d23b6ae8fe15b139bfdf3c39b5688302daf38616cd78b99002cf83cbee48e8f88352d90f9a3
-1b7178bc67f54407be5c5f52b4cc8551bd2c5ffeae478396f890f6766fc41b18b474ce9d87f262
-8bb1ca1277237c5301315aa45738fcb7bbdf060bd51347c1be22bee53a349108037b78dd0421c5
-476a81f7d212fa9509116c616762cf1c657e89414806733156d5b8759bd8780dd4b8d99389790d
-4231b47a650391cf97b70858e0dceacd5fb524e5f44f0cdafc8b037ce72e93de2bacdf82a55641
-6ed0111d2cbbf406a4aebd8670050710a083ea7372011e3bd20177281b68deedd16052f5d30d2e
-11712db732fee061b8a1245eb3970bfc40134662e723befc1f7781008054c2288ac94bf2e52416
-5d0479bb75729819bf27f59cb0616c73120704cc0869ab963381d4abc036aa155a95d345e1b691
-bff734f2b3bbee539274530b240c5e5ddb46d79fa7c9e8280e8632c546ccc7cc41974657bc723e
-ba685086deb805e07d8d499aa4089453386e7ed24a9c2cd1c857bd40c3a752cded2abfcdeca0b9
-6163d90b0de84f297d671cf15e7b2609e566895dddb41a0b495b20f613690267121f3b1119d4ff
-41d228660d4fa0b1b7b6c511e0e530734d2da8e2dd8f082c1c06dabb9463080ebbe2cd848fe4c4
-b1a4851002b7d419eed50a6c904b020a9580590796e11076156f3a66d9164a05588b6d272a1347
-225e115c67e9433d238ec2718a5ab53243e0dc6f9db4f179387eeb4019d2a9d584286bdcd4e750
-0b55bf2f70689f761f53dbd79559eab6d58233bd65334af337b596e4f1866d8f4a989cfdbf970f
-45a22a32c53c4fa52108177534b0bfaa3299a2aa2561c61f0fc05fc2b0e56f861aef57e9418478
-e3646b7b6bf3a2c7732dec7afca0fd2169d9b8b26dce83f7ff42c149b09d99529f49078f5422f2
-20d5548769db348312c39dee18fef0eaf37a544f5b55506ca0c2c52f5bc918be704394ef8ab354
-b2eb4d6cefa963ef0c304a107f5e34d693a52f16e4df84149affddce09bfc87b6af8eb87d5448f
-fe8327b4800dec4327ab8257c1ceb7021b1e0fd8381e54c1cf1c0f54ab291777c6cb19d6044d82
-a9edb56df5abab862a3c62a8ee2f5caaf92fe70d5a584a2c1ba16f3376f24e766e6d797490fe5c
-44692b2add37af335f85ee4415d9f1d1082afb97e4d358463056e69cffc1df788ead73d9a52b06
-a2933a3e86e2abef8fc4b96285ded5ebf11bd7656c73ee4a6d963b1dcbb1b76d8b5bb6b783f5d7
-173667c76902426d48badf027941f5faa1cd5ff354d3058b7e333fa8550a695b3411ed3d46edbe
-396b09cf854999a0f4fe1d221eed76a341088ac5d2da34adea6da8aec1cf43ee9bd9f2bdc8aa47
-39321d1c04368ac3680af97310716a06b7cf9586713ca0d3d43fd4019ce717af28624fd39819b5
-813a2de83040b16bffbb47c48a55a8929982ecba3668ce24168d5ac9c604b495b31f7538a47fff
-0bd3981dbce24924ef7243e3cbe51fc60d9df8373e7929f05f5e868192dcb86ff33b0668cb8d1e
-4461eb7e8f2681fa275454b970c884d07cff6e80bf5e7737c49720540bde77739e7c4d7eb85f95
-9ce463a99bd16cfa5d219180e9f037ded82e8b159203343e52fb550c844c5c49c45319e392acb4
-2c5bcd0c81cfa4a3eb571cdf656065b0fa4aba7f454937c806515fe7d8f257bc1cfeb3d2c902c2
-1d4e2730564b4fa0ffe6062ca8fa11017844dd52a7185c5d1d79224d42514de8edcab4364466d2
-1f2f06e2c5ab233e6be9c550ec12eacf6eafe514d4c83bdc0b91e73a2afd5f8d63282a863860c4
-333ca554f83517d7bd8d35367ac647ad9d6d97f860755dcf7c70bcdc5c116970fa18b01b2495b2
-be66723b0209f4d98fe9e8aced7ce731d6926edc6b51212db2b87aad63d20eec2c2c1114b0057c
-4ab94a906440d1c3c721253aaa9aa6c862ce058df549ac307bd43a126b757cbefaeb7f12045321
-90a161ecd389d52bb71d0e88ba87ee75ca0bb6f9b1ab731f9315fbc3da65fedc452040228b4df9
-9adfd2e193826cd3747288ae57b3b077ab4f8f5bac1c9edcf2fdedd00f58775991194d053484c2
-94501c0b1fcbdd2b1fbb67aab01a21da0683609aba40163aec962b41d386be720d91d19c230d3e
-2c9c85fd9a046e17e1cfc54f974af72e4579dcdd9a0fbccdc60f2669aa65462497a04df6cda4d0
-515709be6470b10575d2b55ce00d1ba39609115a7f3c5bc0782f50ba62951c9978c2a0e4163ad4
-c951581c46891a2a0984a07301502301f2c617fa4a09cf45e420f60cbcfe6ae4c51024b618d30f
-44d28064606f520435707f98ff4ad44348a5ff5baf63ffb00226ac68e4a019fced4a4770190217
-3b40806c7441453cbc0ca26810550a29aa72ce7fd5bc97de78eb817c691d4147490feed9deb5f6
-5b96dc9f6b4b468464fb90dd983b8e6dd5a29c74a59723d8fd300f0c51e8e9865759404ebe17cc
-89b97313e20ddf1c8aa5406fe7d9e25406e29c0b6da8c22795627e41247968f1ae5a7fcf9f3847
-dfa8954d5abf0c826daa6cef675a5a89daa819ad22bd67ab429cb6ff17e8306241e92d38d559b4
-a2573dc13b18c2eace9d65ee41ad8cb29e5e077626dc7ef13df855a0d719b45e48f4e1780a732e
-1a041de0717e296bb1dd6c01c3cd752292f51ce5b6a0bbfd36a407006835c5cbf4f1925ed55e6b
-a3b68a7b205fa6d14ccd6f6eec6b703fef00704aaf0dcc59b332f0ebccc479bfac8b24337b94dc
-e2a9f301c95d8ad027454df11749e0d4ed5089d6b0037eff4668b7db1723a3c849f819c9d814b3
-d5b0c8cf0f785674071284afd75462d3a20514d77d9c4cf0ea7c36927ddb24a69c43b343ca533a
-431dd28e72eb8a41f080a7af8dab590c2fe9c1c907a8155e49374b3cfbd5f3aa5d934778155bc5
-cbd4f3e43f1d95162a12de9300fb2099a0293d23c1252532517c902b8f5f427fe731623b8a7486
-83767d05a42075b36009bd6384fb8b8c2142ffaca606d081f0d759d03b0fcc04e4ba6435331484
-39a20be004ab8a8b35de236d89826ea8c44746019640109847e58eba718bc7cf1f69fd084cf982
-618fbf793bb4ced13c07c5678de7d891c43b85c933d5ac550c57a59fbe5a2a83c31f65d3c03bab
-074171d745143c986bf2d6e54f3003a44b96ea786acd356aa08e991cc8d67c039de9cb251c65e2
-a878b6aff464abb8fb8ed8b4a04ddf34cb499e5db0718ad34abd83683e827ef0486f6f343df3e1
-605919d54e41586177d3a39d1925adbc405aeb700e26de434bf8c68b43082a819cbb025aefb0c7
-95e58a76595d10d4d9cedc3bd860a2a86765d5450bc50684693f44854aa30d3134ad36b76c6288
-98fae6daf36950834a604fe06e3622f223f1b0e36e5302b19350c614f1fbfbe4d19286861c770f
-49e0a3a9e8a951ec52f531e6218cb2d60c10b14382b245ea8c0e94f5a47b1ff32b66b4d776a270
-b2d682b8a3bc22f17565de27ff853522cdf20d6fed095d143b6e78ffd75a3d939daaa4f13bb963
-38c7fd0a3a69c82b562c98f43e3c6364d07a23337ebf72074f0c30ddbed686579ffc8e16d5baaa
-934ec5549a884a08a1d08ea1fc87dcc7170d666ed19e8a968484f1379ad71472a86333defa2574
-0856027de184209a47889c55ba83b92f5ad3c14656343061863c92d7e9187efe4c1e798ba45018
-6dfd17faa45df9f7ef983c4a748882ed8edb7f6f03b6a9d61b9284f658fab4f9b3f6647ddd37db
-e5494b28c3ca0eb6f8150f6aabf898e67de6554210fddf164788fc8fa430fa16397204cdb55cc5
-f24b0e1a1ca6f9270f14b31e
+0d58fe7cceea728243b0a6d07c975363fe2f68dfbdff3612ed968b60f22ec63d9744ec32b65eb8
+36ff5f286773806f0cadfa4513b1cbde4ae0cc985541d3c765b401ccdc2a819865937cc3396f9e
+3b167f17c8026a0511fcec0db7ffc5a16e1cf5ef35571c823fc9ca1f152163ffc472497bfbbe89
+3e9518338b01fbb44360568dc558ab9673cd30c7ae8c0a629ea79a7b127270c043eaf4b8b99786
+b23146617ca7df3432ab7b83be3e1969b17d0ff6c3b08897d99203bd8f3020e1133f3db8511f2d
+5836a4cf7d5ec4b1b9f86d6410f72e668cb58685233e2b0776a0b521f5894205f1e781e7281ec9
+22d6fe9c7bb48387186ed0f89148768631ccd40e887fc489e0083413f0e9f97391d6c24fa2d597
+ebfdba2323943f40c001a5c628f3198161737121b8d041b5ee1124fa140f9b1f78da236a2078e3
+24f6ac6c96d2af20c0e8acfd078babc548bcf3935a23b65a3793cba2de91b88390936b70d6902a
+d30647b374a123e7e4057956317a573b0010b2db9eb6da927c2a484ac34fb4e94096bfcb22e13a
+d88873d97ea93639cac26e3c994ea47588e19f5737ef1933af36a80da186a15c9e834d228a9bf9
+41c3a16c6178d59d2eb158cc770d8b5b9f424cc101bee3a30a80263f9ddc906a9c9d37176e7d4a
+484961609372e15921a5da03e9eb0f22eaff3d3484c5e7c2c25c902f813197cedf30e33840a847
+73d475a8462bc7e7dc6c2fa7c0dc236beef6d23bffc9c493dc8e181ba652abe363bf273e2eb0fd
+cafd63c0f634f2ee9aa638090cb72f1f8869f412cc4921a408ed1756fcab3eeabe8db1bb874f3c
+3595a41fb5f8dd413aa37cf1a37aded7e3c2bf896c939c6f275a5a978cca6ce7623667ec617196
+138f3d01d8b88ea9210af054ce227de928bc8293ed49fbd6830c121e583cb45954388deda9b1d0
+9a1d8cd9fac7f15bae385cd47c0c277d0ce8c58aefdc500c4885f708b7265235cfea918526a50a
+3eb2274fd86caf187e526ebc0e098a98d1d16046632f82fa7aabeeeefadc931060c48317511197
+6083c7d164be600ab9d1d0465875c66ed071eabce13a07034bccc330ed6bd424e0e4444d021a05
+8383bc2685833f2a98770cb21c13c5e876014e6ef2998c1e9b1c4f583731acf588d0427dad8f28
+71df3468108e140dfb706d41b2db7025145c8ad55541eca04aa826b9aa5a926c49a4b1d8c663a6
+d09150dbbcc5711d2517e9b4214209ae7557e6dbe6710cebcc9453b86a9d0e31d213172834b8a3
+e15615d34aa922301f91fed795c786dde1ab27d9a9fedb6e7ed676ffe3b5e9a01a81771e92e1fe
+9744756fd34a604663afd80e4d4bd0e27c3a23d8be4aa679c69c1f507a1e938785808e14bdd29b
+d40b79bb418a91f1bea1f062823dea27b960ab45c9cecdd5bbac5c19561c3280cdadf7aba0f3b5
+ed5170b4bec83fbb094eb4b0b681d0fe78ce2d49fccbb61b5a980054ef862aef1191e82460d965
+b256c63e1babcda13c6733eabad1d8c4b2f17e709751bf72e286175db5aff7300f9f6d0de9a8ff
+bfe5e74a2b3545283f8c41a30ae0f592c8499059cc0473179f322aeef12b908addb89e358f1735
+83c2c9194f37b34f5c2eae78bcc1940c5c9cc230804a1d433737f805628a86f99e0823c01e2f05
+fdb2433b884abf97ab5f4e8427d65f11c69e533ad2032ecd1b2c218ffba545937141cc04d6ba77
+3893c3fe7ed7f0151edfee34574b11e3b447c1a2ba42927519aad2b6604529f7771db38e661688
+4d0941dfa528de1fe91cd219ceeea854daafdbc8861f004207ebfbe02c140ec3cdb3a63f075234
+afebb7a2fa084dee582ac1f542920cc0e9a3f8ac7a1c2d49e64f8c26f4e3e4b6938bece957ddb2
+8451122f81a44d4269e5cc60097d62031c7a9f0d7e309d137d66fbb0e0c2778a8c207e90ccef5e
+db20d38f97a08c754c4f5aec98a2dcb71defdf2445bec90d4ee42d38774ebb71735fb43ce60e20
+6d2ce41262253a895a25731d52bdd51f2d4a645379b576856bd29899c87a165a29f0108c875a72
+33a6c316affb256a595d154eedd236bb7b938ae8d632a065939a0bfcfe34a1edea17e3588ad179
+647fc1e63986214bb1444d3e896fe8cc16951dfacb834ec33873a9f88dfc4be603525affcf9a7d
+cce7ba441701b2d00532f92690ac996ccc07b3f5199a97f13038d701766220848715b2aa408c60
+e4167fbaf909b4e47cc799dc7d05f0ffd68194c551e73ce67094a25677ad372eb80a4f92aa25e0
+57608ecfaaa8931c256faba23c09f081b58f9532382c60c09e00c52853e12c5d8e67b9cb9a9755
+417fe12599f3232a677986e1a4e85364d594ac728ab48d0236e3b60d62c6c019b8ae2758d7a5da
+46d01e3be074dc415080231f1ca6ab01087ba0c74dc204d84a60faec9a0fbdd697a77bce7c844c
+de975affc2abd6c16b36f2c3b6f98017308e3baf18d733485e969491559c2d3fb69a6fd75d0b57
+02e75485ef26a23c08ba173f81a5cd9078d197b916bd3adf4674aabcd2cf11513d7a1bfd2ff04a
+d72672e621a5a7256d7f7b60a3a5928acd936a882d23139491c967f39c6e617d566a235865b45d
+3d7762b3d9c0d6fac7c37b9c671b43044e2f0c7a6d1b2eed0678f614c1c06321bf0cb6bbc4d21f
+59e1a69c70a08b3c44210c96c3aa2c47ec2eb2f5a8195949514ed58b0927c7fa16113617650a58
+608e45db5d122a467257a2ee5ce15cc1f980a966de341bab179bfc0993179e6ef109cb51d8ef3a
+9c1731a516dbdaab056f33ca16a8bb0c7140ba790e147b5bcbf5c4b79539cb502ed108fc31c775
+331ff044842a561d6ca1f4403d0c924d24b8d8d7afed358f7da2f5c9f873361c881b49e8aa3268
+b01cd1a4f555c5e829bdf0145bbd8f1c49424612c3238f4a2a8b2861d2e15e3d82abc73c655cc3
+3c93fe4d103ca20c14905ad1e1da3041fcb2e25bc48cd7ec23650b839630cf236f37abf09c7389
+87b26f8a6c054e30e41a4b371e33999e1bd73c1c0d52ccaa42ec272c9ac636692aeb2a8b5e6a82
+c13800fab6a414a1b02eac505544e4eb5d6c55cb590accf892ac3ece86b5138bf4ca25ba2d3b85
+d9f32ba93f38e8a058edd78ef1b4b59c9dcc3886e20b01141c5a47c689aea09773207ae29fb591
+7fcb57db7e0a0e47f349a81976dbcca0efc32b58bff868a26a8f709ccb99f786e1dbded7443255
+22f3abf53b31fb00622aa63080a054ea10b9b298c846dffecdb3f7b5fd454c56d848d566cb77ff
+a114b1e70e5cc79f9ba7002aae2522bb6c761eeb310522e6eb0728bf9e30140e6b0fdefaa0770a
+1b238a59b6b8af0d0975bae6cabfea2708c759e25c541055f7a9f0d941d575e43fdd3fb6af7d9b
+0b7ed75ada19868a60c90ce452a912a992273d126049c36d3449ea5aac04c3531f7d9507116f29
+0b4c885c60e0ef74182ac562648c82ef24add35647c88cc7da24ce719323024bd3927017cc4cf2
+d27f3c51ba0b8a1366ab0dcfb451377c21e89cdabbb0eb52e1f578b466748ba7000b68aa8074b4
+72d232b7f3b12e14245ceb3137a184b51b5a3b5128213bb17cd3bbfb48bd5702dd903b624735c3
+0259bb926419f02a15a805d4584dcb0da322e294d4b6459ff5f9948aacfa8e52106d00775592fe
+1e33afaa8742635837a04bb36988382f9b2bdf1325ec172ef9c813eff0adc18f6f1e8d960260f5
+18d7e9337aa2c690ec273a0a9b953e090f11139f84f729fe0a37f65822c98b2d4e8a09c077c98c
+7d362c86c29daac4e9d138b3b6e73389ed0614fdb00767b7dd76742351bcf2a44f440f828e7803
+f419769e595ef901c2e344bd60418de58272531f333e5f8cfe8fd95916292f28c29075ac3e672c
+81e80ae7a27d651852f3edbd790a5b8a2731df825bcbf86f2c58365a77f4ae953dbda9bce04430
+37da9a08a55e65506adfa96b76e513bcb8f9675304b28546822d849b2974ea0edc633d73b2fcea
+96eca803f8a59f208f0187cba6ca0cd4b641bd861fd3682c1a2da98f809225ca67d3283d43164d
+2783fb3e307cdd0a106d9cb48acbee2f015dea98207b5cc5c8349b9d7d16da59d0b88f3a970697
+120d7a731a1c209c8a2c4ed3c3d30412abefb31578a0842694681f1c055b634806c20ae0f5683a
+2800d80c9546cb4ebd30c585983e24840630a7f3867337727bea6d6ff599faf096669af9543a05
+bbed65104846cd9b3c231d1df669487d4652d2ace48afcbbaa592ddb5fb6355eff10ce8b414bb9
+9eb48dc13ebcf913b238171496d5cf3459722d3796dc83f988a5778eb89e5a93dacb05f56cb695
+49231804a96c9e056beb523f9ceead4bf7243a1013e839ef7de50106654ddd5371805b64cbf16b
+43163de6f8a96e8558896309a3de6be07df2e1028addb1242aaada003a18825e2bf376b8db8eeb
+954633634443f25e83a166399b61140a8c6e0ff16dcfc05ade69e58af8b726c44ffc2c1dd0c0e9
+842020e76b57f5bbbafb75886ee35bd5b018beda88fabf29f37c403baee20e35b2a7953d82735d
+b84e2f22658f5c99b520a893f4756003cbd53150611fdabdc4e2be36c76793a1a5a238d7e77d17
+f0199626ff6e2616cbec162884178e00e14cfd432113f33a8eea6df9ff2bdc1ef204de45bee434
+f9183e96ccc81a9fe84df0dbbc633b578553ebd763b0273ab9beed429b1e88bafe3ab5ed5d20b7
+4c169ffec0c2a124a1a5d7322cf5328ccb8d6a174a264d9ded8c776263bf2e4b1471c35622c8b1
+c909320e093ad67955a32a88027fe6f3a2d71ae529f9170bf188358ab01b55822d0158901439d1
+08eeb4579e684698f6cda07a59110f2a2aa5766f60fcdab6c27d9eabf39482c7d0805f6adfb8bb
+a05d5d8bc3c563d103d9c5681d39b2df4701235a4a00a6f0c80bf6f6f892421d1434c3fb6ebaed
+3219c3d13d613528c7182c2f62c48e48c04c783d74b16cea034d48dbe3cbdaee7c901e82d22721
+1e81f661a808db793fd329a1b8a443ecde1fa92c177fa1f925e62f1730bdece0d63cbd3b5bc972
+c4d2556ada6c97a534666797c03658fd6b089a2e939a4cf7e5374dd83d6bd9c78a28073e8d89be
+5c99c68a08065c36611c31c3c6822fd6d157589951048030ae1d1b7b306c4d0f89ccf8d2660866
+011b0eb4c802c359d94b8da9611926cb3b7cd58340beadf8a2771debaaf2105bb3efa9242e1f85
+d5b2263a0e8d8476b68d109bff369dcbe823b0a432b7df9c3f5b2d2247b857de0b7dee668261b8
+6883edb751eb20531d95828c0f73c450afb15add781aa6e9ff1d50b518e349e175a169e6c17214
+987a34aa6157a84527881f0e9ed62b55a1ca0b16c8b89fc9f189afd61f05bce3b591c5537390f7
+5c751e1922d9893a3a4a2b43f60e8a5ff01e9bd50af455f68a3ed55df406acbdad55ef14d579e1
+e73dbc0195bc6a8799243c796bc6dd4ac48116294cae9c1200feb5e75a1321728e2b6908e69437
+5323e6ddc8b2124856ba76ea90319f704f6d7401adfef2b120a8a6cf0671b45085a5590f87b125
+9fa97e1778dfc73dae6d7eab1acc3a2e348bf8878d309059bf69ab8de03b73bc7d33041fc54084
+1df2c66e489baa411a18faa6fef9e5574896de095bd72ff81098e5c279762523b0e5e1d0710d0c
+2603ddc998e7d7cf7ca52ec14c96e2198a0efaee66a07867d3268721569c57e5192490d61695fc
+e7fa26a4a1835773ca575cec9e32430cc6f1eca5ffc4bddff3848a2212f36bed37b0cf83276c40
+a1df717a67eed233b74a09df215751dc982f496f711cd93b0eeba34b696d52925f7b3dfe0fda0b
+a2157e377240607e8239f707f69bee83715016320dee33f5d8ca573c84764c051696c0604b5e20
+4786c708e95327ee33e3872d39fc93e459dd223132a02a4814164c131b422956a4ca96d933fa31
+b6707274b84975dae6ed1ddee1768df70348906a3dec81766dacbf366ef8d9dc44d8620706dcb2
+13790b53792ac8ce2d8628817ae373d701d979b7d053d7c0fdc45254693d9fe6c9d319549ce62c
+97d74bf301cb809a7fb4aeb9f13bd7773b43c55add6dfc49515636cd47fe4d813655dd15b0c77f
+52ee925cfdabac103243bdf1a79597944e71fab14dcefd3fc30436a85c5377981fbefa437b4a5b
+8030eeeeb5023aee5d1556c2dc20cc8275a7366b813fc6c3e72ceb7dde68c96f4b39c5fe86bcf2
+d04a772054cc3d28208d59dd21abc03e9ff58e4add5c4f2e0a7028761702370888461d0e43ba11
+1f81eb1893ea98ed2cf07bb03d939d2eaafc9532ac0d1a5eccd5f3c7d569dd715f03cf01d99ce4
+f034051828bf556320afc0d10999fb538e65cd43b63194354ccb11993eb56e85149dc22f5ef6d4
+6d751e8936ff69e5380546c16ffa74c74d501bd6c7168a68d10f9d0bdb225c375040fef33f6fd3
+8c2b23c7b7604f0c505b75f4442865f709ed90d25db46a402e6139f07221febc0e60b259ec81e5
+92d2cc2d0026de9fe5c03bb72ca48e847e6477a655cd3ae224a98099d4c5cb38dfe87e7704154d
+15ec2a73af6684f6b9ce86c803281aae9da73e17d31e83080f2c6a32687dfea2a2942e35bbf384
+d21c2756d894e908061f97a09ef92feec47e9a8650c63fb019137f993426098dc72844ac74dd1e
+270fc43e6f07a9ea6556b2e50c84bb3e6aba735887db7354a35fbc48b0d6c2e6387311b4557cfa
+afe906642ab93fca3b515c67f9cc0b03542ec44e3b173f16bedf663a40dedcd1b56937a30deedb
+f98c55882f04bcc9c8fed9dc96d35bbaa4bbc79f7ca03e5bd2b1439f62c332dc4a0ca34c4fd4cd
+dd4ff8b4a59f3cf1349f1f7b7a5ea5fb936e1b0358b6c099d4c8a98de281cfc3ec7e354a58bccd
+f49828ec9e776539faa688644a8ac75a647c14391b6a0cdbb9421ce21f0d199727c8bbc23b9e12
+7997a624b25ea89372ce0eae0c159394046652671081f86b6a59969c6d3c5a0b4b7872318b4cff
+cc94ea87cf40836291a9f4708c947c9170e44c9616a34f0b1d3f2cd9c4ee1614b48f25b98f0024
+d7ad8f57433a4dd66a73c6612470b94b80ecbf907bce0087a94b13881646e375a7305fa9fdc090
+d2048ca656b6c2054875345dbe12974c230718ff73bc40307eee64c489ed268cceda450a96e57d
+9c1a8b2a1698df481db1c1dc66c22f5dd301b9625d5f31faedd4ecccb09e5a44f378795124a370
+db5d32c93eb4dfeeb269037a40ef5b70532fbb8cec0e80d07e15178fcb4173b873adff580f7e12
+4d9a38a6ff6eb7c71990716fae167bafbee81f98a561773cbbce0c28dd62890c3cd5522d9959f0
+51c5e74c483f683a507dec4be1317f72b87ca112c8012f72c5459b6cce424e1fbb161e101e95d3
+ac206929f9357d2fc2008f50e49d82a5c60b995814899e10b421ab29c1edf0529bf940346995fd
+2764f559a771a7ad73a0cf2695054302bebc39a011be7d232fdc2fe9765018b639aaf56f4c5a1e
+ded3024b5dc81ef9ae26fc70634a0c6fb55de30a9b573360fd7e345382feb0415194c7649b9aa9
+13512e4cbee407253419ed3c6fd0b099c4da5475b23195144c31f6e102185533ec75a19a603f22
+d127e423693c86fe8ad224a4598446f9cd99d82e618d77f38807fa1928bbb2e6c2771b44400faa
+ba9c060210dc5e6ac9128ed85bfbaf080d59978771be5d731258f81e3814e9d5189f8190d1a2f3
+7d9872b22cd19a3f1b6c9d259d5ec69c8d84107b2bc65420878d644f59867931f994326e2e2ea9
+3833a612643316cb420af3b5932414b32f4557d1e84b5ab9858152e3fa12b55a3943b2342a4387
+501e02fc4323554d976e6327ad72cc1c96330e0bcc9d95fb1dae2cbd429114a1f85b7fe7c7cffb
+60365d78074f961548dbfd43ee5bcb8b6ca36adcd84dcc0cb587f262dfa978afc92d6d52bb3da2
+ae02b8513dc10a9422d1dbcf96948c6a0f572235fc58502a1f4aae0fb70847b94c14c91ecee4b3
+70faa1c1b3d7edf1ad7263f9da9b6a9d8980366f7d22c9d8b7122e89da221064c5f88f9f04ea61
+710fc63027f56dc84744bb05b4d91063bb97918926bced4c41fc7226d220f9904f9f963abee22a
+8e8874953d3c073b8875f687b88e0018be4e87dbb2d5bb38fc6bace64d97c1a661da728b8c5201
+92f98c5cf12ff77684bd977819e7e7e11403a8b811e7270a425af756f999634645ace62e196dab
+cc61dd1e0ae67e7b79beeb300cea0089d9625564866c1a3ee66b102f1144dd33d122cf242d03e3
+d85ebb3b55ee3545c901c1ac6035252f9e626d51fde9cc3b603659ec0e17a0109890c3a093049f
+92d3c08fc8f8f42f13d7402dfbd7a6a0170eab0b1e05f667321461d0db213a9cfa0ef0db1b3bbc
+7f730f4e470565d4ed0321413033190a1e0f869c8e4b911bfe06323765cb34c98d2c738c0a6045
+0063ab1e0ef73ccb13789beff049c452fc5f312f8a525683e40d0d97e9bba0d449657043e03295
+7b63d6b968bb1bde8d2f80e433606621754ec3099c34863137c51dc7f916151ef2dc3ea9293239
+4efe4a3a005d30ad47b7e5de9d50010ac04787b886f4375a55fb421a95134eb8ae71b00ca4dc35
+e57d71aa40765d305deaf3ccc17ac733ee49843f548e91bbcf85a39637cab7e1e14cb16c57d74e
+63abce864936dac940a4dc70967b137147d865c3789842587b54fd2b1380a63ac9d2e29dfc4a44
+ad00f3f079e2120e7e4e4f7ed370aaa00626bf42f7f42a503f5201de604c080f6f501896ec65e8
+fbb2467021631bcd52193d483f89ef2bb808724afd6548d5a77873e4d0b950dcfa4ed81dc9b06e
+6c2875cdafca22af89d46b746b7f1e5404a2d88a636b5f5f82557b639271ef2ce27cda5e4be693
+97e3bd1f5709207c16e279ff5260e6444afbeda16b4bc67a804780a32e8c7cfc3e627880b555f6
+27bc379ed9bce07c85fc38afa6aa52590ff5184d8acf560266219c103545d1aa646fd9959b25eb
+c51bf90632e54f8cca66e396fd64ddad9ec6e4615ad6727fb61c91129bf51c6222d4cf05dd832d
+bf1ca617cdc485e0a15bb0407aa6c57f4bd2e96fd29d9153f8f1b8ca539b4dd85d3d7a6a2a32f2
+400037bcaa286d12281021b68393b1da2ce3a740efaeae2502e0e4ce562b6eb6bbc974e5215265
+fb893a5773b0ea5f3190dd7ceb8ef594abac9641c9167dcba014989b8b1a3d5960dcde91af1919
+f578be8c2267debc3ed63506f8a9781f9daf1fd1ed2186bd5beaa84dec8b46587ae4585d63d172
+0c00447a1551ff8a794a00d50bb33ed49aae572babb3277e0640a031d5e76b5ae8d4cb20c71bf0
+48496cf816ee0c9c2090caf5092180fed559a561e3b0b752141e90fbc10f3cefac6bd6bc095d19
+7892497f8f0d16e9b3c8db157a1a7a87e3bfa21bb3a9df33c9310a6a13fe374204ab88dd58451f
+ca01d792cb1f298907709c15f6daae98da812de625ecc20403a5190b03a66cc6d5d24022df1e44
+a832b8cad49bb3568ea92f3e185221c7f568d8d100286bd18765a8a2258061ceab19031e25c803
+964ec8d0a151f057a272020d7396a08f1b54e30b5697688998d4b8683c4e4cefa58086646eae80
+90e0af1bcd8c2439520217d582b60256b5aeb0f83fb3eb16b6329c972a87e9388b2ac4d319e4c3
+40f639eddb3cc2b05298fbd73199c7077346282ff86ca071a615450bcfdfe8dc66ec2c1c4f4a58
+8dc7eeb01bdb71a453290785de18e0c761e0bd23f0a9a31e4adfbab34668b61d026fa57ad9d043
+5dde3940afd9bb707688ad1b2cac54c3de7d4d78be9546b57f2ca147380b90e06a1cd5d5305532
+7f9fa00f844b575ca38664f0d4c4820b8ba25dee12a67851f421cb62a50686d593695c49b85882
+a21f058bec0754091b9bdacc12466bba817a31be0376f517f879532e5d4e8f85dab1792057404d
+7294714b4e0ccc833bf2a8c9e690eee72d2cd5e415eaf1c37690da68a5b4bff3395be186e03e85
+b212977525b1c217107609462bc25613ef695fd5788aa96b30f31515c803cb64ccedd8a26e43c3
+e69d2430ba477d04d2ffd52429f56cfcd3e57077ac9e95c37d8bf1299aa01585cb3ec3b6920a7e
+20991a9e56c624d059f1cd4781ad4056fd1a72fbffc2a17051dae1d29711b655efc1d0e9b9c9bc
+c02fa0cdb5a870a850194028957b3326c4bff19ce4cbf6d1a30b1ea6fbf3851e984c7767aace95
+893c7adb243950b57ea2f8b59a98994362b92b79ab892bec828aae8c29fa829b2e0b5cfb757538
+858756872851fab1dec19d4ab3b71b8020e1d1d0f825b93af9086841e1b24c6478365ba536a65d
+3f35c081721855c2375b4075776623dd920cf838bf383e9629182d72bfc4b5089ad5c0ddfdd0fa
+55f6ee355e59bb68ddb7eae08d52c1d89c7210181266faa9020f3bddfbc16864de09f99e1c87b6
+b20fb131b97f10b874e9f92d33d4f3b01fbdcb946e967b94553071e8c16f97c1e6f4197b639123
+60a0a580070cb32b7f21bf05ebf49bc0741ac4c3ee476cb1523d39fa8d6af90eaa1010a281eeba
+740b62a4371d3f337728f11a4bde7fd8505e8a2eff07a147b37fec4178d24e6b3d846ab21f74b5
+e374aa7d59c77b2c4da89ff60c7f983d0d26de2b1b6d469c31523bcf9d7073dc971ad660e714aa
+958b2c46c6b00a3a8f3075bdff94a87aac93d6b1f738fe93ef39ddd36ee0ccaf86fd24ea23aed8
+4b668cd3035959513a02bc4d5a8a99e8f212528503d12c546ce3d5982705ab65bc5afd9f9b5f8f
+1f01c2e61beec9874f68ac5281a9a8dba257746c618170c54b0dbc08b176a39ee923292069765c
+2b9c8977c7a1a982aafca006a30f9e53bea99dc2881729d6f5eef84888da936b9124f7a42e3959
+8ba16d2a17b0efa68eac19cb6cf01a11c5b7b21dd74f7e49b93ac0ff44631f40083b8b89d3c36b
+e39d1ac33a145be901cd9723df070f3e5425ffe5f4536e460697514f6d719ef87ad900e7217fc4
+968ee08ea4de608da15b8c1c689067aa5921b7d18383e37d8fa31a31efbb0d0e77067ef0e710bb
+c59f5f05298a0cf230da01e4ad4a0daddd515aa65c2537eb96be26e0348951cc7b105092587426
+d6af8a71c38b1ad4d5ba06fec2cf20730c49b16d39c0649c639f23b28971cda948d915449d02eb
+4757c694ec2a5aa9e6ddf2771e026098ca774e0b2cb8e10e896f7d981ab23de939f414c246c11c
+159ab00d1945487b85078e23723bfe600322bb56e722baa4e9aed0b53a092b889b56cd04085609
+d0ed57050f99253e0cf74959f8a4ab993ed88f2efcf39eff81c495d96eb8334288c41a8a90ffcc
+9dfe68c732cd4d3c2421d56227de0aea8b710859011c7fc519b18875bdf25ef958b2358ad1cac9
+682d08d62a5792e5970d8df6252429bf410ea3e1e0d5b248252aeee7231aed7a5813e9ec994203
+280c1acb09effa7c45261a230c22b0148cb3f64760c1ea5ff7adc559715830179dc9e0dacf9880
+28ef994cc38207af9f7f3a473a9aa755c9a9d19332b44116433d65d28c4faca3a7cbecebd79d6f
+29414d41e106a41e57a58d71802bb657601546cb65043baa63c036dcbb79061f5dfc9c145b6be7
+12b51afb50537f85b2e459aee987c07d39585a24a25bf09ba5e9943580b6b01fa0640e1f1e1cab
+b3183355b2820e7bc3790d1f6895d40de43ecb8fde924960eaf37f31661c8588901a50f0765f6a
+f75e6dd6a216abb2eef9abdb011a39ab8183ffb62749d844a8c5411de8e2ff3363606c93514844
+a6c3875e7151c6c6b3a61be439f04c4af66ec638eb8688f9cb82b858f13bedc0b024eae98a1264
+eed76b155fd3fdbbd07c662e03015b1d3eaceae26a9e00268e5e32524a7b8d41e0ced6ad2baf8c
+a406f22279fb653e2346c040f18cd18c9fea36d4f6592e82a297af227d14cfb8282c3c562120c6
+0406f9d12c69013a012edfbc3f9d56e26169c7a901b2b463e3d1e901a4b3f9daafbe0d589eb7a1
+6f09dde2e72e16c80cc96f765d38ff86ca3265236f4ff77c9c2c2cbf3d0da810527d2b52e72eeb
+bf92749702d8f279d58f8b567e152f189e7eb2412f2bfb75de0f80e6b6d1bc8d116ecb4a2271d4
+80893eacf0d6e188060d58b59aa477d90af1095c0ca05381137efba090597b07debb081baad54e
+dfb2f046006de87abc10225afb6b72237090409146198863e40441e1810d20b1e8c4958d6388ea
+55f89cf918b8c155b12ccb1237e41b6a4441ea57d0e887d8277a6139fc9f209c2a5c4becb039a3
+26b2b3645ce804b7463204e9f275523f0827697d6c75c4b6a04235d7b7e0f86d9d27d9b50423f5
+ac07814e52e4aaea404d30f854545fdf21a25c7654655e9274ddda6e26131f9bce6f3e1c5ac088
+fbe1190878c476d681053c9088888535c0aaee78ee77b8aea965b9fc3adb587959d05f32569122
+2e7d621475cd634d053a29f15931011dba762b3278aba30c723687a0641632f8ba52118b1394ae
+82578b3f32fa257bc7662b5e2ead4d77a7869a57f9d7cddca16fa9c0a06a8acb84771630bdbc24
+06f8d69f9049f98e48048c8972beddf75006d1cb80e9f8c7035a60cacb562c996e301aba661183
+26e375866205d209f79f8be8fb9168e3a6d2a9847f13d4ce6b97e2ee98b64760a61bbb5474b15d
+ee12dd91f1259ef657e44812fb2b47b2cadc2b756a14b537d96269d230ec469d8d14fa521f054e
+72a5aac224d0064c7cab87bd53b439bfbf6cd8b6e9f93c37e7ecc20785ee6e82130d08d8d7acc7
+648d2ea96d74204a324208477f16c7e527cbb5373f765663273df9fc71e7b666e1b7b3543fd2c3
+5e851edbb725cbba758770282cba6d2316af49976829b0ddbe3a97d07f55a8
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
@@ -394,9 +369,9 @@ cleartomark
%%EndSetup
%%Page: 1 1
%%BeginPageSetup
-%%PageBoundingBox: 30 125 562 834
+%%PageBoundingBox: 30 124 562 834
%%EndPageSetup
-q 30 125 532 709 rectclip
+q 30 124 532 710 rectclip
1 0 0 -1 0 842 cm q
0 g
481.801 10 m 481.801 7.602 478.199 7.602 478.199 10 c 478.199 12.398 481.801
@@ -1320,16 +1295,16 @@ q 30 125 532 709 rectclip
417.801 698 m 417.801 695.602 414.199 695.602 414.199 698 c 414.199 700.398
417.801 700.398 417.801 698 c h
417.801 698 m f*
-0.18 0.545 0.341 rg
+0 0 1 rg
BT
-9.9626 0 0 -9.9626 416 297.993 Tm
+17.2154 0 0 -17.2154 384 314.001 Tm
/f-0-0 1 Tf
-[(Bigger)-333(Leaf)]TJ
--11.242045 3.21131 Td
-[(Middle)-333(Leaf)]TJ
--22.48409 4.818019 Td
-[(Small)-333(Leaf)]TJ
-40.150162 -19.271375 Td
+[(Bigger)-302(Leaf)]TJ
+-4.647002 2.788259 Td
+[(Middle)-302(Leaf)]TJ
+-13.011606 2.788201 Td
+[(Small)-302(Leaf)]TJ
+23.235011 -11.152863 Td
(Maple)Tj
ET
0 g
@@ -2602,9 +2577,9 @@ ET
121.801 514 m 121.801 511.602 118.199 511.602 118.199 514 c 118.199 516.398
121.801 516.398 121.801 514 c h
121.801 514 m f*
-0.18 0.545 0.341 rg
+0 0 1 rg
BT
-9.9626 0 0 -9.9626 112 713.993 Tm
+17.2154 0 0 -17.2154 112 714.001 Tm
/f-0-0 1 Tf
(Asymmetric)Tj
ET
diff --git a/Latex/conclusion.tex b/Latex/conclusion.tex
index 7cc7f17488368d37c372844bcb48b29dba69ebb7..920119b2646af6aa8dac2c87b20602a58be51749 100644
--- a/Latex/conclusion.tex
+++ b/Latex/conclusion.tex
@@ -1,9 +1,9 @@
-\section{Conclusion}\raggedbottom
-Given the fact that we adopted the model from \citep{myky} and only implemented it in another framework the models shortcomings are still present. It disregards different aspects that play a role in the venation pattern for real plants.
+\section{Conclusion} \label{section:conclusion}\raggedbottom
+Given the fact that we adopted the model from \citep{myky} and only implemented it in another framework, the models shortcomings are still present. It disregards different aspects that play a role in the venation pattern for real plants.
-Additionally our implementation, in its current version, is not capable of generating optimal solutions in a reasonable amount of time for the leaf representing graphs. The ASP implementation performs better on these graphs and therefore is the better choice for to implement the model. Even after different approaches to reduce the runtime were evaluated the ASP implementation performed better. Nevertheless there are still approaches that can be evaluated.
+Additionally our implementation, in its current version, is not capable of generating optimal solutions in a reasonable amount of time for the leaf representing graphs. The ASP implementation performs better on these graphs and therefore is the better choice to implement the model. Even after different approaches to reduce the runtime have been evaluated the ASP implementation performs better. Nevertheless there are still approaches to improve the ILP version that can be evaluated.
The next step for the ILP implementation should either be to adapt the edge based ILP formulation ESA and aspects of its implementation from the current SCIP-Jack software, or to improve the formulation of this thesis. It propably can be improved by inventing a symmetry breaker that reduces the number of symmetrical unconnected integer solutions which are determined in the solving process. Additionally it should be evaluated which type of constraints can be further preadded that would otherwise be added anyway in the process. Another important point is to find heuristics that allow to determine sufficient lower bounds faster.
-Though it is also reasonable to implement the suggestions from \citet{myky} to further improve the ASP implementation as it outperformed the ILP implementation.
+Though it is also reasonable to implement the suggestions from \citet{myky} to further improve the ASP implementation as it outperformes the ILP implementation.
\pagebreak
diff --git a/Latex/discussion.tex b/Latex/discussion.tex
index 545c736297b0c3a3abbbd42360c34afdfd5748f3..ea85cc20c783d1919a837099a92c0d639324c2a7 100644
--- a/Latex/discussion.tex
+++ b/Latex/discussion.tex
@@ -1,31 +1,29 @@
-\section{Discussion}\raggedbottom
-As already mentioned and as \citet{myky} stated our model has some shortcomings and disregards aspects that influence an optimal venation pattern in real plants. We only focus on minimizing the number of cells that have to be transformed into vein cells, under the condition that the entire leaf can still be supplied with water and nutrients. Doing so the number of photo synthetic active cells and their outcome should be maximized. Our model completely disregards the vein hierarchy and among other things that environmental circumstances also influence the venation pattern \citep{bio_veinh}. The fact that plants try to minimize their total branch length and the transport distance for nutrients \citep{bio_netw} is also disregarded.
+\section{Discussion} \label{section:discussion} \raggedbottom
+As already mentioned and as \citet{myky} states, our model has some shortcomings and disregards aspects that influence an optimal venation pattern in real plants. We only focus on minimizing the number of cells that have to be transformed into vein cells, under the condition that the entire leaf can still be supplied with water and nutrients. Doing so the number of photosynthetic active cells and their outcome should be maximized. Our model completely disregards the vein hierarchy and among other things that environmental circumstances also influence the venation pattern \citep{bio_veinh}. The fact that plants try to minimize their total branch length and the transport distance for nutrients \citep{bio_netw} is also disregarded.
-As our results revealed/ showed the neither the ILP implementation nor the ASP implementation are capable of generating solutions for our leaf graphs in a reasonable amount of time. The ILP implementation is incapable of finding an optimal solution in under 1000 seconds for the instance \textit{middle-leaf}, having only 62 nodes, with parameter $k = 1$. The ASP implementation on the other hand needed only 154 seconds to find an optimal solution. However both version find an appropriate upper bound in less than 1 second. The rest of the solving time is entirely used to close the gap from the lower bound.
-The instance \textit{GNM\_ 500\_ 62375} on the contrary has 500 nodes but the ILP implementation nevertheless finds a solution in 154 seconds, whereas the ASP version could not find an optimal solution after 1000 seconds. As the results show the same difference in runtime on other rather spare and large random graphs the ILP version seems to perform better on random graphs in general. As the results for the random graphs indicated our ILP implementation might be a reasonable approach applied to other problems which can be modeled with the \textit{Minimum Connected (rooted) k-hop Dominating Set} depending on the structure of the input instances.
+As our results reveal neither the ILP implementation nor the ASP implementation are capable of generating solutions for our leaf graphs in a reasonable amount of time. The ILP implementation is incapable of finding an optimal solution in under 1000 seconds for the instance \textit{middle-leaf}, having only 62 nodes, with parameter $k = 1$. The ASP implementation on the other hand needs only 154 seconds to find an optimal solution. However both versions find an appropriate upper bound in less than 1 second. The rest of the solving time is entirely used to close the gap from the lower bound.
+The instance \textit{GNM\_ 500\_ 62375} on the contrary has 500 nodes but the ILP implementation finds a solution in 154 seconds, whereas the ASP version can not find an optimal solution after 1000 seconds. The results show the same difference in runtime between the ILP version and the ASP version on other sparse random graphs. Therefore the ILP version seems to perform better on random graphs in general. As the results for the random graphs indicate our ILP implementation might be a reasonable approach applied to other problems which can be modeled with the Minimum Connected rooted k-hop Dominating Set depending on the structure of the input instances.
-As well as \citet{myky} made the observation for the ASP implementation that an increasing parameter $k$ reduces the runtime significantly our tests showed the same effect using the ILP implementation. For the random graphs and parameter $k = 2$ or $k = 3$ every instance could be solved in less than 1 second. It should also be noted that for most of the instances in this case only a few or even none constraints needed to be added lazily. Optimal solutions consisted in this case for the most instances only of the single root node or contained also a few additional nodes.
+As well as \citet{myky} made the observation for the ASP implementation that an increasing parameter $k$ reduces the runtime significantly our tests show the same effect using the ILP implementation. For the random graphs and parameter $k = 2$ or $k = 3$ every instance can be solved in less than 1 second. It should also be noted that for most of the instances in this case only a few or even none constraints need to be added lazily. Optimal solutions consist in this case for the most instances only of the single root node or contain a few additional nodes.
These results can not unconditionally applied to other real world problems as their graphs can have specific structures that differ from random graphs.
-Also on our leaf graphs an increasing $k$ implied a better runtime. However in the case of $k = 2$ and $k = 3$ the instances \textit{maple} and \textit{asymmetric} could not be solved under 1000 seconds. We can not simply arbitrarily increase the parameter $k$ in our model as vein cells must be in a range of 2-3 cells from mesophyl cells ~\cite[p.~469]{watertransport}.
-The runtime of the grid graphs also went down with increased $k$. For this graphs even with $k = 1$ an optimal solution could be found in under 1000 seconds. Admittedly all instances only had 64 nodes. As for the instance \textit{GRID\_ 8\_ 8} the time to find an optimal solution was 775 seconds it can be assumed that for larger instances the runtime exceeds 1000 seconds.
+Also on our leaf graphs an increasing $k$ implies a better runtime. However in the case of $k = 2$ and $k = 3$ the instances \textit{maple} and \textit{asymmetric} can not be solved in under 1000 seconds. We can not arbitrarily increase the parameter $k$ in our model as vein cells must be in a range of two to three cells from mesophyl cells ~\cite[p.~469]{watertransport}. The runtime of the grid graphs also decreases with increasing $k$. For this graphs even with $k = 1$ an optimal solution can be found in under 1000 seconds. Admittedly all instances only have 64 nodes. As for the instance \textit{GRID\_ 8\_ 8} the time to find an optimal solution is 775 seconds it can be assumed that for larger instances the runtime exceeds 1000 seconds.
-Using the \textit{intermediate node constraints} reduced the runtime the most. However in the most cases this constraints added unnecessary nodes to a solution which are not included without using this constraint. Nonetheless it could be considered to use this method to create approximative solutions. But for this purpose it would be desirable to formally prove the maximal amount of extra nodes in relation to an optimal solution. However our results show, at least exemplarily, that in most cases even without this additional constraint in rather short time appropriate upper bounds were established.
-For the instance \textit{middle-leaf} for example the ILP implementation as well as the ASP implementation found an upper bound in less than 1 second that does not differ from an optimal solution. Thus an approximation for the upper bound does not seem to be necessary. In fact a heuristic that generates an appropriate lower bound is much more desirable as closing the gap to the upper bound takes the major amount of time. Even for the rather large instance \textit{maple} an upper bound that does not differ from the optimal solution using the \textit{intermediate node constraint} is found after 29 seconds. At best this constraint could be used to evaluate how good upper bounds from the solving process are. But for this purpose an approximation factor would be necessary. For the \textit{asymmetric} an optimal solution could not be found under 1000 seconds even using this constraint. According to this there is still need for optimization to create a satisfying implementation even if this constraint is used.
+Using the \textit{intermediate node constraint} reduces the runtime the most. However in the most cases this constraint adds unnecessary nodes to a solution which are not included without using this constraint. Nonetheless it could be considered to use this method to create approximative solutions. But for this purpose it would be desirable to formally prove that there is a maximal ratio for the amount of extra nodes in relation to an optimal solution over all possible instances. However our results show, at least exemplarily, that in most cases even without this additional constraint in rather short time appropriate upper bounds are established.
+For the instance \textit{middle-leaf} for example the ILP implementation as well as the ASP implementation find an upper bound in less than 1 second that does not differ from an optimal solution. Thus an approximation for the upper bound does not seem to be necessary. In fact a heuristic that generates an appropriate lower bound is much more desirable as closing the gap to the upper bound takes the major amount of time. Even for the rather large instance \textit{maple} an upper bound that does not differ from the optimal solution using the \textit{intermediate node constraint} is found after 29 seconds. At best this constraint could be used to evaluate how good upper bounds from the solving process are. But for this purpose an approximation factor would be necessary. For the \textit{asymmetric} instance an optimal solution could not be found in under 1000 seconds even using this constraint. According to this there is still need for optimization to create a satisfying implementation using this constraint.
-According to the current information using vertex separators seem to be the best method to induce connectivity on graph theoretical problems. Alternative approaches from \citep{mtz} or \citep{klau} were not as succesfull for the corresponding problems in comparison to formulations that use vertex separators. Especially for the steiner tree problem \citet{fischetti_steiner_t} could achieve good results compared to other approaches. Also \citet{bomersbach} could achieve good results for the Connected Maximum Coverage Problem. In \citep{forrest} and \citep{fault_tolerant} this method was evaluated as promising.
-For our problem and especially for the graphs that represent our leafs this method was not satisfying. The same applies to quadratical grid graphs. We assume the high number of unconnected integer solutions that are generated in the iteration process as beeing crucial. These solutions are most likely in some manner symmetrical such that an appropriate symmetry breaker could reduce the runtime drastically.
+According to the current literature using vertex separators seems to be a favorable method to induce connectivity on graph theoretical problems. Alternative approaches from \citep{mtz} or \citep{klau} were not as succesfull for the corresponding problems in comparison to formulations that use vertex separators. Especially for the Steiner Tree problem \citet{fischetti_steiner_t} could achieve good results compared to other approaches. Also \citet{bomersbach} could achieve good results for the Connected Maximum Coverage Problem. In \citep{forrest} and \citep{fault_tolerant} this method was evaluated as promising.
+For our problem and especially for the graphs that represent our leafs this method is not satisfying. The same applies to quadratical grid graphs. We assume the high number of unconnected integer solutions that are generated in the iteration process as beeing a crucial aspect. These solutions are most likely in some manner symmetrical such that an appropriate symmetry breaker could reduce the runtime drastically.
-In general the ASP implementation performed better on our graphs representing the leafs. \citet{myky} mentioned different aspects in the conclusion of her thesis how the ASP implementation can be improved. As this implementation performed better than the ILP implementation so far it might be more reasonable to improve the ASP implementation rather than the ILP.
+In general the ASP implementation performs better on our graphs representing the leafs. \citet{myky} mentioned different aspects in the conclusion of her thesis how the ASP implementation can be improved. As this implementation performs better than the ILP implementation so far it might be more reasonable to improve the ASP implementation rather than the ILP.
-Another aspect that our tests revealed is that especially on such instance where there is a rather large gap between the size of an optimal unconnected solution and an optimal connected solution the runtime is relatively high. This is probably related to the fact that in such cases many constraints were added lazily, which indicates that there is a high amount of unconnected integer solutions. For the instances where the gap was rather tight the runtime was much better. In the tests from \citep{myky} an ILP implementation for the unconnected Minimum $k$-hop Dominating Set could create solutions much faster than the ASP implementation. This specific superiority is reflected here such that quickly valid solutions could be generated and it only needs to be verified if the solution is connected and otherwise only a few constraints needed to be added.
+Another aspect that our tests reveal is that especially on such instances where there is a rather large gap between the size of an optimal unconnected solution and an optimal connected solution the runtime is relatively high. This is probably related to the fact that in such cases many constraints are added lazily, which indicates that there is a high amount of unconnected integer solutions. For the instances where the gap was rather slim the runtime is much better. In the tests from \citep{myky} an ILP implementation for the unconnected Minimum $k$-hop Dominating Set can create solutions much faster than the ASP implementation. This specific superiority is reflected here such that quickly valid solutions could be generated and it only needs to be verified if the solution is connected and otherwise only a few constraints need to be added.
-The density has also shown as a parameter which highly influences the runtime. On sparse graphs both the ILP implementation and the ASP implementation performed rather bad. For the random graphs instances with 250 and 500 nodes could not be solved under 1000 seconds on rather sparse graphs with parameter $k = 1$. Our leaf graphs are all very sparse such that this effect plays a role as well. With increasing size the density of our graphs even decreases.
+The density has also been exposed as a parameter which highly influences the runtime. On sparse graphs both the ILP implementation and the ASP implementation perform rather bad. The random graphs instances with 250 and 500 nodes can not be solved under 1000 seconds on rather sparse graphs with parameter $k = 1$. Our leaf graphs are all very sparse such that this effect plays a role as well. With increasing size the density of our graphs even decreases.
-Preadding vertex separator constraints had an measurable influence on the runtime. Unfortunately this effect alone could not improve the runtime in a manner that a satisfying implementation for our model could be created. Despite the fact that many constraints were preadded there were still a lot constraints that were added in the iteration process. It could make sense to identify the types of constraints that are still added in the solution process to prevent unnecessary iterations when they are added beforehand. This might lead to a better runtime.
+Preadding vertex separator constraints has an measurable influence on the runtime. Unfortunately this effect alone can not improve the runtime in a manner that a satisfying implementation for our model can be created. Despite the fact that many constraints were preadded there were still a lot constraints that were added in the iteration process. It could make sense to identify the types of constraints that are still added in the solution process to prevent unnecessary iterations when they are added beforehand. This might lead to a better runtime.
Another approach to improve the implementation can be to add violated constraints not only after integer solutions are created but already when LP relaxations are calculated. This approach was used in \citep{forrest} and lead to sufficient LP bounds.
-Eine weitere Möglichkeit, das Verfahren zu optimieren, wäre es, constraints nicht nur dann hinzuzufügen, wenn eine ganzzahlige Lösung ermittelt wurde, sondern schon dann, wenn eine LP relaxierung ermittelt wird. Dieser Ansatz wurde auch in \citep{forrest} verfolgt. Dabei konnten sehr gute Erfolge hinsichtlich der Lp Bound erzielt werden.
-Recently a paper was published that compared different ILP formulations for the MWCSP \citep{esa}. \citet{esa} compare theoretically and empirically an edge based ILP formulation called Extended Steiner Arborescence Formulation (ESA) with the ILP formulation from \citep{fischetti_steiner_t}. In this paper it is proven that the polyhedron of the ESA is a real subset of the node based formulation from \citep{fischetti_steiner_t}. The computational results show that the ESA outperforms the node based one as the runtime was shorter for most instances. Also the with the ESA it was possible to solve previous unsovled instances. It it possible to create an ILP formulation for our model which uses the connectivity inducing constraints of the ESA. The implementation of the ESA is embedded in the upcoming version of \textit{SCIP-Jack}, a \textbf{C} based branch-and-cut framework for the Steiner Tree problem. The ESA also needs exponentially many constraints to induce connectivity. As the efficiency and the runtime of a branch-and-cut approach depends on concrete implementation details and used heuristics, it would be necessary to explore the source code and the documentation. There are also several publications that can be found on the official SCIP webpage \url{https://www.scipopt.org/} that can be helpful.
-It could also be reasonable to combine both approaches, such that a minimum $k$-hop dominating set $D_t$ is found at first and afterwards a minimun weight connected steiner tree $D$ with $D_t$ as set of terminals is found. This method could benefit from the facts that our ILP formulation can find unconnected minimum $k$-hop dominating sets rather quickly and MWCST instances can be solved very quick using ESA. However this might lead to not necessarily optimal solutions.
+Recently a paper was published that compared different ILP formulations for the MWCSP \citep{esa}. \citet{esa} compared theoretically and empirically an edge based ILP formulation called Extended Steiner Arborescence Formulation (ESA) with the ILP formulation from \citep{fischetti_steiner_t}. In this paper it is proven that the polyhedron of the ESA is a real subset of the node based formulation from \citep{fischetti_steiner_t}. The computational results show that the ESA outperforms the node based one as the runtime is shorter for most instances. Also with the ESA it is possible to solve previous unsovled instances. It is possible to create an ILP formulation for our model which uses the connectivity inducing constraints of the ESA. The implementation of the ESA is embedded in the upcoming version of \textit{SCIP-Jack}, a \textbf{C} based branch-and-cut framework for the Steiner Tree problem. The ESA also needs exponentially many constraints to induce connectivity. As the efficiency and the runtime of a branch-and-cut approach depends on concrete implementation details and used heuristics, it would be necessary to explore the source code and the documentation. There are also several publications that can be found on the official SCIP webpage \url{https://www.scipopt.org/} that can be helpful.
+It could also be reasonable to combine both approaches, such that an unconnected minimum $k$-hop dominating set $D_t$ is found at first and afterwards a minimun weight connected steiner tree $D$ with $D_t$ as set of terminals is found. This method could benefit from the facts that our ILP formulation can find unconnected minimum $k$-hop dominating sets rather quickly and MWCST instances can be solved very fast using ESA. However this might lead to not necessarily optimal solutions.
\pagebreak
diff --git a/Latex/implementation.tex b/Latex/implementation.tex
index 988a643b6d6281f28199b30104227362e96abc49..86ab37a5133f075ba11e8436e88f0e054093720d 100644
--- a/Latex/implementation.tex
+++ b/Latex/implementation.tex
@@ -1,12 +1,12 @@
-\section{Implementation} \raggedbottom
-Now, we specify the implementation of the ILP-formulations from the Methods section. We implemented the ILP-formulations and Algorithms \ref{alg:addConst} and \ref{alg:minSep} using Python version 3.7.5. As branch and cut framework and MIP-solver we use Gurobi version 9.0.2. Gurobi offers a Python interface called \textit{gurobipy} which can be called from inside python scripts. This interface offers access to functions included in Gurobi.
+\section{Implementation} \label{section:implementation} \raggedbottom
+Now, we specify the implementation of the ILP formulations from the Methods section. We implemented the ILP-formulations and Algorithms \ref{alg:addConst} and \ref{alg:minSep} using Python version 3.7.5. As branch and cut framework and mixed integer programming solver we use Gurobi version 9.0.2. Gurobi offers a Python interface called \textit{gurobipy} which can be called from inside python scripts. This interface offers access to functions included in Gurobi.
Our implementation is embedded in a conda package. The package is called \textit{k\_ hop\_ dominating\_ set\_ gurobi}. The source of the package can be found on \url{https://gitlab.cs.uni-duesseldorf.de/albi/albi-students/bachelor-mario-surlemont/}.
The package itself can be build via
\begin{lstlisting}[language=bash, frame=none, basicstyle=\small]
conda build .
\end{lstlisting}
after heading into the directory.
-To build the package \textit{conda-build} needs to be installed.
+To build the package the tool \textit{conda-build} needs to be installed.
Afterwards the package can be installed via
\begin{lstlisting}[language=bash, frame=none]
@@ -15,7 +15,7 @@ conda install --use-local k_hop_dominating_set_gurobi
It holds the dependencies \textit{networkX}, \textit{matplotlib.pyplot} and \textit{gurobipy}.
-The vertex separator constraints as well as the MTZ constraints can be chosen. The choice can be specified via the optional argument \textit{-mtz}, for the use of MTZ-constraints. By default the vertex separators are chosen. If required the additional constraints that have been presented in the method section can also be added to the model via the optional argument \textit{-imn| -rpl| -gaus| -pre} with rpl as abbreviation for the naive constraint to reduce the path length and gaus as abbreviation for the constraint involing the gaussian sum formula. The argument \textit{-pre} adds separators to the model before the solution process is started. When the intermediate node constraint is added via \textit{-imn} the generated solutions might not be optimal anymore.
+The vertex separator constraints as well as the MTZ constraints can be chosen. The choice can be specified via the optional argument \textit{-mtz}, for the use of MTZ constraints. By default the vertex separators are chosen. If required the \hyperref[subsection:additional]{additional constraints} that have been presented in the method section can also be added to the model via the optional arguments \textit{-imn| -rpl| -gaus| -pre} with rpl as abbreviation for the naive constraint to reduce the path length and gaus as abbreviation for the constraint involving the gaussian sum formula. The argument \textit{-pre} adds separators to the model before the solution process is started. When the intermediate node constraint is added via \textit{-imn} the generated solutions might not be optimal anymore.
As input networkx graphs stored as ``.graphml'' or ``.gml'' can be used. Also ``.lp'' files from \citep{myky} can be used. A full programm call is
\begin{lstlisting}[language=bash, frame=none, basicstyle=\small]
@@ -23,7 +23,7 @@ k_hop_dominating_set_gurobi -g graph.graphml -k k [OPTIONS]
\end{lstlisting}
with [OPTIONS] = \{-mtz, -inm, -rpl, -gaus, -pre\}.\\
-If the vertex separators are chosen to induce connectivity a lazy approach is used. Gurobi offers a callback function which is called during the solution procedure when different events occur. The function offers a code that communicates the type of the occured event. When the callback code \textit{MIPSOLVE} is communicated a mixed ILP-solution was generated. That is a solution where those variables that must be integers are integers while those variables which do not need to be intergers can be arbitrarily chosen (with respect to the inequalities).
-As we only have integer variables in our model the \textit{MIPSOLVE} code tells us that an integer solution $D^*$ was generated. In this case we check whether the graph is connected. We use a function that is included in networkx to check if the graph $G[D^*]$ is connected. If not, algorithm \ref{alg:addConst} is used to add the corresponding constraints.
-After a valid solution was found the inputgraph it is plottet via matplotlib.plt. The members of the dominating set are displayed in red while all the other vertices are displayed green.
+If the vertex separators are chosen to induce connectivity a lazy approach is used. Gurobi offers a callback function which is called during the solution procedure when different events occur. The function offers a code that communicates the type of the occured event. When the callback code \textit{MIPSOLVE} is communicated a mixed ILP solution has been generated. That is a solution where those variables that must be integers are integers while those variables which do not need to be integers can be arbitrarily chosen (with respect to the inequalities).
+As we only have integer variables in our model the \textit{MIPSOLVE} code tells us that an integer solution $D^*$ was generated. In this case we check whether the graph is connected. We use a function that is included in networkx to check if the graph $G[D^*]$ is connected. If not, Algorithm \ref{alg:addConst} is used to add the corresponding constraints.
+After a valid solution was found it is plottet via matplotlib.plt. The members of the dominating set are displayed in red while all the other vertices are displayed in green.
The console output shows information about the solving process and the solution. Such as the current upper bound and lower bound.
\ No newline at end of file
diff --git a/Latex/introduction.tex b/Latex/introduction.tex
index b21a6f2800394e75972896f3e8fb8159b7daea41..7e291ae136ad1846f5dce3c6e4c82d3bb044a21b 100644
--- a/Latex/introduction.tex
+++ b/Latex/introduction.tex
@@ -1,20 +1,18 @@
\section{Introduction}\raggedbottom
-Plants try to optimize their architecture to fulfil different objectives. One of it is to maximize the photosynthetic output. Another one is to minimize the cost to build the vascular system \citep{bio_netw}. To maximize the photosynthetic output plants optimize different parameters. As increasing one parameter can reduce another one, many parameters can not be optimized at the same time \citep{bio_netw} \citep{bio_nutrient}.
+Plants try to optimize their architecture to fulfill different objectives. One of it is to maximize the photosynthetic output. Another one is to minimize the cost to build the vascular system \citep{bio_netw}. To maximize the photosynthetic output plants optimize different parameters. As increasing one parameter can reduce another one, many parameters can not be optimized at the same time \citep{bio_netw}, \citep{bio_nutrient}.
In this thesis we focus on one particular mechanism how plants can optimize their photosynthetic output.
-
-To generate photosynthetical gains plants need sunlight, carbondioxid and water. (Photosynthese zitat. )
+To generate photosynthetical gains plants need sunlight, carbondioxid and water.
Water and nutrients are supplied via the vascular system. Xylem transports water to the leaves where the mesophyl cells produce sugars. These sugars are carried out to the whole plant by phloem, a tissue specialized on transporting sugars.
-Xylem and phloem cells are not able to generate sugars, but they are mandatory to supply water to the mesophyl cells and to transport sugars. To be satisfied with the amount of water mesophyl cells have access to, they must not be more than 2-3 cells away from a xylem cell. In this range water can flow from the xylem cells through mesophyl cells that are not next to a xylem cell via diffusion. At the same time sugars can be transported away from the mesophyl cells and supplied to the phloem if there is a phloem cell in the range of 2-3 cells. (Zitat finden. )
-
+Xylem and phloem cells are not able to generate sugars, but they are mandatory to supply water to the mesophyl cells and to transport sugars. To be satisfied with the amount of water mesophyl cells have access to, they must not be more than two to three cells away from a xylem cell. In this range water can flow from the xylem cells through mesophyl cells that are not next to a xylem cell via diffusion. At the same time sugars can be transported away from the mesophyl cells and supplied to the phloem if there is a phloem cell in the range of two to three cells~\cite[p.~469]{watertransport}.
-To produce as much sugar as possible the plant can try to(driven by evolutionary processes) maximize the number of mesophyl cells by minimizing the number of vein cells. In this thesis we describe a method to reproduce an optimal venation pattern that minimizes the number of vein cells with respect to the constraint that all mesophyl cells need to be in a fixed range to vein cells. Leaf veins have a hierarchy. In general there is at least one thick major vein branch and several narrow minor branches. This hierarchy is completely disregarded in our problem formulation. Environmental circumstances also influence the venation pattern \citep{bio_veinh}. These influences on the venation are also completely disregarded in our model.
- The input instance is given by an undirected graph $G = (V,E)$ that represents a leaf. The set of vertices $V$ represents the leaf cells while the set of edges $E$ represents the connections between the leaf cells in the form of plasmodesmata. To find an optimal pattern we use a special variant of the dominating set problem. For this problem we present an ILP-formulation and an implementation in a branch and cut framenwork.
+To produce as much sugar as possible the plant can try to (driven by evolutionary processes) maximize the number of mesophyl cells by minimizing the number of vein cells. In this thesis we describe a method to reproduce an optimal venation pattern that minimizes the number of vein cells with respect to the constraint that all mesophyl cells need to be in a fixed range to vein cells. Leaf veins have a hierarchy. In general there is at least one thick major vein branch and several narrow minor branches. This hierarchy is completely disregarded in our problem formulation. Environmental circumstances also influence the venation pattern \citep{bio_veinh}. These influences on the venation are also completely disregarded in our model.
+The input instance is given by an undirected graph $G = (V,E)$ that represents a leaf. The set of vertices $V$ represents the leaf cells while the set of edges $E$ represents the connections between the leaf cells in the form of plasmodesmata. To find an optimal pattern we use a special variant of the dominating set problem. For this problem we present an Integer Linear Programming (ILP) formulation and an implementation in a branch and cut framenwork.
-The dominating set problem and several variants are NP-hard \citep{ilp_np}. For our specific case we demand connectivity between the members of the set. This connectivity in ILP-formulations is subject of different prublications as it is not trivial.
-\citet{myky} presented in her bachelors thesis an alternative to ILPs. She implemented an algorithm for our problem using Answer Set Programming (ASP). For larger input instances the ASP-version did not create optimal solutions in a reasonable amount of time. \citet{myky} compared for the case where the dominating set does not need to be connected the runtime from an ILP-Version to the runtime from her ASP-version. Her tests revealed that for this particular problem the ILP-version performed significantly better.
+The Dominating Set problem and several variants are NP-hard \citep{ilp_np}. For our specific case we demand connectivity between the members of the set. This connectivity in ILP formulations is subject of different prublications as it is not trivial.
+\citet{myky} presents in her bachelors thesis an alternative to ILPs. She implemented an algorithm for our problem using Answer Set Programming (ASP). For larger input instances the ASP version did not create optimal solutions in a reasonable amount of time. \citet{myky} compared the runtime from an ILP version to the runtime from her ASP version for the case where the dominating set does not need to be connected. Her tests reveal that for this particular problem the ILP version performes significantly better.
-Goal of this thesis is to formulate an ILP and to evaluate wether if this performs better on our input graphs. We compared the ASP-version with an ILP-formulation that was created in this thesis. Contrary to the presumption that the ILP-version could generate solutions faster, on our input instances the ASP-version was significantly faster.
-However the ILP-version outperformed the ASP-version on random graphs. The different characteristics and the runtime for the graphs can be taken from the results section. In the discussion section we discuss which characteristics are responsible for the differences in the runtime and what effect initiates them.
-In Section 2, the Preleminaries, we will give a short introduction in ILP. Additionally important defintions are stated. After that in the following Section 3 we define the methods to find an optimal venation pattern. Section 4 demonstrates the implementation. At last in Section 4 and Section 5 we present the results and followed by a discussion on the effectiveness and limitations of the ILP-solution and which characteristics graphs hold to perform either better with the ILP-version or with the ASP-version.
+The goal of this thesis is to formulate an ILP and to evaluate wether if this performs better on our input graphs. We compare the ASP version with an ILP formulation that was created in this thesis. Contrary to the presumption that the ILP version could generate solutions faster, on our input instances the ASP version is significantly faster.
+However the ILP version outperformes the ASP version on random graphs. The different characteristics and the runtime for the graphs can be taken from the \hyperref[section:results]{results section}. In the \hyperref[section:discussion]{discussion section} we review which characteristics are responsible for the differences in the runtime and what effect initiates them.
+In \hyperref[section:preliminaries]{Section 2} we will give a short introduction in ILP. Additionally important defintions are stated. After that in \hyperref[section:methods]{Section 3} we define the methods to find an optimal venation pattern. \hyperref[section:implementation]{Section 4} demonstrates the implementation. At last in \hyperref[section:results]{Section 5} and \hyperref[section:discussion]{Section 6} we present the results followed by a discussion on the effectiveness and limitations of the ILP solution and which characteristics graphs hold to perform either better with the ILP version or with the ASP version.
\pagebreak
diff --git a/Latex/methods.tex b/Latex/methods.tex
index 0878cb49b2b8ea3c9d8f39d7c9f73aab173109bd..084ac712c44eb4f383e3de9b39c064e321616e06 100644
--- a/Latex/methods.tex
+++ b/Latex/methods.tex
@@ -1,14 +1,13 @@
-\section{Methods} \raggedbottom
-We represent a plant's leaf as an undirected graph $G = (V,E)$. Each vertex $v$ represents a leaf cell whereas a root $v_{root}$ is predefined. Leaf cells are connected to its neighboring cells via plasmodesmata. Plasmodesmata are microscopic channels that link plant cells, enabling transport of nutrients and water amongst of other things . Those connections are represented by the edges $E$. We then look for a minimum set of nodes such that the whole leaf can still be supplied with water and the nutrients can be collected. For this purpose these vein cells need as well as the root need to be connected. Those cells form our solution for a rooted connected $k$-hop dominating set $D$\\
-(Irgendwie unterbringen, dass die non-vein-Zellen nicht direkt mit den vein-Zellen benachbart sein müssen.)
+\section{Methods} \label{section:methods} \raggedbottom
+We represent a plant's leaf as an undirected graph $G = (V,E)$. Each vertex $v$ represents a leaf cell whereas a root $v_{r}$ is predefined. Leaf cells are connected to its neighboring cells via plasmodesmata. Plasmodesmata are microscopic channels that link plant cells, enabling transport of nutrients and water amongst of other things. Those connections are represented by the edges $E$. We then look for a minimum set of nodes such that the whole leaf can still be supplied with water and the nutrients can be collected. For this purpose these vein cells as well as the root need to be connected. Those cells form our solution for a rooted connected $k$-hop dominating set $D$, whereas the parameter $k$ denotes the maximal allowed path length between a vein cell and a non-vein cell. \\
\\
-We use a node based ILP-Formulation to solve this special variant of the dominating set. We start by introducing a formulation for the general $k$-hop dominating set. As the objective function for our special variant remains the same, we then add constraints in a stepwise manner until we can present an ILP-formulation for the rooted connected $k$-hop dominating set.\\
-As our implementation is node based we omit decision variables for edges, and instead only assign a variable $x_v \in \{0,1\}$ for every $v \in V$, with the interpretation $x_v = 1 \Leftrightarrow v \in DS$.
+We use a node based ILP formulation to solve this special variant of the Dominating Set problem. We start by introducing a formulation for the general $k$-hop Dominating Set problem. As the objective function for our special variant remains the same, we then add constraints in a stepwise manner until we can present an ILP formulation for the Rooted Connected $k$-hop Dominating Set problem.\\
+As our implementation is node based we omit decision variables for edges, and instead only assign a variable $x_v \in \{0,1\}$ for every $v \in V$, with the interpretation $x_v = 1 \Leftrightarrow v \in D$.
\subsection{Minimum Dominating Set}
As we try to minimize the number of vertices in the dominating set our ILP is given as:\\
\textit{objective target}:
\begin{equation} \label{obj}
-\min \lbrace \sum_{v \in V}{x_v} \rbrace
+\min{\sum_{v \in V}{x_v}}
\end{equation}
\textit{subject to:}
\begin{equation} \label{base}
@@ -17,7 +16,7 @@ As we try to minimize the number of vertices in the dominating set our ILP is gi
The family of inequalities \eqref{base} says that each vertex itself or at least one of its neighbors has to be included in the dominating set.
\subsection{Minimum $k$-hop Dominating Set}
-The objective target for this problem is the same as \eqref{obj}. But the family of inequalities \eqref{base} is not valid for this case. Instead another famility of inequalities is valid: \\
+The objective target for this problem is the same as \eqref{obj}. But the family of inequalities \eqref{base} is not valid for this case. Instead another family of inequalities is valid: \\
\begin{equation} \label{khop}
\sum_{w \in N_k(v)}{x_w} \geq x_v, \forall v \in V
\end{equation}
@@ -26,13 +25,10 @@ This family of inequalities serves to model the requirement that each vertex or
\subsection{Connectivity}
To enforce connectivity (using ILP) there are different approaches. As this is not trivial there have been many publications \citep{bomersbach}, \citep{fischetti_steiner_t}, \citep{fault_tolerant}, \citep{forrest}, \citep{on_imposing_con}, \citep{mtz} concerning this issue in the past years.
\subsubsection{Vertex separators}
-One approach is to use so called vertex separators. In \citep{bomersbach} and \citep{fischetti_steiner_t} the authors used this approach to create ILP based algorithms to solve other graph theoretical optimization problems which require the solution to be connected. \citet{bomersbach} presented an ILP-formulation to solve the connected maximum coverage problem and \citet{fischetti_steiner_t} proposed ILP-formulations for different variants of the steiner tree problem.
-(that was solved in a branch and cut framework?).
-As \citep{bomersbach} refers to \citep{fischetti_steiner_t} in terms of the connectivity constraints, both ILP-formulations use the same constraints to enforce connectivity.
-In \citep{bomersbach}, the authors compared the runtime of this implementation to previous proposed exact algorithms and to greedy approaches for the connected maximum coverage problem. In all test cases this implementation was significantly faster than all other exact algorithms. While in some cases the greedy algorithm was slightly faster, the proposed algorithm was more accurate.
-The algorithm from \citep{fischetti_steiner_t} significantly improved the runtime of an exact solver for all the different steiner tree problem variants and their proposed implementation won most of the different categories of the 11th DIMACS challenge on steiner trees.
-\\
-
+One approach is to use so called vertex separators. \citet{bomersbach} and \citet{fischetti_steiner_t} used this approach to create ILP based algorithms to solve other graph theoretical optimization problems which require the solution to be connected. \citet{bomersbach} presented an ILP formulation to solve the Connected Maximum Coverage problem and \citet{fischetti_steiner_t} proposed ILP formulations for different variants of the Steiner Tree problem.
+As \citet{bomersbach} refers to \citet{fischetti_steiner_t} in terms of the connectivity constraints, both ILP formulations use the same constraints to enforce connectivity.
+\citet{bomersbach} compared the runtime of this implementation to previous proposed exact algorithms and to greedy approaches for the Connected Maximum Coverage problem. In all test cases this implementation is significantly faster than all other exact algorithms. While in some cases the greedy algorithm is slightly faster, the proposed algorithm is more accurate.
+The algorithm from \citep{fischetti_steiner_t} significantly improved the runtime of an exact solver for all the different Steiner Tree problem variants and their proposed implementation won most of the different categories of the 11th DIMACS challenge on steiner trees.
\begin{figure}
\centering
\includegraphics[width=10cm]{bilder/vertex_separator_illustration.eps}
@@ -40,39 +36,39 @@ The algorithm from \citep{fischetti_steiner_t} significantly improved the runtim
\label{mtz}
\end{figure}
-Let $v,w \in V$. A $v$-$w$-separator is a subset $S_{v,w} \subset V$ such that $G[V-S_{v,w}]$ has no path between $v$ and $w$. A minimal $v$-$w$-separator $S_{{v,w}_{min}}$ is a $v$-$w$-separator where no vertex can be removed. That is, $S_{{v,w}_{min}} \setminus \{y\}$ is not a separator for $v$ and $w$. Let $S(v,w)$ (Use different notation. This is misleading) denote the family of all minimal $v$-$w$-separators. \\
-In \citep{bomersbach} and \cite{fischetti_steiner_t} the following family of inequalities is used to enforce connectivity:
+Let $v,w \in V$. A $v$-$w$-separator is a subset $S_{v,w} \subset V$ such that $G[V-S_{v,w}]$ has no path between $v$ and $w$. A minimal $v$-$w$-separator $\hat{S}_{{v,w}}$ is a $v$-$w$-separator where no vertex can be removed. That is, $\hat{S}_{{v,w}} \setminus \{y\}$ is not a separator for $v$ and $w$. Let $\mathcal{S}(v,w)$ denote the family of all minimal $v$-$w$-separators. \\
+In \citep{bomersbach} and \cite{fischetti_steiner_t} the following family of inequalities is used to enforce connectivity:
\begin{equation} \label{sep}
-x_v + x_w \leq \sum_{u \in S_{v,w}}{x_u} + 1, \forall v, w \in V, v \neq w, \forall S_{v,w} \in S(v,w)
+x_v + x_w \leq \sum_{u \in S_{v,w}}{x_u} + 1, \forall v, w \in V, v \neq w, \forall S_{v,w} \in \mathcal{S}(v,w)
\end{equation}
-This inequalities require that for each combination of two vertices $v$ and $w$, if both vertices included in the dominating set, at least one vertex from a minimum $v$-$w$-separator, has also to be included. \\
-In contrast to the problem from \citep{bomersbach} we have a predefined root node which must be part of the solution. In \citep{forrest} the authors introduced ILP-formulations for different problems motivated by forest planning. The objective of this problems is to find a profit maximizing harvest schedule, while old-growth-forest patches have to be conserved. Input instances are given as undirected graphs, with areas of the forest as nodes and edges between adjacent areas. There is one particular case where a predefined area is to be preserved plus all preserved areas need to be connected. This is very similar to our problem i.e. that there is a predefined root vertex and the requirement that all those vertices, which are included in the solution, need to be connected. Also minimum vertex separator constraints were used to enforce connectivity, but if a root node was present only those constraints which separate the connected component, that includes the root node, and all the other components were taken into account. The authors state that rooted inequalities are stronger as this was commonly noted in the literature on steiner tree problems. For our case we also only use constraints
+This inequalities require that for each combination of two vertices $v$ and $w$, if both vertices included in the dominating set, at least one vertex from all minimum $v$-$w$-separators has also to be included. \\
+In contrast to the problem from \citep{bomersbach} we have a predefined root node which must be part of the solution. \citet{forrest} introduced ILP formulations for different problems motivated by forest planning. The objective of this problems is to find a profit maximizing harvest schedule, while old-growth-forest patches have to be conserved. Input instances are given as undirected graphs, with areas of the forest as nodes and edges between adjacent areas. There is one particular case where a predefined area is to be preserved plus all preserved areas need to be connected. This is very similar to our problem, i.e., that there is a predefined root vertex and the requirement that all those vertices, which are included in the solution, need to be connected. Also minimal vertex separator constraints were used to enforce connectivity, but if a root node was present only those constraints which separate the connected component, that includes the root node, and all the other components were taken into account. The authors state that rooted inequalities are stronger as this was commonly noted in the literature on steiner tree problems. For our case we also only use constraints
\begin{equation} \label{rootSep}
-x_v + x_w \leq \sum_{u \in S_{v,w}}{x_u} + 1, \forall v, w \in V, v \neq w, \forall S_{v,w} \in S(v,r)
+x_v + x_w \leq \sum_{u \in S_{v,w}}{x_u} + 1, \forall v, w \in V, v \neq w, \forall S_{v,w} \in \mathcal{S}(v,r)
\end{equation}
-for minimum vertex separators that include the root node.
+for minimal vertex separators that include the root node.
-The number of all minimum vertex separator constraints is potentially exponential \citep{bomersbach}. Therefore in \citep{bomersbach}, \citep{fischetti_steiner_t} and \citep{forrest} they treated these constraints as lazy constraints, which means in particular that none of those constraints are included in the initial model. Instead iteratively integer solutions are resolved \citep{bomersbach}, \citep{fischetti_steiner_t}. If such a solution is not connected, in \citep{bomersbach} and \citep{fischetti_steiner_t} minimal vertex separators that separate single components are identified via a linear time algorithm, while in \citep{forrest} a classical max-flow min-cut theorem is used to identify violated constraints.\\
+The number of all minimal vertex separator constraints is potentially exponential \citep{bomersbach}. Therefore \citet{bomersbach}, \citet{fischetti_steiner_t} and \citet{forrest} treated these constraints as lazy constraints, which means in particular that none of those constraints are included in the initial model. Instead iteratively integer solutions are resolved \citep{bomersbach}, \citep{fischetti_steiner_t}. If such a solution is not connected, in \citep{bomersbach} and \citep{fischetti_steiner_t} minimal vertex separators that separate single components are identified via a linear time algorithm, while in \citep{forrest} a classical max-flow min-cut theorem is used to identify violated constraints.\\
Our algorithm to identify and add violated constraints is analogous the one from \citep{bomersbach} with the exception that we only search for violated constraints that include the root node.
\begin{algorithm}[H] \label{alg:addConst}
\SetAlgoLined
- $DS^* := \{v | x_v = 1\}$ \\
- $G' := G[DS]$\\
+ $D^* := \{v | x_v = 1\}$ \\
+ $G' := G[D]$\\
\If{$G'$ is not connected} {
$C := $ set of all disjunct connected components\\
- $c_{root} := $ connected component that contains $v_{root}$\\
- \For{all components $c$ in $C \setminus \{c_{root}\}$} {
+ $c_{r} := $ connected component that contains $v_{r}$\\
+ \For{all components $c$ in $C \setminus \{c_{r}\}$} {
$v := $ any node from $c$\\
- $s_1 := $ findMinVertexSeparator($G$, $DS^*$, $v \in c$, $v_{root}$, $c_{root}$)\\
- $s_2 :=$ findMinVertexSeparator($G$, $DS^*$, $v_{root}$, $v \in c$, $c$))\\
+ $s_1 := $ findMinVertexSeparator($G$, $D^*$, $v \in c$, $v_{r}$, $c_{r}$)\\
+ $s_2 :=$ findMinVertexSeparator($G$, $D^*$, $v_{r}$, $v \in c$, $c$)\\
\For{all $w_1 \in c$} {
- add the following constraint to the model: $\sum_{s \in s_1}{x_s} \geq x_{w_1} + x_{v_{root}} - 1$\\
+ add the following constraint to the model: $\sum_{s \in s_1}{x_s} \geq x_{w_1} + x_{v_{r}} - 1$\\
}
- \For{all $w_2 \in c_{root}$} {
+ \For{all $w_2 \in c_{r}$} {
add the following constraint to the model: $\sum_{s \in s_2}{x_s} \geq x_{w_2} + x_{v} -1 $
}
}
@@ -83,40 +79,40 @@ This algorithm is executed each time an integer solution is resolved (using a br
\begin{algorithm}[H] \label{alg:minSep}
\SetAlgoLined
- $N(c_v) := $ neighbors of nodes of $c_w$ in $G$ (Maybe use the formal definition from methods?)\\
+ $N(c_v) := $ neighbors of nodes of $c_w$ in $G$\\
$G' := G$ with all edges between vertices in $c_v \cup N(c_v)$ removed\\ \label{alg:remEdges}
$R_w := $ vertices that can be reached from $w$ in $G'$\\
\Return $N(c_v) \cap R_w$
-\caption{findMinVertexSeparator($G$, $DS^*$, $v \in c_v$, $w$, $c_v$)}
+\caption{findMinVertexSeparator($G$, $D^*$, $v \in c_v$, $w$, $c_v$)}
\end{algorithm}
-The algorithm above detects a minimal vertex separator that separates the node $w$ and the connected component $c_v$. It is taken from \citep{bomersbach} although \citet{bomersbach} took it initially from \citep{fischetti_steiner_t}. With this method the minimal vertex separator is found that is closest to the component $c_v$. In figure \ref{pic:min_sep} one can see an illustration of the process. Suppose the red marked nodes are an unconnected solution $D^*$. The set of blue marked nodes is the minimal separator that is closest to the connected component on the upper graph while the set of green marked nodes is the minimal separator that is closest to the component containing the root. On the picture in the middle and the right one can see the line \ref{alg:remEdges} of the algorithm \ref{alg:minSep}. As one can see, after removing all edges between the components and its neighborhood the blue marked nodes on the middle picture and the green marked nodes on the right picture are still reachable from the other component. Therefore the algorithm returns this selection of nodes as minimal vertex separator.
+The algorithm above detects a minimal vertex separator that separates the node $w$ and the connected component $c_v$. It is taken from \citep{bomersbach} although \citet{bomersbach} took it initially from \citet{fischetti_steiner_t}. With this method the minimal vertex separator is found that is closest to the component $c_v$. In figure \ref{pic:min_sep} one can see an illustration of the process. Suppose the red marked nodes are an unconnected solution $D^*$. The set of blue marked nodes is the minimal separator that is closest to the connected component on the upper graph while the set of green marked nodes is the minimal separator that is closest to the component containing the root. On the picture in the middle and the right one can see the line \ref{alg:remEdges} of the algorithm \ref{alg:minSep}. As one can see, after removing all edges between the components and its neighborhood the blue marked nodes on the middle picture and the green marked nodes on the right picture are still reachable from the other component. Therefore the algorithm returns this selection of nodes as minimal vertex separator.
\begin{figure}
\centering
\includegraphics[width=10cm]{bilder/find_minimal_separator_illustration.eps}
- \caption{}
+ \caption{Illustration of Algorithm 2}
\label{pic:min_sep}
\end{figure}
We add an additional constraint to the model to tighten up the feasible region and to prevent unnecessary iterations.
\begin{equation} \label{neigh}
-x_v \leq \sum_{w \in N(v)} x_w, \forall v \in V \setminus \{v_{root}\}
+x_v \leq \sum_{w \in N(v)} x_w, \forall v \in V \setminus \{v_{r}\}
\end{equation}
-This constraint demands that for each vertex which is part of the dominating set at least one of its neighbors is also included. In \citep{bomersbach} and \citep{fischetti_steiner_t} this constraint is also part of the model. As the neighborhood of a single vertex is always a minimal vertex separator that separates this node from any other vertex outside the neighborhood, this constraint is valid. We exclude the root node $v_{root}$ to prevent that for the case of a valid solution that only contains $1$ single vertex another one is added unnecessarily.
+This constraint demands that for each vertex, which is part of the dominating set, at least one of its neighbors is also included. In \citep{bomersbach} and \citep{fischetti_steiner_t} this constraint is also part of the model. As the neighborhood of a single vertex is always a minimal vertex separator that separates this node from any other vertex outside the neighborhood, this constraint is valid. We exclude the root node $v_{r}$ to prevent that for the case of a valid solution that only contains one single vertex another one is added unnecessarily.
-\subsubsection{Miller-Tucker-Zemlin Constraints}
-There are also formulations to enforce connectivity that only need a polynomially number of constraints. These constraints are not added lazily but instead all added initially. There exist some approaches that are based on the construction of a spanning tree. We have implemented one of these formulations in the scope of this thesis. This approach was used in \citep{mtz} to generate an ILP-formulation for the Minimum Connected Dominating Set problem. In the scope of the publication four different formulations, all based on creating a spanning tree, were compared (experimentally). This particular formulation outperformed all three others on all six input graphs. With increasing size the difference in the runtime became larger.
+\subsubsection{Miller-Tucker-Zemlin Constraints} \label{subsection:mtz}
+There are also formulations to enforce connectivity that only need a polynomially number of constraints. These constraints are not added lazily but instead all added initially. There exist some approaches that are based on the construction of a spanning tree. We have implemented one of these formulations in the scope of this thesis. This approach was used in \citep{mtz} to generate an ILP formulation for the Minimum Connected Dominating Set problem. In the scope of the publication four different formulations, all based on creating a spanning tree, were compared (experimentally). This particular formulation outperformes all three others on all six input graphs. With increasing size the difference in the runtime becomes larger.
In the scope of this thesis we therefore only compared this one with the vertex separator version.
-The Miller Tucker Zemlin constraints were initially introduced to present an ILP-formulation for the Traveling Salesman Problem with only polynomial many constraints. Let $G =(V,E)$ be our undirected input graph. We follow the description from \citep{mtz} by defining $G_d = (V \cup \{n+1, n+2\}, A)$ as directed graph, whereas $A = \{(n+1, n+2)\} \cup \{\bigcup_{i=1}^n{(n+1,i), (n+2,i)} \} \cup E'$ and $E' = \{(j,i), (i,j): {i,j} \in E \}$. Note that $E'$ is the bidirected version of $E$, that means, we add an arc in both directions for every edge in $E$.
+The Miller Tucker Zemlin (MTZ) constraints were initially introduced to present an ILP formulation for the Traveling Salesman Problem with only polynomial many constraints. Let $G =(V,E)$ be our undirected input graph. We follow the description from \citep{mtz} by defining $G_d = (V \cup \{n+1, n+2\}, A)$ as directed graph, whereas $A = \{(n+1, n+2)\} \cup \{\bigcup_{i=1}^n{(n+1,i), (n+2,i)} \} \cup E'$ and $E' = \{(j,i), (i,j): {i,j} \in E \}$. Note that $E'$ is the bidirected version of $E$, that means, we add an arc in both directions for every edge in $E$.
Let $n = |V|$. We create two additional nodes $n+1$ and $n+2$. Additionally we add an arc from $n+1$ and from $n+2$ to every vertex $v \in V$, and we add an arc from $n+1$ to $n+2$.
The idea behind the constraints is to create a directed spanning tree $T_d = (V \cup {n+1,n+2}, E_d)$ on $G_d$, such that vertex $n+1$ is a root and holds an arc (on $T_d$) to every vertex, which is not part of $D$ and to $n+2$. While $n+2$ holds an arc to a node $v_r$ within $D$. All the other nodes form a tree with root $v_r$.
-Let $y_{ij} \forall (i,j) \in A$ be decision variables, that specify whether the arc $(i,j)$ is part of the spanning tree $T_d$. Let $u_i \in \mathbb{Z}_+, \forall i \in V \cup \{n+1, n+2\}$ be auxiliary variables, that specify in which step the arc is passed starting from $n+1$. Those auxiliary variables eliminate sub tours as they also do in the Traveling Salesman Problem.
+Let $y_{ij} \forall (i,j) \in A$ be decision variables that specify whether the arc $(i,j)$ is part of the spanning tree $T_d$. Let $u_i \in \mathbb{Z}_+, \forall i \in V \cup \{n+1, n+2\}$ be auxiliary variables that specify in which step the arc is passed starting from $n+1$. Those auxiliary variables eliminate sub tours as they also do in the Traveling Salesman Problem.
-In the following we give a full ILP-formulation for to enforce connectivity via MTZ-constraints.
+In the following we give a full ILP formulation to enforce connectivity via MTZ constraints.
\begin{equation} \label{mtz_eq_1}
\sum_{i \in V}{y_{n+2,i}} = 1
@@ -149,33 +145,33 @@ x_i = 1-y_{n+1,i}, \forall i \in V
\begin{figure}
\centering
\includegraphics[width=10cm]{bilder/mtz_illustration.eps}
- \caption{Illustration of the principle. The dashed circle outlines the dominating set. All vertices, that are connected to $n+1$ are not part of the dominating set.}
+ \caption{Illustration of the principle. The dashed circle outlines the dominating set. All vertices that are connected to $n+1$ are not part of the dominating set.}
\label{mtz}
\end{figure}
-Constraints \eqref{mtz_eq_1} ensure that there is exactly one root for the dominating set. In our case we replace this inequality by the following: $y:{n+2,v_{root}} = 1$ and $y_{n+2, i} = 0, \forall i \in V \setminus \{v_{root}\}$.
+Constraints \eqref{mtz_eq_1} ensure that there is exactly one root for the dominating set. In our case we replace this inequality by the following: $y:{n+2,v_{r}} = 1$ and $y_{n+2, i} = 0, \forall i \in V \setminus \{v_{r}\}$.
Constraints \eqref{mtz_eq_2} enforce that each node on the spanning tree $T_d$ has exactly one incoming arc. While constraints \eqref{mtz_eq_3} require that all the nodes from $T_d$ are either connected to each other or have an incoming arc from node $n+1$, the node which marks nodes that are not part of $D$. With the exception of the term $(n-1)y_{ji}$ the constraints \eqref{mtz_eq_4} and \eqref{mtz_eq_5} are the original MTZ constraints to eliminate sub tours from \citep{mtz_orig}. The mentioned term is an improvement from \citep{mtz_improv}. Constraint \eqref{mtz_eq_6} demands the arc $(n+1,n+2)$ to be included in $T_d$.
-Constraints \eqref{mtz_eq_8} define the value of ranges for the auxiliary variables $u_i$. As these variables specify in which step the arc to node $i$ is passed, only values from $1$ - $n+1$ (the number of incoming arcs) can be assigned to it. Finally the last constraints \eqref{mtz_eq_9} ensure that if there is no incoming arc from node $n+1$ to a node $i$, then $i$ must be included in $D$ and vice versa (I think it is important to mention the backward direction as otherwise the impression could arise that only the MTZ constraints decide which vertices are included).
+Constraints \eqref{mtz_eq_8} define the value of ranges for the auxiliary variables $u_i$. As these variables specify in which step the arc to node $i$ is passed, only values from $1$ - $n+1$ (the number of incoming arcs) can be assigned to it. Finally the last constraints \eqref{mtz_eq_9} ensure that if there is no incoming arc from node $n+1$ to a node $i$, then $i$ must be included in $D$ and vice versa.
-We combine the above mentioned ILP-formulation for MkCDS with this formulation to enforce connectivity. The solution of this formulation then is a optimal connected solution with $v \in D \Leftrightarrow x_v = 1$. As previously mentioned this formulation only needs polynomial many constraints. More precisely there are $(|V|+2) + (2|E|+2|V|+1) = O(|E|+|V|)$ decision variables and $1 + |V| + 2|E| + 2|E| + (2|V|+1) + 1 + 1 + |V| = O(|E|+|V|)$ constraints.
+We combine the above mentioned ILP formulation for MkCDS with this formulation to enforce connectivity. The solution of this formulation then is a optimal connected solution with $v \in D \Leftrightarrow x_v = 1$. As previously mentioned this formulation only needs polynomial many constraints. More precisely there are $(|V|+2) + (2|E|+2|V|+1) = O(|E|+|V|)$ decision variables and $1 + |V| + 2|E| + 2|E| + (2|V|+1) + 1 + 1 + |V| = O(|E|+|V|)$ constraints.
\subsection{Minimum connected $k$-hop Dominating Set} \label{khopmodel}
-A connected $k$-hop dominating set is a $k$-hop dominating set DS such that $G[DS]$ is connected.(Maybe refer to methods as this is redundant?). Its ILP-Formulation consists of the objective target \eqref{obj} and constraints \eqref{khop} and a collection of constraints to induce connectivity(In the future different types of potential constraints should be added).
+A minimum connected $k$-hop dominating set (MCkDS) is a $k$-hop dominating set D such that $G[D]$ is connected. Its ILP formulation consists of the objective target \eqref{obj} and constraints \eqref{khop} and a collection of constraints to induce connectivity.
\subsection{Minimum rooted connected $k$-hop Dominating Set}
-Let $v_{root} \in V$ be the predefined root.The ILP-Model of this problem is the ILP-Model of \ref{khopmodel} enriched with following constraint.
+Let $v_{r} \in V$ be the predefined root.The ILP-Model of this problem is the ILP-Model of \ref{khopmodel} enriched with following constraint.
\begin{equation} \label{root}
-x_{v_{root}} \geq 1
+x_{v_{r}} \geq 1
\end{equation}
-\subsection{Additional methods to tighten up the space of feasible solutions}
-In the scope of this thesis additional constraints were tested, that should tighten up the space of feasible solutions further. As it can potentially cost much time to create unconnected solutions, we want to prevent unnecessary iterations.
-\subsubsection{Intermediate node constraint}
+\subsection{Additional methods to tighten up the space of feasible solutions} \label{subsection:additional}
+In the scope of this thesis we tested additional constraints that should tighten up the space of feasible solutions further. As it can potentially cost much time to create unconnected solutions we want to prevent unnecessary iterations.
+\subsubsection{Intermediate node constraint} \label{subsubsection:imn}
In the paper about the Steiner Tree Problem \citep{fischetti_steiner_t} one inequality to reduce the number of unconnected feasible solutions is proposed. It demands that for each node in the solution, which is not a predefined terminal, to have two neighbors in the solution. A node that has two neighbors in the solution can be seen as an intermediate node. Let $T$ be the set of all terminals. The inequality can formally be described as
\[2 * x_v \leq \sum_{w \in N(v)}{x_v}, \forall v \in T\]
-Unfortunately this inequality can not be applied to our problem without potentially excluding optimal solutions. By this inequality solutions can be generated, which have additional nodes at the end of branches, that are not necessary for the MkCDS but that are necessary to fulfill this inequality. In our case we would need to require that for each vertex, which is not at the end of a branch, this inequality needs to be satisfied. But we can not decide which node will be at the end of a branch in advance.
+Unfortunately this inequality can not be applied to our problem without potentially excluding optimal solutions. By this inequality solutions can be generated which have additional nodes at the end of branches that are not necessary for the MCkDS but that are necessary to fulfill this inequality. In our case we would need to require that for each vertex, which is not at the end of a branch, this inequality needs to be satisfied. But we can not decide which node will be at the end of a branch in advance.
-\begin{figure}
+\begin{figure}[H]
\centering
\includegraphics[width=10cm]{bilder/intermediate_node_constraint_illustration.eps}
\caption{The dashed circle outlines the necessity to have connected triplets at the end of a branch}
@@ -184,25 +180,29 @@ Unfortunately this inequality can not be applied to our problem without potentia
In figure \eqref{pic:inc} there is an illustration that compares one optimal solution without this constraint on the left and one with this constraint on the right. On the right hand side the end of a branch is circled to outline the additional node generated by this constraint.
-Even if the generated solutions are not inevitably optimal, the generated solutions are close to an optimal solution (in terms of the number of nodes). At the same time this constraint reduces the runtime in many instances drastically. That is why it can be considered to generate approximative solutions using this constraint. This constraint can also be used to generate a sufficient upper bound in the branch and cut process. But for the most instances this is not necessary as a sufficient upper bound is found quickly. It needs much more time to find a sufficient lower bound and to close the gap.
+Even if the generated solutions are not inevitably optimal, the generated solutions are close to an optimal solution (in terms of the number of nodes). At the same time this constraint reduces the runtime in many instances drastically. That is why it can be considered to generate approximative solutions using this constraint. This constraint can also be used to generate a sufficient upper bound in the branch and cut process. But for the most instances this is not necessary as a sufficient upper bound is found quickly. The solving procedure needs much more time to find a sufficient lower bound and to close the gap.
\subsubsection{Reduce path length}
-To exclude such solutions which contain single (unconnected) nodes, that are close to the rim we invented constraints to reduce the length of each path between the nodes of a solution and the root node. The length of each path to an arbitrary node is naturally limited by the number of members of the dominating set. In the extreme there is one single branch, which has exactly the length of the number of all members of the dominating set. In the case of more than one branch the upper bound is still valid. On that account we started by following the naive approach to limit the path from the root node to each member of $D$ by the size of $D$. The formal description is
-\begin{equation} \label{gaussian}
-\sum_{v \in V}{x_v} \geq shortestpath\{v_{root}, v\}, \forall v \in V \setminus \{v_{root}\}
+To exclude such solutions which contain single (unconnected) nodes, that are close to the rim we invented constraints to reduce the length of each path between the nodes of a solution and the root node. The length of each path to an arbitrary node is naturally limited by the number of members of the dominating set. In the extreme there is one single branch which has exactly the length of the number of all members of the dominating set. In the case of more than one branch the upper bound is still valid. On that account we started by following the naive approach to limit the path from the root node to each member of $D$ by the size of $D$. The formal description is
+\begin{equation} \label{rpl}
+\sum_{v \in V}{x_v} \geq shortestpath\{v_{r}, v\}, \forall v \in V \setminus \{v_{r}\}
\end{equation}
-As this constraint did not reduce the runtime we tried to refine it. There are too many possible (unconnected) solutions where the constraint is satisfied. Figure \ref{pic:rpl} shows one of it.
+As this constraint does not reduce the runtime we tried to refine it. There are too many possible (unconnected) solutions where the constraint is satisfied. Figure \ref{pic:rpl} shows one of it.
-\begin{figure}
+\begin{figure}[H]
\centering
\includegraphics[width=3cm]{bilder/reduce_path_length_illustration.eps}
\caption{An unconnected solution where the path length constraint is satisfied.}
\label{pic:rpl}
\end{figure}
-This circumstance leads to the following constraint, that makes use of the Gaussian sum formula. The idea is still to limit the distance between the root node $v_{root}$ and all the members of $D$. In this advanced formulation we limit the sum of the distances to $\sum_{i}^{|D*|}{i}$. This constraint cuts off unconnected solutions that are valid using only the previous constraint \eqref{rpl}. But as our tests revealed this constraint did not generate a performance boost but even increased the runtime(As it probably adds too much complexity to the model).
+This circumstance leads to the following constraint that makes use of the Gaussian sum formula. The idea is still to limit the distance between the root node $v_{r}$ and all the members of $D$. In this advanced formulation we limit the sum of the distances to $\sum_{i}^{|D*|}{i}$.
+
+\begin{equation} \label{gaus}
+\sum_{v \in V}{x_v} * shortestpath\{v_{r}, v\} \leq \frac{(\sum_{v \in V}{x_v + 1}) + \sum_{v \in V}{x_v}}{2}, \forall v \in V \setminus \{v_{r}\}
+\end{equation}
-(Maybe also mention that this constraint in isolation allows solutions which are forbidden using the previous one)
+This constraint cuts off unconnected solutions that are valid using only the previous constraint \eqref{rpl}. But as our tests reveal this constraint does not generate a performance boost but even increases the runtime, as it probably adds too much complexity to the model.
\subsubsection{Preventively adding separators}
-We use the lazy approach to prevent that too many constraints are added that are not mandatory to generate sufficient solutions. In despite of this we evaluated if adding particular separator constraints could reduce the runtime. It can be that a more appropriate LP bound is generated using this approach and unnecessary iterations can be prevented.
+We use the lazy approach to prevent that too many constraints are added that are not mandatory to generate sufficient solutions. In despite of this we evaluated if adding particular separator constraints could reduce the runtime. It could have been that a more appropriate LP bound is generated using this approach and unnecessary iterations could be prevented.
diff --git a/Latex/preliminaries.tex b/Latex/preliminaries.tex
index 92ab89652d9449bf7f93c0a47a58da293c2e8b53..c2e43a44f6cd72e38e04fde94b8dedf7e9b10941 100644
--- a/Latex/preliminaries.tex
+++ b/Latex/preliminaries.tex
@@ -1,28 +1,26 @@
-\section{Preliminaries}\raggedbottom
+\section{Preliminaries}\raggedbottom \label{section:preliminaries}
\subsection{Linear Programming}
Linear programming is a technique to minimize linear functions.
-The following definition is based on the book \citep{fischetti2019introduction}\\
+The following definition is based on the book \fullcite{fischetti2019introduction} \citep{fischetti2019introduction}.\\
-A linear program (LP) problem consists of an linear objective function that is minimized with respect to a set of linear inequalities. \\
+A linear program (LP) problem consists of a linear objective function that is minimized with respect to a set of linear inequalities. \\
\\
Linear programs can be expressed as
\[\min\{c^Tx : Ax \geq b, x \geq 0\}\]
where $b \in \mathbb{R}^m$ and $c \in \mathbb{R}^n$ are constant vectors. The matrix $A \in \mathbb{R}^{m \times n}$ contains the coefficients of the $m$ inequalities. We minimize the objective function $c^Tx \in \mathbb{R}$. The vector inequality $Ax \geq b$ has to be satisfied for a valid solution.
The vector $x \in \mathbb{R}^n$ describes possible solutions. If $x \in \mathbb{R}^n$ satisfies all inequalities it is called a feasible solution. A solution $x^*$ is optimal if it respects all inequalities and is minimal.
\\
-\\
Integer linear programs (ILPs) are linear programs with the additional restriction that all variables have to be integers: $x \in \mathbb{Z}^n$.
The decision variant of an ILP is NP-complete \citep{ilp_np}.
\\
-\\
-Each line $j$ of $Ax \geq b$ can be expressed as the sum $\sum_{i=1}^{n}{a_{ij}x_i} \geq b_j$. The objective function can be expressed as $\sum_{i=1}^n{c_ix_i}$. In this thesis we use this notation as we perceive it as more readable.
+Each row $j$ of $Ax \geq b$ can be expressed as the sum $\sum_{i=1}^{n}{a_{ij}x_i} \geq b_j$. The objective function can be expressed as $\sum_{i=1}^n{c_ix_i}$. In this thesis we use this notation as we perceive it as more readable.
Combinatorial optimization problems can be modeled with ILPs. Every variable $x_i \in \{0,1\}$ denotes a possible decision to include item $i \in \{1,...,n\}$ in the solution.
\subsection{Definitions}
\begin{definition}[Neighborhood]
-Given an undirected graph $G = (V,E)$. Let $N(v)$ denote the neighborhood of a vertex $v$. $N(v)$ can formally be described as follows: \[w \in N(v) \Leftrightarrow \exists (v,w) \in E\]
+Given an undirected graph $G = (V,E)$. Let $N(v)$ denote the neighborhood of a vertex $v$. $N(v)$ can formally be described as follows: \[w \in N(v) \Leftrightarrow \{v,w\} \in E\]
\end{definition}
\begin{definition}[Dominating Set]
-Given an undirected Graph $G = (V,E)$ a dominating set is a subset $D \subset V$ such that each vertex $v \in V$ is either included in the dominating set or adjacent to at least one vertex which is included in the dominating set. For a dominating set $D$ the following statement is valid
+Given an undirected Graph $G = (V,E)$ a dominating set is a subset $D \subset V$ such that each vertex $v \in V$ is either included in the dominating set or adjacent to at least one vertex which is included in the dominating set. For a dominating set $D$ the following expression is valid
\[\forall v \in V \setminus D: \exists u \in D, u \in N(v)\]
\end{definition}
@@ -32,7 +30,7 @@ The neighborhood of a single vertex $N(v)$ is defined above. Let the neighborhoo
Let $k \in \mathbb{N}$.
With help of this definition the k-neighborhood $N_k(v)$ of a single vertex $v \in V$ can recursively be defined as:
\[N_k(v) := N(N_{k-1}(v)) \setminus v\]
-whereas $N_1(v) = N(v)$. So $N_k(v)$ is a set of all vertices which can be reached with at most $k$ steps starting from $v$.
+whereas $N_1(v) = N(v)$. This means that $N_k(v)$ is a set of all vertices which can be reached with at most $k$ steps starting from $v$.
\end{definition}
\begin{definition}[k-hop Dominating Set]
@@ -41,15 +39,13 @@ A $k$-hop dominating set is a subset $D \subset V$ such that for each vertex $v
This means that each vertex is either part of $D$ or in $N_k(w)$ for any $w \in D$.
\end{definition}
-\begin{definition}[connected k-hop Dominating Set]
-A $k$-hop dominating set $D$ is a connected $k$-hop Dominating Set if the induced subgraph $G[D]$ is connected.
+\begin{definition}[Connected k-hop Dominating Set]
+A $k$-hop dominating set $D$ is a connected $k$-hop dominating set if the induced subgraph $G[D]$ is connected.
\end{definition}
-\begin{definition}[rooted connected k-hop Dominating Set]
+\begin{definition}[Rooted Connected k-hop Dominating Set]
Let $v \in V$ be the \emph{root}.
A rooted connected $k$-hop dominating set $D$ is as connected $k$-hop dominating set which also includes $v$.
\end{definition}
-
-(Add a definition for what "connected" means)
\pagebreak
diff --git a/Latex/references.bib b/Latex/references.bib
index 39c0ed1594c52a6e1071c815f0eb4547234a6d0d..9d2ba03ef7ff5205d74ec43bf22ca5ad515199e3 100644
--- a/Latex/references.bib
+++ b/Latex/references.bib
@@ -52,11 +52,7 @@ doi = {10.1007/s10107-017-1117-8}
}
@book{fischetti2019introduction,
title={Introduction to Mathematical Optimization},
- author={Fischetti, M.},
- isbn={9781692792022},
- url={https://books.google.de/books?id=0sbhyQEACAAJ},
- year={2019},
- publisher={Independently Published}
+ author={Fischetti, M.}
}
@article{forrest,
author = {Carvajal, R. and Constantino, M. and Goycoolea, M. and Vielma, J. and Weintraub, A.},
@@ -165,7 +161,7 @@ journal = {The New phytologist},
doi = {10.1111/nph.12253}
}
@bachelorsthesis{myky,
- author={Hyunh, M. K.},
+ author={Huynh, M. K.},
title={Solving Dominating Set Using Answer Set Programming},
school={Heinrich Heine University Düsseldorf},
year={2020},
diff --git a/Latex/results.tex b/Latex/results.tex
index 537a1833244ff2d88472b5aa3587d74debb0e9b6..20b40ceff87a098c846ff37216ef0f791333b570 100644
--- a/Latex/results.tex
+++ b/Latex/results.tex
@@ -1,5 +1,5 @@
\section{Results}\raggedbottom
-This section shows our results of the runtime for the Minimum Connected rooted k-hop Dominating Set problem. We test the graphs that represent plant leafs from \citep{myky} as well as randomly generated graphs and grid graphs. At first we briefly describe the graphs from \citep{myky} and our other test graphs. A more detailed description of the leaf graphs can be taken from \citep{myky}. All tests have been performed using a notebook with an Intel Core i7-4720HQ CPU @ 2.60GHz x 8 and 8 GB of RAM under Ubuntu 18.04.14 LTS and in all test cases we only looked for one single optimal solution.
+This section shows our results of the runtime for the Minimum Connected rooted k-hop Dominating Set problem. We tested the graphs that represent plant leafs from \citep{myky} as well as randomly generated graphs and grid graphs. At first we briefly describe the graphs from \citep{myky} and our other test graphs. A more detailed description of the leaf graphs can be taken from \citep{myky}. All tests have been performed using a notebook with an Intel Core i7-4720HQ CPU @ 2.60GHz x 8 and 8 GB of RAM under Ubuntu 18.04.14 LTS and in all test cases we only looked for one single optimal solution.
As leaf graphs we use the instances \textit{small-leaf}, \textit{middle-leaf}, \textit{bigger-leaf}, \textit{maple} and \textit{asymmetric}. The instances \textit{small-leaf}, \textit{middle-leaf} and \textit{bigger-leaf} are similar in their structure. Each of the three graphs has the root at the bottom side and a symmetrical composition. They only differ in the number of nodes. The smallest graph \textit{small-leaf} has only 15 nodes while \textit{middle-leaf} has 62 nodes and \textit{bigger-leaf} has 71 nodes. While \textit{maple} represents a maple's leaf having 118 nodes, \textit{asymmetric} is inspired by an alocasia leaf. The peculiarity here is that it has the root in the middle of the leaf. It has 378 nodes.
@@ -11,7 +11,7 @@ The following figure illustrates the 5 different leaf graphs.
\label{fig:graphs}
\end{figure}
-First of all we introduce a table demonstrating different characteristics of the leaf graphs. The first two columns show the size of the graph, i.e., the number of nodes and edges. The density is shown in the third column. It is a measure that indicates the relative amount of the number of edges a graph has to the theoretical number a graph can have.
+First of all we introduce a table demonstrating different characteristics of the leaf graphs. The first two columns show the size of the graph, i.e., the number of nodes and edges. The density is shown in the third column. It is a measure that indicates the relative amount of the number of edges a graph has to the theoretical number of edges a graph can maximally have.
Additionally the maximal, the average and the minimal node degree is shown. These parameters imply if a graph has at least one node with a much higher degree than the average or if the degrees are equally distributed.
\begin{table}[H]
@@ -28,14 +28,14 @@ Additionally the maximal, the average and the minimal node degree is shown. Thes
\caption[The characteristics of the leaf graphs]{The characteristics of the leaf graphs}
\end{table}
-We then continue with the runtime of our ILP-implementation using the leaf graphs as input.
-The following tables present the runtime in seconds as well as the number of constraints that were lazily added in the solution process. The last column shows the size of an optimal solution, i.e., the number of nodes that form a minimum dominating set.
-For the case that the solution process took more than 1000 seconds we state the upper bound and the lower bound that were determined within this time. The upper bound specifies the smallest solution that was found until the time was over. This means that an optimal solution will not be larger than the upper bound. In contrast the lower bound gives the smallest theoretical possible size of an optimal solution to that time. Let $U$ be an upper bound and $L$ be an lower bound. In the column \textit{optimal} we used the denotion $[U,L]$.
+We then continue with the runtime of our ILP implementation using the leaf graphs as input.
+The following tables present the runtime in seconds as well as the number of constraints that are lazily added in the solution process (denoted by \# C). The last column shows the size of an optimal solution, i.e., the number of nodes that form a minimum dominating set.
+For the case that the solution process takes more than 1000 seconds we state the upper bound and the lower bound that were determined within this time. The upper bound specifies the smallest solution that was found until the time was over. This means that an optimal solution will not be larger than the upper bound. In contrast the lower bound gives the smallest theoretical possible size of an optimal solution to that time. Let $U$ be an upper bound and $L$ be an lower bound. In the column \textit{optimal} we use the notation $[U,L]$.
-\begin{table}[H]
+\begin{table}[H] \label{table:ilp_leaf}
\centering
\begin{tabular}{l cccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal \\
+ name & k & \# C & runtime(s) & optimal \\
\hline
small-leaf & 1 & 9 & 0.01237 & 6 \\
& 2 & 4 & 0.007257 & 3\\
@@ -56,9 +56,9 @@ For the case that the solution process took more than 1000 seconds we state the
\caption[Minimum Connected rooted $k$-hop Dominating Set Results on the leaf graphs]{Minimum Connected rooted $k$-hop Dominating Set Results on the leaf graphs}
\end{table}
-With increasing parameter $k$ the runtime decreases significantly. Additionally this table indicates a relation between the number of constraints that are added lazily and the runtime. Besides some outliers it seems like a high number of lazily added constraints implies a higher runtime. The more constraints that are added the more frequent unconnected integer solutions are found in the solution process. This effect occurs especially on input instances that have many symmetrical solutions which are unconnected. If the input graph only has nodes that have a degree close to the average degree, then more likely this instance has many different symmetrical solutions. In such instances there is no node that is so valuable that it has to be included in the solution. If an unconnected integer solution is generated violated constraints are added to the model. After adding these constraints it most likely is cheaper to swap the nodes and use nodes where no violated constraints have been added yet than to use the same nodes and add those nodes, that the added constraints demand. On graphs where some nodes exist that have a significant higher degree than the average adding constraints more likely will not exclude them from a solution as they cover to many other vertices. This effect is roughly indicated by the number of lazily added constraints. If only a few constraints were added then there probably will not have been many options to swap valuable nodes without creating to many costs.
+With increasing parameter $k$ the runtime decreases significantly. Additionally this table indicates a relation between the number of constraints that are added lazily and the runtime. Besides some outliers it seems like a high number of lazily added constraints implies a higher runtime. The more constraints that are added the more frequent unconnected integer solutions are found in the solution process. This effect occurs especially on input instances that have many symmetrical solutions which are unconnected. If the input graph only has nodes that have a degree close to the average degree, then more likely this instance has many different symmetrical solutions. In such instances there is no node that is so valuable that it has to be included in the solution. If an unconnected integer solution is generated violated constraints are added to the model. After adding these constraints it most likely is cheaper to swap the nodes and use nodes where no violated constraints have been added yet than to use the same nodes and add those nodes, that the added constraints demand. On graphs where some nodes exist that have a significant higher degree than the average, adding constraints more likely will not exclude them from a solution as they cover to many other vertices. This effect is roughly indicated by the number of lazily added constraints. If only a few constraints were added then there probably will not have been many options to swap valuable nodes without creating to many costs.
-With increasing size, i.e., number of nodes a graph has, the density of our graphs decreases. The density of the graph is another indicator that roughly implies the runtime \citep{fault_tolerant}. Especially on graphs with unequal distribution of node degrees. As with increasing size the density decreases on our graphs, the tests can not clearly indicate if the size is purely responsible for the runtime or if the density also has an influence. In the following we will test random generated graphs that have different size and for each size 10 different levels of density. On this graphs the density clearly is the determining factor for the runtime.
+With increasing size, i.e., number of nodes a graph has, the density of our graphs decreases. The density of the graph is another indicator that roughly implies the runtime \citep{fault_tolerant}. Especially on graphs with unequal distribution of node degrees. As with increasing size the density decreases on our graphs, the tests on the leaf graphs can not clearly indicate if the size is purely responsible for the runtime or if the density also has an influence. In the following we will test random generated graphs that have different size and for each size ten different levels of density. On this graphs the density clearly is the determining factor for the runtime.
The next table shows the characteristics of the random graphs.
\begin{table}[H]
@@ -110,57 +110,56 @@ The next table shows the characteristics of the random graphs.
\caption[The characteristics of the random graphs]{The characteristics of the random graphs}
\end{table}
-We have random graphs of four levels of size(|V| = 50; 100; 250; 500). For each of these levels we have ten levels of density(0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0) to explore particularly its influence on the runtime. In the following table we only present the results for the density levels 0.1, 0.5 and 0.9 . The appendix contains the complete tables.
-The results clearly show that, despite the larger size of the random graphs, the runtime is significantly shorter than on the leaf graphs. The density here seems to be a reasonable parameter that implies the runtime. On dense graphs few nodes are mandatory to form a dominating set. This allows to find an optimal solution faster.
+We have random graphs of four levels of size (|V| = 50; 100; 250; 500). For each of these levels we have ten levels of density (0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0) to explore particularly its influence on the runtime. In the following table we only present the results for the density levels 0.1, 0.5 and 0.9. The \hyperref[appendix:tables]{appendix} contains the complete tables. The results clearly show that, despite the larger size of the random graphs, the runtime is significantly shorter than on the leaf graphs. The density here seems to be a reasonable parameter that implies the runtime. On dense graphs few nodes are mandatory to form a dominating set. This allows to find an optimal solution faster.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
GNM\_ 50\_ 122 & 1 & 66 & 0.034878 & 11\\
- GNM\_ 50\_ 122 & 2 & 67 & 11 & 0.03795\\
- GNM\_ 50\_ 122 & 3 & 0 & 2 & 0.01651\\
+ GNM\_ 50\_ 122 & 2 & 67 & 0.03795 & 11 \\
+ GNM\_ 50\_ 122 & 3 & 0 & 0.01651 & 2\\
GNM\_ 50\_ 612 & 1 & 0 & 0.017783 & 4\\
- GNM\_ 50\_ 612 & 2 & 0 & 1 & 0.002223\\
- GNM\_ 50\_ 612 & 3 & 0 & 1 & 0.002541\\
- GNM\_ 50\_ 1102 & 1 & 3 & 0.019566 & 3\\
- GNM\_ 50\_ 1102 & 2 & 0 & 1 & 0.012025\\
- GNM\_ 50\_ 1102 & 3 & 0 & 1 & 0.012196\\
+ GNM\_ 50\_ 612 & 2 & 0 & 0.002223 & 1 \\
+ GNM\_ 50\_ 612 & 3 & 0 & 0.002541 & 1\\
+ GNM\_ 50\_ 1102 & 1 & 3 & 0.019566 & 3\\
+ GNM\_ 50\_ 1102 & 2 & 0 & 0.012025 & 1\\
+ GNM\_ 50\_ 1102 & 3 & 0 & 0.012196 & 1\\
GNM\_ 100\_ 495 & 1 & 113 & 0.376731 & 14\\
- GNM\_ 100\_ 495 & 2 & 6 & 4 & 0.108993\\
- GNM\_ 100\_ 495 & 3 & 0 & 1 & 0.026969\\
+ GNM\_ 100\_ 495 & 2 & 6 & 0.108993 & 4\\
+ GNM\_ 100\_ 495 & 3 & 0 & 0.026969 & 1\\
GNM\_ 100\_ 2475 & 1 & 0 & 0.045136 & 4\\
- GNM\_ 100\_ 2475 & 2 & 0 & 1 & 0.004791\\
- GNM\_ 100\_ 2475 & 3 & 0 & 1 & 0.006448\\
+ GNM\_ 100\_ 2475 & 2 & 0 & 0.004791 & 1\\
+ GNM\_ 100\_ 2475 & 3 & 0 & 0.006448 & 1\\
GNM\_ 100\_ 4455 & 1 & 0 & 0.00505 & 2\\
- GNM\_ 100\_ 4455 & 2 & 0 & 1 & 0.003927\\
- GNM\_ 100\_ 4455 & 3 & 0 & 1 & 0.004094\\
+ GNM\_ 100\_ 4455 & 2 & 0 & 0.003927 & 1\\
+ GNM\_ 100\_ 4455 & 3 & 0 & 0.004094 & 1\\
GNM\_ 250\_ 3112 & 1 & 0 & 1017.303471 & [17;15]\\
- GNM\_ 250\_ 3112 & 2 & 0 & 2 & 0.270981\\
- GNM\_ 250\_ 3112 & 3 & 14 & 1 & 0.141794\\
+ GNM\_ 250\_ 3112 & 2 & 0 & 0.270981 & 2\\
+ GNM\_ 250\_ 3112 & 3 & 14 & 0.141794 & 1\\
GNM\_ 250\_ 15562 & 1 & 0 & 12.29 & 5\\
- GNM\_ 250\_ 15562 & 2 & 109 & 1 & 0.257635\\
- GNM\_ 250\_ 15562 & 3 & 109 & 1 & 0.267159\\
+ GNM\_ 250\_ 15562 & 2 & 109 & 0.257635 & 1\\
+ GNM\_ 250\_ 15562 & 3 & 109 & 0.267159 & 1\\
GNM\_ 250\_ 28012 & 1 & 0 & 0.024473 & 2\\
- GNM\_ 250\_ 28012 & 2 & 0 & 1 & 0.018999\\
- GNM\_ 250\_ 28012 & 3 & 0 & 1 & 0.023179\\
+ GNM\_ 250\_ 28012 & 2 & 0 & 0.018999 & 1\\
+ GNM\_ 250\_ 28012 & 3 & 0 & 0.023179 & 1\\
GNM\_ 500\_ 12475 & 1 & 42 & 1004.920676 & [21;13]\\
- GNM\_ 500\_ 12475 & 2 & 0 & 2 & 1.123904\\
- GNM\_ 500\_ 12475 & 3 & 0 & 1 & 0.634489\\
+ GNM\_ 500\_ 12475 & 2 & 0 & 1.123904 & 2\\
+ GNM\_ 500\_ 12475 & 3 & 0 & 0.634489 & 1\\
GNM\_ 500\_ 62375 & 1 & 0 & 178.495614 & 5\\
- GNM\_ 500\_ 62375 & 2 & 0 & 1 & 0.29011\\
- GNM\_ 500\_ 62375 & 3 & 0 & 1 & 0.544754\\
+ GNM\_ 500\_ 62375 & 2 & 0 & 0.29011 & 1\\
+ GNM\_ 500\_ 62375 & 3 & 0 & 0.544754 & 1\\
GNM\_ 500\_ 112275 & 1 & 0 & 0.189313 & 2\\
- GNM\_ 500\_ 112275 & 2 & 0 & 1 & 0.148031\\
- GNM\_ 500\_ 112275 & 3 & 0 & 1 & 0.205316\\
+ GNM\_ 500\_ 112275 & 2 & 0 & 0.148031 & 1\\
+ GNM\_ 500\_ 112275 & 3 & 0 & 0.205316 & 1\\
\end{tabular}
\caption[Minimum Connected rooted $k$-hop Dominating Set Results on the random graphs]{Minimum Connected rooted $k$-hop Dominating Set Results on the random graphs}
\end{table}
-We also tested another class of graphs on their runtime. The structure of our leaf graphs is similar in the manner that all have a fixed neighborhood of 6 vertices, all are planar and almost all nodes have the same degree. Many grid graphs also have all these characteristics. This is why we tested our implementation also on grid graphs. Here we tested graphs that are quadratic as well as graphs that are more oblong. Especially on quadratic graphs the same behavior like on the leaf graphs has occurred. Here also comparatively many constraints were added lazily. Which indicates that here also many unconnected integer solutions were created. It seems like the ``gridness'' of a graph a the crucial factor that pushs the runtime over a reasonable extent. The gridness can be defined as the combination of the three described properties from the beginning. On grid graphs the ASP-version also performs much better than the ILP-Version.
+We also tested another class of graphs on their runtime. The structure of our leaf graphs is similar in the manner that all have a neighborhood of fixed size, in our case six vertices, all are planar and almost all nodes have the same degree. Many grid graphs also have all these characteristics. This is why we tested our implementation also on grid graphs. Here we tested graphs that are quadratic as well as graphs that are more oblong. Especially on quadratic graphs the same behavior like on the leaf graphs occures. Here also comparatively many constraints are added lazily, which indicates that here also many unconnected integer solutions are created. It seems like the ``gridness'' of a graph is a crucial factor that pushs the runtime over a reasonable extent. The gridness can be defined as the combination of the three described properties from the beginning. On grid graphs the ASP version also performs much better than the ILP version.
-Here also a short overview about the characteristics of the grid graphs.
+The next table gives a short overview over the characteristics of the grid graphs.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
@@ -178,7 +177,7 @@ Here also a short overview about the characteristics of the grid graphs.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
GRID\_ 6\_ 4 & 1 & 178 & 0.054271 & 11\\
GRID\_ 6\_ 4 & 2 & 74 & 0.044738 & 7\\
@@ -199,10 +198,10 @@ Here also a short overview about the characteristics of the grid graphs.
\caption[Minimum Connected rooted $k$-hop Dominating Set Results on the grid graphs]{Minimum Connected rooted $k$-hop Dominating Set Results on the grid graphs}
\end{table}
-Another important factor that comes with a long runtime for the ILP-version is when there is a large gap between the number of an unconnected solution and the number of a connected solution for an instance.
-The other way round the ILP-version performed good on graphs were the gap was tight such that only a few nodes needed to be added to an unconnected solution.
+Another important factor that comes along with a long runtime for the ILP version is, when there is a large gap between the number of an unconnected solution for the simple Minimun $k$-hop Dominating Set problem and the number of a connected solution for the Minumum rooted Connected $k$-hop Dominating Set problem on the same instance.
+The other way round the ILP version performes good on graphs were the gap is small such that only a few nodes need to be added to an unconnected solution.
-In the method section (refer at this place) we introduced the MTZ constraints (also refer) to induce connectivity.
+In the \hyperref[section:methods]{method section} we introduced the \hyperref[subsection:mtz]{MTZ constraints} to induce connectivity.
The next table shows the runtime of three graphs using the MTZ constraints.
\begin{table}[H]
@@ -219,13 +218,13 @@ The next table shows the runtime of three graphs using the MTZ constraints.
The version using the vertex separator is in all testes cases many times faster. The version using the MTZ constraints seems not to be a reasonable alternative.
-Now we study the case when some of the vertex separator constraints are preadded to the model. We preadded for all combinations $c_v$ of a vertex $v$ and its neighborhood $N(v) $the vertex separators that separate $c_v$ and the root vertex $v_r$. As the following table reveals this generates a significant speedup to the runtime. However the bigger leaf instance can still not be solved optimal under 1000 seconds. In all test cases the ILP-version with preadded separators performed better than the ASP-version. Still many separator constraints needed to be added lazily. If these constraints can be identified in advance this could generate another speedup.
-At this point preadding the described separators itself does not improve the ILP-implementation in a manner that the runtime is satisfying.
+Now we study the case when some of the vertex separator constraints are preadded to the model. We preadd for all combinations $c_v$ of a vertex $v$ and its neighborhood $N(v)$ the vertex separators that separate $c_v$ and the root vertex $v_r$. As the following table reveals this generates a significant speedup to the runtime. However the \textit{bigger-leaf} instance can still not be solved optimal under 1000 seconds. In nearly all test cases the ASP version still performes better than the ILP version with preadded separators. Only for the \textit{GRID\_ 8\_ 8} the ILP version performes better. Still many separator constraints need to be added lazily. If these constraints can be identified in advance this could generate another speedup.
+At this point preadding the described separators itself does not improve the ILP implementation in a manner that the runtime is satisfying.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
small-leaf & 1 & 0 & 0.003599 & 6 \\s
middle-leaf & 1 & 3699 & 710.18652 & 22\\
@@ -237,14 +236,14 @@ At this point preadding the described separators itself does not improve the ILP
\end{table}
-At last we present tables that show the effect of the additional constraints (referenz) introduced in the method section(ref) on some graphs.
+At last we present tables that show the effect of the \hyperref[subsection:additional]{additional constraints} introduced in the \hyperref[section:methods]{method section} on some graphs.
-The first table shows the effect of the \textit{intermediate node constraint}(ref) from \citep{fischetti_steiner_t}. To recap this constraint demands that every vertex that is part of the dominating set needs at least two neighbors which are also members of the dominating set. Roughly speaking every node of the dominating set(except for the root) needs to be an intermediate node. This constraint reduces the runtime drastically. However in most cases including this constraint adds nodes to the solution that would not be included without. For example the instances \textit{middle-leaf} and \textit{bigger-leaf} have one extra node in the optimal solution when this constraint is included.
+The first table shows the effect of the \hyperref[subsubsection:imn]{\textit{intermediate node constraint}} from \citep{fischetti_steiner_t}. To recap this constraint demands that every vertex that is part of the dominating set needs at least two neighbors which are also members of the dominating set. Roughly speaking every node of the dominating set (except for the root) needs to be an intermediate node. This constraint reduces the runtime drastically. However in most cases including this constraint adds nodes to the solution that would not be included without. For example the instances \textit{middle-leaf} and \textit{bigger-leaf} have one extra node in the optimal solution when this constraint is included.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
small-leaf & 1 & 8 & 0.011553 & 6 \\
middle-leaf & 1 & 643 & 0.723175 & 23\\
@@ -255,12 +254,12 @@ The first table shows the effect of the \textit{intermediate node constraint}(re
\caption[Minimum Connected rooted $k$-hop Dominating Set Results with IMN constraint]{Minimum Connected rooted $k$-hop Dominating Set Results with IMN constraint}
\end{table}
-The next table shows the results using the naive constraint to reduce the path length from the root to members of the dominating set. It does not reduce the runtime but even increases it. For the cases were we stopped the solution process after a fixed time span the upper bounds and lower bounds are worse than without this constraint. However in some cases this constraint reduces the number of lazily added constraints which is an indicator that the room of possible unconnected solutions was reduced. But this effect did not reduce the runtime. Probably this constraint added complexity to the model which increased the runtime instead.
+The next table shows the results using the naive constraint to reduce the path length from the root to members of the dominating set. It does not reduce the runtime but even increases it. For the cases were we stopped the solution process after a fixed time span the upper bounds and lower bounds are worse than without this constraint. However in some cases this constraint reduces the number of lazily added constraints which is an indicator that the room of possible unconnected solutions is shrunk. But this effect does not reduce the runtime. Probably this constraint adds complexity to the model which increases the runtime instead.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
small-leaf & 2 & 9 & 0.008948 & 3 \\
middle-leaf & 2 & 109 & 10.936048 & 14\\
@@ -272,12 +271,12 @@ The next table shows the results using the naive constraint to reduce the path l
\end{table}
-The additional constraint that uses the Gaussian sum formula even performed drastically worse. The runtime increased significantly as this constraints adds a high degree of complexity to the model.
+The additional constraint that uses the Gaussian sum formula even performes drastically worse. The runtime increases significantly as this constraints adds a high degree of complexity to the model.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
small-leaf & 2 & 8 & 0.009487 & 3 \\
middle-leaf & 2 & 457 & 87.4349 & 14\\
@@ -291,7 +290,7 @@ When using both constraints in conjunction the constraint with the Gaussian sum
\begin{table}[H]
\centering
\begin{tabular}{l ccccccccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
small-leaf & 2 & 0 & 0.004869 & 3 \\
middle-leaf & 2 & 1198 & 87.231026 & 14\\
@@ -300,14 +299,14 @@ When using both constraints in conjunction the constraint with the Gaussian sum
\caption[Minimum Connected rooted $k$-hop Dominating Set Results with SPL and GAUS constraint]{Minimum Connected rooted $k$-hop Dominating Set Results with SPL and GAUS constraint}
\end{table}
-As we compared our ILP-version to the ASP-version from \citep{myky} the following tables list the runtime of the different graphs using the ASP-version.
+As we compare our ILP version to the ASP version from \citep{myky} the following tables list the runtime of the different graphs using the ASP version.
-We start with our leaf graphs. This table clearly shows that the ASP-version performs much better on these graphs. As for example for the \textit{middle-leaf} instance with parameter $k=1$ the ASP-version finds a solution in 154 seconds, after 1100 seconds the ILP-version does not find a solution(ref).
+We start with our leaf graphs. This table clearly shows that the ASP version performs much better on these graphs. As for example for the \textit{middle-leaf} instance with parameter $k=1$ the ASP version finds a solution in 154 seconds, after 1100 seconds the ILP version does not find a \hyperref[table:ilp_leaf]{solution}.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccc}
- name & k & \# lazily added constraints & runtime(s) & optimal\\
+ name & k & \# C & runtime(s) & optimal\\
\hline
small-leaf & 1 & 9 & 0.008 & 6\\
small-leaf & 2 & 4 & 0.009 & 3\\
@@ -329,7 +328,7 @@ We start with our leaf graphs. This table clearly shows that the ASP-version per
\end{table}
-We continue with the runtime of the ASP-version on random graphs. This tables clearly indicate that the ILP-version performs better on random graphs.
+We continue with the runtime of the ASP version on random graphs. This tables clearly indicate that the ILP version performs better on random graphs.
\begin{table}[H]
\centering
@@ -376,7 +375,7 @@ We continue with the runtime of the ASP-version on random graphs. This tables cl
\caption[Minimum Connected rooted $k$-hop Dominating Set Results on the random graphs using ASP]{Minimum Connected rooted $k$-hop Dominating Set Results on the random graphs using ASP}
\end{table}
-On the other hand the ASP-version performs better on the grid graphs. This is as we expected.
+On the other hand the ASP version performs better on the grid graphs. This is as we expected.
\begin{table}[H]
\centering
@@ -402,22 +401,22 @@ On the other hand the ASP-version performs better on the grid graphs. This is as
\caption[Minimum Connected rooted $k$-hop Dominating Set Results on the grid graphs using ASP]{Minimum Connected rooted $k$-hop Dominating Set Results on the grid graphs using ASP}
\end{table}
-At very last we want to have a deeper look into one particular aspect. During the solution process upper and lower bounds are determined. Most of the time the ILP-version is capable of finding a solid upper bound quickly. The vast majority of the time needed to find an optimal solution is spent on closing the gap to the lower bound. To illustrate this the next table shows after what time an upper bound that is 20\%, 10\%, 5\% and 0\% different from an optimal solution is found.
-In the cases were the ASP-version performs better it also founds a proper upper bound faster. In the one case where the ILP-version performs better it finds an appropriate upper bound faster.
+At very last we want to have a deeper look into one particular aspect. During the solution process upper and lower bounds are determined. Most of the time the ILP version is capable of finding a solid upper bound quickly. The vast majority of the time needed to find an optimal solution is spent on closing the gap to the lower bound (denoted as $t_{gap}$). To illustrate this the next table shows after what time an upper bound that is 20\%, 10\%, 5\% and 0\% different from an optimal solution is found.
+In the cases were the ASP version performs better it also finds a proper upper bound faster. In the one case where the ILP version performs better it finds an appropriate upper bound faster.
\begin{table}[H]
\centering
\begin{tabular}{l ccccccP{1cm}P{1cm}cc}
- name & type & k & 20\% & 10\% & 5\% & 0\% & time to close the gap & \# lazily added constraints & runtime(s) & optimal\\
+ name & type & k & 20\% (s) & 10\% (s) & 5\% (s) & 0\% (s) & $t_{gap}$ (s) & \# C & runtime(s) & optimal\\
\hline
- middle-leaf & ILP & 1 & 0s & 0s & 0s & 0s & 1099s & 4945 & 1099.324462 & [22,21]\\
- middle-leaf & ASP & 1 & 0s & 0s & 0s & 0s & 154s & - & 153.605 & 22\\
- bigger-leaf & ILP & 1 & 1s & 4s & 4s & 14s & 1044s & 6726 & 1058.414758 & [25, 22]\\
- bigger-leaf & ASP & 1 & 0s & 2s & 5s & 5s & 997s & - & 1002.022 & [25, 24]\\
- GNM\_ 250\_ 6225 & ILP & 1 & 0s & 0s & 6s & 6s & 894s & 0 & 900.64 & 10\\
- GNM\_ 250\_ 6225 & ASP & 1 & 238s & - & - & - & - & - & - & 10\\
- GRID\_ 8\_ 8 & ILP & 1 & 0s & 2s & 5s & 599s & 175s & 6451 & 774.59 & 26\\
- GRID\_ 8\_ 8 & ASP & 1 & 0s & 0s & 0s & 11s & 81s & - & 92.739 & 26\\
+ middle-leaf & ILP & 1 & 0 & 0 & 0 & 0 & 1099 & 4945 & 1099.324462 & [22,21]\\
+ middle-leaf & ASP & 1 & 0 & 0 & 0 & 0 & 154 & - & 153.605 & 22\\
+ bigger-leaf & ILP & 1 & 1 & 4 & 4 & 14 & 1044 & 6726 & 1058.414758 & [25, 22]\\
+ bigger-leaf & ASP & 1 & 0 & 2 & 5 & 5 & 997 & - & 1002.022 & [25, 24]\\
+ GNM\_ 250\_ 6225 & ILP & 1 & 0 & 0 & 6 & 6 & 894 & 0 & 900.64 & 10\\
+ GNM\_ 250\_ 6225 & ASP & 1 & 238 & - & - & - & - & - & - & 10\\
+ GRID\_ 8\_ 8 & ILP & 1 & 0 & 2 & 5 & 599 & 175 & 6451 & 774.59 & 26\\
+ GRID\_ 8\_ 8 & ASP & 1 & 0 & 0 & 0 & 11 & 81 & - & 92.739 & 26\\
\end{tabular}
\caption[Time that is necessary to find appropriate upper bounds]{Time that is necessary to find appropriate upper bounds}
\end{table}