C Prud'homme

V Chabannes

V Doyeux

M Ismail

A Samake

G Pena
email: gpena@mat.uc.pt

C Daversin
email: cecile.daversin@lncmi.cnrs.fr

C Trophime

ADVANCES IN FEEL++ : A DOMAIN SPECIFIC EMBEDDED LANGUAGE IN C++ FOR PARTIAL DIFFERENTIAL EQUATIONS

Keywords: Galerkin methods, finite element, parallel computing, domain specific embedded language, programming paradigms

.

Introduction

Libraries to solve problems arising from partial differential equations (PDEs) through generalized Galerkin methods are a common tool among mathematicians and engineers. However, most libraries end up specializing in a type of equation, e.g. Navier-Stokes or linear elasticity models, or a specific type of numerical method, e.g. finite elements. The increasing complexity of differential models and the implementation of state of the art robust numerical methods, demand from scientific computing platforms general and clear enough languages to express such problems and provide a wealth of solution algorithms available in a minimal amount of code but maximum mathematical control. There are many freely available libraries which offer the capabilities described previously to a certain extent. To name a few: the Freefem software family [START_REF] Hecht | FreeFEM++ Manual[END_REF][START_REF] Stéphane | FreeFEM3D Manual[END_REF], the Fenics project [START_REF] Kirby | A compiler for variational forms[END_REF][START_REF] Kirby | Efficient compilation of a class of variational forms[END_REF], Getdp [START_REF] Dular | Getdp: a general environment for the treatment of discrete problems[END_REF] or Getfem++ [START_REF] Renard | Getfem++: Generic and efficient c++ library for finite element methods elementary computations[END_REF], or libraries or frameworks such as deal.II (C ++ ) [START_REF] Bangerth | II Differential Equations Analysis Library[END_REF], Sundance (C ++ ) [START_REF] Long | Sundance: Rapid development of high-performance parallel finite-element solutions of partial differential equations[END_REF], Analysa (Scheme) [START_REF] Bagheri | Analysa[END_REF]. Either they rely on a domain specific language (Python, the freefem language, ...) when it comes to describe the PDE to solve, or they are geometry or dimension dependent, or they are not so expressive with respect to the mathematics, i.e. the mathematics are hidden by programming details.

The library we present in this paper, called FEEL++, Finite Element Embedded Language in C ++ , see [START_REF] Prud | A domain specific embedded language in C++ for automatic differentiation, projection, integration and variational formulations[END_REF][START_REF] Prud | Life: Overview of a unified C++ implementation of the finite and spectral element methods in 1d, 2d and 3d[END_REF] for the initial papers, provides also a clear and easy to use interface to solve complex PDE systems. It aims at bringing the scientific community a tool for the implementation of advanced numerical methods and high performance computing. Some recent applications of FEEL++ to multiphysics problems can be found in the literature, see [START_REF] Chabannes | High order fluid structure interaction in 2D and 3D: Application to blood flow in arteries[END_REF][START_REF] Doyeux | Simulation of two fluid flow using a level set method application to bubbles and vesicle dynamics[END_REF][START_REF] Pena | Spectral Element Approximation of the incompressible Navier-Stokes equations evolving in a moving domain and applications[END_REF][START_REF] Pena | Construction of a high order fluid-structure interaction solver[END_REF][START_REF] Pena | High order methods for the approximation of the incompressible navier-stokes equations in a moving domain[END_REF].

Two main aspects in the design of the library are to (i) have the syntax, semantics and pragmatics of the library very close to the mathematics, and (ii) have a small manageable library that makes use wherever possible of established libraries (for linear system solves, for instance). While the first aims at creating a high level language powerful enough to describe solution strategies in a simple way, the second helps with the maintenance of the code delegating some procedures to frequently maintained third party libraries.

FEEL++ relies on a so-called domain specific embedded language (DSEL) designed to closely match the Galerkin mathematical framework. In computer science, DS(E)Ls are used to partition complexity and in our case the DSEL splits low level mathematics and computer science on one side leaving the FEEL++ developer to enhance them and high level mathematics as well as physical applications to the other side which are left to the FEEL++ user. This enables using FEEL++ for teaching purposes, solving complex problems with multiple physics and scales or rapid prototyping of new methods, schemes or algorithms. The goal is always to hide (ideally all) technical details behind software layers, provide only the relevant components required by the user or programmer and enforce the mathematical language computationnally between the users be they physicists, mathematicians, computer scientists, engineers or students. The DSEL approach has advantages over generating a specific external language: (i) interpreter/compiler construction complexities can be ignored, (ii) libraries can concurrently be used which is often not the case of specific languages which would have to also develop their own libraries and library system, (iii) DSELs inherit the capabilities of the host language (e.g.C ++ ).

The DSEL on FEEL++ provides access to powerful, yet with a simple and seamless interface, tools such as interpolation or the clear translation of a wide range of variational formulations into the variational embedded language. Combined with this robust engine, lie also state of the art arbitrary order finite elements -including handling high order geomtrical approximations, -high order quadrature formulas and robust nodal configuration sets. The tools at the user's disposal grant the flexibility to implement numerical methods that cover a large combination of choices from meshes, function spaces or quadrature points using the same integrated language and control at each stage of the solution process the numerical approximations.

Finally FEEL++ uses advanced C ++ (e.g. template meta-programming) and in particular the latest standard C ++ 11 that provides very useful additions such as type inferenceauto and decltype keywords which are used throughout the paper. -FEEL++ also uses the essential Boost C ++ libraries [START_REF]Boost c++ libraries[END_REF]: in this paper most scripts displayed use explicitely the Boost Parameter library1 enabling a very powerful programming interface namely named parameters (required and optional) given in a random order to a class -template parameters -, a class member function or a free function. This library enhances tremendously readability, expressivity and ease of use of the code. Many other Boost libraries are used in FEEL++, some are listed in this document.

The paper describes an overview of the main abstractions and interfaces handled by the library. In section 2 we describe basic ideas behind the construction of the reference element, finite elements defined therein and the geometrical transformation. Section 3 shows how to handle and define meshes, function spaces, forms, functionals and operators. The variational embedded language is presented in section 4, with particular emphasis in the projection and integration procedures. Finally we present FEEL++ mesh adaptation interface to GMSH. Thanks to the language and computational framework, parallel computing using MPI is completely seamless and most of FEEL++ examples can be run either in sequential or parallel without the user having to do anything about MPI. More advanced examples using the mortar, Schwartz (non)overlapping, three fields, and ficticious domain-like methods to illustrate the flexibility of the language are available in [START_REF] Prud'homme | Feel++: A computational framework for galerkin methods and advanced numerical methods[END_REF].

Polynomial Library

The polynomial library is composed of various bricks: (i) the geometrical entities or convexes (ii) the prime basis in which we express subsequently the polynomials, (iii) the definition and construction of point sets in convexes (such as quadrature point sets) and finally (iv) polynomials and finite elements.

Convexes

The supported convexes are simplices and hypercubes of topological dimension n, n = 1, 2, 3 lying in R d such that n d 3. The convexes are described geometrically in a standard way in terms of their subentities (vertices, edges, faces, volumes), see for example [START_REF] George | Spectral/hp element methods for CFD[END_REF], and provide the ability to iterate over the entities of a convex or of the same topological dimension inside a convex, e.g. iterate over the edges of a tetrahedron.

Prime basis: L 2 Orthonormal Polynomials

In order to express polynomials in the convexes defined previously, we need to choose a prime basis, i.e., a basis in which all polynomial families are expressed. Often, the choice falls on the canonical basis (also known as the moment or monomial basis). However, recent work by R.C. Kirby [START_REF] Kirby | Algorithm 839: Fiat, a new paradigm for computing finite element basis functions[END_REF][START_REF] Kirby | Optimizing fiat with level 3 blas[END_REF][START_REF] Kirby | Singularity-free evaluation of collapsed-coordinate orthogonal polynomials[END_REF] proposed to use the Dubiner polynomials as a prime basis on the simplex. We extended these ideas on the hypercubes using the Legendre polynomials. Other interesting examples of prime basis being used are the Bernstein polynomials. Our framework uses the Dubiner or Legendre basis as the default prime basis. This choice simplifies the construction of finite elements due to the hierarchical and L 2 orthogonality properties these basis functions share. The choice of basis polynomials that are hierarchical allows for an easy extraction of a basis spanning a subspace of the polynomial space (which corresponds to extract a range of coefficients), whereas L 2 orthogonality simplifies some operations like numerical integration or the L 2 projection (which is explicit in this case). The use of these basis functions proved to provide much better numerical stability, see [START_REF] Pena | Spectral Element Approximation of the incompressible Navier-Stokes equations evolving in a moving domain and applications[END_REF].

Details on the construction of the Dubiner polynomials can be found in [START_REF] George | Spectral/hp element methods for CFD[END_REF] page 101. In practice, the prime basis is normalized.

Point Sets on Convexes

Now we turn to the construction of point sets P defined on a convex K. Point sets are represented algebraically by a matrix (rows are indexed by the coordinates while columns are indexed by the points) and they are parametrized by the associated convex and the numerical type. We recall that the convex is decomposed in vertices, edges, faces, volumes. A similar decomposition is done for the point sets: points are constructed and associated to their respective entities on which they reside. This is crucial when considering continuous and discontinuous Galerkin formulations.

The type of point sets supported are (i) the Equidistributed point set, (ii) the Warpblend point sets on simplices see [START_REF] Warburton | An explicit construction of interpolation nodes on the simplex[END_REF], (iii) Fekete points in simplices, see [START_REF] George | Spectral/hp element methods for CFD[END_REF], (iv) standard quadrature rules in simplices and finally (v) Gauss, Gauss-Radau and Gauss-Lobatto and combinations in simplices and hypercubes. It should be noted that the last family is constructed from the computation of the zeros of the Legendre polynomials on [-1, 1] including eventually the boundary vertices -1, 1 for the Radau and Lobatto flavors.

Warpblend and Fekete points are used with nodal basis on simplices which, when constructed at these points, present much better interpolation properties (lower Lebesgue constant, see [START_REF] George | Spectral/hp element methods for CFD[END_REF]). Note that the Gauss-Lobatto points are the Fekete points in hypercubes.

Polynomial Set

After introducing in the previous sections the necessary bricks to the construction of polynomials on simplices and hypercubes, we now focus on the polynomial abstraction.

A polynomial set P is a template class parametrized by the prime basis in which it is expressed and the field type in which it has its values: scalar, vectorial or matricial. Its interface provides a number of operations such as evaluation and derivation at a set of points, extraction of polynomials or components (when the FieldType is Vectorial or Matricial) of a polynomial from a polynomial set .

One critical operation is the construction of the gradient of a polynomial (or a polynomial set) expressed in the prime basis. This usually requires solving a linear system where the matrix entries are given by the evaluation of the prime basis and its derivatives at a set of points. Again the choice of set of points is crucial here to avoid ill-conditioning and loss of accuracy. We choose Gauss-Lobatto points for hypercubes and Warpblend or Fekete points for simplicies as they provide a much better conditioning for the underlying system matrix (a generalized Vandermonde matrix, see [START_REF] Pena | Spectral Element Approximation of the incompressible Navier-Stokes equations evolving in a moving domain and applications[END_REF]).

Finite Elements and Other Polynomial Basis

FEEL++ supports modal basis, e.g. Legendre or Dubiner, see [START_REF] Canuto | Spectral Methods: Fundamentals in Single Domains[END_REF][START_REF] George | Spectral/hp element methods for CFD[END_REF], as well as finite elements (FE) following the standard definition, set in [START_REF] Ciarlet | Finite Element Method for Elliptic Problems[END_REF], as a triplet (K, P, Σ) where K is a convex, P the polynomial space and Σ the dual space. We describe now some features of the finite element framework. The description of K and P has been presented previously and it remains to describe Σ. Σ is a set of functionals (which can be identified as degrees of freedom) defined in P with values in R, R d or R d×d . Several types of functionals can then be instantiated which merely require basic operations like evaluation at a set of points, derivation at a set of points, exact integration or numerical integration. Some examples of functionals satisfying such requirements are 1. evaluation at a point x ∈ K, x : p → p(x), 2. derivation at a point x ∈ K in the direction i, x,i : p → ∂ p ∂ x i (x), 3. moment integration associated with a polynomial q ∈ P(K), q : p → K pq.

A functional is represented algebraically by a vector whose entries result from the application of the functional to the prime basis in which we express the polynomials thanks to the bijection between L (P, R) and R dim(P ). Then applying the functional to a polynomial is just a scalar product between the coefficient of this polynomial in the prime basis by the vector representing the functional. For example the Lagrange element is the finite element (K, P, Σ = { x i , x i ∈ X ⊂ K}) such that x i (p j ) = δ i j where p j is a Lagrange polynomial and X = {x i } is a set of points defined in the convex K, for example the Equidistributed, Warpblend or Fekete point sets. Other FE such as P 1,2 -bubble, RT k or N k polynomials are constructed likewise though they require a more involved description.

Geometry

To conclude this section, one important object that is constructed with the help of the polynomial library is the geometric transformation. Indeed all polynomial set constructions are done on a reference convex, denoted K, and the geometrical transformation maps it to a convex in the physical space which we denote K. This map, denoted

φ geo K , is the C 1 -diffeomorphism defined on K ⊂ R p , p = 1, 2, 3 such that the image is K ⊂ R d , i.e. φ geo K : K -→ K for p d 3.
This map is contructed and associated to each convex K in a computational mesh T h , see section 3. Notice that this last condition over p and d covers a large spectrum of geometrical profiles. For instance, we handle lines or surfaces in R 3 . We refer the reader to section ?? for an example where this flexibility is exploited.

x ŷ• x1 • x2 • x3 • x4 • x5 • x6 K x y • x 1 • x 2 • x 3 • x 4 • x 5 • x 6 K φ geo K (x) (φ geo K ) -1 (x)
The geometric transformation is constructed as a suitable linear combination of Lagrange polynomials and therefore it can be a polynomial of arbitrary degree, allowing thus meshes with elements that have curved edges/faces, see [START_REF] Pena | Construction of a high order fluid-structure interaction solver[END_REF][START_REF] Pena | High order methods for the approximation of the incompressible navier-stokes equations in a moving domain[END_REF]. Another consequence of φ geo K being a polynomial of a degree the user can choose, is the possibility to define isoparametric (or subparametric or surparametric) finite elements, see [START_REF] Pena | Spectral Element Approximation of the incompressible Navier-Stokes equations evolving in a moving domain and applications[END_REF][START_REF] Pena | High order methods for the approximation of the incompressible navier-stokes equations in a moving domain[END_REF]. Lets denote k geo the polynomial order of the Lagrange basis in which φ geo K is expanded. If there is no ambiguity, we keep the notation φ geo K , otherwise we use the notation φ geo K,k geo . The class that implements the definition and evaluation of the geometrical transformation also provides a function to evaluate its gradient, automatic consequence of φ geo K being an element belonging to a polynomial set. Another important transformation associated with φ geo K is its inverse, (φ geo K ) -1 . In the case of an affine transformation, the inverse is calculated explicitely. However, if φ geo K is nonlinear, the evaluation/differentiation of (φ geo K ) -1 at a set of points is performed with the help of a nonlinear solver (we have used the nonlinear solver available in PETSc for these calculations, see section 3.2). The inverse transformation plays an essential role in providing an interpolation tool, all the advanced numerical methods presented in [START_REF] Prud'homme | Feel++: A computational framework for galerkin methods and advanced numerical methods[END_REF] use this tool and hence the inverse geometrical transformation.

Meshes, Function Spaces and Operators

In the previous section, we have described roughly the monodomain construction of polynomials. Now we turn to the ingredients for the multidomain construction and we start with the mesh mathematical description and associated data structures. Note that all these data structures presented are parallel (MPI) and work seamlessly in sequential and parallel computational environments.

Mesh Data Structures

Let Ω ⊂ R d , d ≥ 1, denote a bounded connected domain. We first need to introduce a suitable discretization of Ω, Ω h ⊂ Ω. Note that if Ω is a polyhedral domain then Ω h = Ω. We denote by T h a finite collection of nonempty, disjoint open simplices or hypercubes T h = {K = φ geo K ( K)} forming a partition of Ω h such that h = max K∈T h h K , with h K denoting the diameter of the element K ∈ T h . We say that a hyperplanar closed subset F of Ω is a mesh face if it has positive (d-1)-dimensional measure and if either there exist

K 1 , K 2 ∈ T h such that F = ∂ K 1 ∩ ∂ K 2 (and F is called an internal face) or there exists K ∈ T h such that F = ∂ K ∩ ∂ Ω h (
: =F i h ∪ F b h . For all F ∈ F h , we define T F : ={K ∈ T h | F ⊂ ∂ K}.
For every interface F ∈ F i h we introduce two associated normals to the elements in T F and we have n

K 1 ,F = -n K 2 ,F , where n K i ,F , i ∈ {1, 2}, denotes the unit normal to F pointing out of K i ∈ T F . On a boundary face F ∈ F b h , n F = n K,F
denotes the unit normal pointing out of Ω h . We also introduce (i) the set of boundary elements

T b h = {K ∈ T h | ∂ K ∩∂ Ω = / 0}, (ii) the set of internal elements T i h = T h \T b h , (
iii) the set N h which collects the nodes of the mesh, (iv) when d = 3, E h which collects the edges of the mesh.

The collections T h , F h , E h , N h , as well as the internal and boundary collections, are provided by our mesh data structure and stored using the the Boost.Multi_index library 2 . The mesh entities (elements, faces, edges, nodes) are indexed either by their ids, the process id (i.e. the id given by MPI in a parallel context, by default the current process id) to which they belong, their markers (material properties, boundary ids. . . ) or their location (whether the entity is internal or lies on the boundary of the domain). Other indices could certainly be defined, however those previous four already allow a wide range of applications. Thanks to Boost.Multi_index, it is trivial to retrieve pairs of iterators over the entity's containers depending on the usage context. The pairs of iterators are then turned into a range, see Boost.Range3 , to be manipulated by the integration, see section 4.1, and projection, see section 4.2, tools. In C ++ the mesh data structure is defined through the type of geometrical entities (simplex or hypercube) and the geometrical transformation associated, see the listing below.

// T h is a collection of simplices s.t. φ geo K,k geo : K ⊂ R p -→ K ⊂ R d
Mesh<Simplex<p, k geo , d> > mesh; // same as above except that we deal with a set of hypercubes Mesh<Hypercube<p, k geo , d> > mesh;

FEEL++ uses GMSH, see [START_REF] Geuzaine | Gmsh: a three-dimensional finite element mesh generator with built-in pre-and post-processing facilities[END_REF], to generate meshes in all 3 dimensions with 1 k geo 5 for d = 2 and 1 k geo 4 for d = 3. The listing below and the resulting Figure 1 for k geo = 1, 2, 3, 4 illustrate the flexibility of FEEL++ regarding mesh handling.

typedef Mesh<Simplex<3,k geo ,3> > mesh_type; // generate the mesh of the sphere using Gmsh auto mesh = createGMshMesh( _mesh=new mesh_type, _desc=domain(_shape="ellipsoid",_dim=3)); // generate a functionspace, see next section FunctionSpace<mesh_type,bases<Lagrange<k geo > > > Xh_type; auto Xh = Xh_type::New( mesh ); // build the Lagrange interpolant u of degree k geo of cos(5x) sin(5y) auto u = project( _space=Xh, _range=elements(mesh), _expr=cos(5x) sin(5y) ); // export function to gmsh the mesh and u for high order visualisation // gmsh requires that we use isoparametric elements exporter( _format=gmsh, _mesh=mesh, _name="ho_sphere" ).add( _data=u, _name="u" );

Finally the mesh data structure of topological dimension d allows to easily extract submeshes of topological dimension d and d -1. For example, the methods exposed in section ?? use the extraction of trace meshes as follows:

// Trace mesh composed of all boundary faces from 'mesh' auto trace_mesh = mesh->trace(boundaryfaces(mesh)); // mesh of faces marked Gamma in 'mesh' auto Gamma_mesh = mesh->trace(markedfaces(mesh,"Gamma"));

Algebraic representations

Algebraic representations are handled using a so-called backend which is a wrapper class that encapsulates several linear, nonlinear and eigenvalue algorithms as well as data structures like vectors and matrices. It provides all the algebraic data structure behind function spaces, operators and forms (see the following sections). In the case of linear functionals (also called linear forms or 1-forms), the representation is a vector and, in the case of linear operators and bilinear forms, the representation is a matrix.

The backend abstraction allows to write code that is independent of the libraries used in the assembly process or to solve the linear systems involved, thus hiding all the details of that algebraic part under the hood of the backend. Once a backend is set, the user can create in a transparent way vectors and matrices to be used during the assembly process, as is it shown is the following listing.

// allocates a sparse matrix based on the degrees of freedom of the // trial functions space X h and the test functions space V h auto A = backend->newMatrix( _trial=Xh, _test=Vh ); // allocates a vector based on the degrees of freedom of the // test functions space V h auto b = backend->newVector( _test=Vh );

There are two available backends that provide an interface to PETSc/SLEPc, see [START_REF] Balay | PETSc users manual[END_REF][START_REF] Balay | PETSc Web page[END_REF][START_REF] Balay | Efficient management of parallelism in object oriented numerical software libraries[END_REF][START_REF] Hernandez | SLEPc: A scalable and flexible toolkit for the solution of eigenvalue problems[END_REF], and Trilinos, see [START_REF] Heroux | An Overview of Trilinos[END_REF][START_REF] Michael | An overview of the trilinos project[END_REF][START_REF] Heroux | Trilinos Users Guide[END_REF][START_REF] Michael | Trilinos Developers Guide[END_REF]. The user can choose any of them, bearing in mind the tools and features available in each, such as parallelism, direct or iterative linear system solvers or preconditioners for these systems. Once a backend is defined, say Backend<Trilinos>, the user is free to manipulate objects such as vectors and matrices (from the Epetra class, in this case), using most of the algebraic operations attainable from the original library. The backend also provides interfaces to linear system solvers (direct or iterative, with or without a preconditioner). The syntax for this function is illustrated in the next listing. Similar interfaces exist for non-linear and standard/generalized eigenvalue solvers.

// solve the linear system Au = F backend -> solve( _matrix=A , _solution=u , _rhs=F );

Function Spaces and Functions

We now turn to the next crucial mathematical ingredient: the function space, whose definition depends on Ω h -or more precisely its partitioning T h -and the choice of basis function. Function spaces in FEEL++ follow the same definition, see listing 1, and FEEL++ provides support for continuous and discontinuous Galerkin methods and in particular approximations in L 2 , H 1 -conforming and H 1 -nonconforming, H 2 , H(div) and H(curl) 4 .

Listing 1: FunctionSpace // space of continuous piecewise // P 3 functions defined on a mesh // of order 2 triangles in 3D FunctionSpace<Mesh<Simplex<2,2,3>, bases<Lagrange<3> > > Xh;

The FunctionSpace class (i) constructs the table of degrees of freedom which maps local (elementwise) degrees of freedom to the global ones with respect to the geometrical entities, (ii) embeds the definition of the elements of the function space allowing for a tight coupling between the elements and their function spaces, (iii) stores an interpolation data structure (e.g. region tree) for rapid localisation of point sets (determining in which element they reside).

We introduce the following spaces

W h = {v h ∈ L 2 (Ω h ) : ∀K ∈ T h , v h | K ∈ P K }, V h = W h ∩C 0 (Ω h ) = {v h ∈ W h : ∀F ∈ F i h v h F = 0} H h = W h ∩C 1 (Ω h ) = {v h ∈ W h : ∀F ∈ F i h v h F = ∇v h F = 0} CR h = {v h ∈ L 2 (Ω h ) : ∀K ∈ T h , v h | K ∈ P 1 ; ∀F ∈ F i h F v h = 0} R T h = {v h ∈ L 2 (Ω h ) : ∀K ∈ T h , v h | K ∈ span 1, x, y, x 2 -y 2 ; ∀F ∈ F i h F v h = 0} RT h = {v h ∈ [L 2 (Ω h )] d : ∀K ∈ T h , v h | K ∈ RT k ; ∀F ∈ F i h v h • n F = 0} N h = {v h ∈ [L 2 (Ω h )] d : ∀K ∈ T h , v h | K ∈ N k ; ∀F ∈ F i h v h × n F = 0} (1)
where RT k and N k are respectively the Raviart-Thomas and Nédélec finite elements of degree k. The table 2 summarizes the supported approximation spaces. The Legrendre and Dubiner basis yield implicitely discontinuous approximations, the Legendre and Dubiner boundary adapted basis, see [START_REF] George | Spectral/hp element methods for CFD[END_REF], were designed to handle continuous approximations whereas the Lagrange basis can yield either discontinuous or continuous (default The most important feature in FunctionSpace is that it embeds the definition of element which allows for the strict definition of an Element of a FunctionSpace and thus ensures the correctness of the code. An element has its representation as a vector -also in the case of product of multiple spaces. -The vector representation is parametrized by one of the linear algebra backends presented in section 3.2. Other supported operations are interpolation and extraction of components -be it a product of function spaces element or a vectorial/matricial element, -see listing 3.3.

FunctionSpace<Mesh<Simplex<2> >, bases<Lagrange<3,Scalar, Continuous> > > P3ch; // get an element from P3ch auto u = P3ch.element(); FunctionSpace<Mesh<Simplex<2> >, bases<Lagrange<2,Vectorial>, Lagrange<1,Scalar>, Lagrange<1,Scalar> > > P2P1P1; auto U = P2P1P1.element(); // Views: changing a view changes U and vice versa // view on element associated to P2 auto u = U.element<0>(); // extract view of first component auto ux = u.comp(X); // view on element associated to 1st P1 auto p = U.element<1>(); // view on element associated to 2nd P1 auto q = U.element<2>();

Finally FEEL++ provides the Lagrange,

I LAG c,h , I LAG d,h , Crouzeix-Raviart, I CR h , Raviart- Thomas, I RT h
and Nédélec, I N h global interpolation operators. In abstract form, they read

I : X v → dim X ∑ i=1 i (v)φ i (2)
where X is the infinite dimensional space, ( i ) i=1,...,dim X are the linear forms and (φ i ) i=1... dim X the basis function associated with the various approximations in table 2.

Functionals, Operators and Forms

We now introduce the necessary functional vocabulary, namely (i) functionals, : X → R, (ii) operators, A : X → Y and (iii) bilinear forms, a : X × Y → R. Note that for a bilinear form a : X × Y → R there exists a unique operator A : X → Y s.t. a(x, y) = A x, y where • , • denotes the duality product. The C ++ counterpart of these mathematical objects follows closely their mathematical analog: they are template classes with arguments being the space (or product of spaces) they take as input and provide an interface to apply them on elements of the domain space. For operators, we can also apply their inverse to the elements of the image space. In the linear case, we provide also an algebraic representation : a vector for linear functionals or forms and a matrix for linear operators and bilinear forms -matrix-and vector-free representations are possible too. -The listing below excercises auto X h = X h _type::New(mesh); V h = V h _type::New(mesh);

auto u = X h ->element(); auto v = V h ->element(); // operator T : X h → V h auto T = opLinear( _domainSpace=X h , _imageSpace=dual(V h )
[,_backend=backend] ); // definition of T, see eg section 4 T = integrate(_range=elements(mesh),_expr=gradt(u) * trans(grad(v))); // linear functional f : V h → R // f is a linear form auto f = T.apply( u ); f.apply( v ); //or equivalently auto f = funLinear( _domainSpace=V h [, _backend=backend] ); f = T.apply(u); f.apply( v ) ; // a is a bilinear form, auto A=backend->newMatrix( _test=X h , _trial=X h ); auto a = form2( _test=X h , _trial=X h , _matrix=A ); // definition of a, see e.g. section 4 a = integrate(_range=elements(mesh),_expr=idt(u) * id(v)); // b is a linear form, auto B=backend->newVector( _test=X h ); auto b = form1( _test=X h , _vector=B ); // definition of b, see e.g. section 4 b = integrate(_range=elements(mesh),_expr=id(v)); FEEL++ implements currently the following operators (i) interpolation operator, (ii) the lift and trace operators, and (iii) the projection operators (L 2 , H 1 , H(div), H(curl),...). We describe briefly the interpolation operator which is used later in this text. Note that the lift and trace operators are used also in some examples in section ??.

The interpolation operator, I : X -→ Y where Y is a nodal basis and I (v), v ∈ X is the interpolant of v ∈ Y , defined in the previous section. It is based on two fundamental tools: a localisation tool using a kd-tree data structure for fast localisation and the inverse geometrical transformation. This is a crucial tool for all advanced numerical methods presented later in this paper in [START_REF] Prud'homme | Feel++: A computational framework for galerkin methods and advanced numerical methods[END_REF].

Listing 2: Interpolation operator auto X h = X h _type::New(mesh); V h = V h _type::New(mesh); auto u = X h ->element(); auto v = V h ->element(); // operator I : X h → V h auto I = opInterpolation( _domainSpace=X h , _imageSpace=V h [,_backend=backend] ); // compute v the interpolant of u in V h v = I(u);

A Variational Formulation Language Embedded in C ++

The language has a variety of keywords -see appendix in [START_REF] Prud'homme | Feel++: A computational framework for galerkin methods and advanced numerical methods[END_REF] for an exhaustive listthat implement (i) access to geometrical data structure, e.g. exterior normal to the face of an element, (ii) standard mathematical functions and logical relations, (iii) operations related with the function spaces, such as element evaluation or differentiation, (iv) numerical integration. These keywords, with the help of algebraic operations such as sum, multiplication, division, etc, allow to build expressions which are used to define mathematical expressions then used by various objects such as forms or operators. Some keywords show a common pattern in their nomenclature: for instance, the basic expressions id(p), grad(p), jump(p) or div(p) represent the evaluation, gradient, jump across a face or divergence of a test function, while the addition of t at the end of such expressions (idt(p), gradt(p), jumpt(p) or divt(p)) represents the same operators, but now concerning trial functions. Therefore, if p and q belong to the same functionspace, the construction of a bilinear form associated with the expression idt(p) * id(q) will result in the assembly of the associated mass matrix. However, adding a v at the end of the keywords, allows to perform evaluation of the operator applied to the argument, ie, idv(p), gradv(p), jumpv(p) or divv(p) evaluate respectively the gradient of p, the jump of p across faces or the divergence of p.

FEEL++ supports scalar, vectorial and matricial operations in expressions. Indeed the C ++ operators follow the same rank semantics of their mathematical counterparts, see appendix in [START_REF] Prud'homme | Feel++: A computational framework for galerkin methods and advanced numerical methods[END_REF]. Listing 3 displays a C ++ code solving the linear elasticity equations, notice how the vectorial notations make it easy to express the variational formulation.

Often it is the case that we must integrate function space elements or basis functions (trial or test functions) that are defined on a mesh which is different from the integration mesh, see e.g. the mortar method or the Fat Boundary Method in [START_REF] Prud'homme | Feel++: A computational framework for galerkin methods and advanced numerical methods[END_REF]. Such a case is detected automatically and the interpolation procedure is called in the background of the integration or projection processes automatically to handle the necessary information transfer. All possible cases are actually handled by FEEL++.

Finally the variational language, integration and projection are parallel. There are still some complex operations that are not supported in parallel like handling fictitious domain methods such as the FBM, see [START_REF] Prud'homme | Feel++: A computational framework for galerkin methods and advanced numerical methods[END_REF]. Most standard methods are supported and already some complex FEEL++ applications are done in parallel such as Fluid Structure Interaction, see [START_REF] Chabannes | High order fluid structure interaction in 2D and 3D: Application to blood flow in arteries[END_REF].

Integration

Integration is of course a fundamental tool in FEEL++. It is handled through the keyword integrate and is used to define forms, functionals and operators or just to compute integrals. It provides an extremely flexible and versatile interface in all these contexts: integrate( _range=<mesh range iterators>, // integration domain // integrand _expr=<expression to integrate>, // quadrature _quad=_Q<polynomial order to integrate exactly>(), ... // other parameters are available but not necessary here);

The parameters _range (domain of integration) and _expr (integrand) are required while _quad is optional. Indeed, by default, the DSEL computes an approximation of the polynomial order of the integrand and selects the quadrature that integrates it exactely (if the integrand is polynomial then the integration is exact). If this is not statisfactory then the user selects his own quadrature. Multiple integrate keywords can be accumulated using the + operator and returns an object which is handled automatically by forms, functionals and operators. There are two particular flavors: (i) integral evaluation which requires to use the evaluate() member function of the object returned by integrate() (ii) elementwise integral evaluation which requires to use of the broken(<space>) member function to return an element of <space> (typically a space of piecewise constant functions) containing the resulting integral computations.

trans(idv(force)) * id(v) ); auto deft = sym(gradt(u)); auto def = sym(grad(u)); auto lambda=..., mu=....; // Lame coefficients auto D = backend->newMatrix( Xh, Xh ); form2( _test=Xh, _trial=Xh, _matrix=D ) = integrate( elements(mesh), lambda * divt(u) * div(v) + 2 * mu * trace(trans(deft) * def))+ on( markedfaces(mesh,"clamped"), u, F, 0 * one()); // solve backend->solve( _matrix=D, _solution=u, _rhs=F ); // apply displacement to the mesh movemesh( mesh, u );

Mesh adaptation

Since FEEL++ applications become more and more complex, mesh adaptation becomes crucial to control solution accuracy keeping a suitable computational cost. An elegant way is to use the notion of metric, by generating a mesh where the edges have unit length with respect to associated Riemannian metric space.

Metric-based mesh adaptation

Let's denote v i and λ i the eigenvectors and the eigenvalues of the metric tensor describing size and directional constraints of the adapted mesh. The generation of the unit mesh consists in applying the size h i = 1 √ λ i on each direction v i -anisotropic meshing -, or to use the

smallest h i = 1 √ max(λ i )
on all directions -isotropic meshing -.

User can (i) use the metric built from his own function, (ii) use the metric built from the Hessian of the solution, as described in [START_REF] Loseille | Continuous mesh framework, part 1 : well-posed continuous interpolation error[END_REF].

Mesh adaptation tool in Feel++

FEEL++ uses GMSH mesh adaptation possibilities, via GMSH API to avoid system calls and consequently enhance the efficiency. Metrics are stored in post processing files (.pos format), which allow GMSH to generate a background defining the associated constraints to apply on the new mesh. The member function adaptMesh of MeshAdaptation provides an interface allowing to easily build adapted mesh :

MeshAdaptation< <dim>,<approx order>,<geo order> > adaptation(<backend>); adaptation.adaptMesh(_initMesh=<inital mesh> _geofile=<path of geometry file (.geo)> _adaptType=<"isotropic" / "anisotropic"> _var=<list of variables used to adapt mesh> _metric=<list of metric used to adapt mesh>, ...); _var and _metric are optional parameters, containing list of pairs (element_type, "name"). User has to set either _var to use metric built from Hessian of corresponding element_type, or _metric to use it directly as the metric tensor. When several metrics are specified, GMSH uses metric intersection algorithm, taking minimum size on each node.

The following example shows the resolution of -∆u = 1 with homogeneous Dirichlet conditions on a L-shape geometry (2D/3D) with mesh adapted from solution : In this paper, we presented a versatile framework that allows to solve numerically a wide range of problems arising from PDE with an expressivity close to the mathematics. There remain however many challenges to overcome for example (i) automatic differentiation of variational forms, (ii) integration of multiscale methods, (iii) a full framework for domain decomposition including a preconditioner framework and some preconditioners implementation, (iv) the implementation of finite volume variational methods, see [START_REF] Antonio | A domainspecific embedded language in C++ for lowest-order discretizations of diffusive problems on general meshes[END_REF], (v) or integration model order reduction (e.g. certified reduced basis) into our framework. These are just a few of the challenges we are facing and for some of them we have made already good inroads. So far the framework has very nicely scaled with complexity -in terms of physical models, numerical methods or discretisation, solver and computer science -and retained very good properties of maintainability, code size and reproductibility.

Figure 1 :

 1 Figure 1: Sphere discretized with 31 elements. Visualization of a function in Gmsh using tetrahedral elements of order N = 1, 2, 3, 4.

Figure 2 :

 2 Figure 2: Mesh adaptation on 2D/3D L-shape

  and F is called a boundary face). Internal faces are collected in the set F i h , boundary faces in F b h and we let F h

Table 1 :

 1 Table1summarizes some of the available ranges in the library. Some mesh range iterators

	Range iterators	Description
	elements(<mesh>)	range iterator over T h
	faces(<mesh>)	range iterator over F h
	edges(<mesh>)	range iterator over E h
	points(<mesh>)	range iterator over N h
	markedelements(<mesh>,	element range iterator over T h marked by marker
	<marker (id|string)>)
	markedfaces(<mesh>,	face range iterator over T h marked by marker
	<marker (id|string)>)
	boundaryelements(<mesh>) element range iterator over T b h internalelements(<mesh>) element range iterator over T i h boundaryfaces(<mesh>) face range iterator over F b h internalfaces(<mesh>) face range iterator over F i h

Table 2 :

 2 FEEL++ approximations spaces behavior) approximations. RT h and N h are implicitely spaces of vectorial functions f s.t.f : Ω h ⊂ R d → R d .As to the other basis functions, i.e. Lagrange, Legrendre, Dubiner, etc., they are parametrized by their values namely Scalar, Vectorial or Matricial. Note that FunctionSpace handles also products of function spaces. This is very powerful to describe complex multiphysics problems when coupled with operators, functionals and forms described in the next section. Extracting subspaces or component spaces are part of the interface.

	Continuous Solution Discrete Approximation Basis	Order Dimension
			Lagrange
	L 2	W h	Legendre	any	1,2,3
			Dubiner
			Lagrange
	H 1 -conforming	V h	Legendre boundary adapted	any	1,2,3
			Dubiner boundary adapted
	H 1 -nonconforming	CR h R T h	Crouzeix-Raviart Rannacher-Turek	1 2	2,3 2
	H(div)-conforming RT h	Raviart-Thomas	any	2,3
	H(curl)-conforming N h	Nédélec first kind	any	2,3
	H 2 -conforming	H h	Hermite	2	1,2,3
	// continuous piecewise P3
	// approximations
	FunctionSpace<Mesh<Simplex<2> >,
	bases<Lagrange<3,Scalar,
		Continuous> > > P3ch;
	// discontinuous piecewise P3
	// approximations
	FunctionSpace<Mesh<Simplex<2> >,
	bases<Lagrange<3,Scalar,
		Discontinuous> > > P3dh;
	// mixed (P2 vectorial, P1 scalar,
	// P1 Scalar) approximation
	FunctionSpace<Mesh<Simplex<2»,
	bases<Lagrange<2,Vectorial>,
	Lagrange<1,Scalar>,
	Lagrange<1,Scalar»> P2P1P1;

http://www.boost.org/doc/libs/1_50_0/libs/parameter/doc/html/index.html

http://www.boost.org/libs/multi_index/doc/index.html

http://www.boost.org/libs/range/index.html

At the time of writing, H 2 , H(div) and H(curl) approximations are in experimental support.

typedef FunctionSpace<Mesh<Simplex<3>, bases<Lagrange<0,Scalar,Discontinuous> > > P0h_type; auto P0h = P0h_type::New( mesh ) // evaluate Ω h sin x = ∑ K∈T h K sin x auto v = integrate( _range=elements(mesh),

Acknowledgements. The authors wish to thank D. Di Pietro and J.-M. Gratien from IFPEN as well as S. Bertoluzza from Imati/CNR/Pavia for very fruitful discussions. Mourad Ismail and Vincent Doyeux acknowledge the financial support from ANR MOSICOB. Vincent Chabannes and Christophe Prud'homme acknowledge the financial support of the Région Rhône-Alpes through the project ISLE/CHPID. Abdoulaye Samake and Christophe Prud'homme acknowledge the financial support of the project ANR HAMM. Gonçalo Pena ackowledges the financial support of the Calouste Gulbenkian Foundation through the project Estímulo à Investigação.

_expr=sin( Px()) ).evaluate(); // store for all K ∈ T h , K sin x in p0[ι K ] where ι K is the // index of element K auto p0 = integrate( _range=elements(mesh), _expr=sin( Px()) ).broken( P0h ); for( auto ι K : mesh.elements() ) { // print the element wise integrals std::cout << "p0["<< ι K << "]=" << p[ι K ] << "\n"; } Note that there is a special keyword in the context of bilinear forms and linear operators used conjointly with integrate, it is on which allows to eliminate Dirichlet "degrees of freedom".

Projection

Another important keyword is project which allows to compute the interpolant of an expression with respect to a nodal function space over a part of the mesh or the whole mesh. The interface is as follows project( _space=<nodal function space in which the interpolant lives> _range=<domain range iterators>, _expr=<expression to be interpolated>, .... )

Here are some examples typedef FunctionSpace<Mesh<Simplex<d>, bases<Lagrange<1,Vectorial> > > Xhv_type; auto Xhv = Xhv_type::New( mesh ); // build a piecewise P 1 vectorial function in Xhv containing the // coordinates of the vertices the mesh. auto coord = project( _space=Xhv, _range=elements(mesh), _expr=P() ); // compute the x derivative of the coord function auto dx_coord = project( _space=Xhv, _range=elements(mesh), _expr=dxv(coord) ); auto dy_coord = project( _space=Xhv, _range=elements(mesh), _expr=dyv(coord) );

A wrap up example

To finish, we present an example in linear elasticity which is dimension independent and takes only few lines of code to express.

Listing 3: Solving a linear elasticity problem on a campled beam

FunctionSpace<mesh_type,bases<Lagrange<1,Vectorial»> space_type; auto Xh = space_type::New(mesh); auto u = Xh->element(); v = Xh->element(); // strain tensor 0.5 * (∇u + ∇u T ) auto F = backend->newVector( Xh ); auto force=project( _space=Xh, _range=markedface(mesh,"forceZ"), _expr=vec(0,0,-1) ); form1( _test=Xh, _vector=F ) = integrate( markedfaces(mesh,"ForceZ"),


Vincent Chabannes
email: vincent.chabannes@imag.fr

Cécile Daversin

Christophe Prud'homme
email: christophe.prudhomme@ujf-grenoble.fr

Abdoulaye Samake
email: abdoulaye.samake@imag.fr

Christophe Trophime

Stéphane Veys
email: stephane.veys@imag.fr

A computational framework for certified reduced basis methods: applications to multiphysics problems

Keywords: certified reduced basis methods, automated computational framework, reduced order modeling in multiphysics applications

Over the last few years we have been developing an open-source computational framework for certified reduced basis methods [START_REF] Vallaghé | A computational framework for certified reduced basis methods, applications to uncertainty quantification in heattransfer and biology[END_REF] based on the Feel++ framework [START_REF] Prud'homme | Feel++, A Computational Framework for Galerkin Methods and Advanced Numerical Methods[END_REF]. The latter provides (i) a very wide range of arbitrary order Galerkin methods (fem, sem, cG, dG) in 1D, 2D and 3D (ii) an interface to modern linear algebra framework PETSc/SLEPc and Trilinos and (iii) a language embedded in C++ for Galerkin methods with a syntax following closely the mathematical one. Our recent advances in the former allow to (i) treat a wide range of problems as exercised later, (ii) provide an (almost) automated framework including the use of reduced basis element methods [START_REF] Maday | Ronquist The Reduced Basis Element Method: Application to a Thermal Fin Problem[END_REF][START_REF] Huynh | A Static Condensation Reduced Basis Element Method: Approximation and A Posteriori Error Estimation[END_REF], hp reduced basis approximations, empirical interpolation method, the successive contraints methods, a posteriori error estimation for linear and non-linear parametrized partial differential equations.

The exposition is organized as follows, first we present the advances in our framework for certified reduced basis methods since [START_REF] Vallaghé | A computational framework for certified reduced basis methods, applications to uncertainty quantification in heattransfer and biology[END_REF], in particular in two areas (i) automation of the reduced basis method using a domain specific language [START_REF] Prud'homme | Feel++, A Computational Framework for Galerkin Methods and Advanced Numerical Methods[END_REF] and (ii) coupling of the reduced basis methods coupled with domain decomposition methods or multiscale methods. Then we apply our framework to two large multi-physics applications (i) high field magnet design (ii) aerothermal modeling in an airplane cabin. Note that the objective is to identify the bottlenecks in the methodology to be applied to industrial problems. Full results may not be expected but we shall report the scaling issues encountered as well as the intermediary results.

Regarding the first application, the Laboratoire National des Champs Magnétiques Intenses (LNCMI) is a French large scale facility enabling researchers to perform experiments in the highest possible magnetic field (up to 35 T static field). High magnetic fields are obtained by using water cooled resistive magnets (cf. fig. 1) connected with a 24 MW power supply [START_REF] Trophime | Magnet calculations at the GHMFL[END_REF]. As to the second application, its purpose is to build reduced order models aimed at replacing some 0D models in the energy control system of an airplane, see fig. 2. The design, optimization or control of these magnets or the energy control system require from an engineering point of view solutions of a multi-physics model involving combination of electro-thermal, magnetostatics, electro-thermal-mechanical and thermo-hydraulics models. It should be noted that these models are non-linear. In practice the parametric and physical spaces induce huge computational costs.

Figure 1 :

 1 Figure 1: A high field magnet: (left) exploded view; (center) detailled view of the inner part; (right) temperature of the inner part with a zoom on a "turn".

Figure 2 :

 2 Figure 2: Energy control system in an airplane

Acknowledgements

The authors thank M. Fouquembergh from EADS-IW for supplying the second application.


Yves Mahéo

Nicolas Le Sommer

Pascale Launay

Frédéric Guidec

Mario Dragone

Nicolas Le Sommer

Beyond Opportunistic Networking Protocols: a Disruption-Tolerant Application Suite for Disconnected MANETs

Keywords: C.2.1 [Computer-Communication Networks]: Network Architecture and Design-Store and forward networks Design, Experimentation delay/disruption-tolerant networking, opportunistic computing

HAL is

INTRODUCTION

In a mobile ad hoc network (MANET), mobile hosts can communicate directly with one another using direct pair-wise wireless links. Because it requires no fixed infrastructure -and most of the time no explicit administration-a MANET can prove extremely useful to support communication in challenging situations, such as in rural, remote, or disaster-struck areas.

In the literature MANETs are often assumed to be fully connected networks: messages can thus be forwarded at any time from host to host in the network, using one of the many dynamic routing protocols that have been developed specifically for that purpose during the last two decades [START_REF] Liu | A Survey of Mobile Ad Hoc network Routing Protocols[END_REF]. Unfortunately the assumption that a MANET is necessarily a connected network is somewhat contrived: many real MANETs are, at best, only partially or intermittently connected. A MANET can for example become disconnected when the mobile hosts that compose this network are sparsely or irregularly distributed. The whole network then appears as a collection of distinct, continuously changing "islands" -or connected componentsrather than as a single, connected network. In such conditions the mobility of hosts can be considered as an advantage, as it makes it possible to bridge the gap between non-connected parts of the network, using mobile hosts as carriers -or data mules-that can carry messages over long distances. A message can thus be stored temporarily on a host while this host is moving in the network, and be forwarded later to another host when circumstances permit. This "store, carry, and forward" approach fits in the general category of disruption-tolerant -or delay-tolerant-networking (DTN [START_REF] Fall | A Delay-Tolerant Network Architecture for Challenged Internets[END_REF]): connectivity disruptions are indeed tolerated thanks to the mobility of hosts, but this approach generally yields long transmission delays because transporting a message from source to destination can take a long time when one or several data mules are involved during the transport. The term opportunistic networking has been proposed in [START_REF] Pelusi | Opportunistic Networking: Data Forwarding in Disconnected Mobile Ad Hoc Networks[END_REF] to denote delay/disruption-tolerant networking when radio contacts between mobile hosts are not planned in advance and must thus be exploited opportunistically. This is typically the case in many kinds of disconnected MANETs (or D-MANETs), where the mobility pattern of each host is actually that of its physical carrier. If the physical carriers are for example human beings carrying laptops or smartphones, then radio contacts cannot always be predicted, although each contact is still an opportunity for two hosts to exchange messages.

Many papers published in the last few years address the problem of supporting communication in D-MANETs (good surveys can notably be found in [START_REF] Pelusi | Opportunistic Networking: Data Forwarding in Disconnected Mobile Ad Hoc Networks[END_REF] and [START_REF] Zhang | Routing in Intermittently Connected Mobile Ad Hoc Networks and Delay Tolerant Networks: Overview and Challenges[END_REF]). An overwhelming majority of the protocols described in these papers have been implemented and evaluated only in network simulators. Of course network simulators can prove very useful. They make it possible to play the same scenario many times, which is quite convenient when several protocols must be compared in similar conditions. They also make it possible to verify the scalability of a protocol, while conducting experiments with hundreds or thousands of mobile devices could be a tedious -and expensive-task. Yet it is our conviction that protocols must also be implemented and tested for real, so as to avoid some simplifications and not to neglect some constraints that would render these protocols ineffective in real conditions.

For example, due to the limitations of some simulators, many authors run simulations in which battery-powered handheld devices such as laptops, netbooks, or smartphones are assumed to be always on, and therefore always available to exchange messages with any other neighbor device. In real life, though, experience shows that users generally prefer to preserve the battery of their devices, which are thus switched off -or put in suspend mode-most of the time, and are only switched on for short durations. Simulation scenarios in which battery-powered handheld devices are assumed to be always on are thus overly optimistic.

Another typical example is that simulators are often used to evaluate how messages can propagate in a D-MANET, but not how distributed applications could perform in such a network. Yet since a D-MANET is a network in which transmission delays can be very long and where transmissions can even fail altogether, legacy applications (most of which are TCP-based) could not run in such conditions. Indeed, designing and implementing distributed applications capable of running in a D-MANET is quite a challenge. The peer-to-peer model should obviously be preferred over the clientserver model, because as a general rule no host can be considered as stable and accessible enough to play the role of a server for all other hosts. Additionally, any distributed application running in a D-MANET must obviously be able to tolerate long transmission delays, and occasional transmission failures as well. Legacy applications must therefore be re-examined based on these premises, and new applications have to be designed accordingly.

In the remainder of this paper we present a suite of applications we designed along that line, together with lessons learned from the first experimentation campaign we conducted in order to evaluate how these applications can perform -and be accepted by usersin real-life conditions. Our application suite relies on a communication middleware system we designed and implemented. This communication system is only described briefly in Section 2, but interested readers can find details in [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF]. In Section 3 we present the applications we proposed to users during the experimentation campaign. This campaign is described in Section 4, together with some of the results obtained on that occasion. In Section 6, which concludes this paper, we describe our plans for future work.

OVERVIEW OF DODWAN

Building an application suite for D-MANETs requires some communication middleware system with which mobile hosts can collaborate in a peer-to-peer manner to ensure message transportation. DoDWAN (Document Dissemination in mobile Wireless Ad hoc Networks) is a communication middleware system we designed along this line. DoDWAN, whose general architecture is presented in Figure 1, is distributed under the terms of the GNU General Public License 1 .

DoDWAN has been designed so as to be configurable, extensible and customizable. Thanks to the available documentation, API and tutorial, one can easily develop new DoDWAN-based applications and deploy them on different types of devices such as laptops or Android smartphones. DoDWAN has originally been implemented ). Yet it has also been experimented in a military tactical network, using VHF battlefield radios with builtin modems instead of Wi-Fi interfaces, and proved very robust and reliable in such harsh conditions [START_REF] Haillot | Disruption-Tolerant Content-Driven Information Dissemination in Partially Connected Military Tactical Radio Networks[END_REF]. Additionally, DoDWAN is provided with a set of tools that are useful for trials, such as a communication logger, a neighborhood logger, an administration console, etc. DoDWAN supports content-based information dissemination in D-MANETs. This is a characteristic it shares with the Haggle system, while the DTN2 system is rather meant to support destinationdriven message forwarding.

In content-based networking, information flows towards interested receivers rather than towards specifically set destinations. This approach notably fits the needs of applications and services dedicated to information sharing or event distribution. It can also be used for destination-driven message forwarding, though, considering that destination-driven forwarding is simply a particular case of content-driven forwarding where the only significant parameter for message processing is the identifier of the destination host (or user).

DoDWAN implements a selective version of the epidemic routing model proposed in [START_REF] Vahdat | Epidemic Routing for Partially Connected Ad Hoc Networks[END_REF]. It provides application services with a publish/subscribe API. When a message is published on a host, it is simply put in the local cache maintained on this host. Afterwards each radio contact with another host is an opportunity for the DoDWAN system to transfer a copy of the message to that host.

In order to receive messages an application service must subscribe with DoDWAN and provide a selection pattern that characterizes the kind of messages it would like to receive. The selection patterns specified by all local application services running on the same host define this host's interest profile. DoDWAN uses this profile to determine which messages should be exchanged whenever a radio contact is established between two hosts.

Our approach while developing DoDWAN has been quite pragmatic: rather than designing a clever and complicated protocol that can only run efficiently in very specific conditions, we deliberately designed a quite simple protocol that performs satisfactorily in most situations. As a general rule, a mobile host that defines a specific interest profile is expected to serve as a mobile carrier for all messages that match this profile. Yet a host can also be configured so as to serve as an altruistic carrier for messages that present no interest to the application services it runs locally. This behavior is optional, though, and it must be enabled explicitly by setting DoDWAN's configuration parameters accordingly. Details about this interaction scheme and about how it performs in real conditions can be found in [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF].

Mobile hosts running DoDWAN only interact by exchanging

APPLICATION SUITE

A suite of applications suitable for disconnected MANETs has been developed on top of the DoDWAN middleware system. Some of these applications are strongly inspired from legacy Internet communication services: electronic messaging, discussion service, and instant messaging. Since such services rely on the client/server paradigm, each host running DoDWAN must also run pseudo-servers that implement the POP3, SMTP, NNTP and IRC protocols. These pseudo-servers communicate with each other through the DoDWAN middleware system in a peer-to-peer mode. End-users can use the standard client programs they are already familiar with (for example Thunderbird or XChat IRC) in order to access their email accounts, newsgroups or IRC channels.

Other applications have been specifically designed for the DoD-WAN middleware system, with specific user interfaces. One of these applications makes it possible to visualize the user's direct neighbors. A peer-to-peer filesharing application that allows users to define their interests for particular files and to receive them according to their content. Finally, simple text and voice messaging applications are available. These are well adapted to small devices such as smartphones, for they only require limited user interaction.

Figure 2 shows screenshots of some of these applications. In the remainder of this section, we detail how some of these applications make use of DoDWAN's content-based information dissemination to implement application-level communication schemes.

NewsWAN.

NewsWAN (News distribution in Wireless Ad hoc Networks) is a discussion service that is strongly inspired from the legacy Usenet service created in the 1980s. NewsWAN implements an NNTP pseudo-server running on each device. The Thunderbird agent is used as a standard user interface.

Newsgroups, representing topical categories, are used as content description for message dissemination. Any user can create a newsgroup, or discover existing ones. When an article is published to a particular newsgroup, a message is put in the cache maintained by DoDWAN, with the newsgroup as content description. The message then starts propagating from device to device in the network, being carried by those devices whose users have subscribed to the newsgroup considered. Symmetrically, whenever the DoDWAN middleware obtains from a peer host an article that matches its own "interest profile"-that is, an article that pertains to a newsgroup it has been ordered to maintain locally-this article is simply put in the local cache, and the NewsWAN program is notified of this reception, so the article can be made available for the user's newsreader.

FiShWAN.

FiShWAN (File Sharing in Wireless Ad hoc Networks) is a peerto-peer filesharing application, which can be compared with popular filesharing applications such as Emule or Kaaza. FiShWAN leverages on DoDWAN's content-based communication model, and provides users with facilities to describe the content of the files they want to publish or to obtain, and to easily store and retrieve these descriptions when needed. File descriptors are directly used by DoDWAN while performing selective message dissemination.

MailWAN.

MailWAN (Mail exchange in Wireless Ad hoc Networks) is an email exchange service that allows users of mobile devices to send and receive email. It implements POP3 and SMTP pseudo-servers running on each mobile device, accessed locally by standard email agents such as Thunderbird. MailWAN is implemented using the publish/subscribe programming interface offered by DoDWAN.

In the Internet email forwarding relies on an address-based scheme. In contrast DoDWAN implements a content-based propagation model. When publishing an email message, MailWAN includes the email address of the recipient as the content description of the message. In order to receive messages it also registers with DoDWAN as a subscriber for messages whose content description is the email address of the local user.

All mobile devices do not necessarily have to serve as carriers for all email messages. The domain part in an email address is considered as the identifier of a community of users. Thus members of a community collaborate to disseminate messages addressed to any member of this community. Through the usual tool in her email agent, the user can create an account (with a dedicated domain name) for each of the communities she belongs to.

TextWAN and VoiceWAN.

TextWAN and VoiceWAN are text and voice messaging services inspired from the well-known SMS service, and extended to nontextual messages. Each user can belong to one or several groups, and messages can be sent either to specific users or to groups of users. Messages are forwarded towards their destination(s) by disseminating through all devices that belong to the same groups as the target(s).

EXPERIMENTATION

DoDWAN and the application suite described in Section 3 are meant to be useful in challenged environments, especially when traditional communication services are not available. Yet before trying to use DoDWAN and its applications in really harsh conditions, we conducted a preliminary experimentation campaign inmon a more "cozy" environment. This campaign involved groups of volunteer students (up to 25 volunteers during each trial), that were equipped with DoDWAN-enabled netbooks and were strongly invited to use DoDWAN and its applications during and between classes, but also out of the campus (at home, during week-end trips, etc.). Several trials were conducted during that campaign, with durations ranging between a couple of weeks and 6 months.

The netbooks were Dell Inspiron Mini 9 and Mini 10, running an Ubuntu/Linux system. The Wi-Fi interface on each netbook was configured to operate by default in ad hoc mode, using an SSID dedicated to the experiment. The users were not allowed to switch this interface to managed mode, thus preventing wireless connections to access points that may be present in their environment. However, they had the possibility to access the Internet sporadically using the builtin Ethernet interface, while wireless communication was reserved for opportunistic communication with DoDWAN.

All the software needed for the experiments had been packaged in two Debian packages to ease its deployment. These packages included not only DoDWAN and its applications, but also a number of administration tools. Among these tools was a network configurator that could control the Wi-Fi and Ethernet interfaces, and a power manager. This power manager could detect the starts and shutdowns of the netbooks, as well as suspend-to-ram and resume events, and notify DoDWAN of these events. Such events are important for the DoDWAN system, as it uses them to update its perception of a host's neighborhood, and to adapt its gossiping with neighbors accordingly. Another administration tool allowed software upgrade via an Internet connection established through the Ethernet interface. Because of the rather long duration of the whole campaign, bug corrections or parameter adjustments had to be applied during the course of the experiment. Users were informed of these changes (typically via articles published in a dedicated newsgroup accessible with the NewsWAN application), and were invited to temporarily connect their netbook to the Internet, so that an automatic upgrade of the software could be performed. Another administration tool was used to automatically upload the different traces collected on a mobile host to a server in our laboratory. This upload occurred whenever the host's Ethernet interface was plugged. The storage capacity on each netbook was actually sufficient to store the entire trace of a trial. It was however interesting for us to collect traces dynamically, as it allowed us to detect and correct software issues as early as possible.

The execution traces collected on each netbook during the whole campaign pertained to the activity of the operating system, of the DoDWAN middleware, and of the DoDWAN-based applications. The analysis of these traces allowed us not only to check the behavior of DoDWAN's protocol, but also to get a better understanding of the behavior of the users. During the whole experimentation campaign we collected 935 Mbytes of trace data, corresponding to about 8.7 million elementary events observed on the netbooks. In the remainder of this section we illustrate the kind of information that can be extracted from these trace data.

Figure 3 depicts the volatility of 20 netbooks (carried by as many volunteer students) during a 2-month trial, represented as an up/down line for each netbook. The figure clearly shows that the activity of the 20 netbooks varied a lot during the trial, with a global activity level remaining rather low. The right part of Figure 3 focuses on the afternoon of the 4th day of the trial. It can be observed that only 6 netbooks out of 20 had a significant period of activity (longer than one hour) during that afternoon. Very short periods of activity were observed, for example on netbooks n3 and n14 whose traces show activity periods of less than a minute. It turns out that several users sometimes opened the lid of their netbook for a few seconds, just to have a glance at the clock widget or to "check their messages". Ironically, these users were anxious to preserve the battery level of their netbook but, by doing so, they did not allow the local DoDWAN system to interact effectively with neighbor hosts, thus diminishing the interest of having DoDWAN-based applications running on their netbook. Indeed, this observation alone bears out that experimentation in real conditions can highlight technical and non-technical issues that simulators can hardly pinpoint. In that particular case, it notably confirms that the volatility of batterypowered devices must not be underestimated when designing protocols and applications for opportunistic computing. Figure 4 depicts the evolution of the neighborhood of a typical netbook (namely netbook n14) during the same 2-month trial. The neighborhood of a netbook is here defined as the number of other netbooks that are within the radio range of this netbook at a given time. In the figure it can be observed that the number of neighbors of netbook n14 varied continuously and unexpectedly during the 2-month trial. Interestingly, the neighborhood of each netbook was rarely greater than 10 and no clear pattern can be observed in its evolution, although the 20 students often attended the same classes in the same rooms. This confirms that neighborhood between handheld mobile hosts is the result of user-driven volatility and mobility, which when combined together make it hardly predictable. Opportunistic networking and computing then take all their sense, as they allow messages to flow between devices, even though these devices are almost never active at the same time.

The trace data collected during the campaign also allowed us to check the message dissemination scheme implemented in DoD-WAN. Figure 5 shows the dissemination of a particular message, which was published by netbook n6 during one of the trials. This message was actually an article published by n6's user in a particular newsgroup. The dissemination of the message is here displayed as a tree. Indeed this tree was somehow built opportunistically by the DoDWAN protocol, as radio contacts between netbooks occurred over time. The delay-tolerant nature of the dissemination scheme appears clearly in this example: after the message was published on n6 at time 00:00, n6 met n5, n10 and n12 about 6 minutes later. Since the message matched the interest profiles of these three netbooks they all got a copy of the message, and thus became carriers of this message. n5 later met netbook n1, but since the message did not match the interest profile of n1 it did not become a carrier (this is expressed by the dotted line in the figure). n5 went on to meet n14, which got a copy of the message and itself later passed this message to n3 and n16. After 53 minutes, 12 netbooks had received the message, and 3 additional netbooks had been proposed this message but had denied it.

Globally, the experimentation campaign revealed a utilization ratio of the DoDWAN applications lower than what we had expected. For example, the two-month trial discussed above totalized 419 messages published with MailWAN, NewsWAN and FiShWAN, with relative parts of respectively 38%, 43% and 19%. This is partly due to the fact that our volunteer students did not rely entirely on the DoDWAN applications, as they evolved in an environment where traditional communication means (such as 3G infrastructure and Wi-Fi hotspots) were widely available. Indeed, interviews with users showed that they often felt reluctant to rely on asynchronous communication tools, as they are addicted to quasi-interactive communication (even email is often expected to be transmitted almost instantaneously). This fact should be taken into consideration when preparing to run DTN experimental trials, and selecting applications for these trials. The killer-application is still to be found with this respect.

RELATED WORK

As mentioned in Section 1 only a few protocols for D-MANETs have been implemented in fully-functional communication systems, which are now openly distributed and are thus accessible to developers. Among these systems are the DTN2 system [1], the Haggle system [START_REF] Helgason | A Mobile Peer-to-Peer System for Opportunistic Content-Centric Networking[END_REF], and our own system DoDWAN [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF].

Such systems make it possible for developers to design distributed applications, and to use these applications to evaluate the potential of delay/disruption-tolerant and opportunistic networking in challenged environments.

Many possible applications for D-MANETs have been discussed in the literature, although not so many have been implemented and tested in real settings. Email can typically be implemented in a delay/disruption-tolerant environment, due to its inherently asynchronous nature. [START_REF] Naidu | Challenges in Deploying a Delay Tolerant Network[END_REF] thus describes a DTN-enabled Email service based on a modification of the SMTP protocol. This service, which involves static kiosks and mobile data mules, has notably been tested during a limited field deployment in rural India.

DTN applications inspired from Twitter [START_REF] Hossmann | Twitter in Disaster Mode: Opportunistic Communication and Distribution of Sensor Data in Emergencies[END_REF], Facebook [START_REF] Lindgren | Social Networking in a Disconnected Network: fbDTN: Facebook over DTN[END_REF] and

Podcasting [START_REF] May | Wireless Opportunistic Podcasting: Implementation and Design Tradeoffs[END_REF] have also been proposed recently. [START_REF] Ginzboorg | DTN Communication in a Mine[END_REF] proposes to use DTN communication in a Finnish chromium mine. A series of experimental trials have been carried out between 2008 and 2010, in different countries, as part of the EU-funded Networking for Communications Challenged Communities (N4C) project. Trials conducted in Swedish Lapland for example focused on how Web and Email applications based on the PRoPHET protocol [START_REF] Lindgren | Networking in the Land of Northern Lights: Two Years of Experiences from DTN System Deployments[END_REF] and on the DTN2 system [START_REF] Farrell | Report on DTN Applications During Arctic Summer[END_REF] could meet the needs of reindeer herders. The idea of using smartphones as DTN-enabled voice-messaging devices has been addressed in many papers [START_REF] Ntareme | Delay Tolerant Network on Smartphones: Applications for Communication Challenged Areas[END_REF][START_REF] Heimerl | Message Phone: A User Study and Analysis of Asynchronous Messaging in Rural Uganda[END_REF][START_REF] Islam | Voice Messaging for Mobile Delay-Tolerant Networks[END_REF]. A trial deployment was notably carried out in Uganda. Results of this trial are discussed in [START_REF] Heimerl | Message Phone: A User Study and Analysis of Asynchronous Messaging in Rural Uganda[END_REF].

Most of the above-mentioned papers propose to implement applications based on the DTN2 system, although some of them define their own protocol to support applications. Haggle and DoD-WAN yet differ from DTN2 in that they support opportunistic content-driven information dissemination, while DTN2 primarily supports destination-driven message forwarding. Opportunistic content-driven dissemination presents a number of advantages in a D-MANET, for messages can be published in the network with no specific destination. Each mobile host can thus decide to accept -and thus become a carrier for-a message based on its own interest profile or, if needed, based on its willingness to serve as a benevolent carrier for this message. This approach can bring significant benefits in a D-MANET, especially when mobility and contact patterns cannot be predicted.

To the best of our knowledge no extensive experimental trial has ever been conducted with the Haggle system in a challenged environment. As explained in Section 4 the DoDWAN system and the associated applications have so far only been tested in a campus environment (although DoDWAN itself has already proved effective for military tactical communication). The results obtained from this preliminary trial however suggest that DoDWAN and the application suite are reliable enough, so our next goal will be to deploy a small flotilla of DoDWAN-based netbooks and smartphones in a rural environment.

CONCLUSION

In this paper we have presented an application suite we designed and implemented in order to provide users with communication facilities in challenged environments, such as in rural, remote, or disaster-struck areas. The mobile devices used in such conditions are assumed to constitute a disconnected mobile ad hoc network (D-MANET). An opportunistic, content-driven communication model is used to enable message forwarding in such conditions, using mobile hosts as carriers that allow messages to propagate networkwide. This model is implemented in DoDWAN, a communication system we designed and which is distributed under the LGPL license.

Our DoDWAN-based application suite has first been implemented on netbooks, and tested during a preliminary experimentation campaign involving about 20 volunteers per trial. This campaign has confirmed that the communication model is effective at disseminating messages in a flotilla of mobile hosts, and has allowed us to learn a number of lessons from the observations made on that occasion.

Work is now in progress to deploy the same applications on Android-based smartphones. A trade-off must here be made between preserving the limited power budget of the device and ensuring sufficiently frequent radio contacts with other devices. The latter objective is a tricky one since, unlike netbooks, smartphones tend to enter suspend-mode whenever they are not used interactively.

The portability and extended autonomy of smartphones (compared to netbooks) are expected to open up a wide range of field experiments. In the near future we plan to conduct experimentation campaigns, combining this time netbooks and smartphones, in environments devoid of any communication infrastructure.

Figure 2 :

 2 Figure 2: Screenshots of some DoDWAN applications

Figure 5 :

 5 Figure 5: Timeline of the dissemination of a message

the afternoon of day 4 Figure 4 :

 44 Figure 4: Evolution of the neighborhood of netbook n14 during the 2-month trial

Acknowledgments

The authors would like to thank the students of École Normale Supérieure de Cachan-Bretagne and Université de Bretagne-Sud who participated in this experimentation campaign. Special thanks to Prof. Claude Jard who made this all possible.


F Guidec

P Launay

N Le Sommer

Y Mahéo

Demo: Experimentation with a DoDWAN-based Application Suite for Opportunistic Computing

DoDWAN is a middleware system that supports content-based information dissemination in partially or intermittently connected mobile ad hoc networks. It can be used to allow communication between people in challenged environments, such as in rural, remote, or disaster-struck areas. An application suite has been implemented on top of DoDWAN. This suite includes services such as email, text and voice messaging, filesharing, etc. A preliminary experimental trial conducted on a university campus with volunteer students has confirmed that DoDWAN and its applications are robust and reliable. We would now like to deploy a flotilla of DoDWAN-enabled netbooks and smartphones during the ExtremeCom'12 conference, using this event as an opportunity to test our system in challenged conditions while collecting inputs from the users.

OVERVIEW OF DODWAN

Building an application suite for disconnected mobile ad hoc networks (or D-MANETs) requires some communication middleware system with which mobile hosts can collaborate in a peer-to-peer manner to ensure message transportation. DoDWAN (Document Dissemination in mobile Wireless Ad hoc Networks) is a communication middleware system we designed along that line [START_REF] Haillot | A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks[END_REF]. It is written in Java, and it is distributed under the terms of the GNU General Public License 1 .

DoDWAN supports content-based information dissemination in D-MANETs. This is a characteristic it shares with the Haggle system, while the DTN2 system is rather meant to support destinationdriven message forwarding. In content-based networking, information flows towards receivers rather than towards specifically set destinations. This approach notably fits the needs of applications and services dedicated to information sharing or event distribution. It can also be used for destination-driven message forwarding, though, considering that destination-driven forwarding is simply a particular case of content-driven forwarding where the only significant parameter is the identifier of the destination host (or user).

DoDWAN uses the store, carry and forward principle to ensure the dissemination of documents over the network. Each DoDWAN node maintains a local cache and an "interest profile" that determines the kind of information it is interested in, and thus implicitly the kinds of documents for which it is willing to serve as a mobile carrier. A gossip-like communication protocol orchestrates interactions between neighboring nodes, allowing them to exchange documents according to their respective interest profiles. Interaction between mobile nodes relies on a simple scheme, whereby each node informs it neighbors of its own interest profile and of the catalogue of the document headers that are currently available in its local cache. When a node discovers that one of its neighbors can provide a document it is interested in (that is, a document header that matches its own interest profile and that is not already available in its own cache), it can request a copy of this document from this neighbor.

Mobile hosts running DoDWAN only interact by exchanging control and data messages encapsulated in UDP datagrams, which can themselves be transported either in IPv4 or IPv6 packets. DoD-WAN has originally been implemented so as to rely on Wi-Fi interfaces running in ad hoc mode, and this is the way it is usually used in most situations. Yet it has also been experimented in a military tactical network, using VHF battlefield radios with low-bitrate built-in modems instead of Wi-Fi interfaces, and proved robust and reliable in such harsh conditions [START_REF] Haillot | Disruption-Tolerant Content-Driven Information Dissemination in Partially Connected Military Tactical Radio Networks[END_REF].

OPPORTUNISTIC COMPUTING WITH DODWAN

A number of applications have been designed and implemented based on the DoDWAN middleware. These applications allow users to rely on legacy services such as email and newsgroups, although no server is required to use these services: messages are transported by DoDWAN from mobile host to mobile host opportunistically in a peer-to-peer fashion, rather than using the traditional client-server model. Short-text messaging (similar to the SMS service), voice messaging, filesharing, and plateau games are also available.

This application suite has originally been implemented so as to run on laptops and netbooks, and an experimental trial conducted with volunteer students has confirmed that it performs satisfactorily [START_REF] Mahéo | Beyond Opportunistic Networking Protocols: a Disruption-Tolerant Application Suite for Disconnected MANETs[END_REF]. A version of the suite adapted to smartphones has also been developed for the Android platform.

EXPERIMENTATION DURING EXTREMECOM'12

The goal of the experiment is to promote opportunistic computing as a means to support communication and coordination between people in an environment devoid of networking infrastructure. We plan to provide a number of DoDWAN-enabled netbooks and smartphones, which will be available for ExtremeCom'12 attendees during the whole duration of the conference. Participants will also be encouraged to install our software kit on their own laptop or smartphone, provided these devices meet the requirements specified in Section 4.

With our or their own devices, volunteer users will be able to exchange text and voice messages, and to share documents (such as pictures taken with the smartphones' builtin cameras, conference papers, presentation slides...) with all or part of the other users. Some messages may be published for anybody to receive, while in some occasions some users may wish to create a restricted community and exchange messages only within this community. In any case message dissemination will be ensured in the background by DoDWAN, in an opportunistic manner, as radio contacts between devices occur over time.

Conference attendees participating in the outdoor activities (such as igloo building or snowshoe hikes) will be encouraged to bring smartphones and keep using DoDWAN's applications on these occasions. Thus, a picture taken and published with his smartphones by an igloo builder should disseminate opportunistically from host to host, and reach eventually -possibly hours later-the devices of users who were hiking with snowshoes at the same moment. A file containing the presentation slides of a keynote speaker may similarly be published for all to receive, even though all mobile devices do not have to be close to the publisher and running when the file is published.

REQUIREMENTS

We assume that the batteries of netbooks and smartphones can be charged at the conference venue, although snowshoe hikers may have to rely on solar panels (we'll provide a couple of these) or backup batteries. Our software kit can be installed on the participants' own devices, provided these devices include JRE 1.6 and a Wi-Fi interface. This kit is currently available for standard laptops (running Linux preferably) and Android 2.2 and 2.3 smartphones. Users that are not familiar with software installation and Wi-Fi ad hoc configuration on their device may require our assistance. More-over a short introduction to the possibilities offered by the software kit would certainly be helpful for volunteer users. For this reason it is desirable that a time slot be assigned for this activity at the beginning of the conference.

EXPECTED RESULTS

We expect to gather interesting inputs from volunteer users during the conference. Moreover, trace files generated by DoDWAN on each mobile device will be collected at the end of the trial. The confidentiality of user to user communication is here guaranteed: the trace files contain low-level details about the wireless gossiping between mobile hosts (such as radio contact occurrences and durations), but no information is recorded about the actual content of the messages exchanged between these hosts. By analyzing these trace files after the conference, we expect to better understand how opportunistic networking and computing tools such as those we designed can help people communicate in challenged environments.

Figure 1 :

 1 Figure 1: DoDWAN applications deployed on netbooks and smartphones

Figure 2 :

 2 Figure 2: Screenshots of the DoDWAN Android application running on a smartphone

http://www-irisa.univ-ubs.fr/CASA/DoDWAN Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ExtremeCom2012, March 10-14,

2012, Zürich, Switzerland. Copyright 2012 ACM 978-1-4503-1264-6/12/03 ...$10.00.