Francesco Cangemi
email: francesco.cangemi@lpl-aix.fr

PHONETIC DETAIL IN INTONATION CONTOUR DYNAMICS

The Autosegmental-Metrical theory of intonation investigates the relationship between f0 contours and post-lexical meaning. Phonetic data are represented in the phonology as a sequence of discrete, local events. The properties of the transitions between one event and the next are considered to be phonologically irrelevant ( §1).

We present data on Neapolitan Italian which show a significant correlation between the shape of these transitions and the pragmatic context in which a sentence is uttered. This correlation is stronger than the one displayed by traditional autosegmental-metrical indices ( §2 and §3).

In the conclusions, we discuss the usefulness of our findings as a step towards the finetuning of the autosegmental-metrical theory ( §4).

INTRODUCTION

Intonational phonology aims at describing how phonetic suprasegmental features convey post-lexical meaning in a linguistically structured way (see [START_REF] Ladd | Intonational Phonology[END_REF] for an introduction). For instance, vocal fold vibration rate data (f0) are used to describe acoustic differences of the same utterance in different pragmatic contexts, as in the opposition between assertive and questioning modality.

In the frame of the autosegmental-metrical theory of intonation (AM), phonetic (continuous) f0 data are translated into a phonological (discrete) inventory of tunes, composed by combining only two tones, high (H) and low (L). Intonation contours consist of a string of tonal events, linked to the prosodic structure of the sentence. Some tonal events, mainly the pitch accents (i.e. those associated to prominent syllables), can phonetically appear as a rise (or a fall) in the f0 curve. In these cases, they are analyzed as the succession of two tones (L H for rises, H L for falls) 1 .

In AM, the f0 path between the two tones which compose a rising pitch accent is not regarded as phonologically relevant. Speech synthesis systems based on this framework (e.g. [START_REF] Pierrehumbert | The phonology and phonetics of English intonation, PhD Disseration, Massachussets Intitute of Technology[END_REF], Anderson et alii, 1984[START_REF] Black | Generating F0 contours from ToBI labels using linear regression[END_REF] use a simple monotonic interpolation between the two tones. Nonetheless, data from Neapolitan Italian (NI, D'Imperio et alii 2008) show that, in different pragmatic contexts, the intonation contour of the same segmental string also differs systematically in terms of the f0 path between the two tones. The curve seems to follow a concave or convex 2 path, depending on the pragmatic context in which the sentences are uttered (see Figure 1). Figures 2 and3 display the spectrogram and the f0 contour for the sentence Milena lo vuole amaro 'Milena drinks her coffee unsweetened'. In the first case, the sentence is uttered as a statement, while in the second it is uttered as a question. The most striking difference between the two f0 contours is visible in the movement associated to the last stressed syllable of the sentence ("aMAro", highlighted by the box in both figures). In Fig. 2 we find a gradual fall, while in Fig. 3 we find a slight rise followed by a quite rapid fall. In other words, the f0 peak (H in the figures) occurs slightly before the vowel onset in the sentence, but is found later (vowel-internal) in the question, where is also visibly higher. Following the usual terminology, the H belonging to the last pitch accent is aligned (in time) and scaled (in frequency) differently in the two contexts.

Tone alignment and scaling are the indices usually employed in AM to define the phonetic properties of different phonological entities (e.g., of different pitch accents). But if we concentrate on the intonation contour of the first word in the sentence (Milena, isolated from the rest of the utterance by the vertical line in Figures 2 and3), we notice that the rising movement associated with the stressed syllable has a different shape in the two contexts. This difference, though, does not seem to be related either to the alignment or to the scaling of the two tones: both Ls are in the first half of the stressed syllable onset, and around 225Hz; both Hs are at the end of the stressed syllable nucleus, and around 350Hz.

This work aims to investigate some acoustic differences considered in the AM framework as phonetic detail without phonological relevance, such as dynamic (i.e. in shape) differences. Their efficacy as indices to differentiate pragmatic contexts will be compared to that of traditional cues such as the alignment and scaling of the tones which compose the first nuclear accent of our sentences3 . In the conclusions we will discuss the implications of our results with respect to a fine-tuning of the existing phonological model.

MATERIALS AND METHOD

Corpus

For our study we used a subset of the corpus described in (D'Imperio et alii, 2008). Three native speakers of Neapolitan Italian read 30 experimental stimuli and 70 fillers in a silent room. The stimuli consisted of five repetitions of three sentences designed without voiceless plosives, which were semantically plausible and syntactically quite similar: "Amelia dorme da nonna" (Amelia sleeps at grandma's), "Valeria viene alle nove" (Valeria arrives at 9) and "Milena lo vuole amaro". The target words were all feminine proper names, agents, subjects, trisillabic, and paroxitones, with the same syllabic structure (CV) for the tonic syllable and the same quality for its nucleus (/ɛ/). The sentences were presented together with a context paragraph, which had to be read silently; this made possible the elicitation of every sentence with two different pragmatic meanings. For example, the sentence "Milena wants her coffee unsweetened" would be interpreted (and uttered) by speakers as a Narrow Focus Question (QNF, meaning "Is it Milena, the one who drinks unsweetened coffee?", see Figure 3, ) if preceded by the context:

After a family lunch, you're preparing coffee. You know that one of your cousins is on a diet and stays away from sugar, but you don't remember which one. You ask your aunt:...

On the other hand, sentences preceded by the context:

In the afternoon, among friends, your brother is preparing coffee. He asks you whether your friends would like it sweetened or not. You don't know everybody's preferences, but only your girlfriend's. You answer:... would be interpreted (and uttered) as Partial Topic4 Statements (SPT, meaning "As for Milena, she drinks it unsweetened; as for the others, I couldn't tell", see Figure 2, ).

The experimental material consisted of 3 subjects x 3 sentences x 2 pragmatic contexts x 5 repetitions = 90 items in total.

Measures

Target words were manually labelled in syllables using PRAAT [START_REF] Boersma | Praat: doing phonetics by computer[END_REF]. The stressed syllable, which always had a CV structure, was also labelled in segments: the labels were Os for the beginning of the onset (and of the entire syllable), Ns for the beginning of the nucleus (or the end of the onset) and Ne for the end of the nucleus (and of the entire syllable) 5 .

The rising f0 movement in the stressed syllable was characterized by measuring the height (in Hz) and the position in time of its starting and ending points (L and H)6 . Hs were located at f0 maxima inside the stressed vowels, while the detection of Ls proved more challenging. A widely used automatic procedure is based on the detection of the local minima in the stressed syllable's onset, but we found this method too sensitive to microprosodic perturbations, which were irrelevant for our analysis. We determined that another strategy for the detection of Ls, the two lines fitting used for example in [START_REF] D'imperio | The role of perception in defining tonal targets and their alignment[END_REF], was not suited for our goals. With this technique, the region in which the L must be found (in our case, the f0 stretch from utterance start to H) is divided into steps. For each point, two straight lines are fitted with a linear regression to the contour on its left and on its right. The L is chosen as the point associated with the pair of lines leading to the smallest modelling error. Since the differences between a concave and a convex rise have consequences on modelling and errors, the algorithm often locates Ls away from the elbow, the point in which the f0 curve visibly bends upwards. Concave shapes tend to be associated to an L on the left of the real elbow, and for convex ones the L is detected on its right. This means of course that we would still have an index to express our differences in interpolation, but in this case the information is conveyed in an implicit and indirect way: different shapes are translated into different position of a same tonal target.

We decided to use a method which would ignore the specifically local features of the f0 contour (such as microprosodic minima) and at the same time avoid the implicit encoding of the global proprieties we were trying to characterize explicitly (as in the case of the two lines regression). Trying to find a compromise between these two constraints, we decided to locate the elbows at the point of maximal acceleration of the curve. Through the elaboration of an automated procedure in R (R Development Core Team, 2005), the L was located by inspecting the f0 second derivative, looking for sufficiently wide local maxima.

Although the L detection procedure is innovative, height and position of tone targets remain traditional measures. Besides these, we also calculated the height of the mid-point in time between L and H (C)7 . This allowed us to calculate an index (based on [START_REF] Dombrowski | Acoustic patterns and communicative functions of phrase-final F0 rises in German: activating and restricting contours[END_REF] which could express the type of interpolation between the two targets in a simple and explicit way; see §2.3.

In conclusion, for every experimental item we measured the coordinates of L, C and H in the (time, f0) plane.

Indices

We used these coordinates to calculate various indices (see Table 1), and we ran a comparison of the ability of these indices to express the contrast between the aforementioned pragmatic categories. In addition to the traditional indexes of scaling (height of L and H) and alignment (distance of L and H from both start and end of, respectively, stressed syllable onset and nucleus), we calculated a curve index, expressed as the ratio of the difference between the heights of the intermediate and the starting points, and the difference between the heights of the end and starting points of the rise. Table 1. Indices.

Index

RESULTS

The results show, for all subjects, weak or no correlations between the two pragmatic contexts (narrow focus question, QNF, and partial topic statement, SPT) and the indices usually employed in AM-based studies (alignment and scaling of tones). Two-sample Welch-Satterthwaite t-tests show that H scaling tends to be significantly different only for some speakers, while in other subjects only L scaling is significantly correlated to the two pragmatic contexts (see Figure 5). On the other hand, the curve index (and, consequently, the scaling of the midpoint in time between L and H) shows a strong correlation for all subjects with the pragmatic contexts (p<0.001). Moreover, considering that Ci = 0.5 would indicate a linear interpolation, we note a trend towards a convex interpolation for QNF contexts (Ci < 0.5), and a slight trend towards a concave interpolation for SPT contexts (Ci > 0.5); see Figure 6.

DISCUSSION AND CONCLUSION

Our results confirm that two different kinds of interpolation between the two targets which compose a rising pitch accent (specifically, concave and convex) are correlated to two different pragmatic contexts (specifically, partial topic statement and narrow focus question). More generally, we can state that the analysis of the dynamic proprieties of the f0 contour allows for a better description of post-lexical meaning. If, as we mentioned at the beginning of §1, intonational phonology investigates the relationship between suprasegmental features and post-lexical meaning, we suggest that the AM model needs to be revised in order to a give proper place to the phonological value of these dynamic proprieties. This claim seems to be supported by other studies, as [START_REF] Petrone | From tones to tunes: the role of f0 prenuclear region in intonation identification in Italian[END_REF] on NI and [START_REF] Petrone | The role of the prenuclear F0 region in the identification of German questions and statements[END_REF] on German, in which the authors examine the importance of dynamic factors outside pitch accents.

In any case, we believe that such a revision cannot be proposed before an examination is made of the perceptual relevance of the contrasts found in this production experiment. As we said in §1 (see Figures 2 and3), even if we only take into account the f0 contour, the most striking acoustic difference between the two utterances lies in the f0 movement corresponding to the last stressed syllable (i.e., the last pitch accent). In order to correctly retrieve the pragmatic meaning of these utterances, listeners could rely mainly or exclusively on this cue. The patterns we found in production, even if robust, could prove perceptually irrelevant.

In addition, the nature of the pragmatic contrast used in this experiment is another factor that could affect the usefulness of our results. The two contexts were chosen for the acoustic features of their realizations, i.e. for the clear differences in the interpolation between the targets of the first pitch accent, which still were equally aligned and scaled. We acknowledge that from a pragmatic point of view, our two contexts are far from being prototypically contrastive. Even if the modality value of the two contexts is clearly different (question vs statement), both share a "inconclusiveness" or "openness" feature. This feature is self-evident in the question context, but it can also be retrieved in the partial topic statement. In this case, a question about the properties of a set ("How would your friends like their coffee?") is answered to by providing information on the proprieties of a subset ("As for Milena, she drinks it unsweetened…"), implicitly excluding from the predication the properties of the complement subset ("…as for the others, I couldn't say").

Should we want to use a perceptual study to evaluate the phonological importance of the phonetic opposition highlighted in the present production study, we will need to take into account these pragmatic aspects too.

Figure 1 .

 1 Figure 1. Sketch of linear, concave and convex interpolation.

Figure 2 .

 2 Figure 2. Utterance in (partial topic) statement context.

Figure 3 .

 3 Figure 3. Utterance in (narrow focus) question context.

Figure 4 .

 4 Figure 4. Measures.

  to start of stressed vowel onset x(L) -Os aLe L alignment to end of stressed vowel onset Ns -

Figure 5 .

 5 Figure 5. Box-plot for indexes sL, aLs, aLe, sH, aHs, aHe; speaker WP.

Figure 6 .

 6 Figure 6. Box-plot for indexes sC and Ci; speaker WP.

See D'Imperio (1999) for Neapolitan Italian. Similar treatments have been proposed also for spanish(Hualde,

2000;[START_REF] Face | Focus and early peak alignment in Spanish intonation[END_REF] and english[START_REF] Ladd | Sagging transitions" between high pitch accents in English: experimental evidence[END_REF]. 2 Note that the attributes of concave and convex refer to the half-plane above the curve.

For a discussion about the nuclearity of the first pitch accent in the (partial topic) statement utterances, see D'Imperio & Cangemi (2009).

For the notion of Partial Topic, see[START_REF] Büring | The Meaning of Topic and Focus -the 59th Street Bridge Accent[END_REF].

See Figure 4: Os, Ns and Ne on x-axis.

See Figure4: y(L) and y(H) on y-axis for height, and x(L) and x(H) on x-axis for position.

See Figure4: y(C) on y-axis.

ACKNOWLEDGEMENTS

I would like to thank Pauline Welby and two of the anonymous reviewers for useful comments.


Marc Perache
email: marc.perache@cea.fr

Patrick Carribault
email: patrick.carribault@cea.fr

Hervé Jourdren
email: herve.jourdren@cea.fr

Marc Pérache

MPC-MPI: An MPI Implementation Reducing the Overall Memory Consumption

Keywords: Message passing, Memory consumption, High-performance computing, Multithreading

Message-Passing Interface (MPI) has become a standard for parallel applications in high-performance computing. Within a shared address space, MPI implementations benefit from the global memory to speed-up intra-node communications while the underlying network protocol is exploited to communicate between nodes. But, it requires the allocation of additional buffers leading to a memory-consumption overhead. This may become an issue on future clusters with reduced memory amount per core. In this article, we propose an MPI implementation upon the MPC framework called MPC-MPI reducing the overall memory footprint. We obtained up to 47% of memory gain on benchmarks and a real-world application.

Introduction

Message-Passing Interface [START_REF]Message Passing Interface Forum: MPI: A message passing interface standard[END_REF] (MPI) has become a major standard API for SPMD 1 programming model in the high-performance computing (HPC) area. It provides a large set of functions abstracting the communications between several tasks, would these tasks be on the same address space or on different nodes of a cluster. Within a shared-memory environment, MPI runtimes benefit from the global memory available by using buffers stored inside a memorysegment shared among the tasks (or processes). The size of these buffers is mainly implementation-dependent but it may have a huge impact on the final performance of the running application.

Moreover, the amount of memory per core tends to decrease in recent and future high-performance computers. Currently, the Tera10 machine 2 gives access to 3GB of memory per core with a total of about 10,000 cores. With its 1.6 million cores, the future Sequoia machine will only have on average 1GB of memory available per core. One explanation of this trend could be that the number of cores is still increasing, thanks to Moore's law, while the memory space cannot grow the same speed. The memory per core is therefore becoming a bottleneck for efficient scalability of future high-performance applications. MPI libraries have to adapt their memory consumption to guarantee a correct overall scalability on future supercomputers.

In this paper, we introduce MPC-MPI: an extension to the MPC framework [START_REF] Pérache | MPC: A unified parallel runtime for clusters of NUMA machines[END_REF] (MultiProcessor Communications). MPC-MPI provides a full MPIcompatible API with a lower memory footprint compared to state-of-the-art MPI runtimes. The MPC framework implements an MxN thread library including a NUMA-aware thread-aware memory allocator and a scheduler optimized for communications. MPC-MPI is developed upon the MPC framework by providing a compatibility with the MPI API version 1.3 [START_REF]Message Passing Interface Forum: MPI: A message passing interface standard[END_REF] where each task is a single thread handled by the user-level scheduler. Thanks to this implementation, we reduced the whole memory consumption on benchmarks and real-world applications by up to 47%.

This article is organized as follows: Section 2 details the related work and Section 3 summarizes the MPC framework, highlighting the features that are already implemented. Then, Section 4 explains how we extended MPC with MPC-MPI before describing its memory gain in Section 5. Section 6 presents experiments comparing MPC-MPI to state-of-the-art MPI implementations before concluding in Section 7.

Related Work

A significant part of MPI libraries memory consumption is due to additional buffers required to perform efficient communications. This section describes different approaches and their corresponding memory consumption/efficiency.

Standard MPI Approach

The standard approach implements MPI tasks as processes. In such runtimes, the message-passing operations rely on copy methods from the source buffer to the destination one. There are four main approaches to accomplish this copy.

Two-copy method: The 2-copy method relies on the allocation of a sharedmemory segment between the communicating tasks. First of all, this approach requires a copy from the original buffer to the shared-memory segment. Then, an additional copy is performed from this segment to the destination buffer. The size of these segments is a tradeoff between performance and memory consumption. The best-performing variant allocates a shared buffer for each pair of processes leading to a total of N 2 buffers where N is the number of tasks. Even though this approach is not scalable in memory, it is used in MPICH Nemesis fastbox [START_REF] Buntinas | Design and evaluation of nemesis, a scalable, low-latency, message-passing communication subsystem[END_REF] on nodes with low amount of cores. A more-suitable approach for scalability involves only one buffer per task, as MPICH Nemesis uses for large nodes.

Rendez-vous: The rendez-vous method is a variant of the 2-copy method using large buffers to avoid the message splitting required to fit into the shared-memory segments. This method adds task synchronization to choose a free shared buffer and to perform the 2-copy operation, but one advantage is that it only requires few large buffers for large-message copy.

TODO: rewrite the rendez-vous explanations

One-copy method: The 1-copy method is designed for large-message communications when the MPI library is able to perform a direct copy from the source buffer to the destination. This can be done through a kernel module performing physical-address memory copy. This method is efficient in terms of bandwidth but it requires a system call that increases the communication latency. The main advantage of this method is that it does not require additional buffers. This method is used in MPIBull.

Inter-node communications: The main issue related to memory consumption with inter-node communications is that the number of buffers is often in N 2 where N is the number of process. Whereas processes may share a node, it is hard to share buffers used by the Network Interface Controller (NIC) library. This is due to the process model that requires the separation of the memory address spaces. Nevertheless, some solutions have been proposed to reduce the memory footprint of communications related to the NIC and/or the NIC library capabilities [START_REF] Sur | High-performance and scalable MPI over Infini-Band with reduced memory usage: an in-depth performance analysis[END_REF][START_REF] Koop | Reducing connection memory requirements of MPI for InfiniBand clusters: A message coalescing approach[END_REF].

TODO: Rewrite first 2 sentences: what is N ? 2.

Process virtualization

Unlike other approaches [START_REF] Gropp | High-performance, portable implementation of the MPI Message Passing Interface Standard[END_REF][START_REF] Graham | Open MPI: A flexible high performance mpi[END_REF] that map MPI tasks to processes, process virtualization [START_REF] Kalé | The virtualization model of parallel programming: runtime optimizations and the state of art[END_REF][START_REF] Demaine | A threads-only MPI implementation for the development of parallel programming[END_REF][START_REF] Huang | Adaptive MPI[END_REF][START_REF] Tang | Optimizing threaded MPI execution on SMP clusters[END_REF] benefits from shared-memory available on each cluster node by dissociating tasks from processes: tasks are mapped to threads. This allows efficient 1-copy method and it enables straight-forward optimizations of internode communications. Process virtualization is the approach used in the MPC framework. TODO: more details? (not sure) + talk about issues w/ global variables? (not sure either)

The MPC Framework

Our work takes place inside the MultiProcessor Communications (MPC) framework. This environment provides a unified parallel runtime aiming at improving scalability and performance of applications running on large multiprocessor/multicore clusters of NUMA nodes. MPC uses process virtualization as execution model and provides dedicated message-passing functions to enable task communications. The MPC framework is divided into 3 parts: the thread library, the communication layer and the NUMA-aware allocator.

Thread Library

MPC provides an MxN thread library [START_REF] Namyst | PM2: Parallel multithreaded machine. a computing environment for distributed architectures[END_REF][START_REF] Abt | Next Generation POSIX Threading Project[END_REF] that maps tasks on lightweight user-level threads. One key advantages of such MxN approach is the ability to optimize the user-level thread scheduler and thus to create and schedule a large number of threads with a reduced overhead. This scheduler provides a polling method that avoids busy-waiting and keeps a high level of reactivity for communications even when the number of tasks is larger than the number of available cores. Furthermore, collective communications have been integrated into the thread scheduler to enable efficient barrier, reduction and broadcast operations.

Explain MxN (maybe 1 small sentence?)

Memory Allocator

The MPC thread library is linked to a dedicated NUMA-aware and thread-aware memory allocator. It implements a per-thread heap [START_REF] Berger | Hoard: a scalable memory allocator for multithreaded applications[END_REF][START_REF] Berger | Composing high-performance memory allocators[END_REF] approach to avoid contention during allocation and to maintain data locality on NUMA nodes.

Each new data allocation is first performed by a lock-free algorithm on the thread private heap. If this local private heap is unable to provide a new memory block, the requesting thread queries a large page to the second-level global heap with a synchronization scheme. This large page increases its private-heap size leading to the satisfaction of the memory allocation. Memory deallocation is locally performed in each private heap. When a large page is totally free, it is returned to the system with a lock-free method.

Communications

Finally, MPC provides simple mechanisms for intra-node and inter-node communications. Intra-node communications involve two tasks in the same process (MPC uses one process per node). These tasks use the optimized threadscheduler polling method and thread-scheduler integrated collectives to communicate with each other. As far as inter-node communications are concerned, MPC uses an underlying MPI library. This method allows portability and efficiency but hampers aggressive communication optimizations.

MPC-MPI Extension

This paper introduces MPC-MPI: an extension to the MPC framework providing a whole MPI interface both for intra-node (tasks sharing the same address space) and inter-node communications (tasks located on different nodes). This section deals with the various aspects of creating this extension of the MPC framework.

MPI Tasks and Intra-Node Communications

The MPC framework already provides basic blocks to handle message passing between tasks. Therefore, MPC-MPI maps MPI tasks to user-level threads instead of processes. Moreover, we optimized point-to-point communications to reduce their memory footprint (see Section 5) whereas collective communications already reach good performance and low memory consumption. MPC-MPI currently exposes an almost-full compatibility with MPI 1.3 [START_REF]Message Passing Interface Forum: MPI: A message passing interface standard[END_REF]: it passes 82% of the MPICH test suite. 3 The missing features are the inter-communicators and the ability to cancel a message. Nevertheless, compatibility issues remain: MPC-MPI is not 100% MPI compliant due to the process virtualization. Indeed, the user application has to be thread-safe because several MPI tasks will be associated with the same process and will share global variables. To ease the migration from standard MPI source code to MPC-MPI application, we modified the GCC compiler to warn the programmer for each global-scope variable (privatizing or removing such variables is one way to guarantee the thread safety of a program).

Inter-Node Communications

The MPC framework relies on an external MPI library to deal with inter-node message exchange. MPC-MPI now implements its own inter-node communication layer based on direct access to the NICs as far as high performance networks are concerned. This new layer enables optimizations according to communication patterns. For example, it allows to add, with a small overhead, the MPC-MPI messages headers required for communications. So far, MPC-MPI provides three network-protocol implementations: TCP, Elan(Quadrics) and InfiniBandbut there are no restrictions to extend this part to other networks. .

Memory Consumption Optimization

MPC-MPI implements an almost-full MPI runtime. Thanks to process virtualization, intra-node/inter-node communications and memory-management optimizations, MPC-MPI reduces the memory-consumption of MPI applications. This section depicts the various aspects of memory gain in MPC-MPI.

Intra-Node Optimizations

The optimizations of memory requirements for intra-node communications mainly rely on the removal of temporary buffers. The unified address space among tasks within a node allows MPC-MPI to use the 1-copy buffer-free method without requiring any system call. That is why the latency of MPC-MPI communications remains low even for small messages. Nevertheless, for optimization purposes, tiny messages (messages smaller than 128B) may use a 2-copy method on a 2KB per-task buffer. This optimization reduces the latency for tiny messages. Finally, the 1-copy method has been extended to handle non-contiguous messages using derived types without additional packing and unpacking operations.

TODO: more details on 1-copy optimization?

Inter-Node Optimizations

The second category of memory optimizations are related to the inter-node message exchange. In MPC-MPI, a process handles several tasks and only one process is usually spawn on each node. Thus, network buffers and structures are shared among all the tasks of the process. The underlying NIC library only sees one process and, therefore one identifier for communication between nodes. This enables further optimizations at the NIC level e.g., packet aggregation. TODO: I changed the last sentence (the old one is still as comment in the TEX file

Memory Allocation Optimizations

Finally, the MPC memory allocator has been optimized to recycle memory between tasks. Many high-performance applications allocate temporary arrays of objects having a very short lifetime. With a standard memory allocator, these allocations are buffered to avoid a system call each time such event occurs. MPC-MPI uses smaller buffers for each thread private heap but it also maintains a shared pool of memory pages in the global heap to avoid system calls. It enables intra-node page sharing between tasks without system calls unlike in the multiprocess approach.

Experiments

This section describes the experimental results of MPC-MPI, conducted on two architectures: a dual Intel Nehalem-EP (8 cores) with 12GB of main memory running Red Hat Enterprise Linux Client release 5.2 and an octo-dual core Intel Montecito with 48GB of memory running Bull Linux AS4 V5.1 (one node of the CEA/DAM Tera10 machine). To evaluate the MPI performance of MPC-MPI, the Intel MPI Benchmarks4 have been used with the option -off-cache to avoid cache re-usage and, therefore, to provide realistic throughput. The tests compare MPC-MPI to MPICH 2 1.1a2 Nemesis on the Nehalem architecture and MPIBull 1.6.5 on the Tera10 machine. 5 These experiments are divided into 3 categories: (i) the point-to-point benchmarks, (ii) the collective benchmarks and (iii) the results on our real-world application.

Point-to-Point Benchmarks

Figure 1 illustrates the latency and the bandwidth of the MPC-MPI library on the standard pingpong benchmark with two tasks communicating among a total of 2, 8 or 16 tasks. MPC-MPI is a bit slower than MPICH Nemesis on the Nehalem architecture when the number of MPI tasks is low. But with a total of 8 tasks or with 16 hyperthreaded tasks per node, MPC-MPI keeps a constant latency and bandwidth whereas MPICH Nemesis slows down. As far as the Tera10 machine is concerned, MPC-MPI is a bit slower than the vendor MPI library: MPIBull. This pinpong benchmark illustrates the rather good performance of MPC-MPI compared to other MPI libraries in terms of latency and bandwidth. It also illustrates the benefits of MPC-MPI memory optimizations that lead to save a significant amount of memory even on this simple test.

Collective Benchmarks

The second benchmark category is related to collective communications. Figure 3 shows the latency and bandwidth of the MPC-MPI library on the Allreduce benchmark. MPC-MPI is a bit faster than MPICH Nemesis on the Nehalem architecture whatever the number of tasks is. On the Tera10 machine, MPC-MPI is still a bit slower than MPIBull.

Application

MPC-MPI has been used on the application HERA on the Tera10 supercomputer. HERA is a large multi-physics 2D/3D AMR hydrocode platform [START_REF] Jourdren | HERA: A hydrodynamic AMR platform for multi-physics simulations[END_REF]. On a typical ablation front problem, with 3-temperature multifluid hydrodynamics (explicit CFD solver) coupled to 3-temperature diffusion (iterative Newton-Krylov solver + preconditioned conjugate-gradient method), MPC-MPI allows a 47% reduction of memory consumption (1495MB for MPC-MPI instead of 2818MB for MPIBull) on a 16-core Tera10 NUMA node, for just 8% overhead compared to native MPIBull (about 400,000 cells, with aggressive Adaptive Mesh Refinement and dynamic load balancing). This large C++ code uses number of derived types and collective communications during its execution, demonstrating the robustness of the MPC-MPI library.

Conclusion and Future Work

In this paper we proposed MPC-MPI: an extension of the MPC framework providing an MPI-compatible API. This extension reduces the overall memory consumption of MPI applications thanks to the process virtualization and a large number of optimizations concerning the communications (intra node and inter node) and the memory allocator. Experiments on standard benchmarks and a large application show significant memory gains (up to 47%) with only a small performance slowdown compared to vendor MPI (MPIBull on Tera10) and stateof-the-art implementations (MPICH Nemesis). Furthermore, optimizations of inter-node communications in MPC-MPI does not hamper further optimizations proposed by specialized high performance communications library. The benefit of these library are cumulative with MPC-MPI optimizations.

There are still some missing features to propose a full MPI API, these will be implemented in the near future. Furthermore, some work has to be done concerning the thread-safety needed by MPC-MPI. So far, only a modified GCC is able to extract the global variables of the application, but no tools are available to help the programmer to transform its code. Finally, the MPC-MPI extension on MPC is the first step to provide an optimized hybrid MPI/thread framework.

  Latency and bandwidth evaluation of the Nehalem platform.

  Latency and bandwidth evaluation of Tera10 platform.

Fig. 1 .Figure 2

 12 Fig. 1. Performances of the point to point communication benchmark

Fig. 2 .

 2 Fig. 2. Memory consumption of the point to point communication benchmark

  Latency and bandwidth evaluation of the Nehalem platform. Latency and bandwidth evaluation of the Tera10 platform.

Fig. 3 .

 3 Fig. 3. Performances of the allreduce communication benchmark

Figure 4

 4 Figure 4 illustrates the memory consumption of MPC-MPI compared to other implementations. The results with the Allreduce benchmark is similar to the

Fig. 4 .

 4 Fig. 4. Memory consumption of the allreduce communication benchmark

Single Program Multiple Data

As of November 2008, Tera10 is ranked 48th in the TOP500 list http://www.top500.org/

http://www.mcs.anl.goc/research/projects/mpi/mpi tests/tsuite.html

http://www.intel.com/cd/software/products/asmo-na/eng/219848.htm

MPIBull is the vendor MPI available on the Tera10 machine.


Etienne Balmes
email: etienne.balmes@paris.ensam.fr

Corine Florens

Validation of a vibration and electric model of honeycomb panels equiped with piezoelectric patch actuators

Keywords: active control, honeycomb, test-analysis correlation MOTS-CLÉS : contrôle actif, nid d'abeille, corrélation calcul-essai

Active control has often been considered for low frequency noise control of aircraft or helicopter trim panels. The present study proposes a methodology for numerical homogeneization of honeycombs and shell models of piezoelectric patches. These models are validated experimentally. The considered honeycomb is shown to be significantly viscoelastic and local bending effects are shown to limit achievable active control performance. Finally modeling strategies for the integration of the model in a numerical design process are discussed.

RÉSUMÉ. Le contrôle actif à souvent été considéré pour la maitrise du bruit basse fréquence des panneaux d'habillage des avions et hélicoptères. Dans le cas de panneaux en nid d'abeille, les résultats n'ont pas toujours été à la hauteur des attentes. L'étude présentée introduit un modèle détaillé de panneau en nid d'abeille équipé de patchs piézoélectriques et valide ce modèle expérimentalement. L'utilisation de modes périodiques permet une analyse détaillée de l'influence des constituants dans le comportement vibratoire du nid d'abeille. Les effets viscoélastiques présents pour le Nomex sont par ailleurs mis en évidence. Du point de vue électrique, on montre que la flexibilité résiduelle induit une cloque, flexion très localisée des peaux. La performance atteignable par le contrôle actif est donc limitée. Finalement, des stratégies pour l'intégration du modèle proposé dans un processus de conception sont discutées.

Introduction

Reduction of noise transmission inside cabins, for improved passenger comfort, is an important concern for the aircraft industry. Usually trim panels are made of honeycomb sandwich composite. Those panels have a high strength to weight ratio, but acoustical properties have to be improved by complementary treatments. Passive treatments are efficient for high frequencies. Active sound and vibration control is often considered as a solution to reduce residual noise for low and medium frequencies.

While active control of honeycomb panels has been the object of various studies [START_REF] Bihan | Contrôle Actif de panneaux composites[END_REF], detailed modeling of the panels equipped with piezoelectric patches was not performed. In general, such modeling seems necessary to achieve a consistent design methodology and was thus the general objective of this study.

Section 2 discusses honeycomb modeling using the classical assembly of three models : two skins, modeled as composite plates, and a core, modeled as an equivalent orthotropic volume. A numerical homogeneization methodology based on the correlation of periodic bending mode frequencies is introduced to evaluate the effective parameters of the orthotropic material. This methodology is then used to analyze factors influencing the effective parameters.

Section 3 introduces a piezoelectric shell element and discusses methodologies for numerical resolution of the coupled mechanical/electrical problem.

Experimental validations of the proposed models are discussed in section 4. The Nomex honeycomb considered in the test is shown to be significantly viscoelastic. The identified frequency dependent constitutive law is sufficient to accurately predict transfers of the active panel. Local bending effects in the honeycomb skins are then studied in detail since they are a factor limiting the performance that can be achieved in active control.

Finally section 5 discusses practical constraints linked to the use of the proposed model in a design phase.

Models of honeycomb panels

Equivalent models

When modeling honeycomb panels, the use of detailed 3D models where each of the walls of the honeycomb is modeled can rapidly become inaccessible. The classical approach is thus to build an equivalent representation with skins modeled as shells and the honeycomb modeled using an orthotropic volume. A wide range of equivalent formulas giving the effective properties of the orthotropic material as function of the cell properties can be found in the literature [START_REF] Gibson | Cellular Solids Structure and Properties[END_REF][START_REF] Grédiac | A finite element study of the transverse shear in honeycomb cores[END_REF][START_REF] Noor | Assessment of continuum models for sandwich panel honeycomb cores[END_REF][START_REF] Hohe | A refined analysis of the effective elasticity tensor for general cellular sandwich cores[END_REF].

The first objective of the present work is to propose a systematic approach to evaluate the effective (or equivalent) properties based on a detailed FE model of the honeycomb.

To demonstrate the approach, one considers the mesh shown left in figure 1. This model is meant to represent physical reality (geometry, thickness of various walls, material...) as closely as possible, with the intention of minimizing the modeling errors. It will be used as reference to estimate honeycomb properties starting from material and geometric considerations. The geometry of the glue is shown in figure 2. Rather than introducing a detailed geometry, the 3D model, considered here, privileges a functionally equivalent representation as a small plate extending from the skin neutral fiber to its surface. The explicit representation of glue elements thus allows a meshing of the honeycomb cell walls and face-sheets that is compatible and strictly respects the geometry. Functional values of shear and bending stiffness can then be easily related to the glue modulus E g and shell element thickness t g .

Figure 2. Modeling of adhesive fillet

The classical equivalent model for large panels uses the shell/volume/shell (SVS) layout shown right in figure 1. The sandwich face sheets are modeled by isotropic shell, for metallic skin such as aluminum, or multilayered composite laminate, for composite skin such as carbon fiber reinforced composites. As in most of the literature, Mindlin formulations and Classical Laminated Plate Theory [START_REF] Jones | Mechanics of Composite Materials[END_REF][START_REF] Berthelot | Materiaux composites -Comportement mecanique et analyse des structures[END_REF]) is assumed to be sufficient. For the simulations shown, the SDT [START_REF] Balmes | Structural Dynamics Toolbox 6.2 (for use with MATLAB)[END_REF] implementation of MITC4 composite plate/shell elements with shear correction is used. To simplify handling, the face sheets are normally meshed to be compatible with the underlying core models. In the case of detailed 3D models, one thus uses hexagonal shapes composed of two quadrangular elements, while in the SVS model regular rectangles are used.

Determination of effective parameters using periodic modes

Homogeneization techniques determine effective properties of the homogenized model by comparing various properties (static deflections, strain energies for particular deformations, ...). The approach retained here is to compare the frequencies of bending modes obtained with periodicity conditions that are equivalent for both models shown in figure 1 and to update the effective parameters of the SVS model to match the frequencies of the detailed 3D model. This is a numerical homogeneization procedure since one uses a detailed 3D FEM model as reference and a SVS model to determine the effective parameters. The update can be performed for all wavelengths and the range of stability of the parameter is a useful result of the study.

While periodic modes can be computed using a long beam sample and simple conditions of equal displacement at the wavelength [START_REF] Florens | Accounting for glue and temperature effects in Nomex based honeycomb models[END_REF], this approach is costly. These modes can however be computed much more efficiently using Fourier theory as detailed in [START_REF] Clouteau | Free field vibrations due to dynamic loading on a tunnel embedded in a stratified medium[END_REF] for the periodic structures and [START_REF] Sternchüss | Reduction of Multistage disk models : application to an industrial rotor[END_REF] for cyclic symmetry. This section summarizes the theory underlying periodic mode computations. One considers a model whose properties are spatially periodic. For a physical response, known at regularly spaced positions n∆x, one can compute its Fourier transform

U (κ) = +∞ n=-∞ u(n∆x)e -jκn∆x [1]
U (κ) is a complex shape defined on the mesh of the repeated cell. One actually uses two cells to represent the real and imaginary parts of U . The wave number κ varies in the [0, 2π ∆x ] interval (or any interval of the same length, since U (κ) is periodic in the wavelength domain).

Periodic modes can be shown to be mono-harmonic (to involve a single U (κ)). As a result one has u(n∆x) = Re U (κ)e jn (κ∆x) [2]

This property can be used to recover motion on any cell based on known values on the first one. Using the continuity condition linked to the fact that u lef t (n∆x) = u right ((n -1)∆x) and observation matrices c L , c R to extract the edge motion, one can write κ∆x) . Hence in the real/imaginary format, one has the constraint equation on nodes of the cell edge

[c L ]{U (κ)} = [c R ]{U (κ)}e -j(
[c l ] -cos(κ∆x)[c r ] -sin(κ∆x)[c r ] sin(κ∆x)[c r ] [c l ] -cos(κ∆x)[c r ] 2Nr×2N Re(U ) Im(U ) = 0 [3]
Since periodic modes are mono-harmonic solutions of wavelength π/κ, one thus solves for

K -ω 2 j M 0 0 K -ω 2 j M Re(U ) Im(U ) = 0 [4]
with [3] verified. Figure 3 illustrates the basic cell and restitution on multiple cells using [2] of modes computed for 1/κ equal to 3 and 17.

Analysis of properties

For the detailed 3D model of the nominal honeycomb in this study, figure 4 displays the evolution of the periodic mode frequency as a function of wavelength and the associated energy contributions. A terms refer to membrane/shear effects and D to bending (see [START_REF] Jones | Mechanics of Composite Materials[END_REF] andsection 3.1) The plot clearly indicates very different regimes. Above 1000 cell lengths (at low frequencies), the energy is essentially due membrane effects in the skin. This is underlying principle of honeycombs; the core only serves to separate the skins which carry all the load. Between 3 and 100 cell lengths, the core contains a major part of the energy. Its properties are thus critical to properly represent motion with relatively short wavelengths.

For very short wavelengths and very high frequencies, one starts seeing local modes of the skin or local bending of the cell walls. Such modes would be described as surface waves and are not really of interest to the present study. For the parameters of figure 4, the shear energy in the glue is above 8 % in the 10 to 50 cell lengths range. Figure 5 illustrates the evolution of energy fractions in the glue layer for varying glue moduli. Since 0.2 GPa is a very realistic value for epoxy it clearly appears that the glue can indeed have a major impact on the short wavelength dynamics. The bottom graph shows the evolution of the G xz value for which the frequency error is null. The mean value is 26.94 MPa. The nominal model (top curve) showed an increase of the estimated modulus for large wavelength. Several studies were performed to analyze the source of this discrepancy. The skin models clearly have no impact: a SVS model that has skin elements identical to the 3D model also shows the same decrease. Eventually, it was found that the density of the core is an extremely influent parameter in this range. This is not unexpected since the core has very limited strain energy and thus significant modulus changes are needed to compensate for small frequency errors associated with the mass. The nominal model overestimates the mass by 1%. The five curves are evenly spaced in the 1% to 0% interval. A nearly constant modulus is thus found for a 0.5% overestimation of the mass.

In practice, honeycomb bonding procedure clearly induces uncertainties in the mass much larger than 0.5%. The proposed analysis thus motivates the need for experiments evaluating the transverse shear for waves in the 30 to 200 cell length range (1500 Hz to 100 Hz).

Model of piezoelectric patch actuators

Laminated piezoelectric plates

The piezoelectric plate element, implemented in [START_REF] Balmes | Structural Dynamics Toolbox 6.2 (for use with MATLAB)[END_REF] and considered in this work, is based on Classical Laminated Plate Theory (CLPT [START_REF] Jones | Mechanics of Composite Materials[END_REF][START_REF] Berthelot | Materiaux composites -Comportement mecanique et analyse des structures[END_REF]) for the mechanical part and the work of Piefort [START_REF] Piefort | Finite Element Modelling of Piezoelectric Active Structures[END_REF] for the piezoelectric coupling. The global constitutive equations of piezoelectric Mindlin shell are obtained by integration over thickness and are expressed in the global coordination system. The piezoelectric medium has orthotropic mechanic and electric properties; hence the constitutive equations for each layer are related to their orthotropic axes. [R S ] k is the transformation matrix linking the strain in the global coordinate system to the local one, and

[R T ] -1 k = [R S ]
T k is the one linking the stresses in the local coordinate system to the global one. The coupled plate/piezoelectric equations are thus given by >

> > > > > > > < > > > > > > > > : N M Q . . . D k . . . 9 > > > > > > > > = > > > > > > > > ; = 2
A B 0 • • • ([e] k ˆRk s ˜)T B D 0 • • • (z mk [e] k ˆRk s ˜)T 0 0 H • • • 0 • • • . . . [e
                 S m κ γ . . . φ k . . .                  [5]
where the constitutive matrices [A] (membrane) ,[B] (membrane/bending coupling)

[D] (bending), [F ] (shear) are those found in classical laminated plate theory (see [START_REF] Jones | Mechanics of Composite Materials[END_REF]).

It is assumed that the electric field needs only to be known between electrodes and can be described by the difference of potential φ k , leading to an assumed electric field E = -gradφ. When this field is applied in the direction e 3 , the piezoelectric actuator PZT extends in the plane ( e 1 , e 2 ). It produces load on the piezoelectric layer (or ply in the CLPT terminology) in the direction e 1 which depends on e 31 and φ. Because of the offset between the mid-plane of the actuator and the mid-plane of the multilayer laminate, the force induces both membrane and bending loads as will be illustrated in section 4.

In the software implementation, the composite plate is modeled using a classical MITC4 element [START_REF] Bathe | The finite element analysis of shells -fundamentals[END_REF]. The piezoelectric coupling part of [5] is numerically integrated using the nominal four point rule on the patch. For the electric part, a single electric DOF is considered for each patch. This DOF is thus common to all elements covered by the electrode. In the present configuration two patches are stacked together thus leading to a model with two electric DOFs. In practice, the wiring is such that these potential are equal or opposite. The elimination of this constraint is done in the model resolution phase.

Resolution of system equations

Once assembled the model takes the form

Z uu K uφ K φu K φφ q mech φ k = F mech Q k [6]
with the classical dynamic stiffness Z = M s 2 + K. When simulating the response, one needs to consider sensor and actuator configurations.

Piezoelectric patches used as sensors have a charge that remains zero (open circuit mode). One can thus condense the electric DOF. Indeed, one considers an electrostatic behavior (no M φφ or M φu ) and assumes Q k = 0, one thus has

{q mech } φ k = I -[K φφ ] -1 [K φu ] {q} mech = [T ]{q mech } [7]
This relation can be used to eliminate the electric contribution from the system equations which become

[T ] T [Z][T ]{q mech } = [T ] T {F } [8]
From this condensation it clearly appears that a patch used as sensor induces a shift of frequencies form a configuration without piezoelectric coupling.

Piezoelectric patches used as actuators have a difference of potential φ k that is enforced. One can thus use the electric part of [6] to determine the charge

Q k = [K φu K φφ ] q mech φ k [9]
and consider the system equations with no piezoelectric coupling an electric load

Z uu q mech = F mech -K uφ φ k [10]
It clearly appears that the dynamic stiffness of this configuration is that of the purely mechanical model with no piezoelectric coupling. The modes of Z uu correspond to the case with φ k set to zero. In other words, the actuator configuration leads to closed circuit modes.

In the resolution process implemented in [START_REF] Balmes | Structural Dynamics Toolbox 6.2 (for use with MATLAB)[END_REF], electrodes are declared to be either open or closed circuit which allows a condensation or elimination of electrical DOFs before computation of modes and static correction for inputs (Balmes, 1997(Balmes, -2007)), which are used to build the state-space model. The inclusion of the static correction is shown to be critical in the next section.

Experimental validation

Test setup

Multiple modal tests were performed at Ecole Centrale Paris (MSSMat) and KTH Stockholm University (MWL). The test beams external dimensions are 900 × 45 × 21mm (approximately 109 × 5 cells). Configurations with 0.6 mm aluminimum and 1mm carbon laminates were tested. The core is a 19 mm thick Nomex paper honeycomb. The carbon skin beam was equiped with 3 QuickPack piezoelectric patches detailed in figure 9. Excitation was performed using a shaker or the piezoelectric patches.

Measurements over the full length of the beam were performed to obtain global modeshapes correlation. When local effects were shown, a second test was performed using a dense mesh of measurement points located over the patch.

Viscoelastic properties of Nomex

As shown in figure 10 the Nomex honeycomb and/or glue considered in this study show significant viscoelastic behavior. One indeed clearly sees a evolution of stiffness and loss factor with temperature.

Figure 10. Frequency Response for various temperatures. Aluminum Nomex honeycomb [START_REF] Florens | Accounting for glue and temperature effects in Nomex based honeycomb models[END_REF] Using the SVS model of the tested beam, an updating of the G1z modulus was performed for each mode in order to find the value minimizing the error on modal frequencies. In figure 11, the resulting modulus shows the increase with frequency and decreasing slope classically found for viscoelastic materials. The experimental conditions are clearly not sufficient for a complete validation of the G 1z frequency/temperature dependence, but the trend is clearly shown and was found to be sufficient for the purposes of this study. Figure 12 indeed demonstrates that excellent test/analysis correlation is achieved, provided that the frequency dependence of the honeycomb properties is taken into account. The problematic shape is illustrated by simulation results shown in figure 13. It is well known that patches generate loads that correspond to a combination of in plane membrane traction and moments applied on the edges, as shown in the figure. The use of a two layer patch in the QuickPack is meant to allow users select a preferred actuation mechanism depending on whether the two applied voltages φ 1 , φ 2 have equal or opposite polarity. In the considered setup, the polarity favoring membrane loading is used. The objective is thus to generate an elongation of the skin and thus a global bending of the beam.

The shape, shown in figure 13, clearly indicates a poor actuation mechanism. While bending of the overall beam is achieved, the dominant effect at this frequency is a very local bending of the skin. The effect is even large enough to generate a local bending of the opposite skin. With such behavior, the patch is more effective as a local loudspeaker than as a actuator on global bending modes. The result being far from obvious and not documented in the literature, detailed tests were performed. First, it is important to understand that the localized bending effect cannot be seen in the shape of the low frequency modes. To illustrate the point, figures 14 and 15 compare forced responses, computed and simulated at and around the second mode resonance. The test/analysis correlation is very good and clearly demonstrates that the modeshape does not show the blister shape, while off-resonance responses show it clearly. For vibration applications, the response is a linear combination of the modal contributions and a quasi-static effect, often called residual flexibility [START_REF] Craig | A Review of Time-Domain and Frequency Domain Component Mode Synthesis Methods[END_REF]. The blister shape is the deformation generated by the application of a static voltage on the patch. The test detailed in this section illustrated the fact that the residual flexibility cannot be neglected outside resonances. This effect has an obvious limiting effect on the ability to control noise radiated by the panel since control of the modes will generate a local noise source even on the skin opposite to the patch.

Strategies for integrating piezos into FE models

Having validated a FE model, this section focuses on the practical implementation of the modeling strategy. The model considered in previous sections implies significant adaptations. As shown in figure 17/a, the mesh is adapted in the vicinity of the patch and two composite properties are considered. One for the standard honeycomb skin (shown in blue in the figure) and one for the patch which includes multiple layers for the skin plus two layers for the patch, as shown in figure 8. This approach is fine for a small beam model and if only few configurations of patch locations are considered. Indeed, the adaptation of the mesh under the patches would be quite time consuming for a large panel where multiple patch configurations would need to be tested. Furthermore, the use of viscoelastic materials in the glue, considered by many in the literature, implies the use of a multi-layered model with the glue represented as a volume element.

The idea tested in this work is thus to use separate elements to model the skin and the piezoelectric patch, with linear constraints used to account for the offset between the two. The shear stiffness of the glue layer (G/h) is deemed sufficiently high to suppose perfect bonding and thus omit glue modeling.

An automated procedure was introduced to mesh the patch. Based on a given rectangular shape, skin elements strictly under the patch are projected to the patch mid-surface. The boundary between the projected elements and the edge of the reference rectangle is then meshed automatically. The resulting model is shown in figure 17/c. This approach is deemed more acceptable than an adaptation of the honeycomb mesh because it only affects a small part of the model and would be adapted for the reuse of modes of the nominal panel. To compare these models, electric transfers are shown in figure 18 and piezo to laser transfers in figure 19. For a cross transfer from voltage input on piezo 2 to voltage output on piezo 1, the responses are almost perfectly superposed. For the impedance Q P iezo2

V P iezo2 however, there is a significant offset of about 30 % on the static response. This error can reasonably be attributed to the lack of adaptation of the mesh on the patch edges. This is illustrated in figure 20 which shows the quasistatic shaped generated by the actuation (since the structure is free floating, one shows the deformation at 1 Hz which avoids problems linked to rigid body modes). The deformations clearly show that the blister shape under the patch cannot be perfectly reproduced due to the lack of mesh adaptation. The proposed strategy using multiple-elements through the thickness is thus limited by the ability to reproduce local effects under the patch. The local nature of this effect is clearly considered a design flaw of the considered configuration. With better designs, the patch would induce bending with much greater wave length and the mesh adaptation would probably be not as necessary.

Conclusion

Modeling techniques for honeycomb panels equipped with piezoelectric patches are very well correlated with experiments.

For honeycomb models, the classical shell/volume/shell model is well suited for all but very short wavelengths. The numerical homogeneization procedure that was implemented is very efficient and shows that constituent properties, that are not very accurately known (glue modulus, weight and geometry), have a significant impact. Analytic formulas to estimate the orthotropic material properties can thus be used as a starting guess, but should be corrected by correlation with experiments. In the particular case of Nomex honeycomb, the viscoelastic behavior cannot be neglected.

For the piezoelectric patch models, the particular configuration studied shows very strong local effects in the skins, which would give poor results for applications in an active control experiment. Better configurations would imply changing the relative skin/core stiffness. This can be achieved for other skin/core and skin/patch thickness ratios and possibly by introducing local modifications of the skin thickness around the patch. Automating the search for such efficient configurations is a clear perspective of the work presented here.

ANNEXE POUR LE SERVICE FABRICATION

Figure 1 .

 1 Figure 1. Honeycomb representative volume. Left : Detailed 3D model (3D). Right : shell volume shell model (SVS)

Figure 3 .

 3 Figure 3. Periodic modes of the SVS model

Figure 4 .

 4 Figure 4. Energy contribution of constituents and frequency of longitudinal periodic modes as a function of wavelength divided by cell length L L . Detailed 3D model

Figure 5 .

 5 Figure 5. Energy fraction of constituents. Detailed 3D model with 0.2 to 20 GPa glue modulus

Figure 6 .

 6 Figure 6. Energy contribution of constituents for first longitudinal periodic mode as a function of wavelength. SVS model

Figure 7 .

 7 Figure 7. Top: error on frequency of the first periodic bending mode for various values of G xz . Bottom: Estimation of G xz associated with no error. Detailed 3D model with 4 by 4 refinement (curves correspond to +1% to 0% mass)

Figure 8 .

 8 Figure 8. Left Geometry of an N-layered laminate. Right Particularization for a skin with a piezoelectric patch

Figure 9 .

 9 Figure 9. Experimental Setup. Left : full beam measurements. Top right, piezo patch configuration. Bottom right : sensor location of zoom on patch

Figure 11 .

 11 Figure 11. Evolution of bending eigenfrequencies for different temperatures. Equivalent shear modulus G1z of honeycomb + glue core as a function of frequency and temperature

Figure 12 .

 12 Figure 12. Piezo voltage to translation transfer on a carbon/Nomex honeycomb beam (Piezo 1 actuator -Laser sensor 6)

Figure 13 .

 13 Figure 13. Left : Patch configuration. Center : equivalent applied loads. Right : simulated blister of piezoelectric actuator

Figure 14 .Figure 15 .Figure 16 .

 141516 Figure 14. Test of second mode. Carbon/Nomex honeycomb core beam actuated by patch 1. Left : response in the middle of the patch. Right : shape before, at, and after resonance

  As an intermediate validation, a model with two layers (skin and piezo) but an adapted underlying mesh is also considered and shown in 17/b.

Figure 17 .

 17 Figure 17. Piezoelectric patch model strategy: a/ adapted meshing and integrated patch, b/ adapted meshing and 2 layers (patch and face sheet), c/ non-adapted meshing and 2 layers

Figure 18 .

 18 Figure 18. Electric transfers for the 3 model strategies. Input is piezo 2 used as voltage driven actuator. Left piezo 1 used as voltage sensor. Right Charge generated on piezo 2

Figure 19 .

 19 Figure 19. Piezo to laser sensor transfer

Figure 20 .

 20 Figure 20. Shape at 1Hz for the 3 model strategies of the piezoelectric actuator (Piezo2)

A

  FOURNIR PAR LES AUTEURS AVEC UN EXEMPLAIRE PAPIER DE LEUR ARTICLE ET LE COPYRIGHT SIGNE PAR COURRIER LE FICHIER PDF CORRESPONDANT SERA ENVOYE PAR E-MAIL 1. ARTICLE POUR LA REVUE : RCMA -19/2009. Composites multifonctionnels et réactifs 2. AUTEURS : Etienne Balmes * -Corine Florens ** 3. TITRE DE L'ARTICLE : Validation of a vibration and electric model of honeycomb panels equiped with piezoelectric patch actuators 4. TITRE ABRÉGÉ POUR LE HAUT DE PAGE MOINS DE 40 SIGNES : Honeycomb and piezo actuator model 5. DATE DE CETTE VERSION : mail : etienne.balmes@paris.ensam.fr 7. LOGICIEL UTILISÉ POUR LA PRÉPARATION DE CET ARTICLE : L A T E X, avec le fichier de style article-hermes.cls, version 1.23 du 17/11/2005. 8. FORMULAIRE DE COPYRIGHT : Retourner le formulaire de copyright signé par les auteurs, téléchargé sur : http://www.revuesonline.com SERVICE ÉDITORIAL -HERMES-LAVOISIER 14 rue de Provigny, F-94236 Cachan cedex Tél. : 01-47-40-67-67

  ] k ˆRk

	.	s	..	. . . z mk [e] k .	ˆRk s	..	. . . 0 . . .	. . . 0	-ǫ k h k	0 . . .	3 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 5


Damien Cassou
email: damien.cassou@labri.fr

Julien Bruneau
email: julien.bruneau@inria.fr

Charles Consel
email: charles.consel@inria.fr

A Tool Suite to Prototype Pervasive Computing Applications

Keywords: Toolkit, Programming support, Simulation, Pervasive computing architectures, Programming paradigms for pervasive systems

Despite much progress, developing a pervasive computing application remains a challenge because of a lack of conceptual frameworks and supporting tools. This challenge involves coping with heterogeneous entities, overcoming the intricacies of distributed systems technologies, working out an architecture for the application, encoding it in a program, writing specific code to test the application, and finally deploying it.

We present DiaSuite, a tool suite covering the development lifecycle of a pervasive computing system. This tool suite comprises a domain-specific design language, a compiler for this language, which produces a Java programming framework, an editor to define simulation scenarios, and a 2D-renderer to simulate pervasive computing applications.

We have validated our tool suite on a variety of comprehensive applications in areas including telecommunications, building automation, and health-care.

I. INTRODUCTION

Pervasive computing systems are being deployed in a growing number of areas, including building automation, assisted living, and supply chain management. These systems involve a wide range of devices and software components, communicate using a variety of protocols, and rely on intricate distributed systems technologies. Developing pervasive computing applications is a difficult task because it requires to deal with a wide range of issues: heterogeneous devices, entity distribution, entity coordination, low-level hardware knowledge. . . Besides requiring various areas of expertise, programming such applications involves writing a lot of administrative code to glue technologies together and to interface with both hardware and software components. A pervasive computing system thus requires tool support during all stages of the development, from design to deployment and test.

Our approach

We propose an approach that covers the development lifecycle of a pervasive computing application in the form of a suite of tools named DiaSuite. Specifically, we have developed a design language, named DiaSpec [START_REF] Cassou | A generative programming approach to developing pervasive computing systems[END_REF], dedicated to describing pervasive computing systems. From a given DiaSpec description, a compiler provides customized support for each development stage of a pervasive computing system, namely, implementation, testing, and deployment, as depicted in Figure 1. A simulation editor and 2D-renderer are also part of DiaSuite to simulate the resulting pervasive computing application. Let us now give an overview of our tool-based methodology and its main stages.

A. A design language for pervasive computing systems

DiaSuite provides a language, DiaSpec, dedicated to architecturing pervasive computing systems. DiaSpec allows an area expert to define a taxonomy by declaring the required entities of the system. DiaSpec also provides constructs to declare the architecture of the system in the form of context and controller components.

Taxonomy. Because of their heterogeneity, entities of pervasive computing environments need to be specified in a highlevel manner to abstract over their variations. The number of existing entities also require to characterizing the ones that are relevant to a given area. To address these issues, we provide an area expert with a declarative language to define a hierarchy of entities (stage ➀). Each class of entity is characterized in terms of the types of data that are gathered from the environment and the actions that are supported. Attributes are also used to characterize properties of device instances (e.g., location and ownership).

Architecture. A taxonomy definition is used as a basis to declare the architecture of pervasive computing applications. DiaSpec offers constructs to declare the architecture of an application following an architectural pattern 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]. Data gathered from the environment by the entities are refined by context components to match the application needs. Context data are then passed to controller components to make decisions by triggering entity actions, declared in the taxonomy (stage ➁).

B. A generated Java programming framework

The programmer is then required to implement the entities and components (contexts and controllers). This development is supported by a Java programming framework generated by the DiaSpec compiler from the taxonomy and architecture declarations (stage ➂). The compiler produces an abstract class for each entity or component declaration, providing abstract methods to allow the developer to program the application logic (e.g., triggering entity actions) and concrete methods to support the development (discovery and interactions).

The generated programming framework has been devised to closely guide the development of the application. Implementing a DiaSpec-declared entity or component is done by subclassing the corresponding generated abstract class and by implementing each abstract method of the super class (stages ➃ and ➄).

C. A graphical editor to define simulation scenarios

Deploying a pervasive computing system for testing purposes can be expensive and time-consuming because it requires to have acquired, tested and configured all equipments and software components. Furthermore, some scenarios are difficult to test because they involve exceptional situations such as fire. To cope with these issues, DiaSuite includes a simulator for pervasive computing systems, named Dia-Sim [START_REF] Bruneau | Diasim: A parameterized simulator for pervasive computing applications[END_REF], [START_REF] Jouve | Diasim: A parameterized simulator for pervasive computing applications[END_REF]. This tool leverages declarations provided at earlier development stages. It provides support to simulate the physical environment and execute pervasive computing applications developed in DiaSuite (stage ➅). This is achieved without requiring any changes to the application code 1) Modeling the environment: The first step to simulate a pervasive computing application is to model the physical environment. This model can be used to test multiple pervasive computing applications. The modeling of the physical environment is realized in an editor illustrated in Figure 3. The layout of a physical environment is defined by an editor, including structural characteristics (i.e., walls and areas). Then, the tester places entity instances in the environment model, using a DiaSpec taxonomy. 2) Defining the simulation scenarios: DiaSim provides support to define simulation scenarios to test pervasive computing applications. A simulation scenario consists of a series of evolutions of a physical environment and simulated entity instances. In a pervasive computing application, data sources sense stimuli from the physical environment; the collected data are used for context processing. Simulating the environment stimuli allows to test an application in a simulated environment. Defining the evolution of the physical environment consists of defining these simulated environment stimuli. For each stimulus needed in a simulation scenario, the tester defines how its values evolve. To ease stimulus configuration, a library of commonly used stimuli is provided. For instance, this library enables simulated persons to move around the simulated environment. Another library is provided to the developer with commonly used behaviors for entities. Yet, new stimuli and behaviors can be introduced; this development is facilitated by generated programming support.

D. A 2D renderer to simulate pervasive computing systems

Simulation scenarios are executed in the DiaSim renderer. This platform includes a 2D-graphical renderer, based on Siafu 1 , to simulate pervasive computing applications. The simulation renderer is illustrated in Figure 4. The simulated entities are displayed in the environment representation and messages appear above the entities when sensing or actuating is performed.

Fine-grained simulation can be achieved by manually injecting stimuli during the simulation and plotting trajectories to move simulated persons.

Finally, a tested application can be executed in hybrid environments, combining simulated and real entities. Hybrid simulation is a key feature to successfully transition to a real environment: it allows real entities to be added incrementally in the simulation, as the implementation and deployment progress. The goal of this demonstration is to illustrate each step of the development cycle of a pervasive computing application using the DiaSuite tool suite. During this demonstration, we will design, implement, simulate and partially deploy a security system in a home environment.

A. Demonstrated Application

The demonstrated application is a security system responsible for securing an apartment. The security system can be activated or deactivated using a locker protected by a password. When the system is secured, it detects intrusion using motion detectors installed in the apartment. If an intrusion is detected (i.e., the system is secured and a motion has been detected), the alarms of the apartment are turned on. Moreover, a supervisor is alerted by the security system when an intrusion occurs. To alert the supervisor, the security system displays a warning message on his supervision screen and turns on the alarm in his office. Finally, the system sends him an email with a picture taken by a camera covering the intrusion area.

B. Demonstration Steps

Specifying the application architecture: The first step of our demonstration shows how to specify a pervasive computing application using our dedicated language DiaSpec. We describe all required entities along with the context and controller components of the architecture. We also demonstrate the features of the Eclipse plugin we have developed to ease this step.

Implementing the application: From the previously specified architecture, we use our compiler to generate a dedicated programming framework. On top of this dedicated programming framework we develop Java implementations of the entities and components of the application.

Defining simulation scenarios: The next step of our demonstration is the definition of simulation scenarios. Scenarios will be defined using our scenario editor (Figure 3). In this step, we first define the simulated physical environment. Then, from a DiaSpec specification, simulated entities are either graphically defined using a wizard, or developed using the generated simulation programming framework. Both strategies are illustrated by the demonstration. Simulation scenarios are composed of stimulus producers. These stimulus producers are defined using the generated simulation programming framework, as well as libraries of generic stimulus producers. Our demonstration shows examples of such stimulus producers used by our security system (e.g., production of motion stimuli to simulate an intrusion).

Testing the application: In the final step of our demonstration, our security system is tested against the previously defined simulation scenarios. To follow the evolution of the simulated environments, DiaSim extends an existing visualization tool: the Siafu open source context simulator. Siafu provides a 2D rendering and time-control functionalities. To illustrate the testing of applications in hybrid environments, we use both real entities (e.g., a locker on an iPodtouch and real motion detectors) and simulated entities to test our security system.

2 Figure 1 .

 21 Figure 1. Development life-cycle

Figure 2 .

 2 Figure 2. Architecture of a pervasive computing system

Figure 3 .

 3 Figure 3. DiaSim editor

Figure 4 .

 4 Figure 4. DiaSim renderer

http://siafusimulator.sourceforge.net


Zoé Drey
email: zoe.drey@inria.fr

Charles Consel
email: charles.consel@inria.fr

A Visual, Open-Ended Approach to Prototyping Ubiquitous Computing Applications

Keywords: End-User Visual Language, Ubiquitous Computing Prototyping, Programming paradigms for Ubiquitous Systems

By nature, ubiquitous computing applications are intimately intertwined with users' everyday life. This situation is challenging because it requires to make the development of applications accessible to end-users. Furthermore, ubiquitous computing consists of a variety of areas, including home automation and assisted living, raising a need for an open-ended approach.

We present Pantagruel, a visual programming language that is end-user oriented.

Our approach is open-ended in that Pantagruel integrates a language to describe a ubiquitous computing environment. Such description takes the form of a taxonomy, defining the entities relevant to a given ubiquitous computing area. This description serves as a parameter to a sensorcontroller-actuator development paradigm. The orchestration of area-specific entities is supported by high-level constructs, customized with respect to taxonomical information.

We have implemented a visual environment to prototyping ubiquitous computing applications. Furthermore, we have developed a compiler for Pantagruel that targets a domain-specific middleware. Our environment leverages a 2D renderer to enable the simulation and of applications. We successfully simulated a range of applications in various ubiquitous computing areas, such as home automation, assisted living and building management.

I. INTRODUCTION

Ubiquitous computing aims to address end-user needs pertaining to various areas such as assisted living, home automation or energy management. Because it requires expertise in many fields (e.g., networking, multimedia, and systems), programming ubiquitous computing systems is very challenging. Even more challenging is the fact that this programming must be made accessible to end-users because ubiquitous computing applications are intimately involved in our everyday life. Also, the spectrum of potential application areas requires the development process to be open-ended, enabling new entities, whether devices or components, to be integrated. This paper presents Pantagruel, an expressive approach to developing orchestration logic of an open-ended set of entities. A Pantagruel program is parameterized with respect to a taxonomy of entities describing a ubiquitous computing environment. Our visual programming environment includes a simulator that allows programs to be tested prior to their deployment.

Our approach consists of a two-step process: (1) a ubiquitous computing environment is described in terms of its constituent entities, their functionalities and their properties;

(2) this description takes the form of a taxonomy that drives the development of an application.

The environment description allows our approach to be instantiated with respect to a given application area. This description defines the classes of entities that are relevant to the target area. For each class, it specifies an interface to access its functionalities. Because the orchestration logic is written with respect to the environment description, entities are combined in compliance with their description. To facilitate the programming of the orchestration logic, we have developed a visual tool that uses a sensor-controller-actuator paradigm. An orchestration logic collects context data from sensors, combines them with a controller, and reacts by triggering actuators. We assessed the usability of this paradigm with a successfull user study conducted with 18 non-programmer participants. Furthermore, our visual programming environment offers the developer an interface that is customized with respect to the environment description. Information about the environment entities is exploited to guide the programmer in defining sensor-controller-actuator rules. Finally, Pantagruel programs are compiled and executed on a platform dedicated to ubiquitous computing applications.

II. OUR APPROACH

We now describe the key features of our approach.

A. An open-ended approach

We define a novel approach to visual programming of ubiquitous computing applications that is parameterized with respect to the description of a ubiquitous computing environment. In doing so, our approach addresses a range of areas.

An environment description consists of declarations of entity classes, each of which characterizes a collection of entities that share common functionalities. The declaration of an entity class lists how to interact with entities belonging to this class. The generality of these declarations makes it possible to abstract over a range of variations, enabling the re-use of an environment description.

Specifically, the declaration of an entity class consists of attributes defining a context and methods accessing the entity functionalities. A context element may either be constant, external or applicative, according to the kind of information it exposes. Let us introduce each kind of context.

An information may be assigned once and for all to an entity instance at deployment time. This first kind of context information is said to be constant. A constant is used to designate the location of an entity instance, its name, or any other information that remains unchanged throughout the life-cycle of the ubiquitous computing environment. The environment continuously evolves over time and is periodically sensed by entities, whether hardware or software, as is done by a motion sensor, for example. This second kind of context information is said to be external. Finally, context information can also be assigned values during the application execution. This third kind of context information is called applicative.

These three kinds of contexts are respectively interfaced via constant, volatile, and write attributes. Furthermore, attributes are typed to make their purpose explicit. As for methods, they are the interface declarations to the actions provided by an entity, that can be viewed as an actuator. They can also affect the applicative context. For example, the zoom method of a webcam may update the device status.

The declarations form a taxonomy describing a given environment. This is illustrated by the taxonomy extract for the assisted-living area displayed in Figure 1. A given taxonomy is used to define concrete environments by instantiating entity classes, as will be illustrated in our demonstration, summarized in Section III-B.

B. A visual development environment

We now present our visual environment dedicated to the development of orchestration rules. To implement our paradigm, the Pantagruel development environment offers a panel divided in three columns: sensors, controllers, and actuators. This panel is shown in Figure 2. To develop an application, the programmer starts by identifying entities that need to be orchestrated in this application. This is achieved in the visual language by creating sections accross the 3-column panel, each representing an entity available in the concrete environment. Then, the developer defines conditions on context elements provided by the entity interface in the sensor column, combining them in the controller column, and triggering actions on an entity in the actuator column. For readability, rules are numbered in the controller column (e.g.,R1). A key feature of our approach is to drive the development of orchestration rules with respect to an environment description. In doing so, the development environment provides the programmer with contextual menus and on-the-fly verification to guide the definition of rules.

C. A compiler towards a ubicomp platform

To allow Pantagruel programs to be simulated and tested, we have developed a compiler that leverages an architecture description language (ADL), dedicated to distributed systems, named DiaSpec [START_REF] Jouve | High-level programming support for robust pervasive computing applications[END_REF]. Given an architecture description, the compiler for this ADL generates a dedicated programming framework in Java, which provides extensive support to discover and interact with distributed entities. The compilation process of Pantagruel consists of two stages: (1) an environment description is translated into a DiaSpec description (2) orchestration rules are compiled into Java code, supported by a DiaSpec-generated programming framework. To allow Pantagruel applications to be tested, we leverage an existing entity library that implements the entity action interfaces. The overall process is illustrated in Figure 3 and described in [START_REF] Drey | A taxonomy-driven approach to visually prototyping pervasive computing applications[END_REF]. The applications can be executed in a simulator, called DiaSim [START_REF] Bruneau | Diasim, a parameterized simulator for pervasive computing applications[END_REF]. This simulator provides 2D rendering as illustrated by Figure 5. The simulated entities are displayed in a 2D model of the physical environment, and messages appear above the entities when sensing or actuating is performed.

III. DEMONSTRATION

The goal of this demonstration is to show how to program a ubiquitous computing application with Pantagruel. During this demonstration, we will instantiate a concrete environment for the assisted-living area, create Pantagruel orchestration rules, compile them, and simulate the application using DiaSim.

A. Demonstrated applications

We will demonstrate two applications to assist Henrick, a fictitious impaired person living autonomously in his apartment (Figure 4). The first application aims to assist Henrick to taking a shower. It involves the following entities: a motion detector, a smart door, a mixing valve, and a time tracker. If Henrick has been detected in the bathroom and the bathroom door is closed, then the mixingvalve regulates the water temperature to 35 degrees Celsius and then runs automatically. If Henrick is not under the shower, then the mixing valve is stopped. If the mixing valve is running, the time tracker automatically removes the shower task from its registered tasks.

The goal of the second application is to control the lights of Henrick's apartment. It relies on the following entities: lights, motion detectors, and an outside light sensor. If the luminosity is lower than a predefined threshold, the lights of a given room are turned on when Henrick enters this room, and turned off, when the room is empty.

B. Demonstration Steps 1) Creating a concrete environment:

The first step of our demonstration shows how to create a concrete environment for which orchestration rules will be developed. It consists of (1) importing an existing Pantagruel taxonomy, (2) creating entities in a predefined 2D model of a house, described with structural characteristics (i.e.,walls and areas). This concrete environment is created using the DiaSim editor; it enables to locate a person moving in the different rooms of the house. 2) Creating Pantagruel programs: In this step, we show how the Pantagruel orchestration editor is parameterized by the taxonomy, guiding the developer in the creation of programs that are syntactically correct and well-typed. As presented in Figure 6, each graphical element is associated with a contextual help, allowing the developer to write conditions and actions according to the available interface in the taxonomy. The Pantagruel visual editor is also connected to DiaSim, allowing entities created in the 2D model to be available in the editor.

Figure 1 .

 1 Figure 1. An extract of a taxonomy for assisted living

Figure 2 .

 2 Figure 2. Editing of orchestration rules

Figure 3 .

 3 Figure 3. Compilation process of Pantagruel

Figure 4

 4 Figure 4. A 2D model of Henrick's apartment

Figure 5 .

 5 Figure 5. Edition of Henrick's apartment using DiaSim

Figure 6 .

 6 Figure 6. Orchestration guided by the taxonomy