
\title{Porting a GRASS raster module to distributed computing}
\subtitle{Examples for MPI and Ninf-G}
\author{Shamim Akhter, Yann Chemin, Kento Aida}

\maketitle

\section{Abstract}
\label{sec:Abstract}

Satellite imagery provides a large amount of useful information. To extract this information and understand them may require huge computing power and processing time. Distributed computing can reduce the processing time by providing more computational power. GRASS, an open source software, has been used for processing the satellite images. To let the GRASS modules benefit from distributed computing, an example module \texttt{r.vi} is ported in both MPI (\texttt{r.vi.mpi}) and Ninf-G (\texttt{r.vi.grid}) programming modules. Their implementation methodologies are the main discussion issue of this paper which will guide the basic way of representing any GRASS raster module in distributed platform. Additionally, a comparative study on modified \texttt{r.vi, r.vi.mpi} and \texttt{r.vi.grid} is presented here.


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

Satellite image processing plays a vital role for research developments in Remote Sensing, GIS, Agriculture Monitoring, Disaster Management and many other fields of study. However, processing those even increasing spatial resolution satellite images require a large amount of computation time due to its complex and large processing criteria. This seems a barrier for real time decision making. Distributed computing can be a suitable solution to complete the job timely. Cluster and Grid are two well-known distributed systems have been associated with high performance computing of massive CPU bound applications. GRASS GIS \citep{Neteler:2004} is an open source software/tool, which has been used to process satellite images. Inside GRASS, different modules have been developed for processing satellite images. GRASS module \texttt{r.vi} is developed by \citep{Kamble:2006}, and is used as a test example for this study. Developing the methodology, which enables to run GRASS GIS environment for satellite image processing on distributed computing systems, is the main concerning issue of this paper. Additionally, two different implementation methodologies for distributed \texttt{r.vi} are discussed for two different programming platforms MPI \citep{MPI:2007} and Ninf-G \citep{Ninf-G:2007}. 

Vegetation Index (VI) is the major set of indicators for vegetation. The GRASS module \texttt{r.vi}, is used to process 13 different vegetation indexes for the satellite images. NDVI (Normalized Difference Vegetation Index \citep{Weier:2007} is one of them. The NDVI is calculated from these individual measurements as NDVI=(NIR-Red)/(NIR+Red), where RED and NIR stand for the spectral reflectance measurements acquired in the red and near-infrared regions, respectively. Other vegetation indices are as follows:

\begin{figure}[htbp]
   \centering
   \includegraphics[width=1\textwidth]{programming/yann/akhter_chemin_aida_2007_table_0.jpg}
   \caption{Vegetation Indexes}
   \label{fig:akhter_chemin_aida_2007_table_0}
\end{figure}

They are derived using various methods of differentiations and contrast. Fig.~\ref{fig:akhter_chemin_aida_2007_figure_1} shows a snapshot of an output of GRASS Software. 

\begin{figure}[htbp]
   \centering
   \includegraphics[width=0.9\textwidth]{programming/yann/akhter_chemin_aida_2007_figure_1.png}
   \caption{NDVI calculations with GRASS}
   \label{fig:akhter_chemin_aida_2007_figure_1}
\end{figure}

GRASS module \texttt{r.vi} works with raster images (rows x columns). Different band raster images are required for different indices. The generic indices (NDVI, RVI, etc) use red and NIR (Near Infra-Red) band images. However, ARVI uses red, NIR and blue band images, GVI uses red, NIR, blue,green, chan5 and chan 7 of landsat images and GARI uses red, NIR, blue and green bands. GRASS functions are used to extract row-wise data from the specific band images and store them in buffers. Then, each column value is extracted sequentially from the buffers and sent for generating the specific VI values. Thus, after completing the VI from row buffers, the row wise VI values are put back into output image and this process will continue for each row. Fig.~\ref{fig:akhter_chemin_aida_2007_figure_2} presents the structure of serial running \texttt{r.vi} module (for simplicity only two band images have been presented).

\begin{figure}[htbp]
   \centering
   \includegraphics[width=1\textwidth]{programming/yann/akhter_chemin_aida_2007_figure_2.png}
   \caption{Serially Running r.vi Module Structure}
   \label{fig:akhter_chemin_aida_2007_figure_2}
\end{figure}

\section{Objectives}
\label{sec:Objectives}

Under the assumption that distributed style of computing will remove computational time constraints, new image processing distributed algorithms for remotely sensed images can be considered. Different GRASS modules have been developed for solving different Remote Sensing Image analysis problems. To evaluate the performance of the GRASS modules in distributed computing environment is the major objective of this paper. Additionally, it is a new dimension for the remote sensing users to port their jobs in distributed computing environment. Another issue addressed in this paper is to find out the sufficient amount of workload that is needed to dispatch among the worker nodes for getting better performance than the serial module.

\section{Methodology}
\label{sec:Methodology}

To fulfill the above objectives or requirements, the GRASS module (\texttt{r.vi}) has been parallelized by using the master-worker model. The master process runs in the GRASS environment, and decomposes the target images in rows and dispatches the computation of rows to multiple worker processes. Worker processes are free from GRASS, they just run the computation and send back the row wise result to the master process. The module \texttt{r.vi} is implemented using MPI on a PC cluster system (\texttt{r.vi.mpi}) and Ninf-G on the same PC cluster system (\texttt{r.vi.grid}) to hold the similarity between the experimental environments. However, \texttt{r.vi.grid} module has been structured as it is capable to run in distributed GRID system. Additionally, experiments were done to analyse the results with distributed \texttt{r.vi} modules by increasing the number of operations, to find out the amount of workload that is necessary to get a performance benefit from the distributing environments.

   In Fig.~\ref{fig:akhter_chemin_aida_2007_figure_3}, the implementing structure of distributed r.vi is presented (for simplicity only two band images have been presented). Here, S1, S2, .....,Sn are different worker processes.     

\begin{figure}[htbp]
   \centering
   \includegraphics[width=1\textwidth]{programming/yann/akhter_chemin_aida_2007_figure_3.png}
   \caption{Distributed r.vi Module Structure (r.vi.mpi and r.vi.grid)}
   \label{fig:akhter_chemin_aida_2007_figure_3}
\end{figure}

\section{Implementation}
\label{sec:Implementation}

\subsection{MPI and Ninf-G Framework}
\label{subsec:MPI and Ninf-G}


MPI (Message Passing Interface) is a library of functions (in C) or subroutines (in FORTRAN) that one can insert into the source code to perform data communication between processors \citep {Snir:1996}. MPI was designed for high performance on both massively parallel machines and on workstation clusters and developed by a broadly based committee of vendors, implementors, and users.  

The Ninf-G has been developed by AIST (National Institute of Advanced Industrial Science and Technology, Japan) and TITECH (Tokyo Institute of Technology, Japan). Ninf-G is a reimplementation of the Ninf system on top of the Globus Toolkit \citep {Foster:1997}. Globus serves as a robust and common platform for implementing higher level middleware and programming tools, etc., ensuring interoperability amongst such high level components, one of which being NinfG. NinfG system is based on client server computing. The computational resources are available as remote libraries at a remote computation host which can be called through the global network from client program written in existing languages such as FORTRAN, C, or C++.

\subsection{Specification of the Davinchi Cluster}
\label{subsec:Specification of the Davinchi Cluster}

The Cluster nodes for the experiments are as follows:
\begin{figure}[htbp]
   \centering
   \includegraphics[width=1\textwidth]{programming/yann/akhter_chemin_aida_2007_table_1.jpg}
   \caption{Specifications of Davinchi Cluster}
   \label{fig:akhter_chemin_aida_2007_table_1}
\end{figure}

\subsection{Distributed r.vi Module in MPI (r.vi.mpi)}
\label{subsec:Distributed_r_vi_Module_in_MPI_r.vi.mpi}

For \texttt{r.vi.mpi}, GRASS source code is installed in master node and GRASS libraries are copied to the slaves local memory location exactly the same as master (/usr/local/grass-6.0.2/) and the following configuration steps are completed to setup the MPI-GRASS environment. 

\begin{itemize}
	\item $grass.conf$ file is created inside $/etc/ld.so.conf.d/$ directory and the required grass library names are written inside this file.
	\item Then the /sbin/ld\_config command is executed.
\end{itemize}

MPI\_Send and MPI\_Recv both functions have been used for data communication.


The following Makefile is created for compilation
\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}

To run the code the following shell command has been used:
\begin{smallverbatim}
mpirun -np 3 location_of_exec_file parameters.. 
\end{smallverbatim}
In this experiment the location of the executable file is: 
$GRASS\_COMPILE\_DIR$/dist.i686-pc-linux-gnu/bin/r.vi.mpi  
The pseudo-code of r.vi.mpi is appended here:
\begin{smallverbatim}
#include "gis.h"
#include "glocale.h"
#include "mpi.h"


/* main.c: Declare the following MPI code */
/* NUM_HOSTS is total host number         */
/* me is defined processor rank/number    */

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

/*----------------------------------------*/
/* Master Code Begin: Rank 0 (me=0)       */


/* Extract total row and column number    */
/* and sends them to the slaves           */ 


for(i=1;i<NUM_HOSTS;i++)
// i Loop Started:

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

// i Loop Finished.
 
/* Row data are extracted from images and    */
/* dispatched them among slaves with specific*/ 
/* row number by Round Robin Fashion         */

for (r = 1; r*(NUM_HOSTS-1) <= nrows;r++ )
// r Loop Started:

 for(k=1;k<NUM_HOSTS;k++)
 // k Loop Started: 
 
   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++)
   // col Loop Started:
   
      //Each column cell values form all bands
      // are extracted and put them in a 2D array 
     db[0][col]= d_redchan;
     db[1][col]= d_nirchan;
   
   // col Loop Finished.
   
   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);
  
 // k Loop Finished.
 
 // Waiting for the result...
 
 for(k=1;k<NUM_HOSTS;k++)
 // k Loop Start:
 
   MPI_Recv(R,ncols+1,MPI_DOUBLE,k,1,\
   MPI_COMM_WORLD,&status);
   row_n=R[ncols];
   for (cn=0;cn<ncols;cn++)
   // cn Loop Started:
   
	outputImage[row_n][cn]=R[cn];
  
   // cn Loop Finished. 

 // k Loop Finished.
 
 // Processes row put back to the result images
 for(k=0;k<(NUM_HOSTS-1);k++)
 // k Loop Start:
 
  for(j=0;j<ncols;j++)
  // j Loop Start:
  
  ((DCELL *) outrast)[j] = outputImage[k][j];
  G_put_raster_row(outfd,outrast,data_type_output);
    
  // j Loop Finished.
  
 // k Loop Finished.
 
// r Loop Finished.

/* If any row left when (row_number%slaves!=0), */
/* the round robin fashion rest rows (lets n)   */
/* are distributed from slave 1 to slave n again*/
 
MPI_Finalize();
G_free(inrast_redchan);

/* Master code Finished                        */
/*----------------------------------------     */

/*-----------------------------------------    */
/* Slave Code Begin: Rank not 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++;

// Data Receiving from master and process
for(i=0;i<n_rows;i++)
// i Loop Started:
  
  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++)
  // col Loop Started:
   
   ndvi(db[0][col],db[1][col]); // Process ndvi()
  
  // col Loop Finished.
  
  r[ncols]=I[ncols]; 
  
   // results are in r[] and 
   // sends back to master
  MPI_Send(r,ncols+1,MPI_DOUBLE,0,1,\
  MPI_COMM_WORLD);

// i Loop Finished.

 MPI_Finalize();
 
/* Slave Code Finished.                      */
/*-------------------------------------------*/
\end{smallverbatim}


\subsection{Distributed r.vi Module in GRID (r.vi.grid)}
\label{subsec:Distributed_r_vi_Module_in_GRID_r.vi.grid}

\texttt{r.vi} is easier to port in Ninf-G environment than MPI. Here, no need to copy the library files, because the worker procedure is totally independent from the master procedure and GRASS environment. GridRPC \citep{Tanaka:2003} calling API is used for communication between the master and workers.
The following Makefile is created for compilation 

\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}

Like any other GRASS modules \texttt{r.vi.grid} can run by the command:

\begin{smallverbatim}
r.vi.grid  parameters
\end{smallverbatim}

Worker IDL file is as follow:
\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}

Worker code is as follow:
\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++)
 //col Loop Started
 
    //column wise value going to process for 
    // specific indexing, put results in r []
	// as for ndvi processing....
	r[col]=(a[col]-b[col])/(a[col]+b[col]);

 //col Loop Finished.
	
} //function call finish
\end{smallverbatim}


Master module code is as following:
\begin{smallverbatim}

#include "gis.h"
#include "glocale.h"
#include "grpc.h" // we need grpc.h header file
#define NUM_HOSTS 5 //how many hosts available

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);
}


//creating one handle for each host node
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++)
// row Loop Started:


  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++)
  // col Loop Started:

  
     // each column cell values for all 
     // band images are extracted together 
     // and put them in 2D arrays 
    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;  
    // vegetation indexing array  valuess are 
    // filled in I[ncols] array

 
  // col Loop Finished.

  
  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);
  }

  
  // All outputs are put back into raster
  for(j=0;j<ncols;j++)
  // j Loop Started:

  
    ((DCELL *) outrast)[j] = R[j];
  
  // j Loop Finished.
  
   if(G_put_raster_row(outfd,outrast,\
      data_type_output) < 0)
   G_fatal_error(_("Cannot write to output\
      raster file"));
  
  host_n++;

 // row Loop Finished.

 // Destruct the handles
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...(Free memory)
\end{smallverbatim}



\section{Experimental Results}
\label{sec:Experimental_Results}

Fig.~\ref{fig:akhter_chemin_aida_2007_figure_4} is generated by running \texttt{r.vi} and \texttt{r.vi.mpi} GRASS module with increasing the operation numbers. To calculate different vegetation indices the workload in the slaves is too small to get benefit from \texttt{r.vi.mpi} module. Thus, the purpose of this experiment is to find out the sufficient amount of workload that will make the parallel version faster. In Fig.~\ref{fig:akhter_chemin_aida_2007_figure_4}, to calculate the NDVI takes only 3 operations (subtraction, addition and then division) and this amount of workload takes just few seconds to execute, where the serial version takes less processing time then parallel version. However, increasing the number of operations provide better performance in parallel version. It is clear from Fig.~\ref{fig:akhter_chemin_aida_2007_figure_4} that to get the benefit from the parallel version the total workload needs to be around 300 operations or more so that the communication overhead will be overpassed by the computational workload.
\begin{figure}[htbp]
   \centering
   \includegraphics[width=0.8\textwidth]{programming/yann/akhter_chemin_aida_2007_figure_4.png}
   \caption{Performance Evaluation of Serial (r.vi) and MPI (r.vi.mpi) Version}
   \label{fig:akhter_chemin_aida_2007_figure_4}
\end{figure}

When master with one worker node (slave) are working together to solve a particular problem, the master node will dispatch the whole job to his slave for processing. When there will be 2 slaves, the workload will be distributed among two salves. Similarly for 3 slaves, the workload will be distributed to 3 slaves equally. So the time performance increase for master with 2 slaves will be 2 times than master with one slave and the ratio will be 3 times for master with 3 slaves with one slave and so on... This would highlight a perfect parallelism.   
\begin{figure}[htbp]
   \centering
   \includegraphics[width=.9\textwidth]{programming/yann/akhter_chemin_aida_2007_figure_5.png}
   \caption{Parallelization Effect of r.vi.mpi Module with DTT}
   \label{fig:akhter_chemin_aida_2007_figure_5}
\end{figure}

Concerning the above philosophy and experimenting on \texttt{r.vi.mpi} module, Fig.~\ref{fig:akhter_chemin_aida_2007_figure_5} and Fig.~\ref{fig:akhter_chemin_aida_2007_figure_6} have been generated. 
In Fig.~\ref{fig:akhter_chemin_aida_2007_figure_5} and Fig.~\ref{fig:akhter_chemin_aida_2007_figure_6}, the \emph{2 Slaves} curve presents the ratio of  the total running time between master with two slaves and master with one slave. The \emph{3 Slaves} curve represents the ratio of the total running time between master node with 3 slaves and master (one slave) with increasing the operation numbers. Increasing the operations, reflects to increase the workload in slaves and improving the performance. However, in Fig.~\ref{fig:akhter_chemin_aida_2007_figure_5}, the performances are not satisfying with the desire values (as perfect parallelism) due to the regular and high communication overhead. 


In equation 1, 2 and 3 the following terms have been used.

\vspace{0.2cm}

\begin{figure}[htbp]
   \centering
   \includegraphics[width=0.7\textwidth]{programming/yann/akhter_chemin_aida_2007_table_2.jpg}
   \caption{Terms used and their definitions}
   \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}

From equation 2 and 3, equation 1 has been derived as
\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}
 

To evaluate the parallel version performance more precisely, Fig.~\ref{fig:akhter_chemin_aida_2007_figure_6} has been generated. Only the execution time (Data Transfer Time has been reduced from the total running time) is concerned here. Due to a constant amount of data need to transform between master and slaves, the transfer time (DTT) is derived from the above equations. Fig.~\ref{fig:akhter_chemin_aida_2007_figure_6} shows that the performance in the slaves curves are improving and nearly to the desirable values. It concludes that \texttt{r.vi.mpi} module is working well in distributed manner.

%\onecolumn
\begin{figure}[htbp]
   \centering
   \includegraphics[width=0.9\textwidth]{programming/yann/akhter_chemin_aida_2007_figure_6.png}
   \caption{Parallelization Effect of r.vi.mpi module without DTT}
   \label{fig:akhter_chemin_aida_2007_figure_6}
\end{figure}
%\twocolumn[]
Fig.~\ref{fig:akhter_chemin_aida_2007_figure_7} evaluates the performance of the GRASS modules (\texttt{r.vi, r.vi.mpi, r.vi.grid}) in the time domain. Low, middle and high, three testing workloads have been set in the modules. When the workload is low, serial version (\texttt{r.vi}) is performing best because of the fine-grain parallelism where communication time is bigger than the execution time. To get the coarse-grain, the workload need to be increased so that the communication time will be hidden by the execution time. As the workload increased to 1800 and 3000 operations, parallel versions are performing better then the serial version. 


\begin{figure}[htbp]
   \centering
   \includegraphics[width=0.9\textwidth]{programming/yann/akhter_chemin_aida_2007_figure_7.png}
   \caption{Performance Evaluation of GRASS Modules (r.vi, r.vi.mpi and r.vi.grid)}
   \label{fig:akhter_chemin_aida_2007_figure_7}
\end{figure}

MPI version, \texttt{r.vi.mpi} provides the best performance among the three models. However, MPI is used mainly in Cluster Computers where the nodes are homogeneous in their specification. Additionally, available nodes in Clusters are limited up to a specific range and this will be an obstacle for load balancing for big processing jobs. In this case, Grid computing infrastructure is necessary. Indeed, (the environment maintains heterogeneity as well as distributed connecting networks). So far Ninf-G is performing better than the serial version for high work load examples.

Particularly, in this issue, Ninf-G is not performing better than MPI for the reason that, the communication overhead (to establish the session with remote hosts) in Ninf-G is larger than MPI. Ninf-G is specially made for Grid-Computing environment (not for running inside Cluster computing environment as have been done in above experiments). When the processing workload is much higher than the communication workload, the real performance improvement with Ninf-G platform will show up.  So far, \texttt{r.vi.grid} is developed and tested. In near future, the experiment on real Grid testbed will be highlighted.


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

Geographic Resources Analysis Support System (GRASS) has been used for RS and GIS data analysis and visualization. Currently, GRASS handles large datasets and the performance and capabilities of GRASS for large datasets can be greatly improved by integrating GRASS with parallel and distributed computing. The major objective of this research was to provide the Remote Sensing user a compact example with Grid and MPI programming for GRASS GIS distributed processing. Additionally, this type of research will merge the Remote Sensing and GIS with High Performance Computing communities. 

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

The authors would like to acknowledge specially, to Osawa Kiyoshi San (PhD Candidate in AIDA Lab), SunHao San (Masters Student in AIDA Lab) and Nishimora Motokazu San (Masters Student in AIDA Lab) for their support to create the testbed (Davinchi Cluster) ready for this experiment. Authors also like to thanks to all the members in AIDA Lab for the moral support.

\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. (2004) Neteler, Mitasova]{Neteler:2004} 
M. Neteler and H. Mitasova (2004)
\newblock Open Source GIS: A GRASS GIS Approach. Second Edition.
\newblock {\em Kluwer Academic Publishers/Springer}.

\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, Kento Aida\\
Tokyo Institute of Technology\\
\url{http://www.alab.ip.titech.ac.jp/~shamim}\\
\email{shamimakhter AT gmail.com}\\
\\
Yann Chemin\\
\email{yann.chemin AT gmail.com}}
