Sujuan Wu

Cong Wang
email: congwang@buaa.edu.cn

Yinfang Cui

Weichang Hao

Tianmin Wang

Pascal Brault

BiOCl nano/microstructures on substrates: synthesis and photocatalytic properties

Keywords: BiOCl, flake film, microstructures, sol-gel preparation

Bismuth oxycholoride (BiOCl) nano/microstructures, including flake and nanowire arrays, were successfully synthesized on Anodic Aluminum Oxide (AAO) templates via sol-gel combined with the vacuum air-extraction method. The flakes are almost vertically aligned on the surface, but nanowire arrays at a lower sol concentration are aligned along the channels. A possible formation mechanism is proposed. Furthermore, the photocatalytic activity of the BiOCl nano/microstructures is investigated by photocatalytic decomposition of Rhodamine B (Rh B) dye under UV-Visible light irradiation. Compared with the BiOCl flake film on the glass substrate, where the flakes are horizontally oriented on the surface, the vertically aligned flake and nanowire arrays on AAO templates, have a higher photocatalytic efficiency.

Introduction

Recently, Bi-based photocatlytic materials have aroused great interest due to the unique electron structure of Bi, which is beneficial for promoting the mobility of photo-generated carriers [1,2]. In particular BiOCl, which has exhibited wide applications as a pigment in the cosmetic industry and as a candidate material for optoelectronic and photovoltaic devices, e.g. light-emitting diodes, lasers and solar cells, could perform as an potential excellent photocatalytic material for purifying textile dye polluted wastewater [3]. In 2007, Huang and co-workers firstly reported that BiOCl exhibited better performance than TiO 2 (P25, Degussa) on the photocatalytic degradation of methyl orange (MO) dye [1]. An [4] and Zhang [5] found that BiOCl exhibited excellent photocatalytic activity on degradation of Rh B and MO dye under both UV and visible light irradiation. Therefore, it is necessary to further investigate BiOCl growth and morphology to achieve optimum photocatalytic activity and explore the possible applications.

There are two major factors, i.e. high photocatalytic activity and immobilization, that should be considered for the application of photocatalysts [6]. The following strategies can be adopted: phase and morphological control, doping, surface sensitization, composite materials etc. Morphological control of nanostructured materials is one of the efficient and available ways to improve the photocatalytic efficiency due to the high surface-to-volume (S/V) reachable ratio.

Until now, nano-structure materials with different morphologies, such as nanotube, nanowires, flakes, spheres, v-shaped structure, have been fabricated and used to promote the efficiency [7][8][9].

The second important factor is immobilization. The photocatalyst powders are generally suspended in water, which limits their practical use because of the difficulty in collecting and recycling photocatalyst powders from a suspension. One of the methods to solve this problem is to immobilize the photocatalyst on a substrate, e.g. to form thin films, coatings, or directly control growth of nanostructures on the substrate, to meet the requirements of the future applications.

Although different preparation methods have been reported, the AAO template assisted method is the most widely used and also turns out to be quite efficient [10]. AAO templates can not only control the growth of nanostructure, but also can behave as substrate. Recently, we have prepared the BiOCl nanowire arrays successfully by employing AAO templates as substrate [11]. Herein, we report the control growth of different morphological BiOCl nano/microstructures on AAO templates and the BiOCl flake film on glass substrates. Furthermore, their photocatalytic activities were also investigated by photocatalytic decomposition of Rhodamine B (Rh B) dye.

Experiment

BiOCl powder was dissolved in 100 ml alcohol to form 0.3 M, 0.5 M sol, in which 5 M HCl was added to adjust the pH=1 under constant stirring at 60 °C for 2 h. Then, the commercial AAO template (Whatman company) with a pore diameter of 100 nm and depth of 60 μm was placed in a vessel that contained 2 ml of the prepared BiOCl sol. After, they were treated under the vacuum air-extraction [12]. The condition of vacuum pressure was 1 Pa at room temperature for 30 minutes.

The resulting samples were collected and dryed at 100 °C for 10 h. For comparison, the BiOCl flake film on a glass substrate was prepared via the sol-gel dipping method. The glass substrate was dipped slowly into the 0.5 M sol and a raising velocity at 25mm/min was maintained for deposition.

The crystallinity and morphology of the samples was examined by X-ray diffraction (XRD), and field effect-scanning electron microscopy (FE-SEM). Photocatalytic activity of the samples was evaluated by the degradation of Rh B dye solution. The samples with the average area of 4 cm 2 were put into 20 ml 0.01mmol Rh B solution, respectively, and kept in darkness for 24 h to reach the adsorption-desorption equilibrium. The light source was a 35W Xe lamp and the distance between the light source and samples was 20 cm. The UV-Visible absorption spectra and diffuse reflectance spectrum were carried out on a Hitachi U-3010 spectrometer.

Results and discussion

X-ray diffraction (XRD) was used to investigate the phase structures of the samples. All of the sharp diffraction peaks in the XRD patterns were perfectly indexed as pure phase of BiOCl, in good agreement with the standard JCPDS file (No. 06-0249) of BiOCl. A tetragonal lattice with a=3.890 Å and c=7.369 Å was obatined. The three strongest peaks were indexed as (001), (002) and (003) for the BiOCl flake film on the glass substrate (Figure 1c), whereas (101), (110) and (211) for the 0.5 M sol (Figure 1a) and 0.3 M sol (Figure 1b) on the AAO template.

Figure 2 displays the SEM images of the BiOCl morphologies on AAO templates and glass substrates. The flakes, with a diameter of ~3 μm, thickness of ~300 nm, are densely aligned on the surface of the AAO template (Figure 2a). They are almost perpendicular to the surface. A detailed cross-section image (inset of Figure 2a) shows that the flakes are co-existent with nanowires. By decreasing the concentration of the sol to 0.3 M, the flakes disappear and nanowires with the diameter around 100 nm and length around 3 μm are formed (Figure 2b). It can be seen that all nanowires are roughly parallel to each other and vertically oriented on the AAO template to form an array [11]. The morphology of the BiOCl on glass substrate is different from that on the AAO template. The flakes are parallel to the surface and are stacked layer by layer on the glass substrate.

The thickness of these flakes ranges from 50 to 100 nm with corresponding diameters between 0.5 to 1.5 μm (Figure 2c). It can be clearly seen that the BiOCl on the AAO template possesses larger surface-volume area than that on glass. As a consequence, a possible formation mechanism of different BiOCl morphologies is proposed (Figure 3). The formation of the flakes can be attributed to the tetragonal matlockite Hence, the BiOCl flakes prefer to be formed on the surface of glass and AAO template. During the process of the vacuum air-extraction treatment, these flakes on the template start to stand up and densely packed together. Meanwhile, part of the sol is sucked into the channels and becomes coagulated and solidified in the channels. In the other hand, the concentration of the sol determines its viscosity, which will affect its diffusing ability. The viscosity will decrease correspondingly as the concentration decreases. Therefore, the sol with lower concentration is easier to impenetrate into the channels and fully fill them to form nanowire arrays.

The photocatalytic activities of the samples were evaluated for decomposition of Rh B dye.

The removal of Rh B versus irradiation time is plotted in Figure 4a. The initial data shows the normalized concentration after 24 h equilibration of adsorption-desorption. Remarkably, ~39% and ~42% of the initial dye is removed from the aqueous solution by adsorption on the BiOCl flakes and nanowire arrays on AAO templates, respectively. The BiOCl on glass substrate removes only ~ 3% of the dye. The photocatalytic reaction is simply described by

-d[c]/dt = k[c],
where [c] is the Rh B concentration, and k being the degradation rate constant. The calculated degradation rate constants in decomposing Rh B with photocatalytic samples is shown in Figure 4b., and is found to dramatically increase from 0.0038 min -1 for the horizontally oriented flakes film, to 0.0067 min -1 for the nanowire arrays and 0.0242 min -1 for the vertically aligned flakes.

The BiOCl nanowire arrays and the vertically aligned flakes on the AAO template exhibit high photocatalytic activities, whereas the horizontally oriented BiOCl flakes on the glass substrate show a lower efficiency. As indicated in the Figure 4a, the bare AAO template can not cause any adsorption and degradation of the dye. Hence, the higher adsorption and efficiency of the BiOCl on the AAO templates can be attributed to the special morphology of BiOCl structures.

Conclusion

The vertically aligned flakes, nanowire arrays on AAO templates, and horizontally oriented flakes on glass substrates have been successfully formed. It is found that the concentration of the sol has a strong impact on the morphologies of the BiOCl nanostructures on AAO templates. Specifically, nanowire arrays are prepared at a concentration of the sol is 0.3 M, whereas vertically aligned flakes are formed on surface at a concentration of 0.5 M. The photocatalytic action has been evaluated by degradation of Rh B dye under UV-visible light. We find that BiOCl nano/micro structures on AAO templates possesses higher photocatalytic efficiency than the BiOCl on glass substrates. This efficiency can be dramatically improved by controlling the morphology.

Figure captions

  structure of BiOCl expressed by [M 2 O 2 ][Cl m ] or [M 3 O 4+n ][Cl m ] (m= 1-3), where bismuth oxide based fluorite-like layers, [M 2 O 2 ] or [M 3 O 4+n ], are intergrown with double chlorine layers [5,13].

Fig 1 .

 1 Fig 1. XRD patterns of the 0.5 M sol on AAO template (a); 0.3 M sol on AAO templates (b); and the BiOCl film on glass substrates (c).

Fig 2 .

 2 Fig 2. The SEM images of BiOCl flakes structure, from 0.5 M sol (a) and nanowire array structures, from 0.3 M sol (b) on AAO templates, and BiOCl film on glass substrates (c).

Fig 3 .

 3 Fig 3. Schemetic illustration of the formation mechanism of BiOCl nano/micro structures on AAO templates.

Fig 4 .

 4 Fig 4. First order plots for the photocatalytic degradation of Rh B (a) and the corresponding degradation rate constants (b) for flakes, nanowire arrays, and film on glass substrate.

  Fig 1

Fig2

  Fig2

  Fig 3

Acknowledgements

This project was financially supported by the National Basic Research Program of China under grant number 2007CB613302 and the National Natural Science Foundation of China (NSFC) (No. 50772008, No.50732004).


George M Tzoumas

Exact medial axis of quadratic NURBS curves

We study the problem of the exact computation of the medial axis of planar shapes the boundary of which is defined by piecewise conic arcs. The algorithm used is a tracing algorithm, similar to existing numeric algorithms. We trace the medial axis edge by edge. Instead of keeping track of points on the medial axis, we are keeping track of the corresponding footpoints on the boundary curves, thus dealing with bisector curves in parametric space. We exploit some algebraic and geometric properties of the bisector curves that allow for efficient trimming and we represent bifurcation points via their associated footpoints on the boundary, as algebraic numbers. The algorithm computes the correct topology of the medial axis identifying bifurcation points of arbitrary degree.

Introduction

The medial axis (MA) of an object can be defined as the locus of the centres of maximal bitangent disks and was originally introduced by [START_REF] Blum | A Transformation for Extracting New Descriptors of Shape[END_REF]. The medial axis of a simple closed shape has a tree-like structure that provides an efficient shape representation. Along with a radius function, the MA allows for restoration of the original object, an operation called medial axis transform (MAT).

Due to its wide range of applications in biology, path planning and pattern analysis it has been studied extensively [START_REF] Chou | Voronoi diagrams for planar shapes[END_REF][START_REF] Hyeong | Mathematical theory of medial axis transform[END_REF][START_REF] Ramamurthy | Voronoi diagram and medial axis algorithm for planar domains with curved boundaries -II: Detailed algorithm description[END_REF]. However most efforts consist of numerical algorithms to trace the bisector curves. Another approach is to approximate the boundary of the shape with simpler curves or line segments. However the resulting MA may require expensive postprocessing, or be incorrect, as it is very sensitive to perturbations of the boundary of the shape.

Recently, with the availability of algebraic libraries and faster CPUs, there has been interest in exact algorithms following the exact computation paradigm. Successful examples of this approach are the exact and efficient arrangement of conic arcs and the Voronoi diagrams of circles and ellipses [START_REF] Emiris | Exact Delaunay graph of smooth convex pseudocircles: general predicates, and implementation for ellipses[END_REF].

Following this trend, we apply exact computation techniques to the problem of medial axis computation. In theory, one can study some algebraic system and map the problem to the study of an arrangement of algebraic curves, parts of which are the medial axis edges. However, this can lead to highly inefficient computations due to the degree and bitsize explosion of the computed quantities. Therefore, we focus on the parametric representation of the shape, trying to understand the deeper relation between simple geometric constructions (like the tangent line and the circle of curvature) and the parametric bisector curves.

We chose to use a simple O(N 2 ) algorithm that also works with objects with holes. The algorithm includes a tracing step which we substitute with an exact one. Therefore, no tracing is included and all critical points are guaranteed to be identified. The idea is to start tracing the medial axis, always computing the next branching or terminal point in one step. The algorithm used is adapted from [START_REF] Ramanathan | Constructing medial axis transform of planar domains with curved boundaries[END_REF]. The branching point is the center of a maximal disk that is tangent to at least three distinct footpoints, while a terminal point corresponds to a local curvarture maximum ( [START_REF] Chou | Voronoi diagrams for planar shapes[END_REF]). We work in the parametric space, in a manner similar to [START_REF] Seong | Voronoi diagram computations for planar NURBS curves[END_REF], however for efficient trimming of the bisector curves we exploit some algebraic and geometric properties.

Representation

The input is a simply connected closed shape consisting of a sequence of NURBS curves of degree 2, that is, conic arcs. The shape may contain holes, that are also piecewise conic arcs themselves. We follow the notation of [START_REF] Piegl | The NURBS book[END_REF]. The reason we focus on degree 2 NURBS curves is that they are powerful enough to express a wide variety of curves (elliptic, circular, hyperbolic, parabolic arcs) while keeping the algebraic complexity within reasonable bounds at the same time (comparison of algebraic numbers of degree 184 in the worst case). Given three control points P 0 , P 1 , P 2 and a shape factor s (cf. Fig. 1), we represent a conic arc, parametrized by t, from P 0 to P 2 through P 1 as

C(t) = (1 -t) 2 P 0 + 2t(1 -t) s 1-s P 1 + t 2 P 2 (1 -t) 2 + 2t(1 -t) s 1-s + t 2 , t ∈ [0, 1].
As parameter t traces the arc, we assume that the interior of the shape lies always on the left. Therefore, convex boundary arcs have positive or CCW orientation, while concave boundary curves have negative or CW orientation. The control points have the property that the segments P 0 P 1 and P 1 P 2 are tangent to P 0 and P 2 respectively. Note that C(0) = P 0 and C(1) = P 2 . When s < 1/2 we have an ellipse, when s = 1/2 we have a parabola, and 1/2 < s < 1 yields a hyperbola, as shown in Fig. 1.

P0 P1 P2 s < 1/2 s = 1/2 s > 1/2

Bisector curves

Each point on the medial axis is the center of a disk tangent to at least two points of the boundary of the shape. Therefore, the points of the medial axis lie on bisector curves of planar rational curves, or on bisector curves of a point and a curve. They may also lie on the self-bisector of a single curve. The bisector curve of planar rational curves is an algebraic curve and can be defined implicitly in the parametric space as the common intersection of the normal lines at the footpoints and the segment bisector of the footpoints themselves [START_REF] Elber | Bisector curves of planar rational curves[END_REF]. It is of lower degree than the implicit equation in the cartesian space. We can verify that for conics, the bisector equation in the parametric space is of total degree 12 in the worst case, 6 in each parameter. See [START_REF] Emiris | Predicates for the exact Voronoi diagram of ellipses under the euclidean metric[END_REF] for the case of ellipses and [START_REF] Farouki | Degenerate point/curve and curve/curve bisectors arising in medial axis computations for planar domains with curved boundaries[END_REF][START_REF] Elber | Bisector curves of planar rational curves[END_REF] for a study of point-curve or curve-curve bisectors. We represent a point on the medial axis by the corresponding footpoints on the boundary curves, therefore we can represent parts of the medial axis by properly trimming the bisector curves. In [START_REF] Seong | Voronoi diagram computations for planar NURBS curves[END_REF] the bisector curves are split in monotone pieces by using a subdivision technique. In the section that follows we improve this technique by proving and exploiting some algebraic and geometric properties of the bisector curves themselves. This is a generalization of the properties observed and exploited in [START_REF] Emiris | Predicates for the exact Voronoi diagram of ellipses under the euclidean metric[END_REF].

Maximal bitangent disk

The boundary of the shape consists of two types of arcs. Convex and concave ones. We consider the general case where the tangency points of a maximal bitangent disk are not a concave joint. Let a 1 and a 2 be two arcs and P 1 and P 2 the corresponding footpoints of a maximal bitangent disk B (Fig. 2). Given P 1 , since the bisector curve is of degree 6 in each parameter, there may be up to 6 candidate points for P 2 . We can select the proper solution by applying the following lemmas.

Lemma 1 If a 1 is concave, then the tangent line T of a 1 at P 1 separates P 2 and a 1 (Fig. 2 cases (i) and (ii)). If a 1 is convex, then the circle of curvature of a 1 at P 1 contains P 2 (Fig. 2 cases (iii) and (iv)).

Proof. If a 1 is concave, then a 1 and the maximal disk B have opposite curvatures. Therefore all points of a 1 (except P 1 ) and B are separated by T . (In this case, T can be seen as a circle with an infinite radius.) If a 1 is convex, then the circle of curvature of a 1 at P 1 is the circle of maximum radius that lies locally inside a 1 . Therefore its radius bounds from above the radius of B.

Applying the above lemma for P 2 yields the following.

Lemma 2 If a 2 is concave (Fig. 2 cases (i) and (iii)), we consider the tangent lines of a 2 along the arc. At some point Q, the tangent line may pass through P 1 and this will be a boundary condition, that is before Q, P 1 will be on the correct side (left) of the tangent line, while after Q, P 1 will be on the right of the tangent line, thus points after Q on a 2 are rejected. If a 2 is convex (Fig. 2 cases (ii) and (iv)), we consider the cirles of curvature of a 2 along the arc. At some point Q, the circle of curvature may pass through P 1 and this will be a boundary condition, that is before Q, P 1 will be inside the circle of curvature, while after Q, P 1 will be outside the circle of curvature, therefore points after Q on a 2 are rejected.

Algebraically, the tangent line of a 1 evaluated at a point of a 2 is a bivariate polynomial of total degree 4, 2 in each parameter. The circle of curvature of a 1 , evaluated at a point of a 2 is a bivariate polynomial of total degree 10, 6 in t 1 and 4 in t 2 . Fig. 3 (i) shows an instance of Fig. 2, case (iii), where a 1 is a convex arc and a 2 is a concave one. The graph of Fig. 3 (ii) shows a plot of the parametric bisector (solid line graph). The dashed line graph is a plot of the circle of curvature of a 1 evaluated at a point of a 2 . Note that the bisector critical points are separated by the graph of the circle of curvature, providing automatically a subdivision in monotone pieces. This is because at those critical points, the circle of curvature is also a maximal bitangent disk. Similar properties hold for all cases of Fig. 2. Location of the bisector extrema via the circle of curvature is more efficient, because purely algebraic techniques study the bisector curve itself via a discriminant, which has some spurious factors [START_REF] Busé | Explicit factors of some iterated resultants and discriminants[END_REF]. The reason is that the bisector is not an arbitrary curve but it is computed as some resultant of an algebraic system [START_REF] Elber | Bisector curves of planar rational curves[END_REF][START_REF] Emiris | Predicates for the exact Voronoi diagram of ellipses under the euclidean metric[END_REF][START_REF] Emiris | Exact Delaunay graph of smooth convex pseudocircles: general predicates, and implementation for ellipses[END_REF].

Critical points

Three-prong points (Fig. 4). A three-prong point on the medial axis is a point where the associated maximal disk is tangent to three points of the boundary of

P 1 P 2 a 1 a 2 Q a1 a2 P1 P2 Q (i) (ii) a2 a1 P2 P1 Q P 1 P 2 a 2 a 1 Q (iii) (iv)
Figure 3: (i) A convex and a concave arc with the circles of curvature corresponding to parametric bisector extrema. (ii) Parametric bisector and circle of curvature evaluated.

the shape. The points of tangency can be described by an algebraic system. The system can be formulated and solved in a way similar to [START_REF] Emiris | Exact Delaunay graph of smooth convex pseudocircles: general predicates, and implementation for ellipses[END_REF]. Terminal points. They are associated with the circle of curvature at points where the curvature attains a local maximum. These can be considered as degenerate cases of (iii), (iv) and (v) in Fig. 4.

Arc joints. These points are in fact artifacts, due to the fact that a single curve is considered as two or more subcurves. Thus, combinatorially, one has to take into account the MA points corresponding to the arc joints.

Let a 1 , a 2 , a 3 be three conic arcs on the boundary of the shape, with parameters t 1 , t 2 , t 3 respectively. We express a tritangent circle to a 1 , a 2 , a 3 by an algebraic system. Footpoint parameter value t 1 can be expressed as a resultant polynomial the degree of which is shown in table 1. The most difficult case is for three conic arcs, where the degree of the polynomial is 184, as in the case for the Voronoi diagram of ellipses [START_REF] Emiris | Predicates for the exact Voronoi diagram of ellipses under the euclidean metric[END_REF]. Table 1 also summarizes the simpler cases, when the second footpoint lies on the same arc, or when one footpoint corresponds to an arc endpoint and there-fore it is a fixed rational point. The equations used to describe each algebraic system are i) the normal lines N i at the footpoint of arc a i , ii) the segment bisector M ij which is perpendicular to the segment joining the footpoints of a i (or endpoint p i ) and a j (or p j ), iii) the bisector curve B ij of arcs a i and a j or the self-bisector curve B ii of arc a i .

Computing the footpoint as an algebraic number allows for detection of n-prong points, that is bifurcation points of degree ≥ 3, simply by comparing such algebraic numbers. For example, if there exist a maximal disk tangent to a 1 , a 2 , a 3 , a 4 then the footpoints of the tritangent disks of a 1 , a 2 , a 3 and a 1 , a 2 , a 4 on arc a 1 are identical.

Finally, the solution of the algebraic systems of table 1 can be accelerated by incorporating the subdivision technique of [START_REF] Emiris | Exact and efficient evaluation of the InCircle predicate for parametric ellipses and smooth convex objects[END_REF], because after applying lemmas 1 and 2, the bisectors are split in monotone parts.

t2 t3 deg. equations (i) a2 a3 184 N1 N2 N3 M12 M13 (ii) p2 a3 36 N1 N3 M12 M23 (iii) a1 a2 32 N1 N2 M12 B11 (iv) a2 a2 16 N1 N2 M12 M22 B22 (v) a1 p2 8 B12 B22 (vi) p2 p3 6 N1 M12 M13
Table 1: Degree of footpoints for 3-prong MA points (Fig. 4.)

Computing the medial axis

The MA is constructed in a way similar to [START_REF] Ramanathan | Constructing medial axis transform of planar domains with curved boundaries[END_REF]. Instead of tracing the MA via the boundary of the shape with a predefined precision, we check explicitly each critical point, expressed with an algebraic system, as discussed in the previous section. Thus, we trace the MA in a constant number of steps, depending only on the number of input arcs (and not on some precision threshold). We conclude with an example applying the above techniques. Consider the 9 control points P 0 . . . P 7 , P 8 ≡ P 0 with coordinates (1, 5), (-5, 3), (2, -1), (0, -1), (1, -6), (3, 0), (10, 0), [START_REF] Hyeong | Mathematical theory of medial axis transform[END_REF][START_REF] Hyeong | Mathematical theory of medial axis transform[END_REF], [START_REF] Blum | A Transformation for Extracting New Descriptors of Shape[END_REF][START_REF] Elber | Bisector curves of planar rational curves[END_REF] defining 4 arcs with shape factors 2/3, 1/4, 4/5, 3/5 respectively, where arc a i+1 has control points (P 2i , P 2i+1 , P 2i+2 ), i = 0 . . . 3, as shown in Fig. 5. We may start from a convex vertex (i.e., P 8 ) and trace the boundary of the shape, checking for critical points of the medial axis. This way the medial axis is traced edge by edge. Note that there exist two tritangent disks of a 1 ,a 3 ,a 4 . However, the dashed one is rejected, as its associated footpoint on a 4 lies after the footpoint of the other tritangent disk, as we move from P 8 to P 0 .

27th European Workshop on Computational Geometry, 2011

Figure 1 :

 1 Figure 1: Definition of a quadratic NURBS arc.

Figure 2 :

 2 Figure 2: Isolating the proper footpoint.

Figure 4 :Figure 5 :

 45 Figure 4: Various types of three-prong points P0


come

Comparing multisection and recursive bisection partitions in low-rank representations of BEM matrices from electromechanics

Comparing multisection and recursive bisection partitions in low-rank representations of BEM matrices from electromechanics

List of authors: C. Ashcraft 1 P. L'Eplattenier 2

A linear system from a boundary element formulation (BEM) generates dense matrices. However, they can often be permuted and transformed into a data efficient representation using domain decomposition.

We search for a partition of the degrees of freedom into subdomains. When we create a block matrix using this partition, an off-diagonal block, which represents coupling between two different domains, while dense, may have small numerical rank. The storage for the off-diagonal blocks can be greatly reduced. For some of our larger problems, we have notices storage reductions of 98% (using 1/50-th of the dense storage). We consider two types of domain decomposition.

1 LSTC, 7374 Las Positas Road, Livermore, CA 94550 USA, cleve@lstc.com 2 LSTC, 7374 Las Positas Road, Livermore, CA 94550 USA, pierre@lstc.com 1 1. A top-down, divide and conquer scheme we call recursive bisection. One looks at a submatrix, divides it into two parts, and recurses on each part if large enough.

2. A bottom-up, create all domains simultaneous scheme we call multisection. It is also known as a k-way method. The idea is to identify a set of center points. For each domain, we grow and adjust the vertices in a domain around its center point.

The two methods can give partitions with different properties that are visually apparent in Figure 1 for a triangulation of a unit disk.

• Domains in the MS partition seem more rounded than those in RBS.

• Interfaces between domains want to be smooth, but the RBS partition has smoothness at larger scales.

• With our implementations it is possible to finely balance the weights of the domains with RBS, but less so with MS.

• Consistently we see a sizeable difference in the number of interior boundary nodes (those adjacent to a vertex in a different domain). MS outperforms RBS with this metric.

The true judgment of a domain decomposition is how it works with an application. For example, if we were to consider a finite element formulation of the unit disk in Figure 1, we would have a sparse matrix. The number of interior boundary vertices is related to the amount of information communicated among the processors during a matrix-vector multiply.

A BEM matrix is dense, so large communication is expected. We want to reduce the storage for the matrix without sacrificing accuracy. Intuitively, we want subdomains to be compact, with a small aspect ratio. The MS partition appears to be better suited in this regard.

However, a low-rank approximation of a submatrix is best when the submatrix is square. In our context, this means the domains are equally sized. In this respect, RBS partition appears to be better.

In this talk we will provide results for BEM matrices from an electromechanics application from metal forming. We will explore the effects of the two partitions with respect to domain size and grid size.

Figure 1 :

 1 Figure 1: Multisection on (MS) left, recursive bisection (RBS) on right. Each has sixteen subdomains, MS has 425 vertices on interior boundary, RBS has 484.


List of authors:

J. Nagy 1

Imaging systems based on adaptive optics technology attempt to determine and remove phase errors in a measured wavefront. This process requires incorporating regularization, and solving an associated large scale least squares problem involving Kronecker products. Approaches to solve this problem typically use an iterative approach, such as LSQR.

In this talk we describe an efficient preconditioning scheme based on exploiting the Kronecker product structure. Numerical experiments show the effectiveness of the preconditioner.

1 Emory University. nagy@mathcs.emory.edu 1


Nico Schlömer

Wim Vanroose

Preconditioning the Jacobian system of the extreme type II Ginzburg Landau problem

Preconditioning the Jacobian system of the extreme type-II Ginzburg-Landau problem List of authors: N. Schlömer 1

W. Vanroose 2

This presentation considers the extreme type-II Ginzburg-Landau equations that model vortex patterns in superconductors. The nonlinear PDEs are solved using Newton's method where preconditioning the solution method of the Jacobian system is crucial for the performance of the solver. Some of the properties of the Jacobian operator will be highlighted, emphasizing on how it is possible to make use of them to construct a good preconditioner.

For a general superconductor, given an open, bounded domain Ω, the unknowns that need to be solved for are the complex-valued order parameter ψ ∈ H 2 C (Ω) as well as the vector-valued induced magnetic vector potential A ∈ H 2 R n (Ω). We will study extreme type-II superconductors for which magnetic vector potential A can be considered given. The approximation is valid, for example, for all all high-temperature superconductors.

With

X := ψ ∈ H 2 (Ω) : there is a defining sequence ψ k with lim k→∞ n • (-i∇ -A)ψ k = 0 on ∂Ω , Y := L 2 (Ω), the celebrated Ginzburg-Landau problem is to solve 0 = (-i∇ -A) 2 ψ -ψ 1 -|ψ| 2 on Ω (1)
for ψ ∈ X. Here, for any applied magnetic field H 0 the magnetic vector potential A = A(H 0 ) is given by the relations

   ∇ × (∇ × A) = 0, lim x →∞ ∇ × A = H 0 .
Every solution ψ directly corresponds to the physical observable of the density of electron (Cooper) pairs,

ρ C = |ψ| 2 .
The discretization of (1) needs to be constructed with care to preserve certain properties that are physically desirable. For example, there exists a variant of finite volume discretizations which is well-behaving in this sense [START_REF]Numerical approximations of the Ginzburg-Landau Models for Superconductivity[END_REF].

1 University of Antwerp The solution of the Ginzburg-Landau equations is numerically challenging first and foremost due to their nonlinearity which suggests Newton's method to be used for the approximation of solutions. A typical application of numerical calculations with the Ginzburg-Landau equations however would not only involve the solution of the equation for one particular domain and vector potential. It is rather more interesting to get a complete overview over the whole set of possible vortex configurations. An important tool for exploring the energy landscape is numerical continuation with, e.g., the strength of the applied magnetic field as continuation parameter. In this context, thousands of nonlinear systems will need to be solved subsequently.

That is why it is important to come up with efficient ways of solving the Newton system; the key to this of course lies in the solution of the linear Jacobian system that needs to performed in each Newton step.

The Jacobian operator of (1) is

J (ψ; A) : X → Y, J (ψ; A)ϕ := (-i∇ -A) 2 -1 + 2|ψ| 2 ϕ + ψ 2 ϕ. (2)
Note that J (ψ; A) is indeed linear when defined over X and Y as R-vector spaces.

Although this particular form of the operator sets it aside from the more common case of operators not acting on ϕ, this special structure does not have a large impact on iterative solution methods which merely assume a well-defined matrix-vector product. On the other hand, methods that make direct use of the entries of the discretized operator will require more effort to fit into the framework of operators like (2).

The Jacobian operator J has certain convenient properties such as the fact that

• For any given ψ ∈ Y , A ∈ H 2 R n (Ω), the Jacobian operator J (ψ; A) is self-adjoint with respect to the inner product •, • .

2 (Figure 1 :

 21 Figure 1: A solution ψ of the Ginzburg-Landau equation on a two-dimensional cut-circle domain with a magnetic field applied perpendicular to the sample. The typical vortices are exhibited around which the complex argument changes by multiples of 2π.

Note that •, • is in fact the natural inner product in the R-vector space Y . In any case, this makes sure that the spectrum of J is purely real. Another interesting thing to note about the spectrum is that

• Let ψ 0 be a solution of the Ginzburg-Landau equations with given A 0 . Then J (ψ 0 ; A 0 )(iψ 0 ) = 0, so for non-trivial solution states, J has a non-trivial kernel. This is direct consequence of the fact that (1) is invariant under the gauge transformation ψ = exp{iχ}ψ for any χ ∈ R.

Besides the fact that there is always a degenerate eigenvalue and that all eigenvalues are real, not much more can be said about the spectrum; in general, J (ψ) is indefinite. The definiteness depends entirely on the state ψ; if ψ is a solution to [START_REF]Numerical Bifurcation Study of Superconducting Patterns on a Square[END_REF], it in turn is said to be stable or unstable depending whether or not J (ψ) has positive eigenvalues.

The default solving methods for self-adjoint, indefinite linear systems include minres and symmlq, but also the cg method will converge after the negative eigenvalues have been deflated. Generic entry-based preconditioners like the diagonal part or ilu are not readily available but can be constructed to leverage the unusual structure of J . Equation-based preconditioners on the other hand can be derived as usual. Consider for example that • The kinetic energy operator

is self-adjoint with respect to the regular inner product •, • , positive semidefinite, and has an eigenvalue λ 0 = 0 if and only if A = 0. These nice properties help in coming up with an efficient solver for K. For example, linear systems with K could be solved with cg, preconditioned with, e.g., a multigrid strategy. Consequently, K -1 is an appropriate candidate for preconditioning J (ψ).

The talk will highlight more properties of K in conjunction with J , as well as compare its performance as a preconditioner with various other choices. Numerical results for finite volume discretizations of the operator for various domains in two and three dimensions will be presented.


Henner Jakob
email: henner.jakob@inria.fr

Charles Consel
email: charles.consel@inria.fr

Nicolas Loriant
email: nloriant@doc.ic.ac.uk

Architecturing Conflict Handling of Pervasive Computing Resources

Pervasive computing environments are created to support human activities in different domains (e.g., home automation and healthcare). To do so, applications orchestrate deployed services and devices. In a realistic setting, applications are bound to conflict in their usage of shared resources, e.g., controlling doors for security and fire evacuation purposes. These conflicts can have critical effects on the physical world, putting people and assets at risk. This paper presents a domain-specific approach to architecturing conflict handling of pervasive computing resources. This approach covers the software development lifecycle and consists of enriching the description of a pervasive computing system with declarations for resource handling. These declarations are used to automate conflict detection, manage the states of a pervasive computing system, and orchestrate resource accesses accordingly at runtime. In effect, our approach separates the application logic from resource conflict handling. Our approach has been implemented and validated on various building automation applications.

Introduction

The advances in telecommunication technologies and the proliferation of embedded networked devices are allowing the seamless integration of computing systems in our everyday lives. Nowadays, pervasive computing systems, as envisioned by Weiser [START_REF] Weiser | The computer for the twenty-first century[END_REF], are being deployed in an increasing number of areas, including building automation and assisted living.

Typically, a pervasive computing environment consists of multiple applications that gather data from sensing devices, compute decisions from sensed data, and carry out these decisions by orchestrating actuating devices. For example, in building automation, motion and temperature sensors are used to automate lighting and regulate heating.

The rapid development of new devices (i.e., resources), and development tools opened to third-parties, have paved the way to an increasing number of applications being deployed in pervasive computing environments. These applications access resources without any coordination between them because a pervasive computing platform needs to evolve as requirements change. In this situation, it is very common for a resource to be accessed by multiple applications, potentially leading to conflicts. For example, in a building management system, a security application that grants access inside the building can conflict with another application dealing with emergency situations like fires, preventing the building to be evacuated. In fact, conflicts do not only occur across applications but also within an application. For example, different modules of an application may be developed independently of each other, creating a risk that conflicting orders to be issued to devices. Detecting, resolving and preventing intra-and inter-application conflicts is critical to make a pervasive computing system reliable. To do so, a systematic and rigorous approach to handling conflicts throughout the development lifecycle is required.

Detecting conflicts is a daunting task. Pervasive computing systems are complex and involve numerous applications that may conflict on one or multiple resources. Scaling up conflict handling for real-size pervasive computing systems requires to distinguish potential conflicts from safe resource sharing. This may depend on the type of a resource, for example, a conflict may occur on a resource providing mutually exclusive operations (e.g., locking and unlocking a door). This may also depend on the applications being deployed in a pervasive computing environment (e.g., two applications may access a device inconsistently), precluding application developers from anticipating potential conflicts. Without any support, detecting potential conflicts requires to examine the code of all the applications to identify each resource usage, and determine whether it may conflict.

After potential conflicts are pinpointed, it is necessary to resolve each of them. It requires intimate knowledge about the code of the corresponding applications to resolve the conflicts by making code changes. Because of the lack of high-level programming support, writing system-wide conflict-handling strategies is often overlooked. This situation results in polluting the logic of applications with ad hoc code, compromising the system maintainability.

The situation is exacerbated by the fact that pervasive computing environments are prone to changes: applications as well as resources emerge, evolve, and may disappear over time. These changes directly impact conflict management. This problem is well known in the telecommunications domain where it was observed that the number of potential conflicts grows exponentially as new applications are added to an existing system [START_REF] Keck | The feature and service interaction problem in telecommunications systems: A survey[END_REF]. Manually handling conflict thus becomes impractical.

Our approach

Managing conflicts is often decomposed into three stages: detection, resolution and prevention [START_REF] Keck | The feature and service interaction problem in telecommunications systems: A survey[END_REF]. In practice, these stages crosscut the development lifecycle of applications and pervasive computing systems.

We introduce an approach to conflict management that covers the lifecycle of a pervasive computing system. It consists of a design method for applications, supported by declarations and tools, separating conflict management tasks. This approach facilitates the work of architects, developers and administrators: requirements for conflict management are propagated throughout the development stages.

We propose to declare a pervasive computing system and its applications using a domain-specific architecture description language (ADL), named DiaSpec [START_REF] Cassou | A generative programming approach to developing pervasive computing systems[END_REF], developed in our research group. This ADL serves two purposes: (1) it allows domain experts to describe the available resources in the pervasive computing environment, and (2) it is used by software architects to design applications with respect to the declared resources. We extended DiaSpec with conflict-handling declarations that allow domain experts to characterize resources from a conflict-management viewpoint. This information, in combination with the architecture descriptions, allows to automatically pinpoint places where conflicts can occur.

To resolve the detected conflicts, we propose to raise the level of abstraction beyond the code level, by providing declarative support for conflict resolution. Within an application, the developer uses declarations to specify states for a pervasive computing system and order them with respect to their critical nature (e.g., fire is more critical than intrusion). These states are enabled and disabled depending on runtime conditions over the pervasive computing system (e.g., fire detection). State changes are used to update access rights to conflict-sensitive resources (e.g., in case of fire, the fire module takes precedence over the intrusion module). Our approach is incremental in that states and priorities can be added as a pervasive computing system is enriched with new applications. Its declarative nature allows to prevent conflict-handling logic from polluting the application logic.

Conflict-extended architecture descriptions are used to generate customized programming frameworks. These frameworks guide and support the implementation of the conflict-handling logic. Generating the underlying framework from the architecture description guarantees that the architecture implementation can only access the required resources. Additionally, runtime support ensures that access to resources are granted in conformance with conflict-handling declarations.

Our contributions can be summarized as follows.

-Extended development cycle -We have identified the requirements at different development stages to detect, resolve, and prevent conflicts. We have seamlessly integrated conflict-management activities into a software development lifecycle. -Conflict-handling declarations -We have extended a domain-specific ADL to declare conflict resolution at an architectural level. A declarative approach is introduced to define the states of a pervasive computing system and their critical nature. Such declarations form the basis to define the conflict-handling logic of a pervasive computing system. -Programming support -Conflict-handling declarations are used to augment the generated programming framework with code dedicate to conflict handling. This code (1) guides the implementation of the conflict handling logic within and across applications, and (2) generates code that manages resource accesses to prevent runtime conflicts.

The rest of this paper is organized as follows. Section 2 identifies the key requirements to manage resource conflicts. Section 3 presents how to integrate conflict management into the development cycle. Section 4 outlines our implementation. Section 5 evaluates our approach. Related works are discussed in Section 6, and concluding remarks are given in Section 7.

Background and requirements

In this section, we first present a domain-specific architecture description language, named DiaSpec [START_REF] Cassou | A generative programming approach to developing pervasive computing systems[END_REF]. The underlying development process is illustrated with a working example of building management. Second, we examine the requirements for managing resource conflicts when developing pervasive computing applications.

Background

The DiaSpec language enforces an architectural pattern, named sense-compute-control, commonly used in the pervasive computing domain [START_REF] Dey | A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications[END_REF]. This pattern distinguishes three types of components, as depicted in Figure 1: (1) resources, which provide sensing and actuating capabilities on a pervasive computing environment3 , (2) contexts, which aggregate and process sensed data, and (3) controllers, which receive information from contexts and invoke actuators. This architectural pattern goes beyond the pervasive computing domain and enables high-level programming support and a range of verifications [START_REF] Cassou | Architecture-driven programming for sense/compute/control applications[END_REF][START_REF] Cassou | Leveraging software architectures to guide and verify the development of sense/compute/control applications[END_REF][START_REF] Gatti | A step-wise approach for integrating QoS throughout software development[END_REF]. (1) A domain expert declares a taxonomy of resources that can be found in the pervasive computing environment. (2) An architect describes the interactions between resources, contexts and controllers. Given a taxonomy and an architecture description, a compiler, named DiaGen, generates a customized programming framework in Java.

(3) The generated framework is used by the developer to implement the application. (4) The application code can be tested as is, prior to deployment, using a simulator for a pervasive computing environment, named DiaSim [START_REF] Bruneau | DiaSim, a parameterized simulator for pervasive computing applications[END_REF]. (5) A system administrator can deploy the application in a real pervasive computing environment. The suite of tools supporting our development process is called DiaSuite 4 .

We now focus on the first three steps of our development process with an application that treats different types of emergencies in a building. Describing the environment First, the domain expert declares the available resources of a pervasive computing environment, as is done using an interface description language (e.g., WSDL) to declare external resources. In DiaSpec, this process is supported by a language layer dedicated to describing classes of entities that are relevant to a given application area. An entity declaration models sensing capabilities that produce data, and actuating capabilities that provide actions. Specifically, a declaration includes a data source for each one of its sensing capabilities. An actuating capability corresponds to a set of method declarations. Additionally, attributes are included in an entity declaration to characterize properties about instances (e.g., their location). Entity declarations are organized hierarchically, allowing entity classes to inherit attributes, sources, and actions.

Figure 3 shows an excerpt of the taxonomy for the emergency application. Specifically, to detect a fire, the application uses temperature and smoke sensors deployed in the building. Upon fire detection, the doors are unlocked to ensure the safe evacuation of all the building occupants. Additionally the alarms of the building are turned on, as well as the sprinklers nearby the fire. All actions are logged for later analyses.

The domain expert introduces the resource classes with the device keyword. In Figure 3, a root device with a location attribute is declared (see lines 1 to 3). Attributes mainly serve as filters for resource discovery in the pervasive computing environment. The source and action keywords define the capabilities of a resource. For example, line 5 declares that the smoke sensor produces a float value, indicating the current smoke intensity. The Door device provides the LockUnlock action (line 12), which is further detailed in lines 22 to 25. Describing the architecture To support application design, the DiaSpec language offers an ADL layer, based on the architectural pattern depicted in Figure 1, and comprises resource, context and controller components.

To illustrate the ADL layer, let us examine the emergency application. Figure 4 presents an excerpt of the corresponding DiaSpec declarations, describing the fire module. Figure 5 shows a graphical view of the emergency application, including the intrusion module. The arrows indicate the flow of information. The resources at the bottom of the diagram provide information to context components; the resources at the top provide the controller components with actions on the environment.

The temperature sensors of a room send their values to the AvgTemp component. Figure 4, lines 1 through 4, introduces this component using the context keyword. It includes a source declaration, defining the input of this component. The as keyword, line 1, is followed by the type of the output value (Float). The value is indexed by a location: the room where the average temperature is measured. Another context component, SmokeDetected, gathers information from smoke detectors. Both contexts, the average temperature and the smoke information, are used by the Fire component to determine whether there is a fire in the building and its location. Eventually, if there is fire, the FireCtrl component is invoked. It is declared by the controller keyword (line 22). This component declares two input sources using the context keyword and referring to Fire and DoorStatus (lines 23 to 24). The action keyword defines the actuator operations that can be invoked by a controller component. In our example, the FireCtrl component can lock/unlock doors, turn on/off alarms and sprinklers, and log events (lines 25 to 27).

Implementing an application

The customized programming framework produced by DiaGen consists of an abstract class for each DiaSpec component (resource, context, and controller). The abstract class includes methods that implement the programming support (e.g., resource discovery and component communication mechanisms). The application logic to be provided by the developer is declared as abstract methods. Implementing the application logic is done by subclassing a generated abstract class.

Requirements

Let us now define our notion of resource conflict and examine the issues to be resolved within the DiaSpec development approach.

Intra-application resource conflicts Sensors and actuators need to be distinguished when it comes to resource conflicts. Indeed, sensors can sustain many consumers, requesting values either directly (e.g., remote procedure call) or via some runtime support (e.g., notification server). The situation would be comparable for actuators, if only they did not have side effects on the environment. This is illustrated in Figure 5, where the FireCtrl and IntrusionCtrl controllers share resources. These controllers can, for example, have conflicting effects on the door resource, depending on whether the current state of the pervasive computing environment requires anti-intrusion or firefighting measures.

What this example illustrates is that resolving resource conflicts relies on some notion of state that determines which consumer should acquire the resource. A pervasive computing environment can be in different states depending on a variety of conditions. Expressing these conditions is a key to providing a practical approach to conflict resolution. To separate this concern from the application logic, the approach should target the architecture level. In the door example, we would need to introduce states, enabled by conditions over relevant sensed data (e.g., smoke intensity, motion detection). Based on the enabled states, the attempts of the controllers to acquire the doors would be prioritized.

Note that some actuators can be insensitive to conflicts. An example is the log action (lines 26 to 28): it can record data in any order, assuming each invocation has the necessary contextual information (e.g., a time stamp).

Inter-application resource conflicts

The emergency application is only a part of the building management system. The system administrator also deploys a security application to manage access in the building. Figure 6 shows a graphical representation of two applications: emergency and security. Both applications operate the same type of resources, in this case door and logger.

As can be noted, resource conflicts occur at different levels and require to be managed globally. Even though, conflicting usage of resources can be resolved with respect to a given state, there needs to be a global, system-wide approach to combining unitary strategies in a transparent and predictable way.

Conflict management

This section presents our approach to conflict management. It addresses the requirements discussed previously, and illustrates the approach with the building management system.

Log

Detecting potential conflicts

Our approach to conflict management revolves around the DiaSpec description of an application. Such a description exposes the interactions with actuators, allowing resource conflicts to be detected within an application, for the application developer, and between applications, for the system administrator.

Let us examine how the intra-application conflicts between the fire and the intrusion modules are solved (Figure 6). The process is the same for inter-application conflicts.

In DiaSpec, conflicts may occur when a resource is used by more than one controller component. Information about the resource usage can be extracted from the DiaSpec description of an application. This information needs to be refined to account for actions that are insensitive to resource conflicts (e.g., the log action).

Categorizing actions in the taxonomy

We extended the taxonomy language of Dia-Spec with effect declarations for resource actions. An effect declaration applies to an action (i.e., an interface and its associated operations), which is part of a device declaration. In practice, we have identified three main effects that need to be expressed. First, a device includes an action with operations that are mutually exclusive in their effects. For example, a door is either locked or unlocked. Such an action is declared with the exclusive keyword. Second, a device combines operations that interfere with each other. For example, a multimedia device could include two actions: an audio player and a video player; if both players run simultaneously, they interfere with each other. The list of interfering actions of a device is declared with the interfering keyword 5 . Lastly, when an action is conflict insensitive, it is declared without effect keywords.

In our example, the domain expert has to enrich the declaration of the Door, Alarm and Sprinkler devices with the exclusive keyword, as is shown in Figure 7. The Log action is left unchanged because it is conflict insensitive. Analyzing the architecture description Given the taxonomy declarations enriched with conflict-handling information, the application developer and, later in the process the system administrator, investigate potential resource conflicts. A resource usage raises a potential conflict when two or more controllers may access it. These controllers may be defined within an application or across applications. In our approach, potential resource conflicts are automatically detected from a DiaSpec description. Conflict resolution is expressed with declarations, leaving the application logic unchanged.

Declaring conflict resolution

To resolve conflicts, we partition resource users with respect to a set of states in which a pervasive computing environment can be. These states are totally ordered with respect to their assigned priority level; they are associated with resource users (i.e., controller components). For example, our building can be in either of the following states, listed in order of increasing priority: normal, security, or emergency. In doing so, applications and controllers, within an application, can be assigned different states, resolving their access to conflicting resources.

To complete our approach, we need to enable and disable states depending on evolving conditions of the pervasive computing environment. This is done by introducing state component, leveraging the DiaSpec notion of context component. Recall that such a component receives information about the pervasive computing environment (e.g., smoke, fire, . . . ). A state component uses this information to determine whether the conditions for a given state hold, producing a boolean value. Let us illustrate our approach with inter-and intra-application conflict resolution. Consider Figure 8 where two state components are defined (lines 1 to 9): SecuritySt and EmergencySt. These components are declared with the system keyword to indicate that they apply system-wide, allowing the system administrator to resolve interapplication conflicts. With the priority keyword, they are assigned priority values of 5 and 10, respectively, indicating that SecuritySt is less critical than EmergencySt. Following the to keyword is the applications to which the declared state applies. The conditions under which a state holds are parameterized by information sources, as is declared for the SecuritySt state with the Calendar source. As well, the conditions may be parameterized by other states, as is defined by the EmergencySt state with FireASt and IntrusionASt. In fact, these two states are used to resolve intra-application conflicts, promoting state-component reuse -the states are defined in Figure 9 (lines 1 to 9).

Application state components are declared with the application keyword by the application developer and apply to controller components declared within an application. For example, the FireASt state applies to the FireCtrl and IntrusionASt to IntrusionCtrl. Both controllers, and associated states, are local to the Emergency application. This local nature also applies to the priority defined by application states. That is, these priorities resolve conflicts within an application. In our example, these declarations prioritize FireCtrl over IntrusionCtrl. In doing so, intra-application conflicts for resources, such as doors, can get resolved.

Implementing conflict resolution

Declarations of conflict handling are enforced by additional code produced by DiaGen, shielding the application developer and system administrator from low-level implementation details.

Let us illustrate the implementation of the conflict-handling logic by considering the declaration of the FireASt state in Figure 9. This state component relies on two information sources, temperature and smoke, to determine whether the building is on fire.

Figure 10 shows an implementation of this state component. In lines 7 and 8, the component subscribes to all the required sensors. To keep track of the building situation, the component stores temperature and smoke values from all the locations within the building. Specifically, the component implementation updates the value (temperature or smoke) for each location (lines 12 to 21). After refreshing the value, it checks whether the condition for a fire holds by calling the checkFire method (line 17). This method determines whether or not a fire is occurring by publishing a boolean value (line 35), which in turn will enable or disable the corresponding state of the pervasive computing system (i.e., FireASt).

Implementation

To achieve our conflict management approach, we have extended DiaSpec, DiaGen, and the DiaSpec runtime. The extended DiaSpec runtime is illustrated by our building 11. We introduce a ConflictCtrl component that subscribes to state components to gather information about states that get enabled/disabled at runtime. It combines this information with state priorities to compute access rights, and update the enforcer components, associated with each resource class (e.g., Door). The enforcer components intercept resource accesses and decide whether or not to grant them. Specifically, an enforcer component intercepts a method call and creates a request of the form (controller, action, resource). Such a request is matched against an access control list (ACL) attached to each resource class; this ACL comprises rules of the following form. When the request matches an ACL entry, the access to the resource is granted depending on the boolean value of the corresponding rule.

Globally, the conflict management process is performed in two stages. Statically, potential conflicts are detected based on the taxonomy and architecture declarations. For each detected conflict on a resource, the DiaSpec description is searched to identify state components dedicated to resolving it. This information is used to parameterize the ConflictCtrl component. Dynamically, this component will update the ACL of the enforcer component of all the resources impacted by a state change. The updated ACL is calculated based on the enabled/disabled states and their priorities. To assess the usability of our approach, we applied it to the building management system. This case study was particularly interesting because it had been specified in DiaSpec and implemented, prior to the development of our approach. As a result, it could serve as a reference implementation, and a basis to be extended with our conflicthandling approach. We focus on the comprehensibility and reusability of conflict managing code, and the ability to detect conflicts. To test the correct behaviour of both implementations, original and extended, we used our pervasive computing simulator, DiaSim [START_REF] Bruneau | DiaSim, a parameterized simulator for pervasive computing applications[END_REF]. The original building management system was developed by members of our group who have expert knowledge in DiaSpec. They acted as architect, developer, administrator, and used their expertise to solve the foreseeable conflicts. The lack of proper support made them resort to ad hoc strategies to resolve resource conflicts. For example, to prevent three different controllers to conflict in accessing doors, they had to introduce a dedicated action to the door resource for each kind of controller in the taxonomy. This action would essentially mimic our conflict resolution strategy, taking a state as a parameter and determining whether to grant access to the door. In contrast to our approach, this ad hoc technique requires to structure the taxonomy with respect to conflict handling concerns and to pollute the application code with conflict handling logic.

With our approach, adding a new application to an existing system requires to declare and implement an additional system state component, if a new state is needed. In this case, the new system state component is independent from other components, besides the new priority level to be introduced.

Related Work

Conflicts are a major problem in a variety of domains. For example in telecommunications, Keck and Kühn show that feature interaction is an exponential problem that appears when new services are added to an existing system [START_REF] Keck | The feature and service interaction problem in telecommunications systems: A survey[END_REF]. This problem can be directly mapped to pervasive computing, their services and features are our applications and their actions on resources. Calder and Miller [START_REF] Calder | Feature interaction detection by pairwise analysis of LTL properties -a case study[END_REF] use the Spin model checker to analyze telecommunication systems. To do so, a system (services and features) is modeled in Promela using temporal properties. Our approach circumvents the feature interaction problem by relying on existing system specifications and conflict-handling declarations provided by the domain expert and the application developer.

There exist different strategies to resolve conflicts in pervasive computing environments. The idea of proactively changing access control on resources is also used by Gupta et al. [START_REF] Gupta | Criticality aware access control model for pervasive applications[END_REF]. They present a criticality-aware access control approach that is only studied as a conceptual model. In contrast, we cover conflict management throughout the development lifecycle: from design to programming, to runtime.

Haya et al. assign a priority to every operation [START_REF] Haya | A mechanism for solving conflicts in ambient intelligent environments[END_REF]. The priority is calculated by a central component using information about the current state, the caller and the type of operation. In comparison, our approach incurs little overhead for resource invocations because the enforcer component is coupled with the resource, preventing any central component from becoming a bottleneck.

The work closest to ours is that of Retkowitz and Kulle [START_REF] Retkowitz | Dependency management in smart homes[END_REF]. They use the notion of dependency management for handling resource conflicts. It is exemplified in the context of smart homes where it allows fine-grained configuration of a conflict-aware middleware. It is designed so a user can interact with the system and set priorities for different applications. In comparison, our approach is not limited to the home automation domain and addresses conflict handling throughout the development lifecycle.

Tuttlies et al. have a different approach to resolving conflicts. They propose to describe the side effects of an application on the physical environment [START_REF] Tuttlies | Comity -conflict avoidance in pervasive computing environments[END_REF]. Additionally, each application states, what it considers a conflict. As a result, they can detect conflicts between interfering applications. Devising and applying a suitable strategy is left to the application developer. In contrast, we aim for a system-wide conflict management to allow system-wide reasoning.

Conclusion

In this paper we have presented a domain-specific approach to architecturing conflict handling of resources. This approach covers the development lifecycle of a pervasive computing system. Our approach includes a detection of potential conflicts, their resolution, and their prevention at runtime. We extended an ADL to add information that is required for these three stages of conflict management. This information is used to generate code that guides and supports the implementation of conflict management.

We have introduced new tasks dedicated to conflict management in the development process of a pervasive computing system. In the resulting process, application and conflict handling code are cleanly separated. Furthermore, our approach to conflict management is incremental and modular, preserving the independence between applications. This facilitates reuse of applications, and makes the conflict management easier to understand and verify.

To prevent conflicts, our implementation enforces an ACL for each pervasive computing resource. These ACLs are proactively updated based on the current system state.

Currently, our approach treats conflicts for classes of resources. This strategy applies to situations where applications act on all instances of a class (e.g., the emergency application unlocks all doors). We plan to extend this approach by introducing a perimeter (e.g., a room, a floor) in the conflict management declaration of an application.

We also plan to expand our model to include the access rights for users. Access control is a major problem in pervasive computing environments, since it must handle physical and virtual objects at the same time [START_REF] Sampemane | Access Control For Active Spaces[END_REF][START_REF] Tolone | Access control in collaborative systems[END_REF]. A related research direction is to integrate user preferences into our model to resolve certain types of conflicts, as proposed by Shin et al. [START_REF] Shin | Mixed-initiative conflict resolution for context-aware applications[END_REF].

Fig. 1 .Fig. 2 .

 12 Fig. 1. DiaSpec architectural pattern

Fig. 3 . 1 context AvgTemp as Float 2 indexed by location as Location { 3 source temperature from TempSensor ; 4 } 5 6 context SmokeDetected as Boolean 7 indexed by location as Location { 8 source smoke from SmokeSensor ; 9 } 10 11 contextaction}Fig. 4 .

 312345678910114 Fig. 3. Extract of the emergency management taxonomy

Fig. 6 .

 6 Fig. 6. Potential resource conflicts between multiple controller components

1 device 2 source status as LockedStatus ; 3 exclusive action LockUnlock ; 4 } 5 device 6 exclusive action OnOff; 7 } 8 device 9 exclusive action OnOff; 10 }Fig. 7 .

 123456789107 Fig. 7. The taxonomy contains three devices with exclusive actions

Fig. 8 . 1 application state FireASt 2 priority 15 to FireCtrl { 3 source temperature from TempSensor ; 4 source smoke from SmokeSensor ; 5 } 6 application state IntrusionASt 7 priority 10 to IntrusionCtrl { 8 context Intrusion ; 9 }Fig. 9 .

 81234567899 Fig. 8. System state-component declarations (inter-application conflicts)

1 public class FireASt extends AbstractFireASt { 2 3 private 5 13 (Fig. 10 .

 1351310 Fig. 10. An implementation of the FireASt state component

(

  controller , action , resource , [true|false ])

Fig. 11 .

 11 Fig. 11. Extended DiaSpec runtime system

Resources are devices (e.g., a motion detector) or software components (e.g., an address book).

DiaSuite is freely available http://diasuite.inria.fr and open source.

Interfering actions do not occur in our building management example.


W Vanroose

Multigrid preconditioners based on polynomial smoothers for the Helmholtz equation with absorbing layers

B. Reps 2

H. bin Zubair 3

This contribution is focused on the numerical solution of the indefinite Helmholtz equation

Hu ≡ -(∆ + k 2 (x, y))u = f in Ω (1)
with a space a space dependent wave number k and exterior complex stretching as absorbing boundary conditions. The solution method is based on a preconditioned Krylov subspace, however, the preconditioner operator is the Helmholtz equation discretized on a grid with a complex grid distance, which is approximately inverted with one multigrid cycle.

The failure of multigrid on the Helmholtz problem have been widely documented and is caused by the indefinite spectrum of the operator H. Discretized on a grid with grid distance h, the negative Laplacian, -∆, leads to a spectrum that is spread between 0 and O(1/h 2 ) on the real axis. However, the wave number will shift this spectrum in the negative direction. This leads to an indefinite matrix for wave numbers k larger than a certain threshold. This means that the spectrum is spread over both the positive real part as the negative real part of the complex plane, not necessarily excluding zero as an eigenvalue. Realistic problems have absorbing boundary conditions, that move the eigenvalues slightly below the real axis.

Two difficulties emerge when multigrid is applied. First, typical smoothers like weighted Jacobi or Gauss-Seidel become unstable for indefinite problems. However, the unstable modes are the smoothest modes and should be stabilized by the coarse grid correction, for problems that are slightly indefinite. The second problem is the appearance of diverging coarse grid corrections for certain wave numbers. This has been analyzed in detail by [START_REF] Elman | A multigrid method enhanced by Krylov subspace iteration for discrete Helmholtz equations[END_REF]. The peaks in the convergence plots can be interpreted as resonances.

These difficulties are avoided when multigrid is applied to a complex shifted Laplacian [START_REF] Erlangga | A novel multigrid based preconditioner for heterogeneous Helmholtz problems[END_REF][START_REF] Ya Erlangga | On a class of preconditioners for solving the Helmholtz equation[END_REF]. Then the wave number is complex valued which cannot cause resonances in the coarse grid correction. In [START_REF] Reps | On the indefinite Helmholtz equation: Complex stretched absorbing boundary layers, iterative analysis, and preconditioning[END_REF], we show that the complex shifting is equivalent with discretizing the Laplacian with a complex valued grid distance.

It is important to stress that introducing the complex shift suppresses and broadens the resonances during the coarse grid correction, but it leaves the possibility that the smoother is unstable. In this contribution we report on our analysis of replacing the standard smoother such as weighted Jacobi or Gauss-Seidel with a polynomial smoother.

In particular we have analysed the performance of polynomial smoothers [5] on Helmholtz problems discretized with finite difference and an exterior complex scaling as an absorbing boundary conditions. The spectrum of the operator is bounded by a triangle [START_REF] Reps | On the indefinite Helmholtz equation: Complex stretched absorbing boundary layers, iterative analysis, and preconditioning[END_REF] where the first corner lies in -k 2 and the second in -k 2 + 4/h 2 and a third corner lies in down in the complex plane. This triangle lies entirely in the lower half of the complex plane. The eigenvalues of the smooth modes lie near -k 2 , in the other corners the modes are rapidly oscillating.

V(1,0) -average V(1,0) -first V(1,1) -average V(1,1) -first V(2,1) -average V(2,1) -first
f (t) = (1 -ω 1 t)(1 -ω 2 t)(1 -ω 3 t), (2)
where the weights are choosen such that the error iteration, e (k+1) = f (A)e (k) , fits the following requirements. It satisfies the fixed point property since f (0) = 1. The smoothest modes near -k 2 are mapped close to the unit cirlcle since f is such that f (-k 2 ) = e ıϕ with ϕ ∈ [0, 2π[. The two other corners are mapped to zero such that the oscillatory modes are smoothed. In [5] we show that the coefficients ω 1 , ω 2 en ω 3 can be choosen such that the f is stable and behaves as a smoother given certain conditions on the complex grid of the preconditioner operator.

In practice, however, this hand tuned particular polynomial can be replaced by GMRES(3), which optimizes the coefficients ω i each iteration. Since the particular polynomial provides a upper bound the GMRES(3) convergence, the GMRES(3) smoother inherits all the properties from the hand tuned polynomials. Note that since we use a complex grid, we only need a restart of three, while [START_REF] Elman | A multigrid method enhanced by Krylov subspace iteration for discrete Helmholtz equations[END_REF] requires a complicated smoothing strategy.

We have extensively tested this solution strategy. In fig 1 we show the multigrid convergence of the preconditioning problem. Note that this is Helmholtz problem discretized with a complex valued grid distance as in [START_REF] Reps | On the indefinite Helmholtz equation: Complex stretched absorbing boundary layers, iterative analysis, and preconditioning[END_REF]. The convergence rate is independent of the wave numbers and we show results V(1,0), V(1,1) and V(2,1) cycli. The results show both the reduction in the first iteration and the average convergence rate. However, the number of Krylov iteration depends linearly on the wave number k, as shown in figure 2

Figure 1 :

 1 Figure 1: The measured convergence rate of different V-cycles applied to the preconditioner.

Figure 2 :

 2 Figure 2: Left: the number of FGMRES and Bi-CGSTAB iterations as a function of the wave number k for the homogeneous Helmholtz problems. Right: the CPU time of FGMRES and Bi-CGSTAB as a function of the wave number k for the homogeneous Helmholtz problems.

University of Antwerp, Dept. Mathematics and Computer Science, Middelheimlaan 1,

Antwerpen, Belgium 2 University of Antwerp, Dept. Mathematics and Computer Science, Middelheimlaan 1, 2020 Antwerpen, Belgium 3 Institute of Business Administration, Department of Mathematical Sciences (FCS), University Rd., 75270 Karachi, Pakistan


J Gaidamour

J Hu

C Siefert

R Tuminaro

Algebraic Multigrid using Energy-Minimization: a general framework to develop intergrid transfer operator

The repeated solution of sparse linear systems is often a key computational bottleneck for large-scale computer simulations and development of highly scalable preconditioner must be addressed on the path of exascale computing. With this aim in view, we focus on multigrid methods which are among the most scalable algorithms in solving linear systems arising from the discretization of partial differential equations (PDEs). The basic idea of multigrid methods is to use coarse grid correction to handle the error which have not been eliminated by the smoothing process. Algebraic multigrid (AMG) methods construct their hierarchy of coarse systems directly from the initial matrix. The key to designing an effective AMG algorithm is to construct coarse grids and intergrid operators to obtain a good characterization in the coarse levels of error not eliminated by the smoother on the finest level. Our main intention is to extend the applicability of AMG methods to challenging problems like systems of PDEs by defining a general framework for the generation of intergrid transfer operator.

In [START_REF] Vaněk | Algebraic multigrid based on smoothed aggregation for second and fourth order problems[END_REF], the authors propose a set of objectives to obtain an efficient prolongation operation motivated by both the convergence theory and their practical experience. They also present the Smoothed Aggregation (SA) method as an attempts to satisfy this requirements. In SA, the knowledge of near-kernel components are explicitly used to define an intergrid operator which allows an accurate representation of this specific modes on the coarser grid and the smoothing of the prolongator aims to reduce its energy. SA AMG has been applied successfully in many application domains. However, the cost to apply SA can grow unacceptably for systems of PDEs and for large number of near-kernel components. This issue becomes more pronounced for stretched meshes, large material variation, and higher dimensionality.

Considering the same set of objectives, we have developed algorithms for generating AMG grid transfers based on a more general interpolation strategy. In our energy-minimization algorithm, each column of the grid transfer operator P is minimized in an energy-based norm while enforcing two types of constraints: a defined sparsity pattern and preservation of specified modes in the range of P . The resulting constrained optimization problem can be solved by using Krylov based methods. While related to the method proposed in [START_REF] Mandel | Energy optimization of algebraic multigrid bases[END_REF], our algorithm pays close attention to the compression of near-kernel information in order to maintain low preconditioner cost. One of the main advantages of the approach is that it is flexible, allowing for arbitrary coarsenings, unrestricted sparsity patterns, straightforward long distance interpolation, and general use of constraints, either user-defined or auto-generated.

1

  Sandia National Laboratories 2 Sandia National Laboratories 3 Sandia National Laboratories 4 Sandia National Laboratories

1

I will present a use case of the energy minimization algorithm on 3D linear elasticity. For this specific problem, we take advantage of the flexibility of energy-minimization algorithm to compress the information given by the near-kernel components and reduce the number of degree of freedom on coarse grids.

The algorithms presented here will be at the heart of the next multigrid solver of the Trilinos project [3,4]. As future application will require increasingly complex and finely tuned preconditioning methods, I will discuss some aspects of the code design, which was carefully created to maximize the new algorithm's flexibility.


Charles Consel
email: charles.consel@inria.fr

DiaSuite: A Paradigm-Oriented Software Development Approach

Keywords: D.2.11 [Software Engineering]: Software Architectures-Domain-specific architectures, Languages, Patterns; D.3.4 [Programming Languages]: Processors General Terms Design, Language Declarative Languages, Programming Support, Program Analysis, Program Generation

We present a software development approach, whose underlying paradigm goes beyond programming. This approach offers a language-based design framework, high-level programming support, a range of verifications, and an abstraction layer over lowlevel technologies. Our approach is instantiated with the Sense-Compute-Control paradigm, and uniformly integrated into a suite of declarative languages and tools.

Introduction

A software development process inherently relies on some form of development paradigm to help structure, program and compose the building blocks of a software system. A development paradigm is most commonly concretized in the form of a programming language (e.g., functional or object-oriented), associated with a range of techniques and tools to facilitate programming (e.g., editing, verification, and debugging). However, a development paradigm involves multiple dimensions, besides programming, whose integration incurs both a conceptual and programming overhead. Further downstream from programming are dimensions such as middleware, which may impose a specific control flow on the program, as is done by event-based middlewares. Further upstream from programming are architectural styles and patterns [START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF] that guide the decomposition of a software system into components and define their interactions.

Interestingly, the partial evaluation community has been contributing to this multi-dimension approach by promoting the interpreter style [START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF] and introducing related techniques and tools. In the interpreter style, a program must implement a processing driven by the interpretation of a key input argument, whose binding time is assumed early. The structure of the resulting program allows a static analysis phase to determine binding-time invariants. These invariants are used by a transformation phase to specialize

Copyright is held by the author/owner(s). PEPM'11, January 24-25, 2011, Austin, Texas, USA. ACM 978-1-4503-0485-6/11/01. the program, given a value for the key input argument. The static analysis and the transformation phase form the partial evaluation process [START_REF] Consel | Tutorial Notes on Partial Evaluation[END_REF]. This process is most commonly used as an optimization strategy dedicated to removing the interpretation layer. The interpreter paradigm, coupled with partial evaluation, has been successfully applied to a wide range of areas, besides programming language implementations, including string matching [START_REF] Amtoft | The Abstraction and Instantiation of String-Matching Programs[END_REF], networking [START_REF] Bhatia | Automatic Specialization of Protocol Stacks in OS kernels[END_REF] and operating systems [START_REF] Mcnamee | Specialization Tools and Techniques for Systematic Optimization of System Software[END_REF]. Although limited in the dimensions covered, this form of a paradigm-oriented software development approach has demonstrated its effectiveness for optimization purposes.

Realizing that the scope of development paradigm goes beyond programming is a key to improve the software production process, and it suggests to integrate the multiple dimensions of software development into a uniform approach.

This talk. We report on research results showing that a paradigmoriented approach covers many more dimensions than program optimization. We introduce a paradigm-oriented development approach that offers a language-based design framework, high-level programming support, a range of verifications, and an abstraction layer over underlying technologies, going beyond a contemplative approach. We have developed a paradigm inspired by the Sense-Compute-Control (SCC) architecture pattern [START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF]; it is realized by a suite of languages and tools, named DiaSuite [START_REF] Cassou | A Generative Programming Approach to Developing Pervasive Computing Systems[END_REF].

Our Approach

In our approach, an SCC software system gathers data about an environment via sensors (whether hardware or software). Sensed data are used by context components to compute refined, applicationspecific values. These values are then provided to control components; they define the control logic aimed to issue orders to the actuators, impacting the environment. The architecture of an SCC software system is depicted in Figure 1.

The SCC paradigm has a wide spectrum of applicability; we have used it successfully in the domains of home/building automation, multimedia, avionics and networking.

Let us now examine how this paradigm guides the design of a software system, provides dedicated programming support, and enables verifications.

Software design. Our SCC-oriented development approach relies on an SCC-specific description language. This language provides syntax and semantics to define a conceptual framework, and is supported by processing tools.

Specifically, our approach revolves around a description language, named DiaSpec, dedicated to describing an SCC software system. To do so, DiaSpec consists of two language layers: (1) one layer is for declaring a software system at the functional level, decomposing it into context and control components, and defining how these components are connected to each other; (2) another layer is for declaring the sensors and actuators to be used by the SCC software system.

Programming support. A DiaSpec description is processed to generate a customized programming framework. This framework provides high-level support to implement sensors, actuators, and components, abstracting away from the underlying technologies (e.g., hardware, networking and middleware). Furthermore, the generated programming support guides and constrains programming, leveraging the underlying programming language. For example, DiaSuite generates an abstract class for each DiaSpec declaration. An abstract class implements methods, hiding low-level mechanisms such as communications, and declares abstract methods, delimiting where the application logic is to be introduced.

Verification. At declaration time, a DiaSpec description is verified independently of an implementation for consistency properties. For example, every component, sensor and actuator must be connected. At development time, a DiaSpec description is used to reason about an implementation to check its conformance. For example, a component implementation only communicates directly with another component if they are connected in the DiaSpec description. In doing so, we ensure the communication integrity property [START_REF] Moriconi | Correct Architecture Refinement[END_REF]. At runtime, the generated programming framework includes code to preserve this conformance. For example, if a class of sensors has no running instance, an error can be raised and a repair strategy performed.

Non-Functional Properties

Beyond offering a conceptual framework, our language-based approach provides an ideal setting to address non-functional properties (i.e., performance, reliability, security. . . ). A description language can be extended with non-functional declarations, expanding further the type of conformance that can be checked between the description of a software system and its implementation, and enabling additional programming support and guidance.

We have investigated this idea by extending DiaSpec with nonfunctional declarations to address error handling [START_REF] Mercadal | A Domain-Specific Approach to Architecturing Error Handling in Pervasive Computing[END_REF], component flow behavior [START_REF] Cassou | Leveraging Architectures to Guide and Verify Development of Sense/Compute/Control Applications[END_REF], and quality of service constraints [START_REF] Gatti | A Step-wise Approach for Integrating QoS throughout Software Development[END_REF].

Following our approach to paradigm-oriented software development, non-functional declarations are verified at declaration time, they generate support that guides and constrains programming, they produce a runtime system that preserves invariants.

Let us instantiate our approach with error handling [START_REF] Mercadal | A Domain-Specific Approach to Architecturing Error Handling in Pervasive Computing[END_REF].

Software design. First, declarations are introduced to provide a conceptual framework to express how errors should be treated. Specifically, declarations specify what errors are raised by sensors and actuators, and what types of treatment are provided by context and control components. For example, a declaration may require a component to fully handle sensor-related errors, shielding client components from these concerns.

Programming support. A DiaSpec description, extended with error-handling declarations, is used to generate a programming framework that guides and supports the implementation of error handling, besides the application logic. In doing so, the paradigmoriented development makes the programming of error handling more rigorous and systematic.

Verification. Verification at declaration time aims to ensure that components define appropriate treatment types along the flow of errors. Conformance of the component implementation with respect to error-handling declarations is checked statically.

Conclusion

Our initial work on the paradigm-oriented software development approach suggests a number of future research directions. It would be insightful to go beyond the SCC paradigm. What other style could cover a range of application domains and give rise to a dedicated description language, and dedicated framework generation and verification phases? Another direction is to explore other nonfunctional properties of a software system, such as security and performance.

Figure 1 .

 1 Figure 1. The architecture of an SCC software system

Acknowledgements

The author is indebted to the members of the Phoenix Group, who contributed to the research results that enabled this work. Special thanks to Emilie Balland for insightful discussions and helpful comments.