% Template GRASS newsletter - Article
% Language: Latex
%

% Head

\title{Portage d'un module raster de GRASS pour le calcul distribu\'e}
\subtitle{Exemples avec MPI et Ninf-G}
\author{Shamim Akhter, Yann Chemin, Kento Aida, traduit par Yann Chemin}

\maketitle

\section{R\'esum\'e}
\label{sec:R\'esum\'e}

L'imagerie satellitaire procure un grand nombre d'informations utiles. Extraire ces informations et les comprendre peut n\'ecessiter une capacit\'e et un temps de calcul tr\`es importants. Le calcul distribu\'e peut r\'eduire le temps de traitement en fournissant plus de puissance de calcul. GRASS, un logiciel libre, a \'et\'e utilis\'e pour le traitement d'images satellitaires. Pour montrer comment les modules de GRASS peuvent tirer parti du calcul distribu\'e, un module (r.vi) est ici port\'e, \`a titre d’exemple, \`a l’aide des composants de programmation distribu\'ee MPI (r.vi.mpi) et Ninf-G (r.vi.grid). Les façons d'implanter ces modules constituent le sujet principal de cet article qui va progressivement pr\'esenter les \'etapes de base requises pour porter tout module raster de GRASS sur une plate-forme distribu\'ee. Une \'etude comparative des versions modifi\'ees de r.vi, r.vi, r.vi.mpi et r.vi.grid est \'egalement pr\'esent\'ee.


\section{Introduction}
\label{sec:Introduction}

Le traitement de l'imagerie satellitaire joue un r\^ole vital pour les d\'eveloppements de la recherche en t\'el\'ed\'etection, en SIG, pour le suivi de l'agriculture, la gestion des d\'esastres et pour d'autres sujets d'\'etude. N\'eanmoins, traiter ces images satellites de r\'esolution spatiale toujours croissante n\'ecessite un temps de calcul important en raison de la complexit\'e et de la taille des traitements. Cela semble \^etre une barri\`ere pour la prise de d\'ecision en temps r\'eel. Le traitement distribu\'e de donn\'ees peut \^etre une solution r\'ealiste pour r\'ealiser une telle t\^ache dans les temps. Les clusters et (ou grappes de machines) et les environnements de type grid (ou grille de calcul) sont deux syst\`emes distribu\'es bien connus qui ont \'et\'e associ\'es avec le calcul de haute performance pour des applications ayant des besoins tr\`es \'elev\'es en termes de CPU. GRASS GIS \citep{Neteler:2003} est un logiciel libre qui a \'et\'e utilis\'e pour traiter des images satellites. Dans GRASS, diff\'erents modules ont \'et\'e d\'evelopp\'es pour traiter des images satellites. Le module r.vi de GRASS d\'evelopp\'e par \citep{Kamble:2006} est utilis\'e  dans cette \'etude comme un exemple de test. Le d\'eveloppement de la m\'ethode, qui permet d'utiliser l'environnement GRASS GIS pour le traitement d'image satellite sur des syst\`emes de calcul distribu\'e est le sujet principal de cet article. Deux diff\'erentes m\'ethodes d'impl\'ementation d'un r.vi distribu\'e sont pr\'esent\'ees ici pour les plate-formes de programmation MPI \citep{(Message Passing Interface MPI : 2007} et Ninf-G \citep{Page principale de Ninf-G : 2007}. 

L'Index de V\'eg\'etation (VI)  constitue l’ensemble principal d'indicateurs pour la v\'eg\'etation. Le module r.vi de GRASS, est utilis\'e pour calculer 13 indices diff\'erents de v\'eg\'etation pour les images satellite. NDVI (Normalized Difference Vegetation Index \citep{Weier:2007}) est un d'entre eux. Le NDVI est calcul\'e \`a partir de ces mesures individuelles : NDVI=(IRP-Rouge)/(IRP+Rouge), o\`u Rouge et IRP sont respectivement  les mesures de r\'eflectance spectrales acquises dans les r\'egions du rouge et de l'infra-rouge proche. D'autres indices de v\'eg\'etation sont :

%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.42]{programming/yann/akhter_chemin_aida_2007_table_0.jpg}
   %caption of the figure
   \caption{Indices de V\'eg\'etation}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_table_0}
\end{figure}

Ils sont d\'eriv\'es en utilisant diff\'erentes m\'ethodes de diff\'erenciation et de contraste. La figure ~\ref{fig:akhter_chemin_aida_2007_figure_1} montre une capture d'\'ecran d'un r\'esultat de calcul produit par GRASS. 

%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.25]{programming/yann/akhter_chemin_aida_2007_figure_1.png}
   %caption of the figure
   \caption{Calcul de NDVI avec GRASS}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_figure_1}
\end{figure}

Le module r.vi de GRASS utilise des images de type raster (lignes x colonnes). Plusieurs bandes d'images raster sont n\'ecessaires pour diff\'erents indices. Les indices g\'en\'eriques (NDVI, RVI, etc) utilisent les bandes d'images du rouge et de l'IRP (Infrarouge Proche). ARVI utilise quant à lui le rouge, l'IRP et le bleu ; GVI utilise le rouge, l'IRP, le bleu, le vert, la bande 5 et la bande 7 des images Landsat. GARI utilise le rouge, l'IRP, le bleu et le vert. Les fonctions de GRASS sont utilis\'ees pour extraire les lignes de donn\'ees provenant des bandes spectrales pertinentes et pour les stocker dans des zones de m\'emoire tampon. Apr\`es cela, chaque valeur de colonne est extraite s\'equentiellement des zones de m\'emoire tampon et envoy\'ee pour g\'en\'erer les valeurs de VI sp\'ecifiques. Ainsi, apr\`es avoir trait\'e les valeurs de VI des lignes en m\'emoire-tampon, les valeurs de VI par ligne sont \'ecrites dans le fichier image r\'esultat. Cette proc\'edure se r\'ep\`etera pour chaque ligne. La figure ~\ref{fig:akhter_chemin_aida_2007_figure_2} pr\'esente la structure du module r.vi s'ex\'ecutant s\'equentiellement (par soucis de simplicit\'e, seulement deux bandes spectrales sont pr\'esent\'ees).

%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.3]{programming/yann/akhter_chemin_aida_2007_figure_2.png}
   %caption of the figure
   \caption{Structure du Module r.vi s'ex\'ecutant s\'equentiellement}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_figure_2}
\end{figure}

\section{Objectifs}
\label{sec:Objectifs}

Dans l'hypoth\`ese o\`u le calcul distribu\'e \'eliminera les contraintes de temps de calcul, de nouveaux algorithmes de traitement d'image appliqu\'es aux donn\'ees provenant de la t\'el\'ed\'etection peuvent \^etre consid\'er\'es. Divers modules de GRASS ont \'et\'e d\'evelopp\'es pour r\'esoudre diff\'erents probl\`emes d'analyse d'images acquises par t\'el\'ed\'etection. L'objectif principal de cet article est d'\'evaluer la performance des modules de GRASS dans un environnement de calcul distribu\'e. De plus, le portage dans un environnement distribu\'e des processus cr\'e\'es par les utilisateurs de donn\'ees de t\'el\'ed\'etection est une activit\'e nouvelle pour ces derniers. Un autre point abord\'e dans cet article, porte sur l'\'evaluation de la charge de travail n\'ecessaire pour que les performances obtenues en r\'epartissant le travail entre diff\'erents noeuds de calcul soient meilleures que lors de l'utilisation du module s\'equentiel.

\section{M\'ethodologie}
\label{sec:M\'ethodologie}

Pour r\'epondre aux objectifs ou aux besoins mentionn\'es pr\'ec\'edemment, le module de GRASS (r.vi) a \'et\'e parall\'elis\'e en utilisant une strat\'egie ma\^itre-esclave. Le processus ma\^itre est actif dans l'environnement de GRASS et d\'ecompose les images cibles en lignes et les distribue aux multiples processus esclaves. Ces derniers sont ind\'ependants de GRASS, ils effectuent les calculs et renvoient le r\'esultat pour chaque ligne au processus ma\^itre. Le module r.vi est impl\'ement\'e en utilisant MPI sur un syst\`eme de PCs en cluster (r.vi.mpi) et Ninf-G sur le m\^eme syst\`eme (r.vi.grid) afin de pr\'eserver la similarit\'e des environnements exp\'erimentaux. N\'eanmoins, le module r.vi.grid a une structure capable de travailler sur un syst\`eme distribu\'e de type GRID (grille de calcul). Des exp\'eriences ont enfin \'et\'e men\'ees pour analyser les r\'esultats des modules r.vi distribu\'es en augmentant le nombre d'op\'erations, afin de trouver la charge de travail n\'ecessaire pour tirer parti des environnements de calcul distribu\'e.

   Dans la figure~\ref{fig:akhter_chemin_aida_2007_figure_3}, la structure mettant en place le module r.vi distribu\'e est pr\'esent\'ee (par soucis de simplicit\'e, seulement deux bandes spectrales ont \'et\'e repr\'esent\'ees). Ici, S1, S2, ... et Sn sont diff\'erents processus esclaves.

%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.38]{programming/yann/akhter_chemin_aida_2007_figure_3.png}
   %caption of the figure
   \caption{Structure du module r.vi Distribu\'ee (r.vi.mpi et r.vi.grid)}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_figure_3}
\end{figure}

\section{Impl\'ementation}
\label{sec:Impl\'ementation}

\subsection{MPI et le framework Ninf-G}
\label{subsec:Cadre de travail en MPI et Ninf-G}


MPI (Interface de Passage de Message) est une biblioth\`eque de fonctions (en C) ou de sous-routines (en FORTRAN) que l'on peut ins\'erer dans un fichier source de code informatique pour permettre la communication de donn\'ees entre processeurs \citep {Snir:1996}. MPI fut d\'evelopp\'e à des fins de calcul haute performance \`a la fois sur machines massivement parall\`eles mais sur des grappes de stations de travail (cluster). MPI fut mis en oeuvre par un
comit\'e relativement imposant et regroupant des vendeurs de mat\'eriels et de logiciels, des professionnels ainsi que des utilisateurs.

Ninf-G a \'et\'e d\'evelopp\'e par AIST (National Institute of Advanced Industrial Science and Technology, Japan) et TITECH (Tokyo Institute of Technology, Japan). Ninf-G est une r\'e-impl\'ementation du syst\`eme Ninf au-dessus de la bo\^ite \`a outils Globus \citep {Foster:1997}. Globus sert de plate-forme robuste et commune pour la mise en place d'outils middleware et de programmation de plus haut niveau, etc., assurant ainsi l'interop\'erabilit\'e entre de tels \'el\'ements de haut niveau, dont Ninf-G. Le syst\`eme Ninf-G est bas\'e sur une architecture client-serveur. Les ressources de calcul sont disponibles \`a travers des biblioth\`eques h\'eberg\'ees sur un h\^ote de calcul qui peut \^etre appel\'e au travers du r\'eseau global \`a partir de programmes clients \'ecrits dans un langage courant comme FORTRAN, C, ou C++.

\subsection{D\'etails du Cluster Davinchi}
\label{subsec:Details_du_Cluster_Davinchi}

Les noeuds du Cluster utilis\'es pour les exp\'erimentations sont :
%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.42]{programming/yann/akhter_chemin_aida_2007_table_1.jpg}
   %caption of the figure
   \caption{D\'etails du Cluster Davinchi}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_table_1}
\end{figure}

\subsection{ Module r.vi distribu\'e en MPI (r.vi.mpi)}
\label{subsec:Module_r_vi_distribue_en_MPI_r.vi.mpi}

Pour le module r.vi.mpi, le code source de GRASS est install\'e dans le noeud qui sera ma\^itre et les biblioth\`eques GRASS sont copi\'ees sur les noeuds esclaves en m\'emoire locale au m\^eme endroit que dans le noeud ma\^itre (/usr/local/grass-6.0.2/) et les \'etapes de configuration suivantes sont n\'ecessaires pour l'environnement de MPI-GRASS. 

- le fichier grass.conf est cr\'e\'e \`a l'int\'erieur du r\'epertoire /etc/ld.so.conf.d/ et les noms des biblioth\`eques de GRASS sont \'ecrits dans ce fichier.

-	Apr\`es cela la commande /sbin/ld config est ex\'ecut\'ee.

Les fonctions $MPI_Send$ et $MPI_Recv$ ont \'et\'e utilis\'ees pour la communication des donn\'ees.


Le fichier Makefile suivant est cr\'e\'e pour la compilation du code informatique :
\begin{smallverbatim}
MODULE_TOPDIR = ../..
CC=mpicc
PGM = r.vi.mpi
LIBES = \$(GISLIB) \$(GMATHLIB)
DEPENDENCIES = \$(GISDEP) \$(GMATHDEP)
include \$(MODULE_TOPDIR)/include/Make/Module.make
default: cmd
\end{smallverbatim}

Pour ex\'ecuter le code informatique, la commande shell suivante a \'et\'e utilis\'ee :
\begin{smallverbatim}
mpirun -np 3 location_du_fichier_execution parametres
\end{smallverbatim}
Dans cette experience, la localisation du fichier d'ex\'ecution est : $GRASS_COMPILE_DIR$/dist.i686-pc-linux-gnu/bin/r.vi.mpi
Le pseudo-code informatique de r.vi.mpi est ci-apr\`es :
\begin{smallverbatim}
#include "gis.h"
#include "glocale.h"
#include "mpi.h"


/* main.c: Declare le code MPI suivant   */
/* NUM_HOSTS est le nombre total d'hotes */
/* me est le rang/nombre de CPUs         */

MPI_Status status;
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&NUM_HOSTS);
MPI_Comm_rank(MPI_COMM_WORLD,&me);

/*----------------------------------------*/
/* Commence Code Commandant: Rang 0 (me=0)*/


/* Extrait nombre total de lignes et de  */
/* colonnes et envoie les aux executants */

for(i=1;i<NUM_HOSTS;i++)
/* Commence boucle en i :

 MPI_Send(&nrows,1,MPI_INT,i,1,MPI_COMM_WORLD);
 MPI_Send(&ncols,1,MPI_INT,i,1,MPI_COMM_WORLD);

/* Boucle i est finit.
 
/* Donnees des lignes sont extraites des images */
/* et distribuees parmis les executant avec */
/* nombres de lignes specifiques en boucle */
/* d'attribution */

for (r = 1; r*(NUM_HOSTS-1) <= nrows;r++ )
/* D\'ebut de boucle en r:

 for(k=1;k<NUM_HOSTS;k++)
 /* D\'ebut de boucle en k: 
 
   row=(r-1)*(NUM_HOSTS-1)+k-1;
   G_get_raster_row(infd_redchan,...
   G_get_raster_row(infd_nirchan,...
   for (col=0; col < ncols; col++)
   /*D\'ebut de boucle en col:
   
 /* Chaque valeur de cellule de colonne venant de 
 /* toute les bandes sont extraites et mises dans 
 /* une rangee de memoire 2D
     db[0][col]= d_redchan;
     db[1][col]= d_nirchan;
   
   /* Boucle en col finit.
   
   row_n=k-1;
   I[ncols]=row_n;
   MPI_Send(I,ncols+1,MPI_INT,k,1,\
   MPI_COMM_WORLD);
   MPI_Send(db,6*ncols,MPI_DOUBLE,k,1,\
   MPI_COMM_WORLD);
  
 /* Boucle en k finit.
 
 /* Attend les resultats...
 
 for(k=1;k<NUM_HOSTS;k++)
 /* Debut de boucle en k :
 
   MPI_Recv(R,ncols+1,MPI_DOUBLE,k,1,\
   MPI_COMM_WORLD,&status);
   row_n=R[ncols];
   for (cn=0;cn<ncols;cn++)
   /* D\'ebut de boucle en cn:
   
	outputImage[row_n][cn]=R[cn];
  
   /* Fin de boucle en cn.

 /* Fin de boucle en k.
 
 /* Les lignes traitees sont remises dans */
 /* les images resultats */
 for(k=0;k<(NUM_HOSTS-1);k++)
 /* Debut de boucle en k :
 
  for(j=0;j<ncols;j++)
  /* Debut de boucle en j :
  
  ((DCELL *) outrast)[j] = outputImage[k][j];
  G_put_raster_row(outfd,outrast,data_type_output);
    
  /* Fin de boucle en j.
  
 /* Fin de boucle en k.
 
/* Fin de boucle en r.

/* Si il y a quelconque lignes en plus */
/* (row_number%slaves!=0), le reste de */
/* l'attribution des lignes (moins que n) */
/* sont distribuees d'executant 1 a n une */
/* autre fois */
 
MPI_Finalize();
G_free(inrast_redchan);

/* Fin du code Commandant                    */
/*----------------------------------------

/*-----------------------------------------
/* Debut de code executant: Rang non 0 (me!=0)*/

MPI_Recv(&nrows,1,MPI_INT,0,1,MPI_COMM_WORLD,\
&status);
MPI_Recv(&ncols,1,MPI_INT,0,1,MPI_COMM_WORLD,\
&status);

n_rows=nrows/(NUM_HOSTS-1);
modv=nrows%(NUM_HOSTS-1);
if(modv>=me)
	n_rows++;

/* Reception de donnees du commandant et traitement
for(i=0;i<n_rows;i++)
/* Debut de boucle en i :
  
  MPI_Recv(I,ncols+1,MPI_INT,0,1,MPI_COMM_WORLD,\  
  &status);
  MPI_Recv(db,6*ncols,MPI_DOUBLE,0,1,MPI_COMM_WORLD,\ 
  &status);

  for (col=0; col<ncols; col++)
  /* Debut de boucle en col :
   
   ndvi(db[0][col],db[1][col]);// Process ndvi()
  
  /* Fin de boule en col.
  
  r[ncols]=I[ncols]; 
  
   /* resultats sont dans r[] et 
   /* renvoit au Commandant
  MPI_Send(r,ncols+1,MPI_DOUBLE,0,1,\
  MPI_COMM_WORLD);

/* Fin de boucle en i.

 MPI_Finalize();
 
/* Fin de code ex\'ecutant.                 */
/*--------------------------------------------
\end{smallverbatim}


\subsection{Module r.vi distribu\'e en GRID (r.vi.grid)}
\label{subsec:Module_Distribue_r_vi_en_GRID_r.vi.grid}

r.vi est plus ais\'e \`a transformer en environnement Ninf-G que MPI. Ici, il n'y a nul besoin de copier les fichiers des biblioth\`eques de GRASS, car les proc\'edures d'ex\'ecution sont totalement ind\'ependantes de la proc\'edure ma\^itresse et de l'environnement GRASS. L'API d'appel GridRPC \citep{Tanaka:2003} est utilis\'ee pour communiquer entre le ma\^itre et les ex\'ecutants.
Le fichier Makefile suivant est cr\'e\'e pour la compilation du code informatique :

\begin{smallverbatim}
MODULE_TOPDIR = ../..
CC=ng_cc
PGM = r.vi.grid
LIBES = \$(GISLIB) \$(GMATHLIB)
DEPENDENCIES = \$(GISDEP) \$(GMATHDEP)
include \$(MODULE_TOPDIR)/include/Make/Module.make
default: cmd
\end{smallverbatim}

Comme tout autre module GRASS, r.vi.grid peut d\'emarrer \`a partir de la commande

\begin{smallverbatim}
r.vi.grid  param\`etres
\end{smallverbatim}

Le fichier IDL d'un ex\'ecutant est comme suit :
\begin{smallverbatim}
Module VI_Server;
Define VI_CALC (IN int n,IN double I[n], \
IN double a[n], IN double b[n], IN double c[n],\
IN double d[n], IN double e[n],\
IN double f[n], OUT double r[n])
Required "VI_ServerC.o"
Calls "C" VI_CALC(n,I,a,b,c,d,e,f,r);
\end{smallverbatim}

Le code informatique d'un porcessus ex\'ecutant est comme suit :
\begin{smallverbatim}
#include<stdio.h>
#include<math.h>
#include<stdlib.h>
#include<unistd.h>

void VI_CALC(int n, int *I, double *a,\
 double *b,double *c, double *d, double *e,\
 double *f,double *r){
 int col;
 

 for (col=0; col<n; col++)
 //Debut de boucle col
 
    /*Valeur par colonne a envoyer pour traiter par 
    /* index specifique, mettant le resultat en r[]
	/* traitement du ndvi....
	r[col]=(a[col]-b[col])/(a[col]+b[col]);

 //Fin de boucle col.
	
} //function call finish
\end{smallverbatim}


Le code informatique du module ma\^itre est comme suit :
\begin{smallverbatim}

#include "gis.h"
#include "glocale.h"
#include "grpc.h" // inclure entete grpc.h
#define NUM_HOSTS 5 //Combien d'hotes disponibles

char* hosts[]= {"davinchi1.alab.ip.titech.ac.jp",\
"davinchi1.alab.ip.titech.ac.jp", ... , ... , ... ;
grpc_function_handle_t handles[NUM_HOSTS];
grpc_sessionid_t ids[NUM_HOSTS];
int ret;


if((ret=grpc_initialize("/.../raster/r.vi.grid \
 /vi.conf")!=GRPC_NO_ERROR)){
  fprintf(stderr, "Error in grpc_initialize, \
  %d\n",ret);
  exit(2);
}


//creation d'une poign\'ee pour chaque h\^ote
for(i = 0; i < NUM_HOSTS; i++)
 grpc_function_handle_init(&handles[i], hosts[i],\
    "VI_Server/VI_CALC");


for(row = 0; row < nrows; row++)
/* Debut de boucle en row :


  host_n=host_n%NUM_HOSTS;
  if(G_get_raster_row(infd_redchan,\
      inrast_redchan,row,data_type_redchan)<0)
    G_fatal_error(_("Could not read from <%s>"),\
      redchan);
  if(G_get_raster_row(infd_nirchan,\
      inrast_nirchan,row,data_type_nirchan)<0)
    G_fatal_error(_("Could not read from <%s>"),\
      nirchan);


  for(col=0; col < ncols; col++)
  /* D\'ebut de boucle en col:

  
     /* Chaque valeur de cellule de colonne pour 
     /* chaque bande d'image est extraite d'une
     /* fois et mises dans des rangees memoires 2D
    db[0][col]= d_redchan;
    db[1][col]= d_nirchan;
    db[2][col]= d_greenchan;
    db[3][col]= d_bluechan;
    db[4][col]= d_chan5chan;
    db[5][col]= d_chan7chan;  
    /* Les valeurs d'index de 'egetation sont 
    /* remplies en rangees de memoires I[ncols]

 
  /* Fin de boucle en col.

  
  if(grpc_call(&handles[host_n],ncols,I,db0,db1,\
  db2, db3,db4,db5, R) != GRPC_NO_ERROR){
    fprintf(stderr,"grpc_call ERROR\n");
    exit(2);
  }

  
   /* Tous les sortants sont remis dans des raster
  for(j=0;j<ncols;j++)
  /* Debut de boucle j :

  
    ((DCELL *) outrast)[j] = R[j];

  
  /* Fin de boucle j.

  
   if(G_put_raster_row(outfd,outrast,\
      data_type_output) < 0)
   G_fatal_error(_("Cannot write to output\
      raster file"));
  
  
  host_n++;

  
/* Fin de boucle en row.


 /*Destruction des poignees
for(i = 0;i < NUM_HOSTS; i++)
  grpc_function_handle_destruct(&handles[i]);
grpc_finalize();
G_free(inrast_redchan);
G_close_cell(infd_redchan);
...etc...(Libere la memoire)
\end{smallverbatim}

\section{R\'esultats Exp\'erimentaux}
\label{sec:Resultats_Experimentaux}

La figure~\ref{fig:akhter_chemin_aida_2007_figure_4} provient de l'ex\'ecution des modules r.vi et r.vi.mpi de GRASS en utilisant un nombre d'op\'erations croissant. Pour calculer diff\'erents indices de v\'eg\'etation la charge de travail au sein des esclaves est trop petite pour tirer parti du module r.vi.mpi. Donc, le but de cette exp\'erimentation est de d\'eterminer la charge de travail n\'ecessaire pour accro\^itre les performances d'une version parall\`ele. Dans la figure~\ref{fig:akhter_chemin_aida_2007_figure_4}, pour calculer le NDVI seulement 3 op\'erations sont n\'ecessaires (soustraction, addition et division) ce qui prend seulement quelques secondes \`a ex\'ecuter, la version sur CPU unique n\'ecessite au final moins de temps de calcul que la version parall\`ele. N\'eanmoins, une augmentation du nombre d'op\'erations permet une meilleure performance de la version parall\`ele. Il est clair dans la figure~\ref{fig:akhter_chemin_aida_2007_figure_4} que pour avoir un b\'en\'efice en version parall\`ele la charge totale de calcul doit \^etre d'au moins 300 op\'erations pour que le surc\^out de communication soit d\'epass\'e par la charge de calcul elle-m\^eme.
%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.25]{programming/yann/akhter_chemin_aida_2007_figure_4.png}
   %caption of the figure
   \caption{\'Evaluation de la performance des versions s\'equentielles (r.vi) et MPI (r.vi.mpi)}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_figure_4}
\end{figure}

Quand le ma\^itre et un noeud travaillent ensemble pour r\'esoudre un probl\`eme particulier, lenoeud ma\^itre va allouer tout le travail \`a ce seul noeud esclave pout traitement. S'il y a deux noeuds esclaves, la charge de travail sera distribu\'ee entre ces deux noeuds. De m\^eme pour 3 ex\'ecutants, la charge de travail sera distribu\'ee en 3 parts \'egales. Donc la performance en temps augmente : pour un ma\^itre avec 2 noeuds esclaves le temps sera 2 fois moindre qu'avec un seul noeud et le ratio sera de 3 pour un ma\^itre ayant 3 noeuds esclaves au lieu d'un seul, etc... Cela caract\'eriserait un parall\'elisme parfait.
%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.25]{programming/yann/akhter_chemin_aida_2007_figure_5.png}
   %caption of the figure
   \caption{Effet de la parall\'elisation du module r.vi.mpi avec Temps de Transferts de Donn\'ees (DTT)}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_figure_5}
\end{figure}

En adoptant la d\'emarche pr\'ecis\'ee ci-avant et en s'appuyant sur le module r.vi.mpi, les figures~\ref{fig:akhter_chemin_aida_2007_figure_5} et ~\ref{fig:akhter_chemin_aida_2007_figure_6} ont \'et\'e produites.
Dans celles-ci, les deux courbes des repr\'esentent le ratio du temps total d'ex\'ecution avec 2 et 3 noeuds esclaves sur le temps total d'ex\'ecution avec un seul noeud ceci pour un nombr croissant d'op\'erations. L'augmentation des op\'erations refl\`ete l'accroissement de la charge de travail des noeuds esclaves et une meilleure performance. Pourtant, dans la  figure~\ref{fig:akhter_chemin_aida_2007_figure_5}, les performances ne sont pas si satisfaisantes avec les valeurs d\'esir\'ees (c'est \`a dire, pas aussi satisfaisante qu'un parall\'elisme parfait) \`a cause du surco\^ut r\'egulier et \'elev\'e de communication entre les noeuds.

Dans les \'equations 1, 2 et 3, les termes suivants ont \'et\'e utilis\'es :

%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.4]{programming/yann/akhter_chemin_aida_2007_table_2.jpg}
   %caption of the figure
   \caption{Termes utilis\'es et leurs d\'efinitions}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_table_2}
\end{figure}

\begin{equation}
DTT=\{NR \times  (VDS + VDR)\}/(NBW)
\end{equation}
\begin{equation}
VDS=NB \times  DTS \times (NC+1)
\end{equation}
\begin{equation}
VDR=DTS\times (NC+1)
\end{equation}
En s'appuyant sur les \'equations 2 et 3, l'\'equation 1 est d\'eriv\'ee en :

\begin{equation}
DTT1=(6 \times  8 \times (8519 + 1))+(8 \times (8519 + 1)) 
\end{equation}

\begin{equation}
DTT2=100 \times  1024 \times  1024
\end{equation}

\begin{equation}
DTT=(7630 \times 8 \times DTT1)/DTT2=277.74 Sec
\end{equation}

Pour \'evaluer pr\'ecisément la performance de la version parall\`ele, la figure~\ref{fig:akhter_chemin_aida_2007_figure_6} a \'et\'e g\'en\'er\'ee. Seul le temps d'ex\'ecution est adress\'e ici, car le Temps de Transfert des Donn\'ees (DTT) a \'et\'e soustrait du temps total d''ex\'ecution. Due \`a la quantit\'e constante de données qu'il est n\'ecessaire de transformer entre le ma\^itre et les esclaves, le DTT est d\'eriv\'e des \'equations ci-dessus. La figure~\ref{fig:akhter_chemin_aida_2007_figure_6} montre que la performance des noeuds esclaves s'am\'eliorent et atteint presque les valeurs souhait\'ees. Cela conclut que le module r.vi.mpi remplit bien sa fonction de distribution des t\^aches de calcul.


%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.25]{programming/yann/akhter_chemin_aida_2007_figure_6.png}
   %caption of the figure
   \caption{Effet de parall\`elisation du module r.vi.mpi sans DTT}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_figure_6}
\end{figure}

La figure~\ref{fig:akhter_chemin_aida_2007_figure_7} rend compte de la performance des modules r.vi, r.vi.mpi, r.vi.grid de GRASS en terme de temps de calcul. Trois charges de travail test (faible, moyenne et haute) ont \'et\'e assign\'ees \`a chacun de ces modules. Quand la charge de travail est faible, la version sur CPU unique (r.vi) est la meilleure \`a cause du faible parall\`elisme pour lequel le temps de communication est plus grand que le temps d'ex\'ecution. Pour atteindre un parall\'elisme plus important, la charge de travail doit \^etre augment\'ee afin que le temps de communication devienne mineur vis \`a vis du temps d'ex\'ecution. Plus la charge de travail augmente de 1800 vers 3000 op\'erations, plus les versions parall\`eles sont performantes par rapport \`a la version simple s\'equentielle.

%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots etc)/PDF (drawings) format:
   \includegraphics[scale=0.25]{programming/yann/akhter_chemin_aida_2007_figure_7.png}
   %caption of the figure
   \caption{\'Evaluation de la performance des modules GRASS: r.vi, r.vi.mpi et r.vi.grid}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:akhter_chemin_aida_2007_figure_7}
\end{figure}

La version MPI, r.vi.mpi produit les meilleures performances parmi les trois mod\`eles. N\'eanmoins, MPI est utilis\'e principalement dans les syst\`emes de type cluster o\`u les noeuds ont des sp\'ecifications techniques homog\`enes. De plus, les noeuds de calcul disponibles dans un cluster sont limit\'es et cela constitue un obstacle dans la r\'epartition des charges de travail lors de traitements lourds. Dans ce cas pr\'ecis, une infrastructure de type ``Grid computing'' (grille de calcul) peut s'av\'erer n\'ecessaire. En effet, l'environnement g\`ere l'h\'et\'erog\'en\'eit\'e de m\^eme que la distribution des r\'eseaux connect\'es. Jusqu'\`a pr\'esent, Ninf-G est plus performant que la version \`a s'\'equentielle (c'est \`a dire, \`a CPU unique) pour les exemples de charges de travail importante.

Dans cette exp\'erience, Ninf-G n'est pas plus performant que MPI \`a cause du surco\^ut de communication (pour \'etablir la session avec les h\^otes distants) qui avec Ninf-G est plus important qu'avec MPI. Ninf-G est sp\'ecifiquement con\c{c}u pour les environnements de calcul de type Grid (grille de calcul), et non pas pour \^etre utilis\'e dans un cluster comme cela a \'et\'e fait dans les exp\'erimentations illustr\'ees pr\'ec\'edemment. Quand la charge de calcul est plus grande que celle de communication, l'am\'elioration r\'eelle de performance avec Ninf-G se fait sentir. Pour l'instant, r.vi.grid est d\'evelopp\'e et test\'e. Dans un futur proche, un banc d'essai dans un v\'eritable environnement de type grid (grille de calcul) dans lequel l'exp\'erience sera reproduite sera r\'ealis\'e
afin de mettre en exergue les apports d'une telle infrastructure.


\section{Conclusion}
\label{sec:Conclusion}

GRASS (Geographic Resources Analysis Support System) est utilis\'e pour des tâches d’analyse et de visualisation de donn\'ees SIG et de t\'el\'ed\'etection. Aujourd'hui, GRASS est capable de manipuler de larges jeux de donn\'ees. La performance et les capacit\'es de GRASS \`a traiter de grands jeux de donn\'ees peuvent \^etre am\'elior\'ees de beaucoup en int\'egrant GRASS dans des environnements de calcul parall\`ele et distribu\'e. Le principal objectif de cette recherche \'etait de donner \`a un utilisateur de donn\'ees de t\'el\'ed\'etection un exemple compacte de programmation \`a l'aide de Ninf-G et MPI, afin de r\'ealiser des traitements avec GRASS GIS de mani\`ere distribu\'ee. Ce type de recherche devrait de surcro\^it, contribuer \`a rapprocher les communaut\'es de la t\'el\'ed\'etection et des SIG avec celle du calcul en haute performance (HPC).

\section{Remerciements}
\label{sec:Acknowledgements}

Les auteurs voudraient remercier sp\'ecialement Osawa Kiyoshi (doctorant au Laboratoire AIDA), SunHao et Nishimura Motokazu (\'etudiants en Masters au laboratoire AIDA) pour leur support dans la cr\'eation de banc d'essai (Davinchi 
Cluster) ayant permis de mener cette exp\'erience. Les auteurs voudraient aussi remercier tous les membres du laboratoire AIDA pour leur soutien moral.

\begin{footnotesize}
\begin{thebibliography}{99}

\bibitem[Sain et~al. (1996) Snir, Otto, Huss-Lederman, Walker, Dongarra]{Snir:1996} 
M. Snir, S. Otto, S. Huss-Lederman, D. Walker and J . Dongarra (1996)
\newblock MPI: The Complete Reference.
\newblock {Massachusetts Institute of Technology}.
\newblock {http://www.netlib.org/utk/papers/mpi-book/mpi-book.html}.
 

\bibitem[Foster et~al. (1997) Foster, Kesselman]{Foster:1997} 
I. Foster and C. Kesselman (1997)
\newblock Globus: A Metacomputing Infrastructure Toolkit.
\newblock {International Journal of Supercomputer Applications}.

\bibitem[Neteler et~al. (2003) Neteler, Mitasova]{Neteler:2003} 
M. Neteler and H. Mitasova (2003)
\newblock Open Source GIS: A GRASS GIS Approach. Second Edition.
\newblock {\em Kluwer Academic Publishers}.

\bibitem[Tanaka et~al. (2003) Tanaka, Nakada, Sekiguchi, Suzumarn, Matsuoka]{Tanaka:2003} 
Y. Tanaka, H. Nakada, S. Sekiguchi, T. Suzumarn, S. Matsuoka (2003)
\newblock Ninf-G: A Reference Implementation of RPC-based Programming Middleware for Grid Computing
\newblock {Journal of Grid Computing} 1: 41-51.

\bibitem[Kamble et~al. (2006) Kamble, Chemin]{Kamble:2006} 
B. Kamble, Y.H. Chemin (2006)
\newblock GIPE in GRASS Raster Add-ons. 
\newblock http://grass.gdf-hannover.de/wiki/, GRASSAddOns, RasterAdd-ons
\newblock {Internet}.

\bibitem[Message Passing Interface (MPI). (2007) MPI]{MPI:2007} 
MPI(2007)
\newblock http://www-unix.mcs.anl.gov/mpi/
\newblock {Internet}.

\bibitem[Ninf-G Homepage. (2007) Ninf-G]{Ninf-G:2007} 
Ninf-G(2007)
\newblock http://ninf.apgrid.org/
\newblock {Internet}.

\bibitem[Weier et~al. (2007) Weier, Herring]{Weier:2007}
J.Weier and D.Herring. (2007)
\newblock Measuring Vegetation (NDVI/EVI)
\newblock http://earthobservatory.nasa.gov/Library/MeasuringVegetation/
\newblock {Internet}.

\bibitem[SUN Grid Engine. (2007) ]{SUN Grid Engine:2007} 
SUN Grid Engine(2007)
\newblock http://www.lesc.ic.ac.uk/projects/epic-gt-sge.html
\newblock {Internet}.


\end{thebibliography}
\end{footnotesize}


\address{Shamim Akhter\\
  Tokyo Institute of Technology\\
  \url{http://www.alab.ip.titech.ac.jp/~shamim}\\
  \email{shamimakhter@gmail.com}}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: main_document.tex
%%% End: 

