From: David Laiymani Date: Thu, 6 Jan 2011 13:42:52 +0000 (+0100) Subject: Reste la partie gridification X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/gpc2011.git/commitdiff_plain/b7fecdd0207695cf04d57002c79eb7b627594e20?ds=sidebyside Reste la partie gridification --- diff --git a/gpc2011.tex b/gpc2011.tex index 15928ff..a29bb6f 100644 --- a/gpc2011.tex +++ b/gpc2011.tex @@ -45,26 +45,38 @@ \title{Gridification of a Radiotherapy Dose Computation Application with the XtremWeb-CH Environment} -\author{Nabil Abdennhader\inst{1} \and Raphaël Couturier\inst{1} \and David \and - Julien Henriet\inst{2} \and Laiymani\inst{1} \and Sébastien Miquée\inst{1} - \and Marc Sauget\inst{2}} -\institute{Laboratoire d'Informatique de l'universit\'{e} +\author{Nabil Abdennhader\inst{1} \and Mohamed Ben Belgacem{1} \and Raphaël Couturier\inst{2} \and + David Laiymani\inst{2} \and Sébastien Miquée\inst{2} \and Marko Niinimaki\inst{1} \and Marc Sauget\inst{2}} + +\institute{ +University of Applied Sciences Western Switzerland, hepia Geneva, +Switzerland \\ +\email{nabil.abdennadher@hesge.ch, mohamed.benbelgacem@unige.ch, markopekka.niinimaeki@hesge.ch} +\and +Laboratoire d'Informatique de l'universit\'{e} de Franche-Comt\'{e} \\ IUT Belfort-Montbéliard, Rue Engel Gros, 90016 Belfort - France \\ \email{raphael.couturier, david.laiymani, sebastien.miquee@univ-fcomte.fr} \and FEMTO-ST, ENISYS/IRMA, F-25210 Montb\'{e}liard , FRANCE\\ +\email{marc.sauget@femtost.fr} } -%\email{\texttt{[laiymani]@lifc.univ-fcomte.fr}}} \maketitle \begin{abstract} - + This paper presents the design and the evaluation of the + gridification of a radiotherapy dose computation application. Due to + the inherent characteristics of the application and its execution, + we choose the architectural context of global (or volunteer) computing. + For this, we used the XtremWeb-CH environement. Experiments were + conducted on a real global computing testbed and show good speed-ups + and very acceptable platform overhead. \end{abstract} + %-------------INTRODUCTION-------------------- \section{Introduction} @@ -74,22 +86,23 @@ the domain of radiotherapy dose computation the problem is crucial. The main goal of external beam radiotherapy is the treatment of tumors while minimizing exposure to healthy tissue. Dosimetric planning has to be carried out in order to optimize the dose -distribution within the patient is necessary. Thus, to determine the -most accurate dose distribution during treatment planning, a -compromise must be found between the precision and the speed of -calculation. Current techniques, using analytic methods, models and -databases, are rapid but lack precision. Enhanced precision can be -achieved by using calculation codes based, for example, on Monte Carlo -methods. In [] the authors proposed a novel approach using neural -networks. This approach is based on the collaboration of computation -codes and multi-layer neural networks used as universal -approximators. It provides a fast and accurate evaluation of radiation -doses in any given environment for given irradiation parameters. As -the learning step is often very time consuming, in \cite{bcvsv08:ip} -the authors proposed a parallel algorithm that enable to decompose the -learning domain into subdomains. The decomposition has the advantage -to significantly reduce the complexity of the target functions to -approximate. +distribution within the patient. Thus, to determine the most accurate +dose distribution during treatment planning, a compromise must be +found between the precision and the speed of calculation. Current +techniques, using analytic methods, models and databases, are rapid +but lack precision. Enhanced precision can be achieved by using +calculation codes based, for example, on Monte Carlo methods. The main +drawback of these methods is their computation times which can be +rapidly be huge. In [] the authors proposed a novel approach, called +Neurad, using neural networks. This approach is based on the +collaboration of computation codes and multi-layer neural networks +used as universal approximators. It provides a fast and accurate +evaluation of radiation doses in any given environment for given +irradiation parameters. As the learning step is often very time +consuming, in \cite{bcvsv08:ip} the authors proposed a parallel +algorithm that enable to decompose the learning domain into +subdomains. The decomposition has the advantage to significantly +reduce the complexity of the target functions to approximate. Now, as there exist several classes of distributed/parallel architectures (supercomputers, clusters, global computing...) we have @@ -117,8 +130,8 @@ XtremWeb-CH is very acceptable. The paper is organized as follows. In Section 2 we present the Neurad application and particularly it most time consuming part i.e. the -learning step. Section 3 details the XtremWeb-CH environment while in -Section 4 we expose the gridification of the Neurad +learning step. Section 3 details the XtremWeb-CH environment and +Section 4 exposes the gridification of the Neurad application. Experimental results are presented in Section 5 and we end in Section 6 by some concluding remarks and perspectives. @@ -153,22 +166,24 @@ process and the dose deposit evaluation. The first step, the data production, is outside the {\it{Neurad}} project. They are many solutions to obtain data about the radiotherapy treatments like the measure or the simulation. The only essential criterion is that the -result must be obtain in a homogeneous environment. We have chosen to -use only a Monte Carlo simulation because this kind of tool is the -reference in the radiotherapy domains. The advantages to use data -obtained with a Monte Carlo simulator are the following: accuracy, -profusion, quantified error and regularity of measure points. But, -there exist also some disagreements and the most important is the -statistical noise, forcing a data post treatment. Figure~\ref{f_tray} -presents the general behavior of a dose deposit in water. +result must be obtain in a homogeneous environment. +% We have chosen to +% use only a Monte Carlo simulation because this kind of tool is the +% reference in the radiotherapy domains. The advantages to use data +% obtained with a Monte Carlo simulator are the following: accuracy, +% profusion, quantified error and regularity of measure points. But, +% there exist also some disagreements and the most important is the +% statistical noise, forcing a data post treatment. Figure~\ref{f_tray} +% presents the general behavior of a dose deposit in water. -\begin{figure}[http] - \centering - \includegraphics[width=0.7\columnwidth]{figures/testC.pdf} - \caption{Dose deposit by a photon beam of 24 mm of width in water (normalized value).} - \label{f_tray} -\end{figure} + +% \begin{figure}[http] +% \centering +% \includegraphics[width=0.7\columnwidth]{figures/testC.pdf} +% \caption{Dose deposit by a photon beam of 24 mm of width in water (normalized value).} +% \label{f_tray} +% \end{figure} The secondary stage of the {\it{Neurad}} project is the learning step and this is the most time consuming step. This step is off-line but it @@ -218,7 +233,142 @@ as small as possible to limit the size increase of the data subsets. \section{The XtremWeb-CH environment} \input{xwch.tex} +\section{} + +\label{sec:neurad_gridif} + + +The Neurad application can be divided into three parts. The first one +aims at dividing data representing dose distribution on an area. This +area contains various parameters, like the density of the medium and +its nature. Multiple ``views'' can be superposed in order to obtain a +more accurate learning. The second part of the application is the +learning itself. This is the most time consuming part and therefore +this is the one which has been ported to XWCH. This part fits well +with the model of the middleware -- all learning tasks execute in +parallel independently with their own local data part, with no +communication, following the fork-join model. As described on Figure +\ref{fig:neurad_grid}, we first send the learning application and data +to the middleware (more precisely on warehouses (DW)) and create the +computation module. When a worker (W) is ready to compute, it requests +a task to execute to the coordinator (Coord.). This latter assigns it +a task. The worker retrieves the application and its assigned data, +and can start the computation. At the end of the learning process, it +sends the result, a weighted neural network which will be used in a +dose distribution process, to a warehouse. The last step of the +application is to retrieve these results and exploit them. + + +\begin{figure}[ht] + \centering + \includegraphics[width=\linewidth]{neurad_gridif} + \caption{Neurad gridification} + \label{fig:neurad_grid} +\end{figure} + \section{Experimental results} + +\label{sec:neurad_xp} + +\subsubsection{Conditions} +\label{sec:neurad_cond} + + +The evaluation of the execution of the Neurad application on XWCH was +composed as follows. The size of the input data is about 2.4Gb. This +amount of data can be divided into 25 parts – otherwise, data noise +appears and will disturb the learning. We have used 25 computers (XWCH +workers) to execute this part of the application. This generates input +data parts of about 15Mb (in a compressed format). The output data, +which are retrieved after the process, are about 30Kb for each part. We +used two distincts deployments of XWCH. In the first one, the XWCH +coordinator and the warehouses were situated in Geneva, Switzerland +while the workers were running in the same local cluster in Belfort, +France. The second deployment is a local deployment where both +coordinator, warehouses and workers were in the same local cluster. +During the day these machines were used by students of the Computer +Science Department of the IUT of Belfort. + +We have furthermore compared the execution of the Neurad application +with and without the XWCH platform in order to measure the overhead +induced by the use of the platform. By "without XWCH" we mean that the +testbed consists only in workers deployed with their respective data by +the use of shell scripts. No specific middleware was used and the +workers were in the same local cluster. + +Five computation precisions were used: $1e^{-1}$, $0.75e^{-1}$, $0.50e^{-1}$, $0.25e^{-1}$ and $1e^{-2}$. + + +\subsubsection{Results} +\label{sec:neurad_result} + + +In these experiments, we measured the same steps on both kinds of +executions. The steps consist of sending of local data and the +executable, the learning process, and retrieving the result. Table +\ref{tab:neurad_res} presents the execution times of the Neurad +application on 25 machines with XWCH (local and distributed deployment) +and without XWCH. + + +\begin{table}[h!] + \centering + \begin{tabular}[h!]{|c|c|c|c|c|} + \hline + Precision & 1 machine & Without XWCH & With XWCH & With local XWCH\\ + \hline + $1e^{-1}$ & 5190 & 558 & 759 & 629\\ + $0.75e^{-1}$ & 6307 & 792 & 1298 & 801 \\ + $0.50e^{-1}$ & 7487 & 792 & 1010 & 844 \\ + $0.25e^{-1}$ & 7787 & 791 & 1000 & 852\\ + $1e^{-2}$ & 11030 & 1035 & 1447 & 1108 \\ + \hline + \end{tabular} +\caption{Execution time in seconds of the Neurad application, with and without using the XWCH platform} + \label{tab:neurad_res} +\end{table} + +%\begin{table}[ht] +% \centering +% \begin{tabular}[h]{|c|c|c|} +% \hline +% Precision & Without XWCH & With XWCH \\ +% \hline +% $1e^{-1}$ & $558$s & $759$s\\ +% \hline +% \end{tabular} +% \caption{Execution time in seconds of Neurad application, with and without using XtremWeb-CH platform} +% \label{tab:neurad_res} +%\end{table} + + +These experiments show that the overhead induced by the use of the XWCH +platform is about $34\%$ in the distributed deployment and about $7\%$ +in the local deployment. For this last one, the overhead is very acceptable regarding to the benefits of the platform. + +Now, in the distributed deployment the overhead is also acceptable and can be explained by +different factors. First, we point out that the conditions of executions +are not really identical between with and without XWCH. For this last +one, though the same steps were done, all transfer processes are inside +a local cluster with a high bandwidth and a low latency. Whereas when +using XWCH, all transfer processes (between datawarehouses, workers, and +the coordinator) used a wide network area with a smaller bandwidth. + +In addition, in executions without XWCH, all the machines started +immediately the computation, whereas when using the XWCH platform, a +latency is introduced by the fact that a task starts on a machine, only +when this one requests a task. + +These experiments underline that deploying a local coordinator and one +or more warehouses near a cluster of workers can enhance computations +and platform performances. They also show a limited overhead due to the +use of the platform. + + +\end{document} + + + \section{Conclusion and future works} diff --git a/xwch.tex b/xwch.tex index ea36ed9..70a2b12 100644 --- a/xwch.tex +++ b/xwch.tex @@ -19,9 +19,10 @@ results of the computation on warehouses. If the coordinator does not receive a signal from a worker, it will simply remove it from the scheduling list, and if a job had been assigned to that worker, it will be re-assigned to another one. A schema of the architecture is -shown in Figure 4. +shown in Figure \ref{xwch}. \begin{figure}[htp] +\label{xwch} \begin{centering} \includegraphics [scale=0.2]{figures/xwcharchitecture.pdf} \caption{The XWCH Architecture} @@ -37,13 +38,13 @@ to exchange, store and retrieve data. Job submission is done by a client program which is written using a flexible API, available for Java and C/C++ programs. The client program runs on a “client node” and calls the user services to submit -jobs (Figure 1, (1)). The main flexibility provided by the use of this +jobs (Figure \ref{xwch}, (1)). The main flexibility provided by the use of this architecture is to control and generate dynamically jobs especially when their number cannot be known in advance. Communications between the coordinator and the workers are always initiated by the workers -following a pull model (Figure 1, (2)): +following a pull model (Figure \ref{xwch}, (2)): \begin{itemize} -\item Workers receive jobs (Figure 1, (3)) only if they send a “work +\item Workers receive jobs (Figure \ref{xwch}, (3)) only if they send a “work request” signal; \item When a worker finishes its job, it stores its output file on warehouse and sends a “work result” signal to the coordinator; @@ -52,7 +53,7 @@ following a pull model (Figure 1, (2)): warehouse services) to report itself to the coordinator. \end{itemize} -As a whole, XWCH is easy to install, maintain ans use. Its components +As a whole, XWCH is easy to install, maintain and use. Its components are programmed mainly using Java, and their process memory sizes in a typical 32-bit GNU/Linux computer are: \begin{itemize}