Julien Bigot

Zhengxiong Hou

Christian P Érez

Vincent Pichon

A Low Level Component Model enabling Resource Specialization of HPC Applications

Keywords: HPC, Component, Software Architecture, L 2 C, Grid'5000, Domain decomposition

Scientific applications are still getting more complex, e.g. to improve their accuracy by taking into account more phenomena. Moreover, computing infrastructures are continuing their fast evolution. Therefore, software engineering is becoming a major issue to achieve easiness of development, portability, simple maintenance, while achieving high performance. Software component model is a promising approach, which enables to manipulate the software architecture of an application. However, existing models do not capture enough resource specificities. This paper proposes a low level component model (L 2 C) that supports directly native connectors such as MPI, shared memory and method invocation. L 2 C is intended to be used as a back end by a "compiler" (such as HLCM) to generate an application assembly specific to a given machine. This paper shows on a typical domain decomposition use case that L 2 C can achieve the same performance as native implementations, while gaining benefits such as enabling resource specialization capabilities.

Un modèle de composant logiciel de bas niveau permettant la spécialisation d'applications haute performance en fonction des ressources

Résumé :

Les applications scientifiques continuent de devenir de plus en plus complexes, par exemple pour améliorer leur précision en intégrant davantage de phénomènes à simuler. Par ailleurs, les infrastructures de calcul continuent leur rapide évolution. Ainsi, l'ingénierie logicielle devient un défi très important afin de permettre une facilité de développement, la portabilité des codes, et une maintenance acceptable tout en permettant de hautes performances. Les modèles de composants logiciels offrent une approche prometteuse en permettant de manipuler l'architecture logicielle d'une application. Cependant, les modèles existant ne permettent pas de capturer suffisamment les spécificités des ressources de calcul.

Cet article propose un modèle de composant logiciel "bas niveau" (L 2 C) qui permet l'intègration native de connecteurs tels que MPI, la mémoire partagée ou l'invocation de méthode. L 2 C est destiné à être utilisé en tant que langage de sortie d'un "compilateur" (tel que HLCM) générant un assemblage d'une application spécifique à une machine et à une exécution. Cet article montre sur un cas d'étude typique de décomposition de domaines que L 2 C permet d'atteindre les même performances que les applications natives, tout en offrant des possibilités d'optimisation par rapport aux capacités des ressources.

Mots-clés : HPC, Composant, Architecture logicielle, L 2 C, Grid'5000, Décomposition de domaines

Introduction

Scientific applications require more and more computing power to simulate an increasing number of phenomena with increased accuracy. Computing power is provided by parallel hardware resources such as super-computers, clusters of nodes with multi-core CPUs, GPUs, etc. On one hand, these various parallel hardware architectures do offer very distinct features when it comes to memory models or support for communications, for example. This means that in order to obtain high performance, codes have to be specifically optimized for a targeted hardware. On the other hand, the implementation and validation of codes by specialists of the simulated domain is an expensive process. This means that once written, codes tend to be adapted and reused on different hardware and in different applications. Without careful attention, these variations of the codes tend to be maintained independently with very limited code sharing between them which leads to duplication of efforts. This could be avoided by using a suitable programming model to enable adaptation to various hardware while allowing reuse of the non hardware specific codes.

A common approach is to use a wrapping language around computation intensive kernel. Examples of wrapping languages are C++ or Python. However, these imperative languages have been shown to have drawbacks when dealing with large codes, in particular with respect to code re-use, maintenance, and code evolution [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF]. This has led the conception of a new approach for software development: component-based software engineering [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF] that aims at avoiding these drawbacks. It focuses on the decoupling of the various aspects of an application into independent components with clearly identified points of interaction. This could be used to implement the separation of concerns between domain specific codes and hardware specific codes.

While software components offer many advantages, their use in High Performance Computing (HPC) is not as widespread as one could expect. One reason seems to be that some models introduce overheads at runtime that are not acceptable in HPC while other models do not offer the level of abstraction that would allow to adapt applications to distinct hardware resources.

This paper proposes the Low Level Components (L 2 C), a component model close to hardware abstractions. It aims to be easily extensible to integrate distinct HPC hardware resources. The current version supports without overhead interactions such as native method call (C++ and soon fortran), MPI, and remote method invocation (Corba).

As L 2 C aims to be very close to machine abstractions, it does not provide an adequate programming model for developing applications: it should not be directly used by a programmer. L 2 C is intended to be used as a target model by a compiler. For example, we use L 2 C in conjunction of High Level Component Model (HLCM) [START_REF] Bigot | On High Performance Composition Operators in Component Models[END_REF]. HLCM is an abstract component model that supports hierarchy, genericity, connectors, and component and connector implementation choice. Being abstract, HLCM needs a transformation process to generate a concrete application. During this phase, resource specificities can be taken into account.

However, before developing optimization algorithms for such a compiler, the question this paper aims to answer is whether L 2 C can provide high enough performances and to studies which kinds of L 2 C assemblies are well suited for various kinds of resource infrastructures. This evaluation is performed on a well known discrete differential equation approach, the heat equation using the Jacobi method.

The remaining of the paper is organized as follow: Section 2 presents the background and the related work while Section 3 describes L 2 C. Section 4 analyzes how L 2 C can be used to efficiently implement multiple variations of a benchmark Jacobi application on various hardware resources while Section 5 experimentally evaluates some metrics such as code reuse, performance, overhead and complexity. The applicability of the approach to a real world application is discussed in Section 6. Section 7 concludes the paper.

Background

This section introduces some challenges for the programming models of high performance computing applications and analyzes related work.

Programming Model Challenges

Scientific applications offer a complex challenge from a programming model point of view. Firstly, they require high computing power, which means that the programming model should introduce as little overhead as possible and that fine tuning is needed to take advantage of the hardware used to execute them. Secondly, their long life cycle means that they will very likely run on a wide range of parallel architectures ranging from supercomputers to clusters of NUMA nodes but also to future generation hardware not yet designed. Moreover, specialists of the simulated domain are usually not parallel computer experts.

For example, many real world phenomena can be simulated by the resolution of partial differential equations. A common approach is to use the finite difference method that offers a good spatial and temporal locality. It is usually parallelized using a decomposition of the spatial domain into subdomains, where each subdomain is assigned to a computing core. The computation iterates over time and the value of each subdomain is computed based on the value of this subdomain and its neighbors at the previous iteration.

However, many variations of the hardware can impact the performance of the application such as the number of cores, their computing power and their amount of memory. Another variation concerns the interconnection between these cores, with shared memory or via a network, the affinity between memory banks and cores [START_REF] Ribeiro | Improving Memory Affinity of Geophysics Applications on NUMA Platforms Using Minas[END_REF] and the network topology.

These hardware variations require adaptations of the application to provide high performance. For example, for an application based on domain decomposition as previously introduces, the number of threads, the subdomains they handle and their placement on computing cores have to be chosen. Communications methods must also be chosen. They can include implicit memory sharing with synchronization, in-memory copy or message passing over a high speed network or a wide area network. The most efficient approach for a particular configuration may require a combination of several methods.

In order to support these variations, a programming model should ease the adaptation of applications to various hardware resources with the high-est possible degree of reuse between versions, while not impacting performance or ease of development. This means that the model should support the separation of concern between the development of simulated domain specific code and optimizations for the various hardware architectures. The next subsection presents how existing programming models handle the separation of concern, performance and ease of development.

Existing programming models

Infrastructure specialized models A very common programming model for parallel applications is the use of a message passing library such as MPI [START_REF] Gropp | Using MPI: Portable Parallel Programming with the Message-Passing Interface[END_REF]. Such a library offers a quite low level of abstraction to the developers but for collective operations. However, MPI assumed a flat and homogeneous network model between processes. Thus, complex strategies have to be designed to adapt an application to hardware [START_REF] Jeannot | Near-optimal placement of MPI processes on hierarchical NUMA architectures[END_REF] with few possibilities to let an application self-adapt to resources [START_REF] Karonis | MPICH-G2: A Grid-enabled implementation of the Message Passing Interface[END_REF].

A second common programming model is multithreading which enables to efficiently make use of shared memory multi-core machines. Synchronization primitives such as POSIX Threads [START_REF] Butenhof | Programming with POSIX threads[END_REF] also offer a level of abstraction very close to the hardware. Although there is many research work, there is not yet a standard for managing memory placement. As multithreading programming is difficult and error prone, many developers adopt a higher level language such as OpenMP [START_REF] Barbara | Using OpenMP: Portable Shared Memory Parallel Programming (Scientific and Engineering Computation)[END_REF]. From the point of view of the domain code developer, an OpenMP parallel program may look like similar to its sequential counterpart. In the case of the domain decomposition code, it consists in adding a few annotations to the code to let the loops that iterate over the domain be parallel and to control the degree of parallelism.

As one of the main computing infrastructures is interconnected multicore machines, applications based on MPI and OpenMP is an active field of research. MPI and OpenMP support two complementary models of parallelism. It must however be noted that both models require modifications waved with the domain code.

Thus, depending on the targeted machine, applications need quite a large effort to be adapted to MPI, Pthreads, OpenMP, or a mixed of these. This has even become worst with the advent of Inria GPGPUs that add another programming model, usually Cuda or OpenCL or now OpenACC. However, some work aims to transparently handle GPGPU through OpenMP [START_REF] Seyong | OpenMP to GPGPU: a compiler framework for automatic translation and optimization[END_REF].

Infrastructure agnostic models Some parallel programming models such as Charm++ [START_REF] Kale | Programming Petascale Applications with Charm++ and AMPI[END_REF] or more generally Partitioned Global Address Space (PGAS) languages such as UPC or Co-Array fortran [START_REF] Coarfa | An evaluation of global address space languages: co-array fortran and unified parallel C[END_REF] aim at offering a model that is able to compile and execute on various infrastructures. While this goal seems to be reached, it lacks a simple model for code reuse and maintenance [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF]: they do not offer any mechanism to deal with the architecture of an application.

Software Component Models Software component models have been seen as an improvement over object oriented programming as they enable to manage the architecture of an application [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF]. Many large sequential codes such as Eclipse (OSGi [START_REF]OSGi Service Platform Specifications[END_REF]), Firefox (XPCOM [START_REF] Mozilla | The XPCom projet[END_REF]) or OpenOffice (UNO [START_REF]UNO Component Model[END_REF]) are based on component models. Similarly, there are specialized models for distributed computing such as the Corba Component Model (CCM) [START_REF]Object Management Group,Common Object Request Broker Architecture Specification, Version 3.1[END_REF] or the Grid Component Model (GCM) [START_REF] Baude | GCM: A Grid Extension to F RACTAL for Autonomous Distributed Components[END_REF]. These models support decomposition of applications as independent components that interact through a set of well defined interfaces.

However, these models only enable to describe a concrete component assembly, i.e. an assembly where all components are primitive and so also connections between them. GCM provides some supports for adaptability by enabling to control the mapping between abstract component containers and runtime containers [START_REF] Baude | GCM: A Grid Extension to F RACTAL for Autonomous Distributed Components[END_REF]. Therefore, it enables the optimization of the placement of components on available resources. Another issue is that to be portable most of these models usually fix the kinds of supported interactions: usually they only support remote method invocation (RMI) with some support for heterogeneity, such as OMG IDL for CCM. However, it adds unnecessary overhead for components written with the same programming language and collocated within the same process, for example.

To satisfy the constrains of HPC applications, dedicated models have been proposed. A well-known model is the Common Component Architecture (CCA) [START_REF] Allan | A Component Architecture for High-Performance Scientific Computing[END_REF]. Some implementations such as Ccafeine have been conceived as process-local (i.e. without network transparency) in order to minimize runtime overhead. Support for interlanguage calls is provided by the Babel library that is used for inter-components interactions. When support for remote method invocations in addition to inter-language calls has been added to Babel it has made its way into Ccafeine. Though quite small, Babel still introduces overheads for calls between components located within the same process that limit the granularity of Ccafeine components. For parallelism oriented interactions, CCA components are expected to rely on external models such as MPI, but it does not appear in the interface of components. Thus, it does not help a lot to adapt an application to various machines as parallelism support is basically the same as with a pure MPI approach.

Analysis Models or API such as OpenMP, MPI and their combinations can be well suited for a specific kind of hardware respectively. Component models offer an interesting approach to let applications be adaptable. However, existing component models either imply too much overhead at execution for HPC applications or do not offer enough abstraction to let application be efficiently adapted to different hardware resources.

3 Low Level Component Model (L 2 C)
An application can make use of various kinds of interactions that range from local method calls to interactions with language and network transparency such as MPI or Corba and intermediate choices in term of overhead and functionality such as Babel. The choice of a given type of interaction for intercomponent communications impose for the component model designers to make a choice between efficiency and portability. There is not any good trade-off as these two properties are usually not compatible.

We advocate for another approach that consists in relying on a compilation process that enables to define a component model for program-mers and another component model for execution. A transformation process is responsible for generating the "executable" assembly from a "source" assembly. The definition of a component model for the "source" assembly is out of scope of this paper. An example of such model is High Level Component Model (HLCM) [START_REF] Bigot | On High Performance Composition Operators in Component Models[END_REF].

A consequence of the proposed approach is that a model for the "executable" is also needed. As this model is not intended to be used by a programmer, its main property shall be to support native intercomponent communications. Therefore it shall be able to support different forms of interactions. This is the goal of the Low Level Components (L 2 C) model.

Overview of the L 2 C model

The Low Level Components (L 2 C) is a model that we designed to support multiple kinds of interactions between components with runtime overhead reduced to their minimum. This is achieved by having a very simple runtime with only three operations: component creation and destruction, component configuration (include connection establishment), and the transfer of the initial control to at most one component instance in each process. Once the control has been passed to a component, no more L 2 C code is encountered in the execution path, thus ensuring the absence of L 2 C related overhead after deployment.

A L 2 C component is described by some very lightweight metadata in the code. It enables it to be instantiated, destroyed and gives read or write access to configurable elements. The read accesses enable to retrieve information from the components, usually in order to configure another instance. The write accesses enable to configure the component with user provided data or to configure it with elements coming from another component for connection purpose.

For example, the current L 2 C implementation supports three kinds of interactions: C++, Corba, and MPI. C++ local method calls are supported by copying a pointer from the component providing the service to the component using the service. Ongoing work is applying the same approach to fortran interactions. Corba inter-process method calls are supported by similarly copying Corba references. MPI communications are supported by providing a MPI communicator though a point of interaction representing a communication group. Adding support for new kinds of interactions does not require any complex change to the implementation. It may just need some code to simplify the handling of the new type of element that should be configured.

An L 2 C application can be build by programming, using an API to create and connect components. A more suitable alternative for our approach is to describe an L 2 C assembly through a dedicated (XML) file. Such a file contains a complete description of component instances and connections.

Details on the implementation of L 2 C can be found at the website http://hlcm.gforge.inria. fr/l2c:start.

Discussion

L 2 C is a very basic component model, that only differs from other component models by its abilities to define setter and getter operations associated to interactions points. Hence, it does not limit the kinds of interactions it supports. This property was looked after to be able to add other kinds of primitive interactions without adding runtime overhead.

As L 2 C aims to describe a version of application specific to a given machine, L 2 C is not intended to be directly used by a programmer. It is intended to be used as the output of a compilation/transformation process. In particular, L 2 C was designed to be the target model of HLCM [START_REF] Bigot | On High Performance Composition Operators in Component Models[END_REF][START_REF] Bigot | Enabling Connectors in Hierarchical Component Models[END_REF], a high level component model, though it is not specific to HLCM.

Usability of L 2 C on a Jacobi application

In order to evaluate the advantages of L forall pos ∈ DOM AIN do 3:

domain i [pos] ← f (domain i-1 , pos) 4:
end for 5: end for memory usage by allocating only two matrices and reusing them.

In order to take advantage of parallel resources, this algorithm can be parallelized by adopting a domain decomposition approach. This is possible because there are no data dependencies between the various operations executed in a single iteration of the external loop (Line 1). In this specific case, the domain specific code is the function f , so it is rather easy.

For a shared memory target machine, this can be done using OpenMP by adding a parallel for annotation to the loop of Line 2. A finer grain of control can be attained to better fit to hardware by explicitly iterating over subdomains and letting this loop be parallel as illustrated by Algorithm 2.

Algorithm 2 Parallel finite difference computation. The parallel loop over subdomains (Line 2) let the workload be distributed over the computing cores.

1:

for i ← 1 to N do 2:
forall subdomain ∈ sub(DOM AIN ) do 3:

forall pos ∈ subdomain do 4:

domain i [pos] ← f (domain i-1 , pos) 5:
end for

6:
end for 7: end for Memory can be handled in two different ways. A first approach is to allocate the whole domain matrix in a single block. In this case, some synchronizations should be used to ensure that all data have been computed before they are accessed (this can be done with a barrier at each iteration of the external loop). A second approach consists in allocating the domain matrix in multiple blocks, one for each thread. In this case, ghost/overlap zones are welcome: data must be exchanged at the end of each external iteration to ensure consistency. These exchanges also enable to synchronize the various control flows.

The same approach can be used for a distributed memory machine using MPI but it will require to explicitly manage communications.

However, in practice, there is a problem to make scientific applications parallelized. Usually the sequential code is implemented by a specialist of the studied domain. Then, various parallel versions (OpenMP, MPI, ...) are derived from the sequential version by various parallel experts depending of the targeted hardware. However, the sequential code continues to evolve, either to fix bug or to add support for additional aspects of the simulation. Porting such modifications to the parallel versions is usually cumbersome because of the divergence of the codes.

A first L 2 C version of the domain decomposition code

Our goal is to study how to define component assemblies of this application for various kinds of machines -from sequential to various form of parallel machines -while trying to maximize code reuse and separation of concerns. All assemblies and component presented in this section have been implemented and are evaluated in Section 5.

Base (sequential) component version

Six elements of the application architecture can be identified:

1. the main application that at some point uses the domain decomposition algorithm, 2. memory allocation for the matrices, 3. iterations over the time dimension, 4. possibly parallel iterations over the subdomains, 5. iterations over the space dimension, 6. computation of the value at a given position.

Among those, the second and fourth depend on the parallelization choice. A possible L 2 C decomposition of such an application that isolates code linked to parallelism is presented in Figure 1. All connections are C++ interfaces.

Main

Driver Core

Shared memory parallelization

The shared memory parallelization of this code has been implemented by a version of the Driver component called ThreadDriver that relies on the POSIX thread library. It is based on a parallel loop over the subdomains handled by a distinct thread each. Each thread of computation iterates over the time dimension and at each iteration it uses a specific instance of the Core component to compute the next iteration. At the end of each iteration, a barrier ensures that the whole domain has been computed. Algorithm 4 describes the pseudocode of the ThreadDriver component and the complete architecture of the application for four subdomains/threads is presented in Figure 2.

Distributed memory parallelization

The distributed memory parallelization of this code is implemented by a version of the Driver component called MpiDriver that uses MPI for inter-process communication. An instance of this MpiDriver component run in each process together with a Core instance. Algorithm 5 describes MpiDriver component in pseudo-code. The master MpiDriver component that gets called by the Main component broadcasts information it has received and lets each instance computes the subdomain it handles. Each Inria MpiDriver instance then iterates over the time dimension and at each iteration it make use of its bound Core component. At the end of each iteration, overlapping data are exchanged between the MpiDriver instances responsible of neighboring subdomains. The architecture of an application for four subdomains/processes is presented in Figure 3.

Algorithm 5 Algorithm of the distributed memory MpiDriver component. The memory allocation is done locally by each process and it includes the frontiers as shown on Line 3. The data synchronizations between processes are handled by the MPI exchange on Line 6 (typically, this would consists in 2D isend/ireceive groups where D is the number of dimension of the simulation.

Discussion

This section has studied how components can be used to wrap the typical codes one would find for parallel domain decomposition of a finite difference code. By identifying the code that depends of the parallelization in a Driver component, this approach makes it possible to reuse the domain specific code of the Main and Core components in sev-eral parallel versions. However, while the two approaches (shared memory and distributed memory) have been implemented, the question arises in situations in which one would like to combine both approaches. In order to use shared memory inside a node and distributed memory between nodes in a multicore cluster, one would have to implement yet another variation of the driver.

As this driver would combine the two approaches used in ThreadDriver and MpiDriver, one would like to reuse these codes. However, since these components offer an interface distinct from the one they use, they cannot be combined. The next section analyses and proposes a more modular architecture that makes the combination of multiple parallelization approaches possible.

A modular L 2 C version of the domain decomposition code

To increase code reuse among the various parallelization approaches, one has to decompose the aspects handled by the various Driver components at a finer grain. From what has been presented in the previous section, three aspects can be identified:

1. memory allocation; 2. iteration over the time dimension; 3. management of the decomposition, i.e. neighbor interactions.

Separating these three concerns in three distinct components enables the creation of assemblies combining them in various ways thus increasing code reuse compared to a more monolithic approach where each combination requires the development of a new Driver component.

In the previous approach, the (Thread)Driver component (or the set of fully interconnected MpiDriver instances) handled the interactions between all subdomains. In order to enable the choice of interaction implementations at a finer grain, including multiple distinct implementations in a single application, a new approach is proposed. It relies on components supporting interactions between a pair of domains each. These components offer an implementation agnostic C++ interface Exchange that comprises methods to:

1. notify the availability of the data of a given iteration;

2. specify where the data from the neighbor is expected; 3. wait for the data from the neighbor; 4. request authorization to reuse a memory space exposed via the first method.

With this approach, the iteration over the time dimension can be implemented independently of the parallelization. This is the role of the JacobiCoreNiter component. It exposes a service through a C++ interface ComputerNiter very similar to the Computer interface described in Section 4.1.1. Through this interface, a memory space on which to operate is specified but also a number of iterations to execute. At each iteration, ComputerNiter makes a call to the Computer interface to compute the data for the next iteration and makes exchanges with its neighbors via four exchange interfaces.

Finally, the memory allocation can be done after receiving a description of the domain via the XPComputer interface previously identified, and before calling the ComputerNiter to compute over this domain.

Shared memory parallelization

In order to support shared memory parallelism, the ThreadXp component is responsible for memory allocation. It also creates multiple threads that operate on the memory space it has allocated.

The interactions between each pair of neighboring components requires no memory copy, only synchronization. This is what a ThreadConnector component implements. It exposes four services Exchange, once for each of the four neighbor components in the 2D case. The "receive" operation shall just wait for the data to be available. It is implemented by waiting for the other neighbors to call the "send" operation that specifies that the data is available.

In order to implement the whole application based on these components, one instance of the ThreadXp component is created. It executes in parallel a set of instance of JacobiCoreNiter component organized in a grid together with the Cores on which they depend. Then neighboring JacobiCoreNiter components are connected through a ThreadConnector. This complete architecture for four subdomains/threads is presented in Figure 4.

Distributed memory parallelization

In the distributed memory case, there are multiple components responsible for memory allocation that run in a distinct process respectively. The ThreadXp component with a number of threads to create set to 1 could be used. However, this would imply a dependency on the pthread library that might not be available. A version that does not support threads at all, simply called Xp has thus been created. In this case however, interactions require memory copy across the process frontiers. This can not be achieved with a single component instance but requires two component instances, one in each process. The component MpiConnector relies on MPI to implement this behavior. It exposes a single instance of the Exchange service and relies on a MPI communicator to interact with the MpiConnector of the neighboring component. It maps the various operations of the Exchange interface on the corresponding asynchronous exchange methods of MPI.

The architecture of the whole application based on these component consists in a grid of processes containing one instance of the Xp, JacobiCoreNiter and Core components each.

Neighboring JacobiCoreNiter components are connected by a pair of MpiConnector component instances. The architecture for four domains/processes is displayed in Figure 5.

Hierarchic parallelization

No additional component is needed to support a two level hierarchy infrastructure with MPI used between nodes of a cluster and shared memory used within nodes. One ThreadXp instance is used inside each process to allocate memory and create the threads. Interactions between components depend on whether two neighboring component share the same memory space or not.

If they do, a ThreadConnector component is used while if they do not, a pair of MpiConnector components is used. It results in the architecture described in Figure 6.

Single process multiple memory allocation

Another variation that can be easily implemented is a version with multiple threads in a single process but that does not share a single memory allocation. In this case, the interactions between neighbors require a data copy but this copy does not require the use of MPI. A CopyConnector component has been implemented that exposes the same Exchange interface and it is used similarly as ThreadConnector except that it makes a call to memcopy to copy the data. The addition of this simple new component makes it possible to implement many new variations and combinations, such as a three level hierarchy: multiple processes (interconnected with MPI) containing several distinct memory allocations but with several threads attached to each memory allocation. It can be relevant for clusters with large NUMA nodes.

Discussion

This section has shown that introducing components in an application can increase code reuse between various variations of hardware resources. A first step is to simply wrap code inside components keeping the legacy architecture. It enables the identification of the hardware induced variability in a component and its replacement independently of the domain specific code. A finer analysis and adaptation of the application architecture enables the identification of various aspects of variability at a finer grain, regarding memory allocation and interactions between threads of computation. This further increases reuse and adaptability to specific hardware resources by enabling multiple combinations of these choices at various levels. These variations can be described by L 2 C assemblies. However, they become more and more complex when the amount of points of variation increases as can be seen in the various figures. Each variation is described by a distinct assembly which means that a new point of variability may be introduced by a hardware specificity. That is why L 2 C assemblies are not intended to be written by a programmer but should be generated by a compiler.

We can observe that there are a lot of similarity in these assemblies, both inside each assembly (e.g. the code running on each process) and between assemblies targeted at distinct hardware. Thus, with a careful design, code reuse and maintenance can be greatly improve. Let next section quantitatively evaluates this.

Experimental Evaluation

This section evaluates the approach proposed by this paper. It is based on the implementations of the Jacobi domain decomposition application mentioned in the previous section. Table 1 sums up the resource architectures used for the experiments: sequential, shared memory, distributed memory and hierarchical architecture. Experiments have been done on a multi-core based cluster (Griffon) of Grid'5000 made of 92 nodes, with 4 cores per CPU, 2 CPUs, 16 GB RAM. Nodes are interconnected with an Infiniband-20G network. MPI enabled components are used for the uni-core based cluster; multi thread based components are used for multi-core node. For the multi-core based cluster, a two level hierarchical model is provided with MPI used between nodes and shared memory used inside the multi-core nodes.

To evaluate the proposed approach, five criteria are studied: code reuse, speedup, performance, performance overhead, cyclomatic complexity.

The main advantage of our approach is the level of code reuse made possible: this is our first criteria of evaluation. Another important aspect in HPC is the efficiency of the code. This is evaluated by three criteria: the raw performances of the application, the speedup when parallelizing and the overhead due to the component approach in comparison to a legacy version of the code. Finally, the last criterion is the cyclomatic complexity of the codes.

Code Reuse

As shown in Section 4, designing application using component model increases code reuse. To quantify code reuse, we firstly count the number of lines of code in the non-component version of the Jacobi application. Table 2 presents these results.

Table 3 presents the number of lines for different component versions of Jacobi described in Section 4. "Driver" stands for the version based on the wrapping of legacy code in components. "Connector" stands for the advanced version. From the table, we can see the number of lines for each basic component. The table also mentions which components were reused from the sequential component assemblies. Let analyze it by assembly kind.

Driver versions As described in Section 4, the sequential version of the component based application is made of three components: Main, SeqDriver and JacobiCore. The total number of code lines is 239. The multithreaded version of the component based application is also made of three components: Main, ThreadDriver and JacobiCore for a total of 405 lines of code. The MPI version is still made of three components: Main, MpiDriver and JacobiCore which accounts for 285 lines of codes. The total numbers of lines are of the same order of magnitude than the non component version but components enable reuse: The Main and JacobiCore components are shared between the three versions. This results in a rate of reuse of 26% between the sequential and multi-threaded versions and 32% between the sequential and MPI

Inria

Speedup

An important aspect of HPC is the ability to efficiently use hardware resources. This means that the application performances should scale gracefully with the number of computing core available. Figure 7 displays the speedup and the efficiency obtained for various version of the Jacobi applica- tion on various deployment scenarios. The horizontal axis represents different parallelisms with several size of the array of Jacobi application. The threads and processes scenarios are obtained using one node. For multi-node scenarios, a core per node is used unless specified: 8x2 means using 8 nodes and 2 cores per node. The left vertical axis is the speedup while the right vertical axis is the parallel efficiency.

The main objective of this experiment is to show that similar performance than native applications can be obtain with the L 2 C component based versions and that all versions can achieve very good efficiency but for some situations: when using 8 cores per node -either 8 threads or 8 processesthe efficiency drops because of a problem of memory bandwidth. Too many cores access the main memory. The next section goes further in the de-

Performance overhead

Figure 8 reports results obtained without components, with the monolithic driver and with the connector based versions on the configuration than the previous experiments. However, it shows the duration (in nano seconds) for the computation of one cell of the array per core. The results are in accordance with the previous speedup figure. One can see that memory contention appears when more than two threads access the same memory. It is acceptable for 4 cores but not for 8 cores.

Figure 9 display the same experiment results but normalized with respect to the non component version. It shows that the overhead of the component version is always below 1%. In some cases, the component based application is even better than the native application. However, as it is in the range of 1.5 %, it does some relevant.

From these experiments, we can conclude that the Jacobi application can be turns into a component one without impacting performance. If choos- ing carefully the number of active core per node, the time to compute a matrix cell can be the same as the sequential version (considering a large enough data size).

Multi-core Performance

To better understand how to tune the application to maximize performance, some experiments were conducted with different threads with a one node and a multi-node scenarios: the expected increase of the duration to compute a matrix cell when increasing the number of cores inside one node may be compensated by the increase of parallelism.

Figure 10 presents the result for a cluster with 8 cores per node. 8 threads usually get the best speedup, while 4 threads is a better choice considering it is about the speedup and thus a much higher efficiency. The array size is fixed to 22016 × 22016. Under this strong scaling, the best configuration is usually achieved with four threads per node. Component versions performs similarly than native versions. For the 256 core experiments, each core handle less than 16 MB of data.

Strong Scalability

Cyclomatic Complexity

The cyclomatic complexity is a measurement of the complexity of a code. It measures the number of linearly independent paths through the source code. We computed the cyclomatic complexity using pmccabe, a standard package to calculate cyclomatic complexity.

Table 4 shows the total cyclomatic complexity of non component and component codes. Components reduces the cyclomatic complexity because of their promotion of separation of concerns. Only the driver version of component model increases the cyclomatic complexity compared with native code. It is due to the integration of many functions into one big component.

Discussion

The proposed L 2 C model enable to increase code reuse, to reduce code complexity and to achieve the 6 Application to A Domain Specific Application NEMO [START_REF] Madec | NEMO ocean engine, Note du Pole de modélisation[END_REF] is an ocean modeling framework which is composed of "engines" nested in an "environment". The "engines" provide numerical solutions of ocean, sea-ice, tracers and biochemistry equations and their related physics. The "environment" consists of the pre-and post-processing tools, the interface to the other components of the Earth System, the user interface, the computer dependent functions and the documentation of the system. It is written in fortran 90 and parallelized using MPI with a regular domain decomposition in latitude/longitude. The governing equations are solved in finite-difference form upon a tri-polar 'ORCA' grid to get rid of the north pole singularity. With respect to our goal, this application is very similar to the considered Jacobi application. We are currently applying the experience gained with it to modify NEMO so as to study auto-tuning on specific hardware platforms, especially on petascale super-computers.

Conclusion

For the development and adaptability of high performance computing applications on various hardware resources, we proposed and evaluated a low level component model (L 2 C) enabling resource specialization. L 2 C supports multiple kinds of interactions between components with runtime overhead reduced to their minimum. Its evaluations have been conducted on some typical hardware architectures with respect to a well-known benchmark Jacobi application. The experimental results demonstrate that L 2 C succeeds in implementing the separation of concern between domain specific codes and hardware specific codes. It is adaptable to different specific hardware resources. Moreover it brings the benefit of code reuse, without degrading performances.

While L 2 C makes it possible to describe the architecture of a parallel application based on local method calls, MPI and Corba, it does not support adaptation to hardware by itself. It has to be used in conjunction of a more abstract model, such as HLCM whose role is to generate these hardware specific concrete assemblies. Future work include developing auto-tuning algorithms for HLCM to be able to generate well suited L 2 C assemblies for Jacobi but also for NEMO for different kinds of hardware platforms.

Figure 1 :Algorithm 3

 13 Figure 1: Application architecture based on three components. Only the Driver component is specific to a given parallelization strategy.

Algorithm 4 Figure 2 :

 42 Figure 2: Application architecture with four threads of computation running in parallel for a shared memory machine. Each instance of the Core component runs in a distinct thread created by the ThreadDriver component.

Figure 3 :

 3 Figure 3: Application architecture with four domains/processes running in parallel in distinct memory space.

Figure 4 :Figure 5 :

 45 Figure 4: Application architecture with four threads running in parallel in a shared memory space. Only neighboring computational components are connected. PCD stands for Posix-ThreadConnector.

Figure 6 :

 6 Figure 6: Application architecture with four processes running in parallel containing four threads each.

Figure 7 :

 7 Figure 7: Speedup of the Jacobi HPC application with a feasible scalability.

Figure 8 :

 8 Figure 8: Duration in nanoseconds for the computation of one cell normalized with respect to the number of core used.

Figure 9 :

 9 Figure 9: Overhead by percentage of the component model based application against native application

Figure 10 :

 10 Figure 10: Jacobi speedup and efficiency for 1 to 8 threads per node.

Figure 11 :

 11 Figure 11: Performance of the benchmark Jacobi HPC application for selected non component and component applications (strong scalability).

Figure 11

 11 Figure 11 presents the results obtained for native implementations (threads or MPI) and for some selected component assemblies (Connector version). The array size is fixed to 22016 × 22016. Under this strong scaling, the best configuration is usually achieved with four threads per node. Component versions performs similarly than native versions. For the 256 core experiments, each core handle less than 16 MB of data.

Table 1 :

 1

	Hardware Resource Architectures
	Hardware Architecture	Application version
	Single node, single core	Sequential version
	Single node, multi-core	Multithreaded version
	Multi-node, single core	MPI version
	Multi-node, multi-core hierarchical version (MPI + multithread)

Table 2 :

 2 Number of lines for the various versions.

	Jacobi Version	Number of lines (C++ code)
		Non component Driver Connector
	Sequential	161	239	388
	Multithreaded	338	386	643
	MPI	261	285	446

Table 3 :

 3 Detailed SLOC for all components.Connector versions For the second approach, the sequential version requires the XP and JacobiCoreNiter components in addition to Main and JacobiCore. The multithreaded version is based on the ThreadXP and ThreadConnector components, while the MPI version is based on the XP and MpiConnector components. The hierarchical version uses the XP, MpiConnector and ThreadConnector components. Code reuse between the sequential and multithreaded versions is 31% and it is 87% between the sequential and MPI versions. The hierarchical version does not require any new code, just a new component composition. The rate of reuse is thus 100% with respect to the multithread and MPI versions.Components increases reuse of code. Indeed, the basic component (Jacobi algorithm in JacobiCore component) is used in all of the component based applications. If changes are needed to the Jacobi algorithm, only this component has to be modified. Separation of concerns into components can help to quickly and simply create applications.

	Assembly Version	Component Name SLOC Reused from
				seq. version
	Driver & Connector	JacobiCore	25	yes
	Driver & Connector	DataInitializer	68	yes
	Driver & Connector	Main	105	yes
	Driver	SeqDriver	109
	Driver	MpiDriver	155
	Driver	ThreadDriver	256
	Connector	XP	71	yes
	Connector	JacobiCoreNiter	187	yes
	Connector	ThreadXP	186
	Connector	ThreadConnector	140
	Connector	MpiConnector	58
	versions.

Table 4 :

 4 Cyclomatic complexity of the component model based codes and native codes However, the component model introduces a new task to be done: to turn an existing code into a component based code, in addition of creating the components, ones needs to describe an assembly for each specific hardware architecture. As it is very fastidious and error prone, such assembly description should be automatically generated. This is one of the purposes of HLCM[START_REF] Bigot | On High Performance Composition Operators in Component Models[END_REF].

	Version	No Compo. Driver Connector
	Sequential	28	32	8
	Threaded	76	41	26
	MPI	55	22	13
	same performance than non component versions.

RR n°7966

Acknowledgment

The authors would like to thank PRACE association (see http://www.prace-ri.eu) for the support to the work. And experiments presented in this paper were carried out using the Grid'5000 experimental testbed, being developed under the INRIA ALADDIN development action with support from CNRS, RENATER and several Universities as well as other funding bodies (see https://www.grid5000.fr).


Salman Salman

Hervé Folliot
email: herve.folliot@insa-rennes.fr

Julie Le Pouliquen

Nicolas Chevalier

Tony Rohel

Cyril Paranthoën

Nicolas Bertru

Christophe Labbé

Antoine Létoublon

Alain Le Corre

A Letoublon

Thermal conductivity of InAs quantum dot stacks using AlAs strain compensating layers on InP substrate

Keywords: Thermoelectricity, InP substrate, InAs quantum dots, thermal conductivity

Introduction

*Text Only Click here to view linked References

The performance of thermoelectric materials depends on the figure-of-merit ZT, which is defined as ZT = S 2 VT/O, where S is the Seebeck coefficient, V the electrical conductivity, O the thermal conductivity, and T is the absolute temperature. To obtain the highest figure of merit, the power factor defined as S²V must be maximized and in the meantime the thermal conductivity must be minimized.

Several approaches have led to an enhancement of the figure of merit. Most of them have relied on the reduction of the thermal conductivity of conventional thermoelectric materials (e.g. BiTe/BiSbTe) by introducing various phonon scattering nanometre scaled defects including precipitates, grain boundaries, or superlattices. Epitaxial semiconductor nanostructures have been evidenced as very good candidates for obtaining a high figure of merit [START_REF] Pichanusakorn | Nanostructured thermoelectrics[END_REF]. Bi 2 Te 3 /Sb 2 Te 3 superlattices have been reported to have a ZT~2.4 at 300K [START_REF] Venkatasubramanian | Thinfilm thermoelectric devices with high room-temperature figures of merit[END_REF],

while PbSeTe based quantum dots have reached a ZT up to 3 at 550K [START_REF] Harman | Nanostructured thermoelectric materials[END_REF]. Ge QDs on Si with 3nm spacing layers have also shown a clear reduction in thermal conductivity (<1W/mK) [START_REF] Pernot | Precise control of thermal conductivity at the nanoscale through individual phonon-scattering barriers[END_REF] which is a promising result for applications in thermoelectricity.

Looking at the III-V compounds family, InP and GaAs based quantum wells have fist attracted some attention for monolithic thermal cooling of laser diodes [START_REF] Zhang | AlGaAs superlattice microcoolers[END_REF]. If theoretical studies on the thermoelectric properties of III-V QDs have been proposed [START_REF] Fomin | Thermoelectric transport in periodic one-dimensional stacks of InAs/GaAs quantum dots[END_REF][START_REF] Yadav | Thermoelectric properties of quantum dot chains[END_REF], very little thermal conductivity experimental data of such QDs are reported to our knowledge.

Recently, high quality ErAs nano-inclusions in AlGaInAs alloys grown on InP susbtrate have been proposed and succesfully applied to thermoelectric applications. A ZT=1.3 at 800K has been demonstrated [START_REF] Zide | High efficiency semimetal/semiconductor nanocomposite thermoelectric materials[END_REF]. A route not yet explored is based on stacks of Stranski-Krastanov InAs nanostructures on InP substrate grown by molecular beam epitaxy (MBE). Owing to a relative small lattice mismatch (3.2%), different nanostructure morphologies have been evidenced in this system. On exactly oriented (100) surface, Quantum Dashes (QDashes) or quantum wires (QWires) elongated along the [START_REF] Pichanusakorn | Nanostructured thermoelectrics[END_REF][START_REF] Venkatasubramanian | Thinfilm thermoelectric devices with high room-temperature figures of merit[END_REF][START_REF] Harman | Nanostructured thermoelectric materials[END_REF][START_REF] Pernot | Precise control of thermal conductivity at the nanoscale through individual phonon-scattering barriers[END_REF][START_REF] Zhang | AlGaAs superlattice microcoolers[END_REF][START_REF] Fomin | Thermoelectric transport in periodic one-dimensional stacks of InAs/GaAs quantum dots[END_REF][START_REF] Yadav | Thermoelectric properties of quantum dot chains[END_REF][START_REF] Zide | High efficiency semimetal/semiconductor nanocomposite thermoelectric materials[END_REF][START_REF] Notzel Sritirawisarn | InAs/InP Quantum Dots, Dashes, and Ordered Arrays[END_REF][START_REF] Oshima | Optical properties of stacked InAs self-organized quantum dots on InP (3 1 1)B[END_REF] direction nanostructures are easily obtained. The control and preservation of the morphology and the density from layer to layer when close stacking is however difficult [START_REF] Notzel Sritirawisarn | InAs/InP Quantum Dots, Dashes, and Ordered Arrays[END_REF]. On (113)B substrate however, well resolved QD facets are generally observed due to a higher buffer layer surface energy. This surface orientation is thus more favourable to control the stack of InAs QDs with reproducible morphologies from layer to layer. For instance, a stack of 150 InAs QD layers with 20nm spacers grown by MBE has been realised [START_REF] Oshima | Optical properties of stacked InAs self-organized quantum dots on InP (3 1 1)B[END_REF].

Moreover, it is well known that strain accumulation during QD stack growth leads to surface degradation, or more severely, creation of defects, such as misfit dislocations. Dislocations are known to reduce the thermal conductivity [START_REF] Watling | A study of the impact of dislocations on the thermoelectric properties of quantum wells in the Si/SiGe materials system[END_REF] when present in rather high density, but are also responsible of a reduction of carrier mobility and sometimes also act as deep levels or conductive carrier channels. These dislocations are thus generally detrimental to thermoelectric performances of semiconductor materials.

Therefore, the stack of self assembled QDs generally requires a strain compensation technique.

We here show that by balancing the compressively strained Stranski-Krastanow InAs quantum dots using AlAs tensile strained layers, a high number of closely stacked quantum dot layers with good quality can be obtained.

In the following, the 3Z thermal conductivity measurement method is briefly presented and first applied to Si and InP substrate. The insulating Si x N y layer is also characterized in terms of thermal conductivity and interface thermal resistance. The growth of InAs QD stacks using AlAs as strain compensating layers is then presented. AFM imaging is used for structural analysis on two stacks of 20 QD layers, with and without insertion of the strain compensating layers. X-Ray analysis is used to analyse the structural quality of a stack of 100 QD layers and Photoluminescence (PL) measurement is performed to reveal the optical quality of the layers.

The thermal conductivity of this stack is measured and shows a clear reduction when compared to a bulk lattice-matched GaInAs.

ZT figure of merit of InAs/InP nanostructures for thermoelectric generation is finally discussed.

Thermal conductivity measurements using the 3Z method 2.1 Experimental details

The thermal conductivity measurements were performed using the so called "3Z method" developed by Cahill [START_REF] David | Thermal conductivity measurement from 30 to 750 K: the 3ω method[END_REF] with a modified model by Borca-Tasciuc to take into account the finite thickness of the substrate and adiabatic boundary conditions [START_REF] Borca-Tasciuc | Data reduction in 3ω method for thin-film thermal conductivity determination[END_REF]. This method has proven to be well suited for epitaxial films. Basically, it consists in measuring the temperature rise in a metal line driven by an AC current, which simultaneously acts as a heater and a thermometer, as a function of the current frequency.

All samples were prepared using the same method. Typically, a 200 nm silicon nitride (Si x N y ) insulating layer was deposited by PECVD (Plasma Enhanced Chemical Vapor Deposition) at 250°C. A Ti(20nm)/Au(200nm) was subsequently deposited by e-beam evaporation and liftoff processed, resulting into a 10mm long and 20µm wide heating metallic stripe with two 2x2mm pads at both ends for electrical access. The metal stripe resistance versus temperature measurements was calibrated for each metal stripe. Temperature was measured both by Ktype thermocouple and by measuring the calibrated metal line resistance. The 3Z signal acquisition was performed using a 12 bit DAC converter in the 10Hz to 1kHz range, using a four probe configuration. A 1: shunt resistance in series with the metal line was used to monitor the current. The current amplitudes were kept in the 70 to 80mA for all samples, ensuring a small mean temperature elevation (< 2K).

Validation on Si silicon substrate

In order to check the accuracy of the thermal conductivity measurements and analysis, we first used a p Boron (~10 15 cm -3 ) doped silicon substrate. A value of 148 ± 1 W/m.K at 300K is obtained, which is in very good agreement with previously reported values [START_REF] Burzo | Non-contact thermal conductivity measurements of p-doped and n-doped gold covered natural and isotopically-pure silicon and their oxides[END_REF]. Fig. 1 shows the measured temperature rise as a function of twice the current frequency (2f), that confirms the good agreement of our measurements with the theoretical model of Borca-Tasciuc and al [0] even at rather low frequencies. The temperature elevation at low frequencies due to the finite thickness (330 µm) of the Si substrate is well reproduced by the model.

Figure 1: 3Z method measured and modelled temperature elevation of a TiAu stripe on silicon substrate.

Thermal conductivity of InP n doped substrate and SiN layer

A set of four InP n=4.10 18 cm -3 S doped (100) commercial substrates from the same ingot (supplier: Sumitomo Corporation) was used. On each of them a SiN PECVD layer with different thicknesses varying from 100nm to 600nm was deposited in order to characterise both InP and SiN thermal conductivity, and the total TiAu/SiN/InP interface thermal resistance.

The thermal conductivity measurements on all substrates gave similar results with small differences (within 1W/mK at each temperature). Fig. 2 represents the temperature dependence of the InP measured thermal conductivity. A fitting empirical power relation of the form O=A(T/300) -n with n=1.57 is deduced and found to be in good agreement with literature [START_REF] Sajan | Thermal characterization of intrinsic and extrinsic InP using photoacoustic technique[END_REF], but it is to be noticed that the A mean value at 300K (75.6W/mK) is slightly higher than those previously reported (68W/mK [START_REF] Bertolotti | New photothermal deflection method for thermal diffusivity measurement of semiconductor wafers[END_REF] and 60.5W/mK [START_REF] Sajan | Thermal characterization of intrinsic and extrinsic InP using photoacoustic technique[END_REF]) which could be due to a higher quality of currently available substrates. The thermal conductivity of the SiN layer was also characterized and found to be 0.72 W/m.K at room temperature. As shown on Fig. 3, the thermal conductivity slightly increases at higher temperature, which is an usual characteristic of SiN amorphous material. These values are in very good agreement with [START_REF] Lee | Heat transport in thin dielectric films[END_REF][START_REF] Griffin | The effective transverse thermal conductivity of amorphous Si3N4 thin films[END_REF] for PECVD SiN layers. The thermal interface resistance (sum of the Ti-Au/SiN and SiN/InP interface resistances) was also deduced by measuring the variation of thermal resistance as a function of the SiN layer thickness on InP samples.

Measurements are presented in Fig. 4. It was found to be 4.10 -8 W/m²K which is comparable to previously reported values for SiN layers on Si samples [START_REF] Griffin | The effective transverse thermal conductivity of amorphous Si3N4 thin films[END_REF].

Growth, structural and thermal conductivity characterisation of InAs stacked QDs on InP (113)B

Growth

All samples were grown by Solid-Source MBE at 480°C on InP (113)B Sulphur (S) doped substrates (3 to 5.10 18 cm -3 ). A single QD layer of 2ML of InAs (3.2% compressively strained) on lattice matched In 0.53 Ga 0.47 As was grown to check the formation of QDs. A QD area density of 5.1 10 10 /cm² is obtained as shown on the AFM image (Fig. 5). QD mean height and diameter are 3 nm and 33nm respectively. Two samples containing a stack of 20 QD layers were then grown. The last QD layer was left uncapped for AFM measurements.

The first sample consisted in 20 InAs QD layers separated by 10 nm of lattice-matched InGaAs. The second differed from the first by the insertion of a 2ML AlAs layer in the middle of the 10nm InGaAs layer. This AlAs layer, which is 3.5% tensile strained on InP is expected to act as a strain compensating layer in order to conserve a good quality growth front [START_REF] Oshima | Optical properties of stacked InAs self-organized quantum dots on InP (3 1 1)B[END_REF].

Structural and optical characterisations

Fig. 6. a) (without strain compensating layer) and b) (with strain compensation layer) show the AFM image of the corresponding samples. The absence of the strain compensating layer results in a very rough surface with no clear distinction of QDs, whereas its presence preserves both the shape and the density of InAs QDs with however a small undulation of the growth front. The areal density is 5.0 10 10 /cm² and the average height and diameter are 40nm and 3.8nm respectively. While the areal density is preserved from 1 to 20 layers, both average diameter and height are increased by ~20%, which likely indicates an impact of the strain field on the morphology of the dots, as already observed in [START_REF] Oshima | Optical properties of stacked InAs self-organized quantum dots on InP (3 1 1)B[END_REF] for thicker (20nm) spacing layers. A sample containing a stack of 100 layers of InAs QDs with AlAs strain compensating layers with a final 200nm InP cap was subsequently grown for thermal conductivity measurements.

The sample was uniformly n doped with Si (5.10 18 cm-3) for future Seebeck measurements.

The structure of the layer was investigated using x-ray diffraction reciprocal space mapping (RSM). Measurements along the [311] (growth axis) direction (Fig. 7) show a limited but well defined number of satellite peaks showing a rather good structural quality. The extracted period is 11.35nm in good agreement with the nominal 11.17nm value. The mean strain status of the structure, obtained by the position of the diffraction peak close to the substrate peak, is found to be 0.06% in compression. At this value and for this total thickness of the structure, it is expected that very few dislocations should be created [START_REF] Salviati | Structural characterization of InGaAs/InP heterostructures grown under compressive and tensile stress[END_REF]. Moreover, no dislocation lines are visible on the AFM images. Photoluminescence (PL) was performed at 10K using a 1064nm YAG laser and the spectrum is reported in Fig. 8. At this excitation wavelength, the whole stack PL is rather uniformly excited due to the relatively small absorption coefficient of InGaAs (the absorption length is estimated to be 0.5µm). The observed PL is thus representative of the whole structure. Two gaussian peaks can be resolved, and can be tentatively attributed to the InGaAs QW superlattice with AlAs barriers (peak at 0.8eV) and the InAs QDs (peak at 0.7eV). Simple calculation of the PL peaks using k.p. method assuming 1D confinement [START_REF] Folliot | Effects of interfacelayers composition and strain distribution on the optical transitions of InAs quantum dots on InP[END_REF] lead to corresponding energies of 0.83eV and 0.66eV respectively, as shown in the inset of fig. 8. PL intensity is comparable with the one of InGaAs quantum wells with AlInAs barriers lattice matched on InP, which reveals no clear degradation of the optical quality of the QD stack when AlAs strain compensating layers are inserted.

Thermal conductivity measurements

The stack of 100 strain compensated InAs QD layers was characterised by means of the 3Z method and compared with a 1µm thick Si doped (5.10 18 cm -3 ) lattice matched InGaAs reference layer. The thermal conductivity of the QD stack was found to be 2.7±0.1W/mK at 300K and to remain constant (within estimated experimental error) in the 20°C to 200°C range (Fig. 9). The thermal conductivity of the InGaAs reference layer was measured to be 5.1±0.2W/mK, consistent with previously reported values [START_REF] Kim | Cross-plane lattice and electronic thermal conductivities of ErAs:InGaAs⁄InGaAlAs superlattices[END_REF]. A higher reduction of the thermal conductivity of InGaAs / InGaAsP MQW structure has been reported for a 15/5 nm period [START_REF] Zhen | Thermal conductivity measurement of InGaAs/InGaAsP superlattice thin films[END_REF]. The presented results show however an abnormal high thermal conduction (higher than bulk value) or very small period leaving unclear the origin of the observed reduction in the thermal conductivity.

If dislocations can have an impact on the reduction of thermal conductivity, their effect is expected to play a major role when their density exceeds 10 7 /cm² as calculated in [START_REF] Jeremy | A study of the impact of dislocations on the thermoelectric properties of quantum wells in the Si/SiGe materials system[END_REF] and observed in for SiGe system [START_REF] Lee | Thermal conductivity of Si-Ge superlattices[END_REF] or measured in [START_REF] Mion | Accurate dependence of gallium nitride thermal conductivity on dislocation density[END_REF] for bulk GaN. To our knowledge no data is available for the InGaAs system, but we can expect that dislocations in our sample play a minor effect in the reduction of the thermal conductivity. InGaAs/AlInAs digital alloy with both comparable (1.9 10 18 /cm 3 ) n doping and average composition was studied [26] and the measured thermal conductivity was only slightly reduced (4.5W/mK) as compared to InGaAs.

The clear reduction by a factor of ~1.9 of the thermal conductivity can thus be attributed to the presence of the QDs and AlAs strain compensating layers. The precise role of the shape, density and strain distribution inside/outside the QDs is however still unclear a would require further investigations. For instance, interdiffusion can play an important role on the thermal conductivity, and the precise nature of the different interfaces is required to get a clearer understanding [27]. This reduction in thermal conductivity at room temperature is comparable with the value obtained at maximum ZT of ErAs clusters in AlGaInAs on InP [START_REF] Zide | High efficiency semimetal/semiconductor nanocomposite thermoelectric materials[END_REF], where ErAs clusters mainly act as phonon diffusion centres, but also as electron filters.

It is interesting to note that in the same temperature range, the thermal conductivity of this material is also found to be mainly constant for 3% ErAs concentration.

Seebeck and electrical conductivity measurements of our InAs QD stacks are in progress.

Conclusions

We have presented results on the reduction of thermal conductivity by the insertion of densely stacked InAs QDs layers embedded in lattice-matched InGaAs on InP substrate using AlAs strain compensating layers. A reduction by a factor of 1.9 of the thermal conductivity is observed at room temperature as compared to a bulk lattice-matched GaInAs layer. This reduction in thermal conductivity is similar to the best reported values on InP using ErAs nanoparticles embedded in AlGaInAs alloys on InP [02] when optimized ZT is reached. Moreover, a revised empirical law for InP S doped substrate thermal conductivity is proposed, which could also be of interest for other applications.

Seebeck and conductivity measurements are currently under investigation.

Figure 2 :

 2 Figure 2: S doped InP substrates measured thermal conductivity as a function of temperature.

Figure 3 :

 3 Figure 3: thermal conductivity (λ in W/mK) of PECVD SiN on InP as a function of temperature.

Figure 4 :

 4 Figure 4: measured PECVD SiN thermal resistance versus SiN thickness and extracted parameters.

Figure 5 :

 5 Figure 5: 1x1µm² AFM image of a single layer of InAs QDs grown on InGaAs buffer on InP (113)B.

Figure 6 :

 6 Figure 6: a) 1x1µm² AFM image of the surface of a 20 stacked InAs 2ML layers without strain compensation layer and b) with AlAs strain compensation layer.

Figure 7 :

 7 Figure 7: X-Ray Z-2T curve extracted from RSM along the growth axis (113) of the 100 strain compensated InAs QD stack. Thick blue vertical line is related to InP substrate, thinner vertical lines correspond to satellites peaks.

Figure 8 :

 8 Figure 8: 10K PL spectrum of 100 InAs QD stack with strain compensation AlAs layers with two fitting Gaussian peaks. Inset: band alignment of InAs/InGaAs/AlAs system with corresponding calculated energy levels (CB: conduction band minimum at * point, HH: heavy hole and LH: light hole band maxima). E 1 and HH 1 are the calculated QD ground states in the conduction and valence band respectively.

Figure 9 :

 9 Figure 9: Thermal conductivity of 100 InAs QD stack with strain compensation AlAs layers versus temperature.

  Figure(s)

Acknowledgements

The author wishes to thank the Région Bretagne for financial support through ARED PhD research grant.

[26] Je-Hyeong Bahk, Zhixi Bian, Mona Zebarjadi, Joshua M. O.