Constantinos Makassikis
email: constantinos.makassikis@loria.fr

Stéphane Vialle
email: stephane.vialle@supelec.fr

Xavier Warin
email: xavier.warin@edf.fr

FT-GReLoSSS: a Skeletal-Based Approach towards Application Parallelization and Low-Overhead Fault Tolerance

Keywords: distributed fault tolerance, application-level checkpointing, SPMD paradigm, framework, skeletons

FT-GReLoSSS (FTG) is a C++/MPI framework to ease the development of fault-tolerant parallel applications belonging to a SPMD family termed GReLoSSS. The originality of FTG is to rely on the MoLOToF programming model principles to facilitate the addition of an efficient checkpoint-based fault tolerance at the application level. Main features of MoLOToF encompass a structured application development based on faulttolerant "skeletons" and lay emphasis on collaborations. The latter exist between the programmer, the framework and the underlying runtime middleware/environment. Together with the structured approach they contribute into achieving reduced checkpoint sizes, as well as reduced checkpoint and recovery overhead at runtime. This paper introduces the main principles of MoLOToF and the design of the FTG framework. To properly assess the framework's ease of use for a programmer as well as fault tolerance efficiency, a series of benchmarks were conducted up to 128 nodes on a multicore PC cluster. These benchmarks involved an existing parallel financial application for gas storage valuation, originally developed in collaboration with EDF company, and a rewritten version which made use of the FTG framework and its features. Experiments results display low-overhead compared to existing system-level counterparts.

I. INTRODUCTION

As a result of increased competition, many industries have strived for new, more accurate simulation models. Their design, assessment and exploitation often requires huge amounts of computational power which eventually led those industries to adopt high performance distributed systems (HPDS).

In many cases, computations may be broken into several independent parts which can straightforwardly exploit HPDS. However, not all computations fit efficiently the embarrassingly parallel computation model. Programmers with little parallel background face three major issues. Firstly, they need to learn how to make their applications run efficiently on HPDS. Secondly, as the probability of failure increases with the number of computational resources (or nodes) used, developped applications have to be robust and fault-tolerant. Finally, HPDS systems involve rapidly evolving hardware and software which compels the use of portable fault tolerance (FT) solutions. Efficiency of these solutions is not an option as industrial environments are subject to time constraints: for example, some long-running applications in financial institutions are run overnight, and their results are expected in the morning in order to decide on the daily strategy to follow. Hence, FT efficiency translates into little slowdown of applications during failure-free time intervals. In case of failure, it translates into little wasted work and short restart times.

Checkpointing is a widely spread FT technique which consists in periodically saving the application state to stable storage. Following a failure, application execution is interrupted and the most recent saved state is then used to resume execution. This paper presents FTG, a specialized framework derived from the MoLOToF programming model [START_REF] Makassikis | A Skeletal-Based Approach for the Development of Fault-Tolerant SPMD Applications[END_REF]. MoLOToF aims to facilitate the development of efficient parallel applications and their endowment with efficient application-level checkpointing.

After covering related works (Section II), we describe the MoLOToF programming model and the software architecture of the FTG programming framework (Sections III and IV). Ease of development is assessed through the use of FTG on an existing industrial application for gas storage valuation from EDF company (Section V). Finally, the efficiency of the approach is evaluated experimentally (Section VI) before concluding (Section VII).

II. RELATED WORKS

Existing FT research for message passing applications has focused a lot on transparency. By combining a sequential checkpointer (e.g.: BLCR [START_REF] Hargrove | Berkeley Lab Checkpoint/Restart (BLCR) for Linux Clusters[END_REF], MTCP [START_REF] Rieker | Transparent User-Level Checkpointing for the Native Posix Thread Library for Linux[END_REF] . . . ) and some rollback recovery (RR) protocol, it was possible to endow existing MPI libraries such as OpenMPI [START_REF] Hursey | The Design and Implementation of Checkpoint/Restart Process Fault Tolerance for Open MPI[END_REF] or MPICH [START_REF] Bouteiller | MPICH-V: a Multiprotocol Fault Tolerant MPI[END_REF] with transparent FT or to provide more general solutions such as DMTCP [START_REF] Ansel | DMTCP: Transparent checkpointing for cluster computations and the desktop[END_REF] for socket-based distributed applications. RR protocols ensure that individual checkpoints of MPI processes remain consistent despite interdependencies created by communications: they form a recovery line. Most available solutions implement a so called blocking RR protocol which "freezes" communications while a checkpoint is made. MPICH-V [START_REF] Bouteiller | MPICH-V: a Multiprotocol Fault Tolerant MPI[END_REF] is the exception, for it implements several other RR protocols. From our experience with the OpenMPI-BLCR pair or DMTCP, such solutions yield bulky checkpoint files, and are very sensitive to changes of the underlying runtime system. As a result of including too much system-dependent information, issues are often raised as the system is updated.

C 3 [START_REF] Bronevetsky | Recent Advances in Checkpoint/Recovery Systems[END_REF] and CPPC [START_REF] Rodríguez | CPPC: A compiler-assisted tool for portable checkpointing of messagepassing applications[END_REF] strive for similar levels of transparency to the user, but at the application level. By leveraging source-to-source compilers, source code of C/Fortran MPI applications is automatically transformed such as the resulting application can checkpoint and restart itself. Besides unburdening the user from non-trivial source code transformations, this approach benefits from high portability for it works at the application level. Many legacy and recent applications written in C/Fortran can benefit from this approach. However, providing similar transformations is challenging for languages such as C++ which is commonly used in many applications.

On the other end, FT can be tackled manually. Though not clearly stated in the litterature, the manual approach to FT is not unusual. Admittedly, the approach is tedious even with the aid of third-party libraries (e.g.: TCS [START_REF] Stone | A Checkpoint and Recovery System for the Pittsburgh Supercomputing Center Terascale Computing System[END_REF], SCR [START_REF] Moody | Design, Modeling, and Evaluation of a Scalable Multi-level Checkpointing System[END_REF] checkpointing libraries). Nevertheless, resulting FT is very efficient and portable, and the user may improve it further based on his knowledge of the application. For production applications, the efficiency gained quickly outweighs the endeavour.

Finally, users can rely upon frameworks to achieve FT. PUL-RD [START_REF] Silva | Fault-Tolerance on Regular Decomposition Grid Applications[END_REF] and Cactus [START_REF] Allen | Cactus Tools for Grid Applications[END_REF] are examples where users are subject to some programming constraints in exchange of which they benefit among others from FT. Compared to the previous two approaches, frameworks also facilitate writing parallel applications. As a framework, FTG shares similarities with PUL-RD and Cactus as far as the parallelization model is concerned. All three involve iterative calculations with two array datastructures, swapped at the end of each iteration. FTG supports applications with none-trivial distribution of calculations among processes. It differs by relying on a specific programming model for fault tolerance named MoLOToF. The introduction of fault-tolerant skeletons yields an explicit structuration of the application, which in turn provides a simple, yet efficient, way to endow applications with FT. Hence, users are led to "actively" interact with the framework. Our faulttolerant skeletons are inspired by the skeleton programming approach, and are designed at lower level. Hence they should be named "sub-skeletons" (or "low-level skeletons"). But for simplicity, in the rest of this paper we call them "skeletons". 2) on establishing collaborations through inter-action functionalities between the programmer, the framework and the underlying environment. To achieve these, MoLOToF introduces the concept of fault-tolerant skeletons. The latter are structured pieces of code endowed with fault-tolerant properties. Usually, they are made of fault-tolerant loops each of which has the ability to save and restore itself. As illustrated in fig. 1, a typical loop body contains calculation, and possibly communication phases (l. [START_REF] Bouteiller | MPICH-V: a Multiprotocol Fault Tolerant MPI[END_REF][START_REF] Ansel | DMTCP: Transparent checkpointing for cluster computations and the desktop[END_REF]. Checkpoint definition (l. 7) within the loop allows to save calculations and related application state.

III. MOLOTOF PROGRAMMING MODEL FOR FT

A. Skeleton-based code structuring

Using fault-tolerant skeletons, the application is split into two broad types of code operations: heavy and light operations. Heavy operations correspond to time-consuming code. Such code is usually found within calculation and communication phases of a skeleton. Light operations designate every other piece of code which is really fast to reexecute, and hence not interesting to checkpoint. Such separation results in a straightforward save/restore (checkpointing) mechanism based on application reexecution. To illustrate the mechanics, let us assume an application made of a single skeleton as the one in fig. 1. As represented in fig. 2, the application comprises an initialization phase, a skeleton and a cleanup phase. During normal application execution (cf. Fig. 3), checkpointing occurs whenever a checkpoint location and a checkpoint condition are met. In our example, a checkpoint occurs on the second iteration. Among saved data is the iterator's value (i.e.: 2). Consistency of individual checkpoints is ensured by some adapted RR protocol. An application executes until it quits gracefully or until a failure occurs. In our example it fails somewhere during communications of the third iteration.

After the detection of a failure (cf. Fig. 4), the application is restarted from its most recent recovery line: here, the checkpoint taken at iteration 2. The application enters recovery mode (cf. "restarting:true" in fig. 4). Namely, each process restarts from the very beginning as in its initial run til it reaches the checkpoint location where the checkpoint it is supposed to restart from was achieved. During this course, only light operations are reexecuted therefore resulting in fast restarts. When reaching the appropriate checkpoint location, application context is restored. To complete recovery, checkpoint file contents are loaded back into the application, which can then normally resume its execution: the application falls back into normal execution mode (cf. "restarting:false" in fig. 4) and resumes with the third iteration.

Runtime

Calc

Comm Ckpt

B. Collaborations

To ease parallel programming, skeletons enclose a parallelization paradigm and come usually as part of a specialized framework. Through their use, the programmer easily develops his parallel application and installs checkpoint/restart semantics in it. Further involvement of the user may be required when checkpoints of fault-tolerant skeletons are not "self-contained". This means that their default contents do not capture entirely the application state. The user has to register as part of the checkpoint contents missing data in order to capture the application state. When fault-tolerant skeletons are self-contained, such action on behalf of the user is unnecessary as far as correctness is concerned. However, it is desirable in order to reduce the resulting checkpoint size and hence improve checkpointing efficiency. Therefore, in order to either constitute a consistent checkpoint or improve efficiency, the programmer's intervention may be needed. It makes all the more sense as the programmer, knowing the application semantics, may come up with smart choices.

Moreover, checkpoint efficiency may depend on the execution environment characteristics over time. For example, platforms under heavy load or aged platforms are more prone to failures. Hence, it is important that the application is able to adapt its fault tolerance based on external information.

To allow such interventions, FT skeletons come up with additional functionality allowing the programmer to control data which is enclosed in a checkpoint as well as setting the checkpointing frequency. Such interaction is seen as collaboration between the framework and the programmer. The other collaboration envisionned by MoLOToF lies between the framework and the underlying middleware, and is fully compatible with the spirit of fault-tolerant ecosystems such as the Fault-Tolerant Backplane [START_REF] Gupta | CIFTS: A Coordinated infrastructure for Fault-Tolerant Systems[END_REF]. To date, two framework implementations following the MoLOToF programming model exist. The first implementation is a Javaspace-based Master-Worker framework [START_REF] Galtier | A Javaspace-based Framework for Efficient Fault-Tolerant Master-Worker Distributed Applications[END_REF] which considers self-contained skeletons. The second implementation is a framework named FT-SPMD [START_REF] Makassikis | A Skeletal-Based Approach for the Development of Fault-Tolerant SPMD Applications[END_REF] which targets a broad family of SPMD applications named GReLoSSS (cf. Section IV). FT-SPMD benefitted from several modifications in its architecture and API which resulted in a seriously improved version called FT-GReLoSSS (FTG for short) which is presented hereafter. Compared to [START_REF] Makassikis | A Skeletal-Based Approach for the Development of Fault-Tolerant SPMD Applications[END_REF] the framework architecture is presented more in-depth and it is validated using an industrial application (cf. Section IV).

IV. FTG PROGRAMMING FRAMEWORK

A. GReLoSSS computation model

The GReLoSSS (Globally Relaxed, Locally Strict Synchronization SPMD) parallel computation model encompasses SPMD applications consisting in a main loop where each iteration (or superstep) contains a calculation and a communication phase. Such applications follow globally a classic BSP scheme [START_REF] Valiant | A bridging model for parallel computation[END_REF]. However, these applications differ from BSP in two ways:

1) to improve efficiency on big parallel architectures, algorithms do not have a global synchronization between supersteps: each process starts its next superstep as soon as it has issued, but not necessarily completed, all its communications. Hence, global synchronization is relaxed as in the PRO model [START_REF] Gebremedhin | PRO: A Model for Parallel Resource-Optimal Computation[END_REF].

2) yet, to improve checkpointing efficiency, each process completes all its communications before starting the next superstep. Dependencies due to communications between processes disappear and consistent checkpointing is facilitated. Hence, compared to PRO, GReLoSSS has a locally strict synchronization which prevents overlapping of calculations with communications.

B. Application class supported by GReLoSSS and examples

The applications of the class supported by FTG (FT-GReLoSSS) involve two array datastructures one of which contains data used in the current superstep. The role of the second one depends on the application. A domain decomposition application such as Jacobi relaxations [START_REF] Gropp | Using MPI: Portable Parallel Programming with the Message-Passing Interface[END_REF] will use that datastructure to store new results at the current superstep. A data circulation application such as in some parallel matrix multiplication algorithms [START_REF] Makassikis | A Skeletal-Based Approach for the Development of Fault-Tolerant SPMD Applications[END_REF] will use it to receive data for the next superstep from neighbouring processes.

During communications, processes exchange data corresponding to initial data or to intermediary results. Communications between processes may be quite varied, yet, in most cases, they are sufficiently foreseeable to be specified by the programmer. For example, in a Jacobi relaxations application, it consists in exchanging borders (or shadow regions) between subdomains assigned to different processes. A subdomain designates the subset of the entire domain which was assigned to a process. Thus, a subdomain has the same datatype as array datastructures. At the end of communications, the two array datastructures are swapped.

Algorithms using two array datastructures (of 1 or more dimensions) such as the ones described may seem restrictive. But from our experience, they cover the needs of a fairly wide class of applications.

C. Software architecture and features

FTG is a C++ framework implementing programming principles described in MoLOToF. It is built on top of the MPI specification which makes it compatible with every MPI library. It provides a set of classes to ease the development of fault-tolerant GReLoSSS parallel applications.

Relations between main FTG classes are depicted in fig. 5. The ftg_Skel class represents a GReLoSSS skeleton and comprises:

• a calculation kernel (cf. ftg_Calc_Kern) which provides the calculation method and the skeleton's main loop iterator. It is also possible to specify a condition for communications achievement.

• a routing plan (cf. ftg_Routing_plan) which is responsible for determining and scheduling communication exchanges between processes.

• a checkpoint (cf. ftg_Checkpoint) which sets the location in the skeleton where checkpoints will be taken.

Fig. 5: FTG UML class diagram

The source code excerpt of ftg_Skel class (cf. Fig. 6) shows how these abstractions are layed out within the execute method. The resulting structure closely follows the example skeleton in fig. 1. It differs in the existence of conditional communications (l. 50-51) and the presence of a swap method (l. 61) where the two datastructures exchange their data according to the GReLoSSS computation model.

Condition has to be verified globally: all processes enter communication phase or none. Notice the name prefixes: ftgu_ are user-provided (l. 29-30, 41, 44), ftg_ are framework provided (l. [START_REF] Gebremedhin | PRO: A Model for Parallel Resource-Optimal Computation[END_REF]), and ftgf_ are framework-provided based on user-provided methods (l. 38).

Concerning FT, the GReLoSSS skeleton defines a checkpoint right after the swap operation. By default, it contains data internal to the skeleton such as the two datastructures and skeleton iterators. ftg_Skel exposes to the programmer an interface allowing him to control data to include in the checkpoint. Furthermore, data which can be included in checkpoint files has to be either a primitive C++ type or derived from the framework's ftg_Serializable class (cf. Fig. 5), in which case the programmer has to provide a pair of save and load methods. This approach was used within FTG to make ftg_Domain and ftg_Domain_desc classes serializable. The latter is a helper class which describes the extent of a domain (or subdomain) along each dimension.

Upon instantiation of the skeleton, the user has to inform the routing plan whether application communication consists in borders exchanges or in circulating data. Aside from this, he may choose among different communication schemes. Currently, the routing plan integrates two schemes based on the MPI_Issend-MPI_Irecv pair of MPI primitives. The first scheme performs all communications in parallel, while the second tries to "pace" them so that there is only a limited amount of ongoing concurrent communications at a time [START_REF] Makassikis | Distribution of a Stochastic Control Algorithm Applied to Gas Storage Valuation[END_REF]. Concerning data movement, the routing plan groups sparse data into contiguous large messages and also minimizes copies from/to communication buffers by detecting ranges of contiguous elements. This last feature proved useful in applications where data to transfer is contiguous as it avoids using intermediate buffers.

The calculation kernel is merely made of pure virtual methods which the programmer has to define.

The array datastructure provides the programmer with an interface to N-dimensional arrays enclosed in ftg_Domain. When interfacing his own array datastructure (by inheriting from ftg_Domain), the programmer provides information regarding (1) the way the domain is split among processes as well as (2) the way to access an element given its coordinates (x 1 , x 2 , • • • , x n ). Moreover, the programmer provides information regarding the storage order. In 2D, C storage order consists in storing the array line-wise, while a Fortran storage order consists in storing the array column-wise. Storage order generalizes in higher dimensions and can lead to more different storages depending on the order of storing each dimension.

Since the interface proposed by ftg_Domain targets Ndimensional domains, it manipulates a vector of coordinates which can be inconvenient to the programmer in small dimensions. It can also be less efficient. Therefore, FTG proposes specific interfaces for dimensions 2 and 3 (resp. ftg_Domain2D and ftg_Domain3D in fig. 5).

Finally, after splitting a domain among processes (cf. Fig. 7), any given element can be located either relative to the first element of the entire domain or relative to the first element of FTG allows the programmer to use either of them without any further involvement. Access through local coordinates is preferable since it is faster, but it is not always the most convenient. Using global coordinates incurs a slight overhead due to an additional offset computation.

From a design standpoint, the use of dynamic polymorphism (through classic inheritance) is sufficient. However, since array access methods are often used, the resulting overhead is tremendous. That is why FTG relies also on static polymorphism, and more specifically on the Curiously Recurring Template Pattern (CRTP) [START_REF] Coplien | Curiously recurring template patterns[END_REF].

In the following section, we decribe the Swing application and the steps to interface it efficiently with FTG.

V. Swing FINANCIAL APPLICATION MIGRATION Due to house heating, demand in gas is higher in winter than in summer. Gas is mainly provided by pipes that cannot deliver more than a specific amount of gas per day and it results in far higher gas prices in winter. In order to provide energy to their customers, gas market actors have to own some storages that can help them smooth peak demand. In order to assess a project's rentability, gas companies can use a financial real option approach that can be implemented in a software.

A. Swing application goal and implementation

The Swing application is used at EDF company to valuate a gas storage facing the energy market. It aims at giving the average cash flow generated by the asset depending on some prices scenario. It also gives the management and hedging strategies [START_REF] Warin | Gas storage hedging[END_REF]. These calculated strategies are used in a second application simulating the way the storage is used. This second application gives some cash flow distributions obtained by the storage management. While the time needed for the second application is short, the swing valuation can be very costly depending on the price models used to generate scenarios. The price models used at EDF for this software are a gaussian onefactor model (g), a normal inverse gaussian model (nig), and a two-factor gaussian model (g2d) [START_REF] Warin | Electricity asset management with future hedging[END_REF]. The resolution method for the Swing application is the dynamic programming method that has been written in C++ and uses MPI for parallelization following the methodology in [START_REF] Makassikis | Distribution of a Stochastic Control Algorithm Applied to Gas Storage Valuation[END_REF]. It also makes extensive use of the Blitz library for its convenient array manipulation facilities [START_REF]The Blitz++ library[END_REF], and is about 18380 logical lines of code.

From an algorithmic standpoint, the Swing application fits perfectly the GReLoSSS computation model. While being a domain decomposition application, it is more complex than classic Jacobi relaxations. Indeed, over supersteps:

• calculations involve a subdomain of the entire calculation domain; that subdomain may change;

• shadow regions between processes have no fixed extent and may change as well. To interface the existing application with FTG, we follow some typical development steps which are described hereafter and summarized in fig. 8.

B. Development workflow

As part of the typical development steps, we have to inherit from ftg_Calc_Kern to define a calculation kernel:

/ i m p l e m e n t s C u r i o u s l y R e c u r r i n g T e m p l a t e P a t t e r n { }

When inheriting from ftg_Calc_Kern we provide the calculation method:

v o i d f t g u c a l c u l a t e ( f t g u D o m a i n t * d1 , f t g u D o m a i n t * d2 , T i t e r s t e p ) ;
the main loop calculation iterator:

T i t e r f t g u b e g ( v o i d ) ; T i t e r f t g u e n d ( v o i d ) ; T i t e r f t g u n x t ( T i t e r ) ;

and a method which tells when to achieve communications: which tell what data is owned and what is needed by each process at each superstep. In an application with borders exchange, such as the Swing application, data owned is a subset of the data needed. Moreover, we have to define a method telling the framework how to resize a domain:

v o i d
f t g u r e s i z e ( T i n y V e c t o r <i n t , N rank> &e x t e n t )

and some methods on how to access any element or retrieve its memory address, given its local coordinates: The resize method is not relevant to every application. Yet, in the case of Swing, it is interesting as subdomains attributed to each process and subdomains sizes vary across the course of an execution. Leveraging this feature, FTG can optimize memory management. The resize, the partition and the local access methods which the user provides (ftgu_ prefix) are used to build the routing plan. The "ftg_Domain * " classes also use local access methods to implement the global access methods they provide the user with.

Finally, the application's main function consisted in instantiating a calculation kernel and using it to initialize and execute the GReLoSSS skeleton. The corresponding source code has to be enclosed between the initialization and finalization statements of the framework provided by the ftg_Cpr (Checkpoint recovery) singleton class (cf. Fig. 8). The last step consists in choosing relevant checkpoint data. In particular, we unregister from the checkpoint the Domain which is useless at the end of the iteration, and register some application specific data which is not restored upon recovery (by mere reexecution), and hence has to be saved.

C. Ease of development assessement

The definition of the calculation method within our Swing calculation kernel involves the reuse of calculation functions in Gas_storage_price, and access to data in Gas_storage_asset (cf. Fig. 8). Both classes stem from the original Swing application. Similarly, partition methods in our Swing_Domain class require access to data and code reuse from Gas_storage_asset.

The calculation and partition methods are usually the most time-consuming to write. Especially the partition methods, which are prone to error due to indexes. Since compatible partition functions already exist in the original parallel Swing application, it is a matter of adapting them to use ftg_Domain_desc type to describe subdomains. The same applies for the calculation method, but some pieces of code have to be rewritten to use the accessors provided by ftg_Domain instead of those provided by Blitz Arrays. In the process, the interface of Swing_Domain was enriched to allow efficient and convenient access to ranges of data.

Another challenge we encountered concerned efficiency. In particular, partition methods have to be really fast as they are often called by the framework either to access elements through global coordinates or to build the routing plan.

In the end, the full fault-tolerant Swing application with FTG is about 353 logical lines of code less than the original application. Provided we are careful, the resulting application displays a clean and simple design as shown in fig. 8. Moreover, the application is fault-tolerant and the programmer has less lines of code to write. As shown in the next section, performance is as good as without FTG, sometimes slightly better.

VI. PERFORMANCE EXPERIMENTS

The evaluation of FTG consists in a comparison with the popular OpenMPI (OMPI) library which implements a blocking checkpoint protocol in combination with BLCR. OMPI applications benefit from a system-level checkpoint/restart solution. Experiments led, assess FTG and OMPI performances without and with FT enabled. When FT is enabled, checkpoints are taken, and we consider application runtimes in the failure-free case and recovery times otherwise. We also consider checkpoint size reduction and their impact on runtime overhead.

In these experiments, we consider temporary crash failures of nodes which can be dealt with by having both FTG and OMPI store checkpoints locally to each node (i.e.: /tmp). Also, this setting avoids disrupting measurements due to additional communications resulting from significant data transfer across the network.

A. Testbed description

Experiments were led on the Intercell cluster hosted at SUPELEC. Intercell features 256 nodes running on 64-bit Fedora Core 8 and inteconnected through a CISCO 6509 Gigabit Ethernet switch. Each node has an Intel Xeon-3075 dual-core processor (i.e.: a total of 512 cores) and 4 GB of RAM. However, experiments were run with one process per node. Benchmarks applications use OpenMPI 1.5.3 and were compiled with g++ 4.1.2 compiler and -O3 optimization flag.

B. Runtime overheads comparison in absence of checkpoints

Fig. 9 shows that FTG exhibits negligible to no overhead for the g2d price model, and scales well up to 256 nodes where it performs better than the application not using FTG. Similar results were observed for the g and nig price models.

C. Checkpoint size

Checkpoint size is dominated by the size of the two array datastructures used for parallelization. Since at the end of a superstep, the input data is useless, it can be omitted from the checkpoint. This optimization results in checkpoint sizes per node twice as light compared to system-level checkpoints (cf. Fig. 10). The same can be observed for the g and nig models. These models require less memory and result in checkpoints size ranging between 20 MB and several kilobytes with FTG compared to 40 MB et 7 MB for OMPI BLCR. In what follows, we focus on the g2d model: its' long runtimes make it a good candidate for FT.

D. Fault tolerance performance without failures

For this experiment, we have run both versions of our application with the g2d model and different number of checkpoints: the lengthier the benchmark the more checkpoints were achieved in order to minimize the wasted amount of time in case of failure. In the present experiments we set the maximum allowed wasted amount of time to 4 minutes. Fig. 11 reports the runtimes on 128, 64 and 32 nodes. The plots compare OMPI with BLCR and FTG. In the latter's case we measured runtimes without and with checkpoint size optimization in an attempt to quantify the impact of checkpoint size reduction. The difference remains marginal (0 -3%) and is the highest with the biggest checkpoint sizes as the ones involved on 32 nodes. The difference is expected to grow further with bulkier checkpoint files. The remaining overhead observed with OMPI-BLCR ranges between 6% and 40%. Overhead incurred by FTG is always lower and does not exceed 8% in all cases. OMPI-BLCR's overhead is mainly attributed to its blocking checkpoint protocol [START_REF] Hursey | The Design and Implementation of Checkpoint/Restart Process Fault Tolerance for Open MPI[END_REF], which, unlike FTG's protocol, involves communications and "freezes" the application execution in order to checkpoint.

E. Recovery overhead

Recovery from a checkpoint comprises (1) a negotiation phase where processes decide from which recovery line to recover, followed by a (2) context recovery phase, and finally (3) a recovery from checkpoint file phase (i.e.: time to load data). Measured negotiation phase time is negligible (< 10ms). Context recovery phase is small as well. Overall recovery time from a checkpoint is rather small as it does not exceed 1s for the g2d model on 128, 64 and 32 nodes. Thus, fast restarts combined with the low-overhead checkpointing pointed out earlier make FTG suited for applications with time constraints.

VII. CONCLUSION AND PERSPECTIVES

Endowing parallel applications with efficient checkpointbased FT at the application level can be a tedious task which adds up to the existing difficulties of parallelization. Our approach based on the MoLOToF programming model introduces fault-tolerant skeletons and results in a tractable way for users to endow efficient fault tolerance into their applications. Moreover, combined with a specialized framework, MoLOToF eases parallel programming, and encourages a synergy between the user, the framework and the runtime environment to improve FT efficiency. MoLOToF is applied to the GReLoSSS family of applications which we characterized in this paper. The application of the resulting FTG framework to an industrial application of EDF company showed that initial development with FTG involved simple steps and points out some elements to watch in order to minimize runtime overhead. Finally, experiments show the effectiveness of the overall approach and especially the efficiency of FT. For the same number of checkpoints achieved, FTG yields smaller checkpoint sizes than OMPI-BLCR and incurs at most 8% runtime overhead. Recovery from achieved checkpoints exhibited negligible overheads. These results confirm previous ones we achieved on more elementary but varied benchmark applications [START_REF] Makassikis | A Skeletal-Based Approach for the Development of Fault-Tolerant SPMD Applications[END_REF].

Many principles of MoLOToF were used in the design of FTG. But some of them, such as the integration with faulttolerant ecosystems, still have to be integrated and experimented with. Moreover, due to its inherent portability, the approach appears viable for hybrid GP-GPU applications. FTG might further be extended to support other parallelization models such as asynchronous distributed iterative algorithms. Future works are planned along the aforementioned lines.

ACKNOWLEDGMENT

This research is partially supported by Region Lorraine.

Fig. 1 :

 1 Fig. 1: MoLOToF faulttolerant skeleton example. MoLOToF (Model for Low-Overhead Tolerance of Faults) is a programming model geared towards easing the development of fault-tolerant parallel applications. MoLOToF relies (1) on a peculiar structuring of the application and (2) on establishing collaborations through inter-

Fig. 2 :

 2 Fig. 2: Application source code representation.

[FailureFig. 3 :

 3 Fig. 3: Normal execution with checkpoint and failure.

Fig. 4 :

 4 Fig. 4: Recovery execution.

•

  two array datastructures (cf. ftg_Domain) as introduced previously in the GReLoSSS computation model (cf. Sections IV-A and IV-B).

Fig. 6 :Fig. 7 :

 67 Fig. 6: FTG's fault-tolerant skeleton.

Fig. 8 :

 8 Fig. 8: Swing application within FTG.

b o o l f

  t g u d o e x e c u t e r o u t i n g p l a n ( T i t e r s t e p ) ; When inheriting from one of the available ftg_Domain classes, we have to define two so called partition methods:f tg D o main d es c <N rank> f t g u d a t a p o s s e s s e d d e f ( i n t r an k , i n t numprocs , i n t s t e p ) f tg D o m ain d es c <N rank> f t g u d a t a n e e d e d d e f ( i n t r an k , i n t numprocs , i n t s t e p )

d o u b le f t g u l g e t ( i n t lx , i n t l y ) v o i d f t g u l s e t ( i n t

  lx , i n t ly , d o u b le e ) d o u b le * f t g u l g e t A d d r ( T i n y V e c t o r <i n t , N rank> &l c o o r d )

Fig. 9 :Fig. 10 :

 910 Fig. 9: Runtime comparison under the g2d price model.

Fig. 11 :

 11 Fig. 11: Runtimes comparison under the g2d model when increasing number of achieved checkpoints.


M Foroutan
email: foroutan@gsi.ir

Michel Sébrier
email: michel.sebrier@upmc.fr

H Nazari
email: h.nazari@gsi.ir

Bertrand Meyer
email: bertrand.meyer@upmc.fr

M Fattahi
email: mfattahi@ut.ac.ir

A Rashidi

Kristell Le Dortz
email: ledortz@geologie.ens.fr

D Bateman
email: m.d.bateman@sheffield.ac.uk

Foroutan

K Le 3 Dortz

M D Bateman

New evidence for large earthquakes on the Central Iran plateau: palaeoseismology of the Anar fault

come

Introduction 47

The Central Iran Plateau is a wide region experiencing low GPS deformation rates 48 and is commonly described as a rigid block (e.g., [START_REF] Jackson | Active tectonics of the Alpine-Himalayan Belt between 390 western Turkey and Pakistan[END_REF]Vernant et 49 al., 2004). The region (Figure 1) is nonetheless sliced by several strike-slip faults with 50 clear morphological traces [START_REF] Walker | Active tectonics and late Cenozoic strain distribution in 431 central and eastern Iran[END_REF][START_REF] Meyer | Evidence of Quaternary activity 400 along the Deshir Fault[END_REF]Meyer & Le 51 Dortz, 2007) that contrast with the very few earthquakes recorded in the region 52 [START_REF] Ambraseys | Faulting associated with historical and recent 359 earthquakes in the Eastern Mediterranean region[END_REF]. Destructive earthquakes have occurred close to or along 53 the Lut faulted borders only, and, according to the historical and instrumental records 54 [START_REF] Ambraseys | A history of Persian earthquakes[END_REF][START_REF] Ambraseys | Faulting associated with historical and recent 359 earthquakes in the Eastern Mediterranean region[END_REF], the prominent right-lateral 55 strike-slip faults inland remained quiescent for millenniums. Although the absence of 56 historical record of earthquakes in remote and uninhabited desert does not mean an 57 absence of earthquakes, knowledge of the behaviour of such faults and assessment of 58 the regional seismic hazard requires paleoseismic studies and depends on the selection 59 of suitable trenching sites. This is the case for the region of the Dehshir and Anar faults. 60

While a recent paleoseismic study stated the occurrence of large and infrequent 61 earthquakes on the Dehshir fault [START_REF] Nazari | First evidence for large earthquakes on the 408 Deshir Fault, Central Iran Plateau[END_REF][START_REF] Fattahi | Refining the OSL age of the 384 last earthquake on the Dheshir fault, Central Iran[END_REF], the seismic 62 behaviour of the Anar fault is still to be assessed. 63 The Anar fault is a 200-km-long NS strike-slip fault located nearby 55°E, in the 64 middle of the Central Iran Plateau (Figure 1). The northern part of the fault is located 65 within a mountainous region where several closely spaced splays cut across the Kuh-e 66 Kharanaq range. The southern portion of the fault runs along the Kuh-e Bafq range and cuts 67 right across the western piedmont of the range and across the Anar salt flat. The fault goes 68 through the populated city of Anar and further bends eastwards to reactivate a thrust fault 69 to the south. According to 10 Be cosmic ray exposure (CRE) and optically-stimulated 70 luminescence (OSL) dating of cumulative offset of alluvial fans, the southern portion of the 71 fault slips at a minimum rate of 0.8 mm/year (Le [START_REF] Dortz | Holocene right-slip rate determined by cosmogenic and OSL dating on the 394 Anar fault, Central Iran[END_REF]. Both the sharpness 72 of these cumulative offsets and the absence of along fault microseismicity suggest these 73 offsets have accrued through large and infrequent earthquakes rather than by creeping. 74 At a few places, the offset of small gullies that ranges between 2.5 and 3.5 m (Figure 2) 75 may be interpreted as the amount of coseismic slip during the last earthquake but clear 76 evidence for a continuous and distinctive surface break is missing. Trenching appears 77 therefore necessary to document earthquakes and access the Recent seismic history of 78 the fault. 79 80

Site selection and trench stratigraphy 81

We scrutinized the fault on Quickbird satellite imagery and in the field to select 82 the most favourable place to conduct paleoseismic investigations. The selected site is 83 located 35 km north of the city of Anar along a very clear portion of the N175°E fault 84 trace that is highlighted by an E-facing scarp (Figure 3). This fault scarp is readily seen 85 cutting across numerous rills and ephemeral streams that incise a fan surface 86 characterized by a subdued bar-and-swale morphology. The abandoned alluvial fan 87 surface comprises a loose desert pavement of varnished clasts separated by sandy-silty 88 material. The smooth scarp has a minimum height of 35 cm near the excavation (Figure 89 3b). South of the trench site, the scarp height increases progressively to reach one meter 90 where small streams, which have been dammed and channelled along the fault, 91 rejuvenate this scarp. North of the trench site, the scarp height also increases, but the 92 streams are wider and deeper than to the south and have been able to maintain their 93 courses to flow across the fault trace. At the trench site, the possibility of damming small 94 intermittent streams during the emplacement of the fan material is high and the ). The trench strikes N85°E, it has a 28-m-length, a depth between 4.3 and 4.7 m, and 102 a width of some 1.5 m (Figures 3, 4, and5). Trench walls expose a total deposit thickness 103 of 5.9 m with fairly flat, 0.1-to 1-m-thick beds that correspond to medium-distal, alluvial 104 fan facies. Trench stratigraphy is relatively straightforward as these beds are continuous 105 and easily correlated across the fault zone located approximately in the middle of the 106 trench (Figure 5). Overall the beds found in the trench are composed of sands and 107 gravels mixed with variable amounts of silt and clay, these deposits correspond mostly 108 to a debris-flow dominated alluvial fan. Although debris-flows and sheet-floods appears 109 to dominate, sediment dynamics is not easy to determine precisely for each bed due to 110 the medium-distal deposit conditions. 111 A total of 17 units have been defined in the excavated trench (see Table 1 and112 Figures 4 and5). The uppermost part of the trench, approximately the last meter, is 113 made of the thinner units 13 to 17 containing smaller pebbles than the alluvial units 1 to 114 8 and an almost clay-free matrix contrary to the units 9 to 11. This last meter hence is 115 made of runoff deposits. The only evidence for a significant break in alluvial 116 sedimentation is the シ0.15-m-thick, gypsiferous calcrete that is located toward the top of 117 unit 11. This latter unit and units 9 and 10 correspond to reddish brown, mud-118 dominated debris flows. OSL was used to date the alluvial layers seen in the trench. 119 120

OSL dating 121

Six lenses of fine sandy-silts intercalated between fanglomerates at various depths 122 below the surface were sampled for OSL in opaque tubes (Figure 5). The Single Aliquot 123 Regeneration (SAR) protocol (e.g.; Murray and Wintle, 2000) was employed for the 124 Equivalent dose (De) measurement once quartz had been extracted and cleaned from each 125 sample. The analytical procedures employed are identical to that applied to similar samples 126 from the neighbouring Sabzevar, Doruneh, and Dehshir faults (Fattahi et al, 2006;2007;127 2010;[START_REF] Dortz | Dating inset 397 terraces and offset fans along the Dehshir fault combining cosmogenic and OSL 398 methods[END_REF]. In order to make all data consistent, three samples with ages that 128 were previously published in Le [START_REF] Dortz | Holocene right-slip rate determined by cosmogenic and OSL dating on the 394 Anar fault, Central Iran[END_REF], including one sample collected 129 approximately 8 km farther north (OSL-2 on Figure 1 and in Table 2), have been refined in 130 the light of procedural development outlined by [START_REF] Fattahi | Refining the OSL age of the 384 last earthquake on the Dheshir fault, Central Iran[END_REF]. Table 2 2), which are interpreted as having had the OSL signal reset (bleached) prior to 142 burial, Central Age Model (CAM) was employed for calculation purposes. For the remaining 143 samples (Ant-II, Ant-III, Ant-V, Ant-VI and OSL-2 in Table 2), the depositional setting, field 144 sedimentary logs, and the scatter of the replicate aliquot De data indicated that prior to burial, 145 full resetting (bleaching) of the OSL signal had not taken place and/or that the sediments had 146 undergone some post-depositional disturbance [START_REF] Bateman | 370 Preserving the palaeoenvironmental record in Drylands: Bioturbation and its 371 significance for luminescence derived chronologies[END_REF]. Indeed, the small size 147 of the catchment area at the trench site, less than 20 km 2 , is indicative of a rapid transport 148 before the emplacement of the fan (Le [START_REF] Dortz | Holocene right-slip rate determined by cosmogenic and OSL dating on the 394 Anar fault, Central Iran[END_REF]. The great majority of the Anar 149 trench deposits come from high-discharge depositional events with limited surface exposure, 150 which favour partial bleaching [START_REF] Rittenour | Luminescence dating of fluvial deposits: applications to 410 geomorphic, palaeoseismic and archaeological research[END_REF]. As a consequence, Finite Mixture Model 151 (FMM; [START_REF] Roberts | Distinguishing dose 412 populations in sediment mixtures: a test of single-grain optical dating 413 procedures using mixtures of laboratory-dosed quartz[END_REF] was used where samples showed skewed, scattered, or 152 multimodal distributions and the dominant De component was used for age calculations (as in 153 [START_REF] Fattahi | Refining the OSL age of the 384 last earthquake on the Dheshir fault, Central Iran[END_REF]. This approach yielded ages in accordance with site stratigraphy except 154 for sample Ant-III whose age was too young. This sample has exhibited the highest over-155 dispersion value (51%, Table 2) of all measured samples and three De component were 156 extracted by FMM for this sample, the highest representing 30% of the signal and the smallest 157 47%. It is possible to get an age that fits with stratigraphy using the higher two De 158 components extracted using FMM, corresponding to ages of 7.3±0.5 ka and 10.7±0.8 ka, 159 and9). As the dose-rate for this sample is based only on the activity from unit 9, a difference 166 in the gamma radiation dose received from unit 8 might help explain the apparent under-167 estimation of age based on the lowest FFM De component. Unfortunately field-based gamma-168 spectrometer readings or material for analyzing the radioactive elements within unit 8 were 169 not available to test this and so the age of Ant-III has not been included within the subsequent 170 site interpretation. Thus, the ages of the trench units have been constrained based on only five 171 OSL ages (Ant-I, Ant-II, Ant-IV, Ant-V, and Ant-VI). 172 173

Ages of trench units 174

The samples collected within the trench define a time range spanning from 5.8 to 175 14.9 ka. The oldest age Ant-I (13.6±1.3 ka) stands at the bottom of the trench and 176 belongs to one of the oldest stratigraphic units (unit 2), it indicates that all the trench 177 units should be younger than 15 ka. As the youngest OSL sample Ant-VI (6.2 ± 0.4 ka) is 178 located at 0.8 m below the surface (unit 14), these ages define a maximum time interval 179 between 0 and 14.9 ka and a minimum one between 6.6 and 12.3 ka, indicating the 180 trench deposits aggraded during the uppermost Marine Isotopic Stage 2 (MIS-2シなに-181 22 ka) and part, or the entirety of MIS-1. The age of the fan surface at the trench site 182 appears poorly constrained between 0 and 6.6 ka. 183

A proxy to the surface age may be obtained by estimating average sedimentation 184 rates. Assuming this fan surface is still active, the whole 5.9 m of sedimentary units seen 185 in the trench should have been aggraded during the last 14.9 or 12.3 ka at an overall 186 sedimentation rate ranging between 0.4 and 0.48 mm/yr. Deposit thicknesses above the 187 samples Ant-I (13.6±1.3 ka) and Ant-II (12.4±0.6 ka) yield slightly lower rates ranging 188 between 0.28 and 0.36 mm/yr. Conversely, if one assumes the top of the fan surface was 189 abandoned just after 6.6 ka, the oldest possibility for the youngest sample (Ant-VI), the 190 ̇ºaeß̶̋ø" ̨̇º" aeº" ß̶̋" øAEoe̋ø" aę" ̇" シね の" OE" AEº˚AEoe̋¸" ¸ø " oeßø̋̇OE, suggests its surface was 196 abandoned some 9-10 ka ago at this site while the fan surface at the trench site cannot 197 be older than 6.6 ka. These ages are in agreement with the late Pleistocene and Holocene 198 regional climate scenario, for the central and eastern Iran, as recently proposed by 199 [START_REF] Walker | A framework of Holocene and Late Pleistocene 427 environmental change in eastern Iran inferred from the dating of periods of 428 alluvial fan abandonment, river terracing, and lake deposition[END_REF]. In fact, the satellite image in the vicinity of the trench site 200 (Figure 3a) shows this location corresponds to an area where the fan surface has been 201

exceptionally preserved from the backward erosion of deeply incised dry streams. 202

Therefore, the late aggradation on the fan surface at the trench site (漢1544 m a.s.l.), 203 resulting from surface runoff, lasted until more recently than some 8 km further north 204 on a more proximal alluvial fan (漢1748 m a.s.l.) where Le [START_REF] Dortz | Holocene right-slip rate determined by cosmogenic and OSL dating on the 394 Anar fault, Central Iran[END_REF] collected 205 the sample OSL-2. In conclusion, the best estimate for the aggradation rate of the trench 206 sediments is provided by the depth difference of 3.3 m between Ant-I (13.6 ± 1.3 ka) and 207 Ant-VI (6.2 ± 0.4 ka) samples, this rate ranges between 0.36 and 0.58 mm/yr. 208

Interestingly, this rate is comparable to the late Pleistocene-Holocene aggradation rates 209 derived from alluvial sediments in similar deposition settings at southwestern Nebraska, 210

Negev desert and Central Iran plateau [START_REF] Daniels | Floodplain aggradation and pedogenesis in a semiarid environment[END_REF][START_REF] Guralnik | Constraining the evolution of 387 river terraces with integrated OSL and cosmogenic nuclide data[END_REF]211 Schmidt et al., 2011). Consequently, the best averaged net sedimentation rate, if 212 meaningful in such environment, amounts to 0.47±0.11 mm/yr suggesting that the final 213 aggradation of the trench units ended between 3.6 and 5.2 ka to the west of the fault 214 Event A, the youngest event is responsible for the 35-cm-high, E-facing scarp, 228 which is observed at the surface in the vicinity of the trench (Figures 3b and3c). The 229 trench log shows this scarp is located above a nearly 1-m-wide, steep faulted zone 230 associated with an E-facing flexure of the upper trench units; i.e., downthrown to the 231 east (Figure 5). Units 16 and 17 are not observed west of the fault zone nor warped 232 eastward. They rest unconformably on unit 15 dipping about 25°E (Figure 6), hence 233 indicating the faulting and flexuring deformation postdate unit 15 and predate units 16 234 and 17. As there are no significant thickness differences of the upper trench units on 235 both sides of the fault zone, the faulting and flexuring deformation appear to result from 236 a sudden and discrete slipping event on the fault zone instead of a continuous shear; i.e., 237 creep slip (Figure 7-step 1). Inasmuch as the upper trench units are seen faulted up to 238 unit 15, the discrete slipping event should relate to an earthquake that ruptured the 239 surface producing the scarp. The event horizon of this earthquake locates on the top 240 boundary of unit 15, so that it stands between this latter and units 16 and 17 to the east 241 of the fault and corresponds approximately with the present-day topographic surface to 242 the west of the fault. This suggests that the western block has been slightly eroded as 243 well as partly concealed by units 16 and 17 so that its present-day height 244 underestimates its original height at the time of the earthquake (Figure 7-step 2). Then, 245 unit 17 is a local sag pond deposit caused by event A. 246 Backstripping of event A suggests its vertical throw is of some 60 cm (Figure 7-247 step 3), confirming that the 35-cm high scarp at the surface has been partly degraded. 248

Taking into account the Anar fault is dominantly a strike-slip fault (Figure 2), the 60 cm 249 of vertical displacement should be associated with at least a couple of meters of right-250 lateral displacement. Then, the magnitude of event A should be at least on the order of 251 Mw 7. The age of event A is poorly constrained as the uppermost OSL sample (Ant-VI), 252 which is at 0.8-m-depth, comes from unit 14. This indicates only that event A is younger 253 than 6.6 ka. Tentatively, the sediment thickness, which stands between the sample Ant-254 ). It is possible to observe these features formed suddenly as they disrupt the hard 265 gypsiferous calcrete (e.g., Figure 8b), which is located in the top part of unit 11. Thus, the 266 interface between units 11 and 13 corresponds to the event horizon of event B. The 267 backstripping analysis of the trench log (Figure 7), removing the effects of event A and 268 the units aggraded between events A and B, allow reconstructing the event B horizon 269 just after the penultimate earthquake (Figure 7-step 4). This reconstruction suggests 270 that the rupture of event B should have occurred on two parallel fault strands of the 271 Anar fault zone, totalling a vertical throw of some 40 cm, distributed into 25 cm on the 272 eastern strand and 15 cm on the western one. Thus, the penultimate earthquake appears 273 to have a vertical throw close to that of the last one, hence a magnitude lightly 274 comparable with the one of event A. The age of event B is well constrained by three OSL 275 ages (Ant-V, -IV, and -VI) and bracketed between 5.8 ka and 7.8 ka yielding an average 276 age of 6.8±1 ka for this earthquake (Figure 9). 277

Event C, the oldest seismic event, can be safely identified on the trench walls. 278

Evidence for a third earthquake rests on the facts that lower trench units (5 to 8) exhibit 279 higher vertical throws than middle ones (9 to 11). Different reconstructions have been 280

tested to restore the trench lower units, the best fit is obtained when considering the 281 interface between units 8 and 9 as the event horizon of a surface rupturing earthquake 282 (Figure 7-step 6). This reconstruction favours that event C ruptured along the eastern 283 fault strand with a vertical displacement of about 25 cm. Nevertheless, this vertical 284 displacement is poorly constrained and higher estimates might be obtained according to 285 the amount of erosion chosen (dashed line on Figure 7 throw is poorly determined and appears smaller than the ones of the subsequent 287 earthquakes, this does not imply a much smaller magnitude as the amount of coseismic 288 vertical displacement is highly variable along a strike-slip fault (e.g., [START_REF] Barka | Slip distribution along the North Anatolian Fault associated with the 361 large earthquakes of the period 1939 to 1967[END_REF]Barka 289 et al., 2002). The age of event C is not well constrained, it occurred prior to the OSL age 290 of sample Ant-V (7.1±0.7 ka) and after that of Ant-II (12.4±0.6 ka) so that it is bracketed 291 within the interval between 6.4 and 13 ka, with a minimum interval of 4 ka (Figure 9). 292

We have investigated the possibility for a fourth event in the lowermost part of the 293 trench (Figure 5). However, the lowermost units (1 to 4) cannot be followed on the 294 eastern side of the trench precluding the possibility to document an additional event. 295 296

Discussion and Conclusions 297

Due to the reduced size of the surface sag pond, a 3D trench exploration was not 298 undertaken at the trench site so that the slip per event was not directly measurable for 299 the three identified seismic events, A, B, and C. Accounting for the lack of morphological 300 segmentation along the Anar fault (Le [START_REF] Dortz | Holocene right-slip rate determined by cosmogenic and OSL dating on the 394 Anar fault, Central Iran[END_REF] and the excavation of a single 301 trench, there are no possibilities to calculate confidently any magnitude. The restored 302 vertical throws per event suggest only that the related magnitudes are more likely on 303 the order of Mwシば" (see previous section). The right-lateral offsets observed at the 304 surface (Figures 2 and3a) permit to reinforce this inference. Deeply incised intermittent 305 streams are seen offset by 8±0.5 m (Le Dortz et al., 2009 and Figure 3a) while several 306 weakly incised small dry gullies show offsets of 3±0.5 m only (Figure 2). Considering 307 these lower offsets were more likely formed during the most recent earthquake, they 308 provide the best estimate for the coseismic horizontal slip of event A. Such a coseismic 309 slip at the surface agrees with a magnitude close to 7. Thus the higher offsets, which are 310 only observed where the alluvial surface is older, should represent the cumulative 311 horizontal slip of the last three events that are seen in the trench. Therefore, the three 312 events, which are observed within the trench to the north of Anar city, should have had 313 slip per event on the order of 3 m, suggesting they are of similar magnitudes. 314

Overall, the new data presented in this paper give evidence for at least three 315 seismic events of similar sizes on the Anar fault (Figure 9). OSL age of Ant-I sample 316 indicates that the aggradation of the trench units did not started much before 14.9 ka or 317 to the latest by 12.3 ka. Since only 3 events have occurred during the last 15 ka, this 318 provides a rough estimate of at most 5 ka for the average maximum time interval 319 between two earthquakes. The youngest age possibility may reduce this average time 320 interval between two earthquakes ßae" シね ka. Considering the best estimates of average 321 ages for the three seismic events A, B, and C are: 4.4±0.8 ka, 6.8±1 ka, and 9.7±3.3 ka, 322 respectively (Figure 9), the time interval between two subsequent earthquakes is ill-323 defined and might vary significantly. Nevertheless, the average ages for events A, B, and 324 C indicate that the intervals between two subsequent earthquakes should be of 2400 325 and 2900 years between events A-B and B-C, respectively. As the elapsed time since the 326 last earthquake is 3600 years at least and 5200 years at most, this suggests we are 327 getting close to the end of the seismic cycle and may anticipate a destructive earthquake 328 for the Anar city in the near future. 329

Finally, the cumulative offset of 8±0.5 m (Le [START_REF] Dortz | Holocene right-slip rate determined by cosmogenic and OSL dating on the 394 Anar fault, Central Iran[END_REF] postdating fan 330 aggradation and the refined age of fan abandonment given by OSL-2 sample 331 (10.1±0.6 ka) confirms a minimum slip rate estimate of 0.8±0.1 mm/yr for the Anar 332 fault. Then, the westernmost prominent right-lateral faults of the Central Iran plateau, 333 namely the Dehshir and Anar faults, which are active though void of historical and 334 instrumental earthquakes, are characterized by slip rates close to 1 mm/yr (Le Dortz et 335 al., 2009 and2011). Such faults have repeatedly produced destructive earthquakes with 336 large magnitudes (Mwシば) and long recurrence interval of several thousands of years 337 during the Holocene [START_REF] Nazari | First evidence for large earthquakes on the 408 Deshir Fault, Central Iran Plateau[END_REF]Fattahi et al., 2010 and this paper). This 338 demonstrates that the Central Iran plateau does not behave totally as a rigid block and 339 that its moderate internal deformation is nonetheless responsible for a significant 340 Sample Ant-II, collected east of the fault zone at 4.2-m-deep within unit 5, yields an age 466 of 12.4±0.6 ka. Sample Ant-III, collected at 1.5-m-deep in a sandy lens of unit 9, yields a 467 poorly constrain ages between 11.5 and 3.3 ka. Sample Ant-IV, collected at 1.5-m-deep at 468 the base of a fissure filled with eolian and runoff sand deposits within unit 12, yields an 469 age of 6.2±0.6 ka. Sample Ant-V, collected at 1-m-deep within unit 11, yields an age of 470 7.1±0.7 ka. Sample Ant-VI, collected at 0.8-m-deep in a sandy lens within unit 14, yields 471 an age of 6.2±0.4 ka. 472 Step 2) is E-facing fault scarp formed during the most recent earthquake.

Step 3) is 482 restoration of the ground surface to its position prior to event A showing a vertical 483 displacement of about 60 cm created by faulting on the eastern branch. Step 4) is the 484 penultimate earthquake denoted by open fissures and cracks formed near the main 485 faulted zone. Sand-blows also emplaced in both sides and away of the main faulted zone. 486

Step 5) is restoration of the ground surface to its position prior to event B showing 487 vertical displacement created during penultimate earthquake on the eastern and 488 western fault branches about 25 and 15 cm, respectively. Step 6) is the oldest 489 earthquake, it has produced some surficial fissures within downthrown (eastern) block 490 and a 25-cm-height E-facing fault scarp. Step 7) is restoration of the ground surface to its 491 position prior to event C, showing a vertical displacement of about 25 cm. 492 The fissure is ~85-cm-deep and up to ~55-cm-wide, tapering downward through unit 9. 497 Colours denote stratigraphy as shown in Figures 4 and5. The material at the base of the 498 fissure includes a collapsed piece from sidewall and grades into interbedded sand and 499 silt layers. The fissure is sealed by a grey, well-stratified, surficial runoff deposit (unit 500 13). (b) Photomosaic and interpretative sketch of a sand-blow (unit 12) made of sandy 501 material of unit 8 injected into and deforming units 9 and 11. Hydraulic fractures, 502 vertical and oblique alignments of dragged sands and gravels deform the host sediments 503 close to the liquefaction pillar. 504

537

including some channels of angular gravels (90%, 2-15 cm) with silt matrix.

538 8 Cream to brownish grey, fairly stratified, well consolidated, angular granules and pebbles (60%, 0.2-3 cm),

539

with silty sand matrix, including some small cobbles and traces of sulfate calcrete within the coarser levels. 545 4 Grey to light grey, poorly stratified, well sorted, silty sands with some cross-bedding and gravelly lenses.

546

3 Grey, fairly stratified, well consolidated, medium to well sorted, coarse angular gravels (90%, 0.5-10 cm)

547

with silty sand matrix, including some sparse bigger cobbles and clayish silty sand lenses.

548 2 Grey, stratified, loose, silty sand, with some cross-bedding.

549

1 Grey, poorly stratified, well consolidated, angular pebbles (>20%, 0.5-3 cm) with silty sand matrix.

555

b Age based on De determined using the dominant component of Finite Mixture Modeling (FMM; [START_REF] Roberts | Distinguishing dose 412 populations in sediment mixtures: a test of single-grain optical dating 413 procedures using mixtures of laboratory-dosed quartz[END_REF].

556

c Age previously published, now refined using Finite Mixture Modeling (FMM; [START_REF] Roberts | Distinguishing dose 412 populations in sediment mixtures: a test of single-grain optical dating 413 procedures using mixtures of laboratory-dosed quartz[END_REF].

  erosion low, maximizing the chances to record the earthquakes 96 coeval with alluvial aggradation and subsequent colluvial deposition. The next 97 paragraphs report the observations gathered at the selected site, where trenching 98 allowed us to distinguish three unambiguous events. 99The eastern tip of the excavated trench is located about 5 km west of the Kuh-e 100 Bafq range at 31.1953°N; 55.1536°E, and 1544-m-altitude above sea level (Figures 1 and 101

  3b

  , there are no good reasons to accept components representing only 160 23% or 30% of the data over the 47% of the data incorporated into the dominant smallest 161 FMM component. The latter cannot be ignored on the basis of partial bleaching as it has a 162 lower De and is unlikely to represent post-depositional disturbance as it is the dominant De 163 component but also based on observed bedding within the unit. However, unlike most other 164 samples studied, Ant-III was sampled actually on a stratigraphic boundary (between units 8 165

  Figure 1, see also Figures 4a and 7 in Le Dortz et al., 2009) at 0.8 m below the surface of 195

  zone and approximately one thousand years later to the east of the fault zone. The 215 abandonment age of the fan surface at the trench site (4.4±0.8 ka) is comparable with 216 late Holocene drought cycles at 4.2 ka, proposed by[START_REF] Staubwasser | Climate change at the 4.2 ka 420 BP termination of the Indus valley civilization and Holocene south Asian monsoon 421 variability[END_REF] to the 217 southeast of the Persian Gulf. 218 219Seismic event identification 220The surface geomorphology, particularly, the characteristics of the fault scarp, 221 fault strands, and fissure fills or sand-blows), and restoration of the trench log 223 permit to trace three individual event horizons that correlate with three destructive past 224 earthquakes, which ruptured the ground surface. The evidence for these three seismic 225 events, which are labelled A, B, and C from the youngest to the oldest, is presented 226 below. 227

  event horizon of event A, may be used to propose a rough estimate of the 255 youngest possible age for this seismic event based on the aggradation rate between Ant-256 VI and Ant-I. Since aggradation of unit 15 ended between 3600 and 5200 years (see 257 previous section) event A should not be younger than 3600 years and might be as old as 258 5200 years. This time interval will be considered as the preferred age of event A in the 259 following discussion. 260 Event B, the penultimate event, is easily determined from analysis of the trench 261 walls. Several filled fissures (unit 12), which postdate unit 11 and predate unit 13, are 262 seen. A careful analysis of these filled fissures permits to 263 conclude they correspond indeed to either open cracks or sand-blows (Figures 8a and 264

  8b

Figure 1 .Figure 2 .Figure 4 .Figure 5 .

 1245 Figure captions 434

Figure 6 . 477 Figure 7 .

 64777 Figure 6. Photomosaic (top) and interpretation (bottom) of the main faulted 473 zone showing evidence for the most recent earthquake (event A). Units 11 to 15, 474 affected by faulting, are warped downward, while undeformed units 16 and 17 lie 475 unconformably atop. Faults and tiny fractures are shown as red and dashed red lines, 476 respectively. 477

Figure 8 .

 8 Figure 8. Evidence for the penultimate earthquake (event B) encountered in a 493

Figure 9 .

 9 Figure 9. Five well-constrained OSL ages place bounds on the ages of the three 505 paleoearthquakes (A, B, and C) identified in the Anar trench exposure. Light grey areas 506 represent the maximum time windows for the past earthquakes, dark grey pointing the 507 minimum time window for event C. For event A, hatched domain shows the preferred 508 time interval of the earthquake (4.4±0.8 ka). Colour codes are similar to units shown in 509 Figures 4 and 5. Question mark illustrates the ambiguity due to the lack of ages in units 510 postdating the most recent earthquake (16 and 17). 511

542 65

 542 grey, poorly stratified, poorly sorted angular pebbles (70%, 0.5-10 cm), with sandy silt 541 matrix. Cream to brown, fairly stratified, angular granules and pebbles (80%, 0.2-4 cm), with silty sand matrix,543including some sparse big cobbles and silty sand lenses.544 Buff to light grey, fairly stratified, loose silt and sand.

557*

  Parenthesis contains the sample label used by Le Dortz et al.

Table 1 .

 1 Detailed description of the units observed in the trench excavated across the 513

	514	Anar fault, corresponding stratigraphic column and log are shown in Figures 4 and 5,
	515	respectively.
	516

Table 2 .

 2 Calculated OSL ages on the Anar samples with their parameters.

	Ages have

536 9

Reddish brown to brownish grey, non-stratified, semi-consolidated coarse sand, with clayish silt matrix,

Geophysical Journal International