reponses KD

[LiCO.git] / PeCO-EO / reponse.tex

diff --git a/PeCO-EO/reponse.tex b/PeCO-EO/reponse.tex
index ff5a80ce947dbd71d43ca51b9a4cbae0a0cafe71..4965597e9a7bee070b0095bd5b03148d96d34332 100644 (file)
--- a/PeCO-EO/reponse.tex
+++ b/PeCO-EO/reponse.tex
@@ -178,20 +178,20 @@ The paper entitled "Perimeter-based Coverage Optimization to Improve Lifetime in
 \textcolor{blue}{\textbf{\textsc{Answer:}
 To implement PeCO on real sensors nodes with limited memories capacities, we can act on :
 \begin{itemize}
 \textcolor{blue}{\textbf{\textsc{Answer:}
 To implement PeCO on real sensors nodes with limited memories capacities, we can act on :
 \begin{itemize}

-\item the solver : GLPK is memory consuming for the resolution of integer programming (IP) compared with other commercial solvers like CPLEX\texttrademark. Commercial solvers generally outperform open source solvers  (See "Analysis of commercial and free and open source
-solvers for linear optimization problems" by B. Meindl and M. Templ from Vienna University of Technology). Memory use depends on the number of variables and number of  constraints.  For linear programs (LP), a reasonable estimate of memory use with CPLEX\texttrademark is to allow one megabyte per thousand constraints. For integer programs, no simple formula exists since memory use depends so heavily on the size of the branch and bound tree. But, the estimate for linear programs still provides a lower bound. In our case, the characteristics of the integer programming (2) are the following:\\
+\item the solver : GLPK is memory consuming for the resolution of integer programming (IP) compared with other commercial solvers like CPLEX\textregistered. Commercial solvers generally outperform open source solvers  (See the report : "Analysis of commercial and free and open source
+solvers for linear optimization problems" by B. Meindl and M. Templ from Vienna University of Technology). Memory use depends on the number of variables and number of  constraints.  For linear programs (LP), a reasonable estimate of memory use with CPLE\textregistered is to allow one megabyte per thousand constraints. For integer programs, no simple formula exists since memory use depends so heavily on the size of the branch and bound tree (B \& B tree). But, the estimate for linear programs still provides a lower bound. In our case, the characteristics of the integer programming (2) are the following:

 \begin{itemize}
 \item number of variables : $S* (2*I+1)$
 \item number of constraints : $2* I *S$
 \item number of non-zero coefficients : $2* I *S * B$
 \item number of parameters (in the objective function) : $2* I *S$
 \end{itemize}
 \begin{itemize}
 \item number of variables : $S* (2*I+1)$
 \item number of constraints : $2* I *S$
 \item number of non-zero coefficients : $2* I *S * B$
 \item number of parameters (in the objective function) : $2* I *S$
 \end{itemize}

-where $S$ denotes the number of sensors in the subregion, $I$ the average number of cover intervals per sensor, $B$ the average number of sensors involved in a cover interval. The following table gives the memory used with GLPK to solve the integer program (column 3) and its LP-relaxation (column 4) for different problem sizes. The sixth column gives an estimate of the memory used with CPLEX to solves the LP-relaxation according to the number of constraints.
+where $S$ denotes the number of sensors in the subregion, $I$ the average number of cover intervals per sensor, $B$ the average number of sensors involved in a coverage interval. The following table gives the memory used with GLPK to solve the integer program (column 3) and its LP-relaxation (column 4) for different problem sizes. The sixth column gives an estimate of the memory used with CPLEX to solves the LP-relaxation according to the number of constraints.

 \\
 \\

-\begin{tabular}{|c|c|c|c|c|c|}
+\begin{tabular}{|c|c|c|c|c|c|r|}

 \hline
 \hline

-Total number of nodes& S & I & GLPK IP & GLPK LP & number of nodes in the &CPLEX\\
-of nodes &&&&relaxation &branch-and-bound tree &\\
+Total number & S & I & GLPK IP & GLPK LP & nodes&CPLEX\\
+of nodes &&&&relaxation &B\&B tree &\\

 \hline
 100 & 6.25& 5&0.2 Mb & 0.2 Mb &1 &  64 Kb\\
 \hline
 \hline
 100 & 6.25& 5&0.2 Mb & 0.2 Mb &1 &  64 Kb\\
 \hline


@@ -200,13 +200,8 @@ of nodes &&&&relaxation &branch-and-bound tree &\\
 300 &18.5 & 17&3.6 Mb & 3.5 Mb & 3 &644 Kb\\
 \hline
 \end{tabular}
 300 &18.5 & 17&3.6 Mb & 3.5 Mb & 3 &644 Kb\\
 \hline
 \end{tabular}

-It is noteworthy that the difference of memory used with GLPK between the resolution of the IP and its LP-relaxation is very weak (not more than 0.1 Mb). The size of the branch and bound tree dos not exceed 3 nodes. This result leads one to believe the memory used with CPLEX for solving the IP would be very close to that for the LP-relaxation, that is to say around 100 Kb for a subregion containing $S=10$ sensors. Moreover the IP seems to have some specifities that encourage us to develop our own solver (coefficents matrix is very sparse) or to use an existing heuristic to find good approximate solution ().
-
-
-
-\item the subdivision of the region of interest. To make the resolution of integer programming tractable by a leader sensor, we need to limit the number of nodes in each subregion (the number of variables and constraints of the integer programming is directly depending on the number of nodes and neigbors). It is therefore necessary to adapt the subdvision  according to the number of sensors deployed in the area and their sensing range (impact on the number of  cover intervals).  
-\item heuristic
-
+It is noteworthy that the difference of memory used with GLPK between the resolution of the IP and its LP-relaxation is very weak (not more than 0.1 Mb). The size of the branch and bound tree dos not exceed 3 nodes. This result leads one to believe the memory used with CPLEX for solving the IP would be very close to that for the LP-relaxation, that is to say around 100 Kb for a subregion containing $S=10$ sensors. Moreover the IP seems to have some specifities that encourage us to develop our own solver (coefficents matrix is very sparse) or to use an existing heuristic to find good approximate solutions (Reference : "A feasibility pump heuristic for general mixed-integer problems", Livio Bertacco and Matteo Fischetti and Andrea Lodi, Discrete Optimization, issn 1572-5286).
+\item the subdivision of the region of interest. To make the resolution of integer programming tractable by a leader sensor, we need to limit the number of nodes in each subregion (the number of variables and constraints of the integer programming is directly depending on the number of nodes and neigbors). It is therefore necessary to adapt the subdvision  according to the number of sensors deployed in the area and their sensing range (impact on the number of  coverage intervals).  

 \end{itemize}}}\\
 
 
 \end{itemize}}}\\