Arnaud Blouin
email: arnaud.blouin@irisa.fr

Benoît Combemale
email: bcombemale@irisa.fr

Benoit Baudry
email: bbaudry@inria.fr

Olivier Beaudoux
email: olivier.beaudoux@eseo.fr

§ Benoit Baudry

Kompren: Modeling and Generating Model Slicers *

Among model comprehension tools, model slicers are tools that extract a subset of model elements, for a specific purpose. Model slicers provide a mechanism to isolate and focus on parts of the model, thereby improving the overall analysis process. However, existing slicers are dedicated to a specific modeling language. This is an issue when we observe that new domain specific modeling languages (DSMLs), for which we want slicing abilities, are created almost on a daily basis. This paper proposes the Kompren language to model and generate model slicers for any DSL (e.g. modeling for software development or for civil engineering) and for different purposes (e.g. monitoring and model comprehension). We detail the semantics of the Kompren language and of the model slicer generator. This provides a set of expected properties about the slices that are extracted by the different forms of the slicer. Then we illustrate these different forms of slicers on case studies from various domains.

1 Introduction

Context

Program slicing [START_REF] Weiser | Program slicing[END_REF] is a "technique for focusing on certain aspects of a program's behavior and removing all other parts of code not concerned with this behavior [START_REF] Jaiprakash | A dynamic slicing technique for UML architectural models[END_REF]". The two major slicing methods are currently static and dynamic slicing. Static slicing is an operation that takes as input slicing criteria, i.e. variables and their position in the program to slice. This operation produces as output a slice composed of the statements that may have effects on the slicing criteria. The static slicing operation does not execute or interpret the program so that the output slice may not be minimal. For instance, control flows such as if(foo) then ... else ... endif are not evaluated to state which conditional branch, then or else, must be sliced; the whole if statement is sliced. Dynamic slicing remedies this drawback by evaluating the programs' statements. The interested reader can refer to [START_REF] Silva | A vocabulary of program-slicing based techniques[END_REF][START_REF] Harman | An overview of program slicing[END_REF][START_REF] Gallagher | Program slicing[END_REF][START_REF] Xu | A brief survey of program slicing[END_REF][START_REF] Tip | A survey of program slicing techniques[END_REF] for more details on program slicing.

Model slicing is a model comprehension technique inspired by program slicing. The process of model slicing involves extracting a subset of model elements which represent a model slice. The model slice may vary depending on the intended purpose. For example, when seeking to understand a large class diagram, it may help to extract the sub-part of the diagram that includes only the dependencies of a particular class. For other comprehension purposes one might want the footprint of model operations [START_REF] Jeanneret | Estimating footprints of model operations[END_REF], or extracting information from several interdependent models [START_REF] Jaiprakash | A dynamic slicing technique for UML architectural models[END_REF].

Program slicing transposed to models can be divided into static and dynamic slicing as well. Static model slicing consists in slicing models according to structural criteria. For instance, slicers relying on the MOF (Meta-Object Facility1 ) metametamodel will slice the structure of models (classes, properties, etc.). Dynamic model slicing considers the behavioral semantics of the input metamodel and requires the execution of the sliced model. For example, slicing an automaton with respect to a specific event as a slicing criterion, consists in extracting a sub-automaton, which reacts to the selected event. In this paper we focus on static slicing of models.

There has been previous work on the definition of model slicers. But all the existing model slicers are dedicated to extracting one form of slice from models that conform to a specific metamodel. In times when new domain specific modeling languages (DSMLs) appear regularly to improve productivity, this becomes an issue: on the one hand, it is not convenient to develop slicers from scratch for each new DSML; on the other hand, these DSMLs will provide full expected benefits for productivity only if they are supported by the same analysis and comprehension tools as general purpose languages. Thus it is necessary to develop a generative approach that will automatically build model slicers for new metamodels.

Contributions

In this paper we propose Kompren 2 , a DSML to model model slicers for a particular domain (captured in a metamodel). The knowledge gained from practical experience and current model slicers, lead to the design choices of the Kompren language. The primary objective of Kompren is the selection of classes and properties in an input metamodel. Kompren promotes the definition of slicers that slice all necessary elements to make the slice a valid instance of the input metamodel. Kompren also facilitates the relaxation of the conformance required by the input metamodel. Kompren offers a set of language features to generate model slicers that can still be parameterized to process the model slice for a specific purpose. The different characteristics of Kompren tackle two goals for our generative approach: automatically building model slicers for any DSML; have model slicers that can extract different forms of slices, depending on the purpose of the slice.

The contributions of this paper are the following:

1. a language to model model slicers for any metamodel;

2. an illustration of the language expressiveness over three uses cases on model operation analysis, model comprehension, and model monitoring at runtime; This paper extends our work published at MODELS 2011 [START_REF] Blouin | Modeling model slicers[END_REF] with the last three contributions 3, 4, and 5.

Paper Outline

In section 2 we introduce several motivating scenarios that illustrate the various forms of model slices that must be generated when analyzing models in various languages. Section 3 introduces the overview of building model slicers with the Kompren language. Section 4 presents the Kompren language: its metamodel, compiler, and concrete syntax. Section 5 describes the Kompren tools provided to users and different benchmarks to analyze the scalability of the implementation. Section 6 demonstrates the expressiveness of Kompren on the three illustrative cases introduced in Section 2. Section 7 discusses the related work on model slicing. Section 8 concludes this work and proposes a research agenda on model slicing.

Heterogeneous Use Cases of Model Slicing

The classical use of model slicing consists in extracting submodels from models by keeping conformance rules. However, as shown in the motivating use cases below model comprehension also requires extracting models which do not satisfy conformance. Still, this extraction can rely on model slicing mechanism.

Use case 1: Model operation analysis. Given a model operation on a large metamodel M M 1 , developers demand the effective metamodel M M 2 used by the operation such that M M 2 ⊂ M M 1 . For instance, when defining a state machine flattening operation over the UML metamodel, only the UML class diagram and the UML state machine elements are used. This model operation must be analyzed to select the M M 1 elements it uses and to get the effective metamodel M M 2 [START_REF] Sen | Meta-model Pruning[END_REF].

In terms of program slicing this is similar to the technique used in bytecode shrinking. For example, Proguard 3 analyzes Java bytecode to eliminate all classes that are not used.

Use case 2: Semantic zooming on models. Several program slicing methods have been used to assist in program comprehension (e.g. [START_REF] Binkley | An empirical study of amorphous slicing as a program comprehension support tool[END_REF][START_REF] Rilling | Identifying comprehension bottlenecks using program slicing and cognitive complexity metrics[END_REF]). Similarly, understanding and manipulating large models require visualization techniques to provide meaningful navigation capabilities [START_REF] Margaret | Cognitive design elements to support the construction of a mental model during soft-ware exploration[END_REF]. Semantic zooming is a Human-Computer Interaction (HCI) technique that can be applied for this purpose. In contrast to physical zooming that alters the size of objects, semantic zooming changes the type and meaning of information displayed by objects [START_REF] Herman | Graph visualization and navigation in information visualization: A survey[END_REF]. For instance, as shown in Fig. 1a, semantically zooming on class inheritance extracts superclasses of a given class. We can notice that semantic zooming does not require the output slices to conform to their metamodel; the output slices are not saved as new models, but used by HCI features to perform semantic zooming. The model slicing applications are not limited to the computer science domain. For example, recent work proposed a model-driven approach in civil engineering for the interoperability and comprehension of building models [START_REF] Steel | Model interoperability in building information modelling[END_REF]. This application of MDE is particularly challenging for all MDE tools since the entire model includes more than 5M of model Use case 3: Model Monitoring at runtime. Monitoring models at runtime is an important feature to control their evolution. For example, state-based model stakeholders may want to monitor the current state. Thus dedicated tools need to extract only information relevant to the current state. Such information must be incrementally extracted to improve performance on large models. This use of model slicing is similar to slicing techniques extract the value of variables of a running program for debugging [START_REF] Tip | A survey of program slicing techniques[END_REF].

Overview

Fig. 2 provides an overview of the proposed approach to model model slicers. The core contribution of this paper is a modeling language dedicated to the construction of model slicers. The language is called Kompren. All the concepts and relations of Kompren are captured in a model slicer metamodel (MSMM at the top of Fig. 2). A model slicer model (MSM) expressed with Kompren refers to a set of classes and relations from the input metamodel expressed using an object-oriented meta-language (e.g., Ecore, in our case). Instances of the referenced classes and relations will be selected for slicing in the input model. Thus MSMM points to Ecore to enable MSM to use Ecore elements from an input metamodel. Because Ecore describes the structure of metamodels, the Kompren model slicers are syntactic. MSMM also points to Kermeta [START_REF] Muller | Weaving executability into objectoriented meta-languages[END_REF], an action language used to specify the behavior of a slicer. Kompren's compiler processes an MSM defined for an input metamodel and automatically generates an actual model slicer function (MSF). In this context, a slicing criterion is a set of model elements that provide the entry point for extracting a model slice. Using Kompren, the MSM specifies the type of the slicing criteria among the classes of the input metamodel. Then, Kompren generates the set of corresponding parameters for the MSF, letting the domain expert specify a slicing criterion to execute the MSF.

This global approach is a two-level generation process: Kompren's compiler generates an MSF, which in turn generates model slices. From a methodological perspective, we also distinguish two roles for Kompren users:

• Domain expert. The domain expert knows the domain captured in the input metamodel and knows its concepts and relationships. This person is thus in charge of leveraging this domain to model one or several model slicers relevant for this domain. The domain expert selects the elements in the input metamodel that will be processed by the model slicer through the MSF.

• Domain users create models in the domain. These users, through their modeling activities, can create large instances of the input metamodel. At some point these users need to extract slices thanks to the MSF. These users parameterize the model slicer according to their need and according to the values in the input model.

4 Model-Driven Specification of Slicers

Kompren Features for Model Slicer Generation

A model slicer is specified by a Model Slicer Model (MSM) and implemented by a Model Slicing Function (MSF) generated from the MSM (cf. Fig. 3). An MSM enables the specification of classes and properties whose instances must be selected from a given input model. Input models can be either structural or behavioral. In both cases, the slicing operation consists in visiting the model for a particular purpose according to the structure of their metamodel and the classes and properties specified in the MSM. Such a processing is performed by a Model Slicing Function (MSF) generated from an MSM, and results in a slice.

Below, we detail the features offered by Kompren to (i) ease the modeling of MSMs, and to (ii) specify an evaluation mode of an MSF. We also discuss the different properties one can expect on slices generated by the MSF (cf. Fig. 4). We use an example to illustrate theses features: the class diagram input metamodel (Fig. 5a) and the input model shown in Fig. 5b.

Kompren proposes the following constructs to assist the definition of an MSM (left part of Fig. 4):

• Add a transient opposite property in the input metamodel to ease the slicing. For example, Fig. 6b is a slice of 5b that selects A and its subclasses. To ease the slicing of the input model, the MSM requires the opposite of the superTypes property in the input metamodel.

Slicing Mode

The MSF can be generated from one MSM with one of the following slicing mode:

• Batch: the MSF slices the input model once, when called by the domain user (cf. use cases 1 and 2);

• Active: the MSF automatically updates the slice each time the input model changes (cf. use case 3).

Slicing Output Formats

According to the specified MSF and the selected options, the model slicers will generate model slices, which have different properties. In the following we list the properties one can expect from a model slice (right part of Fig. 4, feature model below 'Output metamodel').

First, the MSF can provide a resulting slice as a new model satisfying all the structural constraints imposed by the input metamodel. In such a case the slice is a valid instance of the input metamodel, and we call the corresponding model slicer an endogenous model slicer . For example, Fig. 6a is a slice of Fig. 5b that includes only A and F, as well as the mandatory classes D and E to satisfy the conformance with the input metamodel. Model slicers providing a slice conforming to a different metamodel than the input metamodel are called exogenous model slicer. We distinguish two categories of exogenous model slicers:

• Exogenous model slicers that generate a slice conforming to a metamodel inferred by analyzing the MSM and adapting the input metamodel (cf. in Fig. 4).

-Add a persistent opposite property in the output metamodel. For example, Fig. 6b could be saved with the opposites of the superTypes property used to ease the slicing (e.g. to facilitate its navigation according to this property in a later processing). In such a case, the input metamodel must be enriched with the opposite properties to save the resulting slice (cf. Fig. 7a).

-Add constraints to filter the sliced elements removing elements required to conforms to the input metamodel. For example, Fig. 7b shows a constrained version of the metamodel of Fig. 5a where the two relations type (cardinality [START_REF] Mathieu Acher | Slicing feature models[END_REF]) were removed.

• Exogenous model slicers that generate slice conforming to a metamodel explicitly imported by the domain expert in its MSM definition (cf. in Fig. 4). For example, Fig. 6e is an RDBMS 4 -based slice extracted from Fig. 5b by selecting the class B and its direct classes (A).

In addition to Model to Model (M2M) model slicers, Kompren also supports the generation of MSF that produce texual slices. We call these slicers Model to Text (M2T) slicers. These can be used to print information about the sliced model elements or to notify external tools about the slice.

All the previous expected features were considered in the design of the Kompren language. We present respectively in the remainder of this section the abstract syntax, concrete syntax, and semantics embedded into the compiler of the Kompren language.

Kompren Abstract Syntax

The metamodel shown in Fig. 8 describes the abstract syntax of Kompren. An instance of this metamodel is a Model Slicer Model (MSM). The main package is slicer. In this package, a Slicer is mainly composed of SlicedElements. These sliced elements are the classes (SlicedClass) and the properties (SlicedProperty) of interest in the Model Slicing Function (MSF). All sliced elements belong to the input metamodel identified in the slicer by its URI 5 (uriMetamodel ). Optional SlicedElements (i.e. isOption is true) are 4 Relational DataBase Management System 5 Uniform Resource Identifier options of the generated MSF. This lets the domain user choose whether an element must be considered during the slicing.

A SlicedClass refers to a class (EClass) in the input metamodel (domain). All instances of a referenced class in a given input model are selected by the MSF. Then ctx (contained in SlicedClass) serves as a temporary variable to successively manipulate each instance (i.e. an iterator). The type of this iterator (type in VarDecl) must correspond to the sliced class. This constraint can be formalized using OCL (Object Constraint Language6 ) as follows:

1 context SlicedClass inv: 2 self.domain = self.ctx.type
Similarly, a SlicedProperty refers to a property (EStruc-turalFeature) in the input metamodel (domain). All instances of a referenced property in an input model are selected by the MSF. The src and tgt iterators allow the manipulation of the property's source and target. The type of the src and tgt iterators is respectively the source and the target class of the property: In addition, a sliced property may specify an Opposite-Creation to define that an opposite must be created on the targeted domain. The name of this new opposite is given by the attribute name. By default, such opposites are used as helpers for exploring the input metamodel and are not serialized in the output slice. But developers may want to serialize some of the opposites; in such a case, the attribute transient of a given OppositeCreation must be set to false and an output metamodel, augmented with the selected opposites, will be inferred.

We assume in this paper an input metamodel defined with an existing object-oriented metamodeling language. In our experiments we use the Ecore metamodeling language provided by the Eclipse Modeling Framework7 whose required elements are imported in the package ecore. In Ecore, a class and a property are identified by respectively the classes EClass and EStructuralFeature. Another object-oriented metamodeling language could be easily considered in Kompren.

Moreover, the iterators on sliced elements (instances of the specified SlicedClass and SlicedProperty) allow the domain expert to express the expected behavior for each selected instance. The effect of the MSF on each selected instance is described as an expression using an action language. In our experiments, we use the action language of Kermeta [START_REF] Muller | Weaving executability into objectoriented meta-languages[END_REF] whose required elements are imported in the package kermeta. Another action language could be easily considered in Kompren.

By default, the model slicer can be exogenous or endogenous depending on the behavior defined by the developers. The expressions onStart and onEnd are used to add a par- The radius and the constraints can be used to filter the sliced elements in the input model. The radius sets in the MSM the focusedClasses for which the MSF should be ited to a selection within a given radius. Starting at 0, a value is incremented on each visited class instance focused by the radius. The slicing process stops when no elements can be sliced anymore or when this value is greater than the radius given as parameter. Fig. 9 shows an example of the radius process where the focused class is Class and the slicing criterion c 1 . Each dashed ellipse shows the sliced instances for a specific radius value: c 1 , c 2 , c 3 , and ref are sliced when the radius equals 1; ref , ref 2 , and c 1 to c 4 are sliced when the radius equals 2. The radius is defined by the domain expert for a sliced class, and its value must be specified by the domain user as a parameter of the MSF. The focused classes must be included in the sliced classes that can be formalized using OCL as follows: The constraints allow the domain expert to define a condition that must be respected to trigger the slicing of the element targeted by the condition.

The inputClasses precise the type of the slicing criteria that the MSF will take as input to start the slicing.

Finally, the attribute active permits to specify whether the MSF must be executed as a batch or as an active process. By default, the generated MSF is a batch process executed a single time on the input model. By setting the attribute active to true the generated MSF is executed a first time, and then observes modifications applied on the input model to incrementally update the slice.

Concrete Syntax

A textual concrete syntax has been defined for Kompren allowing the domain expert to define a Model Slicer Model (MSM). As an example, the following listing shows the active and non-strict MSM ClassModelSlicer (cf. line 1), for the metamodel in Fig. 5a (cf. line 2). The classes of the instances used to launch the Model Slicing Function (MSF) are declared on line 3.

Thereafter, line 6 specifies a sliced class while lines 7 to 10 specify the sliced properties. An expression defined for the sliced class Class is described on line 6 where cl refers to the context of the sliced class. An optional property is illustrated on line 7 with the keyword option. An opposite to a property is defined with the keyword opposite as shown on line 8 where lowerTypes is the name of the opposite.

Line 4 illustrates how to declare a radius based on Class to limit the selection in the input model by the MSF. The definition of a constraint consists in specifying a Kermeta boolean expression as shown on line 5. Lines 11 to 13 illustrate the definition of the preprocessing, the postprocessing, and the helper of the slicer.

Semantics

As defined in Fig. 2, model slicer models (MSM) are compiled into model slicer functions (MSF). This compilation produces Kermeta programs composed of three parts. The first part augments the input metamodel with required information. This information is the opposites added to the input metamodel and methods required by the visitor to explore the input model. These methods are generated for the metamodel elements selected in MSMs. If the slicer is defined as strict, these methods are also generated for elements not selected in MSMs but required to assure the semantic properties.

The second part performs a static analysis of the MSM to infer whether a new metamodel is required as output metamodel (usually to relax some cardinalities).

Finally, the compiler generates the MSF. The preprocessing (onStart) and the postprocessing (onEnd) methods and the Kermeta code corresponding to the helper are created.

From the input classes, the radius and the constraints defined in MSMs are generated as parameters of the slicer function. For instance, the following Kermeta code illustrates such generation where: launch is the operation that starts the slicing; inputClass:Class[0..*] defines the Class instances used to launch the slicing (the slicing criteria); radius:Integer specifies the slicing radius; composition:Boolean is a constraint that restricts the slicing of references to composite references. Once generated, the MSF can be executed by calling the launch operation with its required parameters. The preprocessing is first executed. Then begins the exploration of the input model using the input instances (i.e. the slicing criteria) given as parameters. Each of these instances is visited. Visiting an instance or a property consists in executing the associated behavior, i.e. the corresponding Kermeta expression defined by the domain expert. Each selected property of the current visited class instance are then explored (if they satisfy the constraints defined in MSMs) to recursively explore their target class instance. In case of a strict slicer, the MSF also slices the required model elements to conform to the input metamodel, and automatically add all the sliced instances into a new model.

Because Kermeta does not support observability of Ecore models, active slicers are based on the ActiveKermeta toolkit [START_REF] Beaudoux | Active operations on collections[END_REF]. ActiveKermeta adds observability to Ecore models through the operations c.added{e | ...}, c.removed{e | ...}, and c.updated{p, e | ...}. These operations register a function respectively invoked when the element e is added to collection c, removed from collection c, or when the element p is replaced by the element e into c.

Tooling

Domain Expert

We provide domain experts with a comprehensive set of prototyping tools to develop model slicers 8 . These tools are composed of two editors and of a compiler running on the top of Eclipse9 and Scala10 .

The Kompren Editors

Two editors are provided for editing MSMs. The first one is a customized Ecore reflexive editor that edits MSMs through a tree-based presentation. The second editor is a textual editor based on our proposed concrete textual syntax (see Fig. 10 for a screenshot of this editor). This editor provides auto-completion, serializes as Ecore models, and compiles MSMs in MSFs.

The Kompren Compiler

The MSM to MSF compiler has been developed using Kermeta 2 running on the top of Scala (Kermeta 2 programs are compiled into Scala, then into Java byte-code). We performed benchmarks on several use cases we developed to study the compilation time. These uses cases have different levels of complexity as described in Table 1. This table describes the characteristics of the use cases: S c and S p respectively define the number of classes and properties of the input metamodel; S sc and S sp respectively define the number of the sliced classes and properties; P k enumerates the Kompren's features used; T c gives the average compilation time (in second) for 100 executions of the use cases. The experiments described in this section have been performed on Linux using a laptop with a Core2Duo at 3.06GHz and 4Gb of RAM, Scala 2.9.0, and Java 7. For the simplest use case T c equals 0.189s. For the most complex one T c equals 2.026s. Because finding the mandatory elements to slice requires extra computations, the strict property complexifies the MSFs generation. Large input metamodels increase the computations as well.

Use cases

Domain User

Once defined by domain experts, MSF can be used by domain users. As the compiler, MSFs are Kermeta 2 programs running on the top of Scala. MSFs take as inputs the slicing criteria, the options, the constraints, and the radius value as defined in the MSMs. MSFs produce as output either a sliced model when the model slicer is strict, nor results as defined by domain experts.

MSFs can be integrated into applications. For instance, our tool that visualizes metamodels uses an MSF using the Kermeta metamodel as input metamodel. In our current prototype, the slicing process is based on the visitor design pattern using a deep-first search algorithm. Following Table 1, Table 2 gives the slicing execution time T e (in second) for the state-machine slicing example presented in Table 1. The benchmarks have been performed using input models of different sizes: S m refers to the number of elements that the models contain. The goal of this experiment is to demonstrate that Kompren can slice large models in a reasonable time. For the sizes from 100 to 10 5 , 100 models (more precisely 100 connected state-machines) were randomly generated. T e is the average execution time for slicing these models. Because of technical limits, only a single model was randomly generated for the size 10 6 . In this case, T e is the average execution time for slicing this model 100 times. The goal of this strict slicer is to slice the whole input model using as input the initial state. For the smallest size, 100, T e is 0.023. For the larger size, 10 6 , T e is 9775.51. Because of the model loading and saving operations, the progression of the execution time over the different sizes is not linear. The materials used for these benchmarks are available on the Kompren website11 .

Threats to Validity

The benchmarks performed on non-strict Kompren model slicers strongly depend on the Kermeta expressions, defined by the developers, used in the slicer. Optimizations may be applied on our current prototyping implementation to improve these benchmarks.

The slicing execution time T e strongly depends on the parameters of the model slicers. For instance, the definition of an opposite in a model slicer will increase the execution time by 2 at least: before the slicing operation, the opposite must be integrated into the input model; this operation requires the whole exploration of the input model.

Validation

In this section, we apply our model slicing approach to three heterogeneous case studies illustrating the main usages that can be done using our approach.

Model Operation Analysis

Extracting static metamodel footprint for a model operation defined over a metamodel M M 1 (in our case the Kermeta metamodel) consists in extracting the elements of M M 1 used by the operation [START_REF] Jeanneret | Estimating footprints of model operations[END_REF]. In this section, we use Kompren to model the footprint generator proposed by Jeanneret et al. [START_REF] Jeanneret | Estimating footprints of model operations[END_REF] and the metamodel pruner proposed by Sen et al. [START_REF] Sen | Meta-model Pruning[END_REF]. This use case illustrates the ability of Kompren to: ease the slicer definition process; combine several Kompren model slicers to perform a task not related to model slicing.

This model operation analysis is performed through two model slicers: a first slicer analyzes the model operation to extract the metamodel footprint, i.e. the list of M M 1 elements used by the operation; a second slicer uses this footprint to extract the effective metamodel from M M 1 .

The first slicer extracts the list of M M 1 elements used by the operation. Because such a slice does not conform to M M 1 , the slicer is not strict. The model operation is implemented in Kermeta. Thus it is an instance of the Kermeta metamodel M M op and the slicer explores classes and properties of M M op (lines 6 to 16). The result of the slicing function will be the list of classes used in the operation (line 5). This list is defined in the helper (line 18). By default all the classes that can come from either M M 1 or M M op are explored. Because only the classes from M M 1 must be stored, a helper is defined to select them (lines 19 to 25). The second slicer, modeled as follows, uses the footprint computed by the first one. This slicer is defined as strict (line 1) to create an output model that is an endogenous slice of the input metamodel M M 1 (specified line 2). This slicer slices all the classes (line 4) linked to the input classes by inheritance or properties (lines 10 to 12). All properties and operations of the class sliced are included (lines 5 to 9). Because ClassDefinition is linked to Package by a 1..1 reference, this relation and its target class must be sliced to extract a strict slice. Since we model in strict mode, the packages containing sliced elements are sliced even if Package is not modeled as a slicedClass. This mode also includes 1..n attributes of classes ClassDefinition, Property, and Operation.

These Kompren model slicers are smaller than the Jeanneret's and Sen's model slicers: around 70 Kompren LoC compared to 1200 Kermeta LoC for both the static metamodel footprinting and the metamodel pruner. The number of generated Scala LoC when compiling a Kompren model into an executable slicer (a Scala program) is another relevant metric. This use case generated around 6700 of Scala LoC 12 . Because Kompren is a DSL dedicated to the definition of model slicers, Kompren hides some technical details such as the Visitor pattern. By opposition, Kermeta and Scala are GPLs (General Purpose Language) that require the explicit definition of such technical details. This difference can explain the gap in terms of LoC differences between the slicers.

Bringing Semantic Zooming to Model Visualization

Model slicing can be used to bring semantic zooming to model visualization. In this case, the slicer defines which classes and relations of the visualized model must be displayed in the user interface (UI). For example, the following code defines a slicer that slices Kermeta models. Because the goal of this slicer is to notify the UI about sliced elements, it is not defined as strict. It takes as input instances of ClassDefinition (line 3) selected by users using the UI. As shown in Fig. 11, the UI displays classes, inheritances, and properties. At the beginning of the slicing all these model elements are hidden (line 23). Then when model elements are sliced, the UI is notified that these elements must be shown (lines 7, 9, and 17). At the end of the slicing, the UI is updated to perform the graphical changes (line 24). Some properties must be explored to access the instances to slice (lines 14 to 22). All these properties to slice are defined as optional. Thus for each feature of the model visualizer (e.g. showing the inheritance tree of a selected class), developers can define which properties must be explored. The UI shown in Fig. 11 provides a spinner that permits to define the radius effect of the slicing (defined line 4). The UI also provides a check-box called "With card 0". This checkbox permits to set whether properties which lower cardinality equals 0 must be sliced or not (line 5). The graphical representation of the model and the widgets of the UI are defined separately from the slicer.

Monitoring State-machines at Runtime

Our model slicing approach can also be used to slice models at runtime, i.e. the slicing process is no more a batch process but is sustained at runtime to re-evaluate model elements that change. In such a context, a slice can be used to observe how a specific sliced part of a larger model evolves. The following Kompren code slices the current state of a state-machine and displays its name on changes. The slicer first displays the name of the initial state. Whenever the currentState relation cs is updated the anonymous function given by the updated method is invoked. In this method prev and next are the previous and the new states contained in cs respectively. Running the CurrentStateSlicer with the sequence of transitions As this example illustrates, Kompren active slicers are based on Active Kermeta that makes the four collections provided by Kermeta (set, oset, seq, and bag) observable [START_REF] Beaudoux | Active operations on collections[END_REF]. Relation currentState is implemented using an Active Kermeta set having its cardinality restricted to [1..1]. Using collections for relations with cardinality [0..1] or [1..1] is mandatory for observing their content. Two others methods, added and removed, are provided by Active Kermeta collections to respectively observe additions and removals into collections.

t 1 → t 2 → t 3 → t 2 → t 4 results in displaying s 0 → s 1 → s 2 → s 1 → s 2 → s 3 .

Related Work

We classified in Table 3 the main related work using the slicer's properties proposed in Fig. 4 (slicing mode, slicing process, and slicer) supplemented with four others properties: Slice. States whether the output slices can be structurally modified compared with the input models; KOM-PRENable. Defines whether the slicing method can be done using Kompren; Metamodel. The supported input metamodel; Usage. The context of use of the slicing method.

To our best knowledge, Zhao [START_REF] Zhao | Applying slicing technique to software architectures[END_REF] was the first to use program slicing concepts at a higher level than code. He uses a syntactic, batch, and endogenous slicing algorithm to slice software architectures. Following this work, Kim et al. [START_REF] Kim | Software architecture analysis: a dynamic slicing approach[END_REF] bring semantic slicing to software architecture.

Slicing state-based models has been widely tackled in the literature [START_REF] Heimdahl | On the effectiveness of slicing hierarchical state machines: a case study[END_REF][START_REF] Korel | Slicing of state-based models[END_REF][START_REF] Van Langenhove | SVtL: system verification through logic tool support for verifying sliced hierarchical statecharts[END_REF][START_REF] Labbé | Slicing communicating automata specifications: polynomial algorithms for model reduction[END_REF][START_REF] Androutsopoulos | Model projection: Simplifying models in response to restricting the environment[END_REF][START_REF] Wang | Slicing hierarchical automata for model checking UML statecharts[END_REF][START_REF] Chunyu | Dynamic slicing of statechart specifications for reactive systems[END_REF][START_REF] Luangsodsai | Concurrent statechart slicing[END_REF]. Koren et al. [START_REF] Korel | Slicing of state-based models[END_REF] introduce a batch and endogenous slicing method that uses dependency graphs (data and control dependencies) derived from the state-based models to slice. This method does not evaluate transitions' condition and is thus syntactic. This method provides a post-process step that merges states to reduce the size of the slices.

Androutsopoulos et al. [START_REF] Androutsopoulos | Model projection: Simplifying models in response to restricting the environment[END_REF] propose different finite statebased model slicing algorithms. Their basic slicer removes a set of transitions to ignore and useless states. This algorithm can be performed using our approach by defining parameters that state the slicer not to slice transitions having given names. Their other algorithms extend the first one by removing untriggerable transitions and merging states having identical semantics. Our approach does not permit to define such slicers.

Acher et al. [START_REF] Mathieu Acher | Slicing feature models[END_REF][START_REF] Mathieu Acher | Separation of Concerns in Feature Modeling: Support and Applications[END_REF] propose a batch feature model slicer. The slicing process is both semantic and syntactic: the cross-cutting constraints are statically analyzed to define features that must be or cannot be sliced. The output slices still conform to their metamodel but may structurally differ; the feature model and its cross-cutting constraints are first transformed into predicates for analysis. These predicates are then transformed in a sliced feature model.

Hubaux et al. [START_REF] Hubaux | Supporting multiple perspectives in feature-based configuration[END_REF] slice feature diagrams to design three different views of an input diagram. The sliced diagrams do not keep the same structure as the input diagram. This approach does not consider cross-cutting constraints and is thus syntactic.

Kelsen et al. [START_REF] Kelsen | Models within models: Taming model complexity using the sub-model lattice[END_REF] propose an approach for decomposing models into sub-models to tame the complexity of large models. This approach shares similarities with ours since they are both not dedicated to a unique DSML and they can extract sub-models of interest that still conform to the input metamodel. However, their approach does not permit developers to specify the slicing process, i.e. to select which elements of the input models must be sliced, and is restricted to the strict model slicing usage.

Jeanneret et al. [START_REF] Jeanneret | Estimating footprints of model operations[END_REF] introduce a method to statically or dynamically extract model footprints. As discussed in Sec-tion 6.1 the static footprinting can be done using Kompren. But the dynamic footprinting refers to dynamic slicing concepts that Kompren does not support yet.

Similarly, Ujhelyi et al. [START_REF] Ujhelyi | Towards dynamic backward slicing of model transformations[END_REF] develop a dynamic slicer for model transformations. The goal of this slicer is two-fold: providing transformation slices depending on the slicing criterion; providing model slices (model footprints) composed the model elements used by the transformation. Backtraces of the execution of the transformation are used to slice the statements used during the execution. Thus this approach is both syntactic and semantic. No information is provided regarding the conformance of the output slices toward their metamodel.

Sen et al. [START_REF] Sen | Meta-model Pruning[END_REF] present an approach for pruning metamodels. The proposed pruner takes as input slicing criteria, i.e. classes, operations, etc. of the metamodel to slice. The pruner produces as output slices that satisfy all the structural constraints imposed by the input metamodel. Such a pruner is thus a slicing operation strictly endogenous, syntactically based and is a batch process.

As state-based models, UML is widely tackled in the literature [START_REF] Wang | Slicing hierarchical automata for model checking UML statecharts[END_REF][START_REF] Kagdi | Context-free slicing of UML class models[END_REF][START_REF] Ho | UMLSlicer: A tool for modularizing the UML metamodel using slicing[END_REF][START_REF] Shaikh | Verification-driven slicing of UML/OCL models[END_REF][START_REF] Shaikh | UOST: UML/OCL aggressive slicing technique for efficient verification of models[END_REF][START_REF] Shaikh | Evaluation of tools and slicing techniques for efficient verification of UML/OCL class diagrams[END_REF][START_REF] Lano | Slicing of UML models using model transformations[END_REF][START_REF] Jaiprakash | A dynamic slicing technique for UML architectural models[END_REF][START_REF] Chunyu | Dynamic slicing of statechart specifications for reactive systems[END_REF]. Shaikh et al. [START_REF] Shaikh | Verification-driven slicing of UML/OCL models[END_REF][START_REF] Shaikh | Evaluation of tools and slicing techniques for efficient verification of UML/OCL class diagrams[END_REF][START_REF] Shaikh | UOST: UML/OCL aggressive slicing technique for efficient verification of models[END_REF] use model slicing for verification purpose. The goal of this approach is to check whether an input UML model supplemented with OCL constraints has legal instances. OCL constraints are thus analyzed and interpreted to identify which model elements are constrained.

Closely to Sen's work, Bae et al. [START_REF] Ho | UMLSlicer: A tool for modularizing the UML metamodel using slicing[END_REF] develop a tool, UML-Slicer, to slice to UML metamodel. As Kompren this tool slices using the structure of the model. But because UML-Slicer does not provide radius and constraint features, it is less expressive than Kompren.

Wang et al. [START_REF] Wang | Slicing hierarchical automata for model checking UML statecharts[END_REF] introduce a method to reduce the state space during the model checking of UML statecharts. The proposed slicing process is semantically based and exogenous: the output slices are not UML statechart models but extended hierarchical automata (EHA) used by the model checker.

Lano et al. [START_REF] Lano | Slicing of UML models using model transformations[END_REF] present slicing techniques dedicated to UML models. Using these techniques the output slices may structurally differ from the input model without modifying their semantics.

Lallchandani et al. [START_REF] Jaiprakash | A dynamic slicing technique for UML architectural models[END_REF] propose a slicing technique for UML architectural models. Even if the proposed approach is limited to UML architectural models, it uses slicing for different purposes such as regression testing and understanding large architectures.

Samuel et al. [START_REF] Samuel | Slicing-based test case generation from UML activity diagrams[END_REF] describe a UML activity diagram slicing technique dedicated to the generation of test cases. The input diagram is first converted into a flow dependency graph to be then sliced and be used for the test case generation process.

Yatapanage et al. introduce a slicing technique to reduce behavior tree models prior to verification. This batch process uses the semantics of the input model to perform the slicing and produces endogenous output slices. Fal et al. [START_REF] Falessi | SafeSlice: a model slicing and design safety inspection tool for SysML[END_REF] propose a batch model slicer dedicated to the slicing of SysML (Systems Modeling Language13 ) models related to safety requirements. The most important step in this approach is the pre-process step that maps a requirements model to a SysML model. Once the mapping established the slicing process operates on the structure of the joined models. Requirements are used as input of the slicer and their related SysML elements that conform to the SysML metamodel.

Clark [START_REF] Clark | A general model-based slicing framework[END_REF] introduces a model slicing theory that can be used to implement the slicing function as model transformations. This theory is based both on the syntactic and the semantics of the targeted language.

Obeo Designer14 offers the possibility to easily design graphical viewpoints on large models. The representation of a slice can be seen as a viewpoint. However, the tool is limited to visualization and does not address manipulation or serialization of the slices.

Conclusion and Future Work 8.1 Contributions

Many recent work inspired by program slicing [START_REF] Weiser | Program slicing[END_REF] have proposed operations that extract sub parts of models for different purposes [START_REF] Shaikh | Verification-driven slicing of UML/OCL models[END_REF][START_REF] Lano | Slicing of UML models using model transformations[END_REF][START_REF] Kelsen | Models within models: Taming model complexity using the sub-model lattice[END_REF][START_REF] Jeanneret | Estimating footprints of model operations[END_REF]. These operations are extremely helpful to assist comprehension when building large models. With the growing adoption of domain-specific modeling, these model comprehension abilities should be available for any domain-specific modeling language. However, all existing model slicing approaches are dedicated to one modeling language and one form of slice.

In this work we analyze needs for model slicing to precisely identify expected features for domain-specific model slicers. The major contribution of this paper is the Kompren language to model model slicers for domain-specific metamodels. We develop a two-level generative approach on the basis of Kompren: Kompren's compiler processes Kompren models to automatically generate a model slicer function; this function can in turn automatically extract model slices from domain-specific models. This paper presents the details of Kompren's features, abstract and concrete syntax and tools. We propose an exhaustive state-of-art on model slicing. We also demonstrate Kompren's expressiveness through three different cases that aim at slicing three different forms of slices in three different domains. In particular we model the slicers defined by Jeanneret et al. [START_REF] Jeanneret | Estimating footprints of model operations[END_REF] and by Sen et al. [START_REF] Sen | Meta-model Pruning[END_REF] and show that the Kompren models (a.k.a. model slicer models) are much smaller and easier to understand and evolve than the original slicers.

Research Agenda

As an immediate future work, we expect to provide empirical evidence of the Kompren usability elaborating a qualitative evaluation. This will require a study with users to evaluate the qualitative benefits of Kompren w.r.t the construction of slicers with general purpose languages.

Then our perspectives are twofold. First, we aim at supporting the definition of generic model slicer models. Currently, the definition of MSMs relies on a specific input metamodel. For instance, one can define a MSM based on the Ecore metamodel to slice class models. However, slicing the class model in a UML class diagram, requires defining a new MSM. But Ecore and UML Class diagram share the concept of class model and relations. MSM definitions could thus be more generic by taking as input not a metamodel (Ecore, UML) but a concept (class model), i.e., a model type [START_REF] Steel | On model typing[END_REF].

Second, Kompren slicers are currently static since they are based on the structure defined by the input metamodel. A next step of our work will go toward dynamic model slicing. "While static slicing computes slices with respect to any execution, dynamic slicing computes slices with respect to a particular execution" [START_REF] Silva | A vocabulary of program-slicing based techniques[END_REF]. But while all programs are executable, all models are not. Thus, it must be identified: the different kinds of models that can be dynamically sliced; the additional information to use for specifying dynamic model slicers (action languages, etc.); the different applications of dynamic model slicing (executable model debugging, etc.). Then, other forms of dynamic slicing could be studied, such as conditioned [START_REF] Ning | Automated support for legacy code understanding[END_REF], quasi-static [START_REF] Venkatesh | The semantic approach to program slicing[END_REF], and simultaneous slicing [START_REF] Hall | Automatic extraction of executable program subsets by simultaneous dynamic program slicing[END_REF], that compute slices with respect to a particular set of executions.

3 .

 3 a systematic classification of properties one can expect from the model slicers generated by Kompren; 4. an exhaustive classification of the related work on model slicing; 5. a complete set of tools to define and execute model slicers, including editors and a new version of the compiler featuring evaluated performance improvements.

  (a) Viewing Super-classes of the UML Class Class (b) Complex Mechanical Model of a Building, extracted from[START_REF] Steel | Model interoperability in building information modelling[END_REF]

Figure 1 :

 1 Figure 1: Examples of Semantic Zooms

Figure 2 :

 2 Figure 2: Overview for Modeling Model Slicers with Kompren

Figure 3 :

 3 Figure 3: Relationships between Model Slicer, MSM, and MSF according to the analytical and synthetical representations proposed in[START_REF] Muller | Modeling modeling modeling. Software and Systems Modeling[END_REF]

Figure 4 :

 4 Figure 4: Kompren's Features

Figure 5 Figure 6 : 1 (Figure 7 :

 5617 Figure 5: Class Model Example

Figure 8 :

 8 Figure 8: Model Slicer Metamodel

Figure 9 :

 9 Figure 9: Example of the Radius Process

  operation launch(inputClass:Class[0.. * ], radius:Integer, composition:Boolean)

Figure 10 :

 10 Figure 10: Kompren Editor in the Eclipse Environment

Figure 11 :

 11 Figure 11: Class Diagram Visualizer Providing Semantic Zooming Features

  Fig. 12a describes a basic state-machine metamodel. The root class StateMachine specifies all the states and transitions defined within the state-machine. A Transition links a source state and a target state; conversely, a State is linked to (a) A State-Machine Metamodel

Figure 12 :

 12 Figure 12: A State-Machine Example

Fig. 12b shows

  Fig.12bshows a state-machine composed of four states s 0 to s 3 and four transitions t 1 to t 4 . Slicing such a model at runtime consists in capturing the evolution of a model slice while the state-machine is running, i.e. slicing changes of the current state.

Table 1 :

 1 Several MSM Compilation Benchmarks

		S c	S p S sc S sp	P k	T c
	Super-classes	1	1	1	1	not strict 0.189
	State-machine	8	7	7	3	strict	0.209
	Semantic					not strict,
	Zooming	20	51	9	10 opposite, 0.371
	Ecore					radius
	Kermeta
	Operation	73	95	1	29	not strict 0.503
	Analysis
	UML
	Class Diagram 246 769 16	21	strict	2.026
	Extraction

Table 2 :

 2 Several Execution Benchmarks of the State Machine Slicer

http://www.omg.org/mof/

http://people.irisa.fr/Arnaud.Blouin/software_ kompren.html

http://proguard.sourceforge.net/

http://www.omg.org/spec/OCL/

http://www.eclipse.org/modeling/

http://people.irisa.fr/Arnaud.Blouin/software_kompren.html

http://www.eclipse.org/

http://www.scala-lang.org/

http://people.irisa.fr/Arnaud.Blouin/software_ kompren.html

This number can certainly be reduced by optimizing the compiler.

http://www.sysml.org/

http://obeo.fr/pages/obeo-designer

* This work is partially supported by the EU FP7-ICT-2009.1.4 Project N°256980, NESSoS: Network of Excellence on Engineering Secure Future

Approaches


G Latu

M Becoulet

G Dif-Pradalier

V Grandgirard

M Hoelzl

G Huysmans

X Lacoste

E Nardon

F Orain

C Passeron

P Ramet

A Ratnani

Paul -Lez-Durance

Non regression testing for the JOREK code

Keywords: nonlinear MHD, Tokamak plasma, Non Regression Testing MHD non-linéaire, plasma de Tokamak, tests de non-regression

Non Regression Testing (NRT) aims to check if software modifications result in undesired behaviour. Suppose the behaviour of the application previously known, this kind of test makes it possible to identify an eventual regression, a bug. Improving and tuning a parallel code can be a time-consuming and difficult task, especially whenever people from different scientific fields interact closely. The JOREK code aims at investing Magnetohydrodynamic (MHD) instabilities in a Tokamak plasma. This paper describes the NRT procedure that has been tuned for this simulation code. Automation of the NRT is one keypoint to keeping the code healthy in a source code repository.

Introduction

This paper deals with a Non Regression Testing (NRT) tool for a code dedicated to the simulation of MHD instabilities relevant to magnetically confined fusion.

Magnetohydrodynamic (MHD) stability and the avoidance of plasma disruption -rapid loss of plasma energy and abrupt termination of the plasma current caused by global MHD instability growth -are key considerations to the attainment of burning plasma conditions in ITER (a large fusion reactor www.iter.org ). Realization of adequate MHD stability and careful control of the plasma operation will be critical ITER operation issues: MHD instabilities can damage components of tokamak walls.

Numerical simulations play an important role in the investigation of the non-linear behaviour of these instabilities and can help for interpretating experimental observations. In the framework of non-linear MHD codes, targeting realistic simulation requires: to model complex geometry, to handle a large gap between the different time scales relevant to plasmas, to address full 3D simulation. Computational time needed to run 3D MHD code named JOREK necessitates parallel computing in order to get reduced restitution time for the user [CH08, HMH + 12].

We describe here procedures and solutions to overcome a lack of NRT and benchmarking tools for JOREK users. The aims of such improvements are twofold: first, to keep the main JOREK trunk healthy in the version control system, second, to have a way to compare execution times and results of runs launched on different supercomputers.

In this document, we will often refer to the SVN repository where JOREK code is stored. This repository contains also all the materials and scripts that are described herein: scm.gforge.inria.fr/svnroot/aster This work was made possible by a ANR grant and the accesses to several parallel machines. The authors acknowledge the support of the French Agence Nationale de la Recherche (ANR) under reference ANR-11-MONU-0002 (ANEMOS project). Computations have been performed at the Mésocentre d'Aix-Marseille Université (France), on PLAFRIM Bordeaux (France), on IFERC Rokasho (Japan).

NRT

To begin with, we will sketch up the JOREK environment in order to explain the choices made for the Non Regression Testing. Then, the method used to achieve NRT is explained.

Numerical components

Spatial discretization JOREK is a MHD three dimensional fluid code that takes into account realistic tokamak geometry. High spatial resolution in the poloidal plane is needed to resolve the MHD instabilities at high Reynolds and/or Lundquist numbers. Bezier patches (2D cubic Bezier finite elements) are used to dicretize variables in this plane. Hence, several physical variables and their derivatives have a continuous representation over a poloidal cross-section. The periodic toroidal direction is treated via a sine/cosine expansion.

Set of equations Some of the variables modelled in JOREK code are: the poloidal flux Ψ, the electric potential u, the toroidal current density j, the toroidal vorticity ω, the density ρ, the temperature T , and the velocity v parallel along magnetic field lines. Depending on the model choosen (hereafter denoted model which is a simulation parameter), the number of variables and the number of equations on them are setup. At every time-step, this set of reduced MHD equations is solved in weak form as a large sparse implicit system. The fully implicit method leads to very large sparse matrices. There are some benefits to this approach: there is no a priori limit on the time step, the numerical core adapts easily on the physics modelled (compared to semi-implicit methods that rely on additional hypothesis). There are also some disadvantages: high computational costs and high memory consumption for the parallel direct sparse solver (PASTIX or others).

Time integration scheme

The temporal discretization is performed by a fully implicit second-order linearized Crank-Nicholson scheme. Two operators C and D are matrices that Latu & al describe the set of MHD equations in weak form:

∂C( u) ∂t = D( u), discretized by ∂C( u n ) ∂u - 1 2 δ t ∂D( u n ) ∂u δ u = D( u n ) δt (1) Let us denote A = ∂C( u n ) ∂u - 1 2 δ t ∂D( u n ) ∂u , b = D( u n ) δt, then (2)
A δ u = b (3)
Where u n is the set of variables at time step n, and δ u = u n+1 -u n is the unknown. In the following, we will refer to A as the sparse matrix that should be solved, and b the right hand side of the problem.

Equilibrium Each JOREK simulation begins with the solving of the static magnetic equilibrium equation (so-called Grad-Shafranov equation) in the 2 dimensions of the cross-section plane. A keypoint is the ability to handle magnetic equilibria which include an X-point. High accuracy is needed to have a correct representation of this equilibrium and avoid spurious instabilities whenever the whole simulation 3D+t is launched. JOREK is able to build a Bezier finite element grid aligned with the flux surfaces both inside and outside the separatrix (i.e. the flux surface containing the X-point). This strategy allows one to improve the accuracy of the equilibrium representation. The flux surfaces are represented by sets of 1D Bezier curves determined from the numerical solution of the equilibrium. The Grad-Shafranov solver is based on a Picard's iteration scheme.

After the Grad-Shafranov solving step, a supplementary phase is required: the timeevolution equations are solved only for the n = 0 mode (the first toroidal harmonic, i.e. purely axisymmetric) over a short duration. First, very small time-steps are taken, then they are gradually increased. This process allows the plasma equilibrium flows to establish safely in simulations involving a X-point.

Sparse solver & preconditionning A direct parallel sparse matrix solver (PASTIX or others) is used to solve the large linear systems inside JOREK. In order to minimise the memory requirements of the fully implicit solver and to access larger domain sizes, a preconditioner accompanied with a GMRES iterative solver have been included a few years ago. Preconditioning transforms the original linear system A x = b into an equivalent one which is easier to solve by an iterative technique. A good preconditioner P is an approximation for A which can be efficiently inverted, chosen in a way that using P -1 A or A P -1 instead of A leads to a better convergence behaviour. Usually, GMRES iterative solver is applied in collaboration with a preconditioner. The preconditioner typically incorporates information about the specific problem under consideration.

The JOREK physics-based preconditioner has been constructed by using the diagonal block for each of the n_tor Fourier modes in the toroidal direction of the matrix A presented earlier in Eq. 3. The preconditioner represents the linear part of each harmonic but neglects the interaction between harmonics (similar to a block-Jacobi preconditioning on a reordered matrix). So, we set many coefficients of the original matrix A to zero, in order to get a block-diagonal matrix with m independent submatrices on the diagonal. The preconditioner P consists in the composition of m independent linear systems

(P i ) i∈[1,m] , with m = n_tor+1 2
. Practically, the set of processors are split in m independent MPI communicators, each of them treats only one single linear system P i with a sparse direct solver. This preconditioned parallel approach avoids large costs in terms of memory consumption compared to the first approach that considers the whole linear system to solve (it saves the memory needed by the sparse solver to store the decomposition of big matrix Ae.g. L, U factors). Nevertheless, the whole linear system A has to be built (in parallel) in order to perform the matrix-vector multiplication needed by the GMRES. But, the cost in memory and in computation is far less than invoking the parallel sparse solver on the large linear system A.

This strategy improves the scalability (m inpendent systems), and the parallelisation performance of the code. The bad point is that in some specific circumstances, the iterative scheme may not converge.

Parameters

From the user perspective, one can distinguish three sets of parameters in the JOREK code: Inria • Category A -Hardcoded. A first set of parameters is fixed inside the source code.

For example: the selected physics model (model parameter), the number of harmonics which defines the discretization along toroidal dimension (n_tor), and some others (n_period, n_plane, n_vertex_max, n_nodes_max, n_elements_max, n_boundary_max, n_pieces_max, gmres_max_iter, iter_precon, . . .).

• Category B -Input file. A second set of parameters are given through the standard input to JOREK at launch time. Some examples of such input files can be found in jorek2/trunk/namelist directory in the JOREK repository.

• Category C -Environment. A third set of parameters consists in the parallel environment at launch time. For example, the following data constrain the execution time and impact a little bit the numerical results: the number of MPI processes, the number of shared memory nodes, the number of OpenMP threads, the set of libraries used (MPI, sparse solver library).

Several kinds of simulations can be undertaken with this tool. We will mainly address in this document few simulations that are parametrized by the following inputs (mainly of category B -input file):

• Geometry Three main configurations are available concerning the geometry in the poloidal plane: circular cross-section (parameter xpoint=.f.), single X-point (parameter xpoint=.t.), two X-points (not detailed here). Other fine parameters permit to fit the geometry to a realistic configuration.

• Spatial domain size Some parameters set up the computational domain. The discretization highly impacts the memory and computational costs. Poloidal domain is sized by n_flux the number of flux surfaces (radial coordinate), n_tht the number of points in the angular direction (equivalent to θ). In the toroidal direction, n_tor-1 sizes the number of sine/cosine components that will be computed. The n_tor parameter is in the category A -hardcoded. JOREK code is able to handle the increase of n_tor parameter between a checkpoint and a restart.

• Time axis Depending on the simulation kind and the evolution of the simulation, the time step duration can be adjusted. The timestep tstep is typically fixed from a fraction of an Alfven time to thousands of Alfven times. The number of time steps in a single run is set by nstep. There is another way to specify both number of time steps and durations through the parameters tstep_n and nstep_n which are vectors. It helps the user in order to define complex scenarii with multiple timesteps inside a single run.

Scenarii definition

Edge localized modes (ELMs) are intermittent relaxations of the edge transport barrier. During these events, particles and energy are ejected from the plasma edge into the surrounding low density envelope, the SOL (scrape-off layer). The associated transient power loads create problems during the operation of tokamak reactors. MHD codes, such as JOREK, can describe the ELM evolution. One of the relevant instabilities for the ELMs are the MHD peeling-ballooning modes, but other kinds of instabilities or physics phenomena can be studied with JOREK [HC07, NBHC07] (kink modes, tearing modes ...). A typical simulation begins from an axisymmetric equilibrium (n = 0) on top of which a small n = 0 perturbation is initialised. First, an initial linear phase of exponential growth shows a rapid energy increase (when a mode is unstable), starting from a very low level of energy (a little bit noisy). Kinetic and magnetic energies can have quite large growth rates during the linear phase. For some identified cases, the theoretical growth rates that should be obtained are known. After a while, some Fourier modes saturate non-linearly (growth rates are droping).

In order to track a simulation and analyse its time evolution, we will look at the dynamics of kinetic and magnetic energies. Somehow, they constitute a valid signature of a given simulation scenario. The physics phenomena strongly constrain these energies. Other criteria could also be taken into account in the future, in order to track fine differences between two runs that reproduce the same scenario (for example spatially localized phenomena).

A typical scenario execution is decomposed in the following way. First, the equilibrium is computed separately within a single JOREK execution. Second, a set of tstep_n and nstep_n vectors defines a subsequence of time steps that will be used in a second JOREK execution. A Latu & al complete scenario is composed from one subsequence to several such subsequences. Let us notice that between two successive JOREK executions, the parameter n_tor can be modified in order to increase/decrease toroidal resolution. A set of scenarii definitions have been encapsulated in jorek2/trunk/util/launch_tests.sh. For each scenario, the following data are fixed: the input parameter file, the set of vectors tstep_n and nstep_n, the times where n_tor is changed, and the series of JOREK executions (2 to 9 successive runs).

Metric

In order to build Non Regression Testing for a whole simulation code1 , one mainly needs two basic tools: 1) a methodology to replay a given scenario for the code, 2) a way to measure the differences between two runs of the same scenario with respect to test selection criteria. The second point involves the definition of a Metric that captures numerically the distance beween two scenario execution traces. Ideally, the Metric should also allow users to identify problems, help them in the process of improving the code, and provide a way to detect bugs quickly.

Reproducibility is the degree of agreement between measurements conducted on replicate scenario. While repeatability of scientific experiments is desirable, this is not always an easy task, even in the field of numerical simulations. Typically in the JOREK code, there are at least four reasons that limit someone to reproduce the same results upon demand:

• OpenMP introduces a dependance on threads scheduling inside processes that may alter a bit numerical results from one run to another,

• Global summation with MPI of distributed arrays is most susceptible to nonreproducible rounding errors (e.g. addition in MPI_Reduce is not strictly commutative),

• The iterative solver used for the large linear systems depends on a threshold to stop the iteration loop, this nonlinearity is able to amplify numerical noise,

• In many simulations, the starting point of the linear phase is dominated by numerical noise because system state is not far from a perfect equilibrium; then, the very beginning of a simulation run is expected to be very difficult to reproduce. Nevertheless, the rest of the simulation is dominated by a strong signal with much less numerical noise and this second part is reproducible.

So, given that the application is nondeterministic, the difficulty is to discriminate differences between two runs that are fully acceptable (coming from nonreproducibility), from differences that are likely to originate from a bug.

The metric we have chosen is the following: a time series of the growth rate of magnetic and kinetic Fourier modes on a specific time interval. The number of Fourier modes and the time interval are test-case dependent. The time interval will be fixed such that the very beginning of the simulation is excluded. We will also not keep the long term evolution of the non-linear saturation because small noise can be amplified and therefore comparison is notably biaised. Finally, only a time interval in the linear phase is kept for this metric. Practically, this means that we have for each reference scenario: a time interval [t start , t end ] and a threshold thr, a time series S of the growth rates of M Fourier modes. Let us denote s t,m A the growth rates of Fourier mode m ∈ [1, M ] at time step t ∈ [t start , t end ] of simulation S A . To compare two different runs A and B reproducing the same scenario, the metric consists in comparing S A and S B with the following criteria:

∀t, ∀m, 2 |s t,m A -s t,m B | |s t,m A | + |s t,m B |

< thr

The difference between two growth rates coming from two runs A and B should be below a given threshold percentage fixed by thr. If it is not the case, we will consider that A and B are different, i.e. one run has a wrong behaviour.

Parallel job launch

For the sake of simplicity, a complete scenario is executed in only one single parallel job. If it was not the case, one would have to chain multiple jobs which requires some specific parameters to give to the batch scheduler of the parallel machine. In order to automate the NRT as much as possible, the compilation and execution are done within the same parallel job (three models are available: 199, 302, 303). There are two possibilities to launch a JOREK reference scenario: a) Launch a parallel job over 4 SMP nodes (one MPI process per node) and inside this job compile all executables and then run the scenario with the following commands (it requires that you have configured your Makefile.inc already):

$ jorek2/trunk/util/compile_test.sh <MODEL> # compile JOREK for some <MODEL> $ export PRERUN='export OMP_NUM_THREADS=8' # command to launch before mpirun $ export MPIRUN='mpirun -np 4' # mpirun command $ export BASEDIR='/scratchdir/username' # root where the new dir will be created $ jorek2/trunk/util/launch_test.sh <DIRECTORY PREFIX><MODEL> # run the scenario Let us remark that on some machines (e.g. Helios-IFERC machine), the compilation process (i.e compile_test.sh) can not be done on compute nodes. Therefore the compilation should be done on login nodes, before the job launch. b) If subjorek is configured for the target parallel machine, you can alternatively use the following command:

jorek2/trunk/run_jorek/nrt_run.sh all <DIRECTORY PREFIX><MODEL>

The reference scenario will be executed and will generate a directory named <DIRECTORY PREFIX><MODEL> that contains all outputs of a standard JOREK run. In this directory, the main data that we will used to compare numerical results to another run is stored in the file macroscopic_vars.dat.

Some examples of batch scripts to run a reference scenario are given in benchmark/batch directory.

Comparing against reference scenario

To compare a run against a reference scenario, you have to download some files from the SVN repository with a command such as svn co svn+ssh://<LOGIN>@scm.gforge.inria.fr/svnroot/aster/benchmark A set of reference scenarii is located in benchmark/model* directories. The data used to compare with the metric a JOREK run against a reference scenario is encapsulated into the script file jorek2/trunk/util/nrt_compare.sh. This script requires the access to a tiny tool named numdiff that is easy to compile and install on a LINUX/UNIX system (http://ftp.igh. cnrs.fr/pub/nongnu/numdiff/).

For example, let suppose that you have reproduced the reference scenario of model 199 with the command: $ jorek2/trunk/util/launch_test.sh new199

After the job completion, the directory new199 contains the results of the simulation you have launched.

To compare your data with the reference case stored into aster/benchmark/model199/helios_a, you just have to do this: $ nrt_compare.sh 199 new199 aster/benchmark/model199/helios_a OK (nb lines compared: 53/53) # gnuplot commands to look at growth rates that have been compared : set key autotitle columnhead; set auto; plot 'f1' u 1:2 ls 1, 'f2' u 1:2 ls 4; pause -1 set auto; plot 'f1' u 1:3 ls 3, 'f2' u 1:3 ls 6

The comparison is successful and 53 time steps over 53 have been compared and verified 2 . To look at the growth rates of kinetic and magnetic energies that have been compared, you can Latu & al use the gnuplot commands that are mentionned. The data inside f1 and f2 files are extracted from growth rates of the file macroscopic_vars.dat that is generated by JOREK. On the Fig. 1, the f1 curve corresponds to the growth rate of one Fourier mode (magnetic energy n = 3) for simulation model199/helios_a, while f2 corresponds to the same mode on another machine new199 (= model199/rheticus_a). One can see that even the beginning differs slightly (numerical noise is perceptible), the two curves coincide almost exactly above 30 000 Alfven times. The nrt_compare.sh script checks between the two simulations if growth rates do not differ much more than 1 percent and says OK in this case.

A good methology using NRT is the following: whenever the user wants to perform a svn commit, he or she should launch all reference scenarii. If the modification is not supposed to alter the results, nrt_compare.sh will say OK for each scenario. The database for Non Regression Testing is located in benchmark/model*, the user can equally refer to all cases stored into benchmark/model* directories as third parameter of the nrt_compare.sh call. Once the user has obtained a OK for all scenarii, he or she can commit the changes in the SVN repository.

Benchmarks

The need for NRT has permitted to define a set of scenarii which are representative of some classical user cases of JOREK (yet, not exhaustive but the list is expected to be extended by users). These scenarii can also be used to benchmark machines and to compare execution times in different parallel configurations (number of MPI processes, threads), on several parallel machines. This information helps the user to determine if the performance on a new machine is far away from other machines or not, and to evaluate the parallel performance.

Timer measurements

A script timing_bench.sh is located in the benchmark directory. It facilitates the extraction of timers stored in JOREK log files. For example to look at the elapsed time taken by each JOREK temporal iteration on the two machines fourmi and rheticus in the out_loop1 log file, one can execute the command:

$ cd benchmark $ ./timing_bench.sh ITER out_loop1 grep3 model199/fourmi_a model199/rheticus_a == model199/fourmi_a ( openmpi ) 0 # Elapsed time ITERATION : 22.4025180 0 # Elapsed time ITERATION : 10.5183380 0 # Elapsed time ITERATION : 11.3435830 == model199/rheticus_a ( mvapich2 ) 0 # Elapsed time ITERATION : 15.2480000 0 # Elapsed time ITERATION : 7.2230000 0 # Elapsed time ITERATION : 7.5020000

Several parameters has to be given to this script: 1) the keyword that will be used to perform the grep in the log file (e.g. ITER to get the time taken by one temporal iteration), 2) the name of the JOREK log file (e.g. out_loop1), 3) optionally grep followed by a number specifying the number of lines to keep (e.g. grep3 to keep the 3 first lines), 4) a list of directories where the script will lookup the log files to process (e.g. model199/fourmi_a model199/rheticus_a to look into theses two directories). The outputted numbers show that the rheticus machine performs a single JOREK iteration a little bit faster than the fourmi machine. The two machines that have been used for the runs are described in README.txt files.

$ cat model199/fourmi_a/README.txt Machine : PLAFRIM/fourmi Location : Bordeaux -France Processor : Intel(R) Xeon(R) CPU X5550 @ 2.67GHz Cores/node : 8 3.2.2 Impact of the Fortran compiler JOREK numerical core relies partly on PASTIX and BLAS libraries. These libraries should be configured and compiled properly. But, the compilation of JOREK impacts also the performance. We want to evaluate the impact of fortran compiler on timers. Each iteration takes a bit more time with gfortran compared to ifort. After some investigations in the output files, the responsible for this difference can be found: The matrix construct subroutine takes more time with gfortran. It explains the gap between elapsed time for a complete ITERATION seen previously.

PASTIX thread-funneled versus thread-multiple

The PASTIX sparse parallel solver uses by default the MPI_THREAD_MULTIPLE if the MPI library supports it. The design of this parallel library is based on a fully multi-threaded environment, and the MPI_THREAD_MULTIPLE mode of MPI helps for that. But if the MPI implementation does not handle MPI_THREAD_MULTIPLE, a funneled version of PASTIX is also accessible. This version, available through -DPASTIX_FUNNELED during PASTIX configuration requires only the MPI_THREAD_FUNNELED capability of the MPI library. In this mode, the MPI process may be multi-threaded, but only the main thread will make MPI calls.

$ cd benchmark $ ./timing_bench.sh facto out_loop3 grep2 model302/fourmi_? model302/rheticus_? == model302/fourmi_a ( openmpi ) 0 ## Elapsed time, facto : 64.7742300 == model302/fourmi_b ( openmpi + FUNNELED ) 0 ## Elapsed time, facto : 50.9117520 == model302/rheticus_a ( mvapich2 ) 0 ## Elapsed time, facto : 39.4410000 == model302/rheticus_b ( mvapich2 + FUNNELED ) 0 ## Elapsed time, facto : 35.4110000

This example show the time taken by the factorisation step performed by PASTIX solver on two machines for model 302. On the two machines, with two different MPI libraries, the funneled version of Pastix is quicker than the multi-threaded one.

Latu & al

$ cd benchmark $ ./timing_bench.sh gmres/solve out_loop3 grep1 model302/fourmi_? model302/rheticus_? == model302/fourmi_a ( openmpi ) 0 # Elapsed time gmres/solve : 1.5070440 == model302/fourmi_b ( openmpi + FUNNELED ) 0 # Elapsed time gmres/solve : 4.4459140 == model302/rheticus_a ( mvapich2 ) 0 # Elapsed time gmres/solve : 1.3680000 == model302/rheticus_b ( mvapich2 + FUNNELED ) 0 # Elapsed time gmres/solve : 3.7280000

Concerning the gmres/solve iterative process that mainly involves the solve step of the Pastix solver, the funneled version is nearly three times slower than the multithreaded version. The performance ratio is the opposite of the one made for the factorisation.

As a conclusion, if you have access to a library that has both MPI_THREAD_FUNNELED and MPI_THREAD_MULTIPLE available, you have to check which configuration gives you best performance for your runs. If your JOREK jobs are mainly dominated by solve performance MPI_THREAD_MULTIPLE should be better, but if your runs are dominated by facto performance MPI_THREAD_FUNNELED should be faster.

Parallel strong scaling

The timing_bench.sh tool can be used for parallel benchmarking. In order to evaluate parallel performance of a code, a classical test is the strong scaling. Given a fixed test case (we have taken the reference scenario of model 302 with X-point geometry and n_tor=3), the number of cores is doubled successively. Ideally, the timing of parallel subroutines should be successively divided by a factor two. For this experiment, we have set the JOREK compilation flag -DUSE_BLOCK that shortens the analysis step of the parallel sparse solver. The rheticus machine of Mésocentre de Marseilles was used. The configuration on only one node (first column of the left table) is pathological. It is strongly penalized by a very large part of the available memory occupied by JOREK processes (memory shortfall and system starts swapping). That's better to exclude this configuration in a performance analysis.

In the left table, the timers for an iteration that includes analysis and factorisation steps is presented. Two steps scale quite well: construct_matrix and factorisation. Three steps do not scale at all: coicsr, distribute, analysis. A step is in the middle with some scaling but not a good one: gmres/solve step. For one complete iteration (ITER keyword), the scaling is not so bad, this is partly due to the large relative weight of the factorisation step.

In the right table, the timers for an iteration that does not include analysis and factorisation steps is shown. The distribute step takes less time than previous table because only the RHS vector b is transferred among cores, not the whole matrix A. The execution time for one iteration is dominated by the steps construct_matrix and gmres/solve and scales reasonably well.

Inria 4 Conclusion

A Non Regression Tool has been installed in JOREK code that allows the user to check if its runs give the same results as compared to some reference scenarii. Three reference scenarii have been designed for models 199, 302 and 303. The comparison of one run against a reference run is performed thanks to a specific metric encasulated into a shell script. This metric is based on the numerical differences between several energy Fourier modes growth rates during a given time interval against one reference scenario.

The reference scenarii can also be used for benchmarking issues. We have compared in different configurations some timers outputted by the JOREK code. These timers give clues to determine a performant configuration when porting the code on new systems.

Figure 1 :

 1 Figure 1: Example of gnuplot output generated by plotting f1 and f2 files with time evolution (abscissa) of growth rates (ordinate)

$

  benchmark/timing_bench.sh ITER out_loop2 grep5 rheticus_gf_302 if_302 == rheticus_gf_302 ( gfortran 4.4.6 ) 0 # Elapsed time ITERATION : 157.0370000 0 # Elapsed time ITERATION : 78.8670000 0 # Elapsed time ITERATION : 14.6350000 0 # Elapsed time ITERATION : 14.9580000 0 # Elapsed time ITERATION : 15.1500000 == rheticus_if_302 ( ifort 12.1 ) 0 # Elapsed time ITERATION : 150.9672940 0 # Elapsed time ITERATION : 74.2307940 0 # Elapsed time ITERATION : 8.2149000 0 # Elapsed time ITERATION : 9.0045110 0 # Elapsed time ITERATION : 9.8495460

$

  benchmark/timing_bench.sh construct_ out_loop2 grep5 rheticus_gf_302 rheticus_if_302 == rheticus_gf_302 ( gfortran 4.4.6 ) 0 # Elapsed time construct_matrix : 11.9530000 0 # Elapsed time construct_matrix : 11.5190000 0 # Elapsed time construct_matrix : 11.4940000 0 # Elapsed time construct_matrix : 11.4600000 0 # Elapsed time construct_matrix : 11.5520000 == rheticus_if_302 ( ifort 12.1 ) 0 # Elapsed time construct_matrix : 5.2446580 0 # Elapsed time construct_matrix : 4.8440020 0 # Elapsed time construct_matrix : 4.8604400 0 # Elapsed time construct_matrix : 4.8635080 0 # Elapsed time construct_matrix : 5.4503650

Table 1 :

 1 Timing in seconds for the first iteration (reference scenario model 302, out_loop3 file)

	Nb cores	12	24	48	96	192	Nb cores	12	24	48	96	192
	Nb nodes	1	2	4	8	16	Nb nodes	1	2	4	8	16
	Nb MPI proc.	4	4	4	8	16	Nb MPI proc.	4	4	4	8	16
	Nb threads	3	6	12	12	12	Nb threads	3	6	12	12	12
	Steps						Steps
	construct_m	14.74	7.53	4.13	2.08	1.47	construct_m	15.7	7.20	3.90	2.07	1.20
	coicsr	0.41	0.30	0.29	0.31	0.31	coicsr	0.	0.	0.	0.	0.
	distribute	3.30	2.90	2.93	2.50	2.25	distribute	0.002	0.004	0.002	0.002	0.002
	analysis	2.03	1.69	1.71	2.16	2.40	analysis	0.	0.	0.	0.	0.
	facto	265.8	67.2	41.5	22.7	14.5	facto	0.	0.	0.	0.	0.
	gmres/solve	18.5	2.53	1.76	1.33	0.73	gmres/solve	12.8	6.89	5.92	3.56	2.12
	ITER	308.7	83.4	53.3	31.9	22.5	ITER	29.9	14.8	10.2	5.97	3.58

Table 2 :

 2 Timing in seconds for the third iteration (reference scenario model 302, out_loop3 file)

RR n°8134

Non Regression Testing involve an entire code whereas unitary tests involve subroutines or subparts of the code.

It is also possible to perform a nrt_compare.sh during a simulation and the check will be realized on available data in the macroscopic_vars.dat file.RR n°8134

Inria

Latu & al

351, Cours de la Libération Bâtiment A 29

Publisher Inria Domaine de Voluceau -Rocquencourt BP 105 -78153 Le Chesnay Cedex inria.fr ISSN 0249-6399

At present day, a reduced set of timers are accessible. Here is a list of these timers:

• construct_matrix: time elapsed to compute all matrix coefficients of the global system A and to build the right hand side vector b (see Eq. 3). A domain decomposition is used to parallelize this step, based on distribution of the Bezier finite elements among MPI processes. A communication step is also performed to form the RHS b. • distribute: time to distribute the coefficients of the preconditioner matrix P i (copied from distributed A) to all master processes, but also to send the local RHS associated to each local P i . There is one master process per harmonic (i.e.

n_tor+1 2

) that receives P i and its local RHS.

• coicsr: time to convert the preconditioner matrix P i on each master from (i, j, value) format to CSR (standard compressed sparse format). This transform is generally needed to give P i as input to the sparse parallel solver (actually Pastix or MUMPS or WSMP). • analysis: first phase of the sparse solver to solve linear systems for matrices P i . It comprises an ordering step that reorders the rows and columns, an analysis step or symbolic factorization that determines the nonzero structures of matrix and creates internally suitable data structures. • facto: second phase of the sparse solver, the factorisation computes the L and U matrices (or another decomposition). • first solve: time to solve the first set of linear systems in a single JOREK temporal step (matrices P i ), that includes potentially the analysis, the factorization and the solve step (forward and back substitution algorithms). But often, analysis or factorisation can be skipped. • gmres/solve: time needed by GMRES iterative process that solves many times the linear system until a convergence is achieved or a maximum iteration count is reached. Because analysis and factorization are not done again and again, this gmres/solve step is mainly m successive solve steps using P i matrix. • ITER: time for one temporal iteration of JOREK. It can be viewed as a partial sum of a subset of the previous timing counters.

Depending on the configuration, the compilation and the deployment of JOREK on a particular parallel machine, the relative weight of these timers over the total time can be quite different. For example, some parts scale along with the number of cores used (e.g. construct_matrix), others do not scale well (e.g. coicsr).

If you want to store the data obtained from a reference run in the SVN repository (your run is saved into ∼/MYDIR_302 for example), you can use the following procedure:

Latu & al

This will create a directory at the benchmark/model302/MYMACHINE_a location and also copy from your directory ˜/MYDIR_302 only a reduced set of files that should be conserved (the macroscopic_vars.dat file, the standard ouput files of JOREK runs). There will be a README.txt file created in the new directory that you can fill in order to give some information on the machine you used.

Comparing timers

A set of benchmarks of JOREK on several machines and with different settings are presented in this section. It can give some clues to the JOREK user in order to choose a convenient set of parameters during the configuration/compilation of the code on a new machine.

Impact of the MPI library

On Helios machine (IFERC, Rokasho-Japan), available versions of MPI can not use MPI_THREAD_MULTIPLE safely (up to now -september 2012). Then the funneled version of PASTIX has to be used (MPI_THREAD_FUNNELED mode of MPI). Two MPI libraries have been tested in order to determine which one should be preferred: intelmpi (version 4.0.3) or bullxmpi (version 1.1.14.3). From the first two commands, one can draw two conclusions:

a) The solve step (with the funneled version of Pastix) takes roughly the same amount of time with bullxmpi or intelmpi MPI libraries. b) The factorisation is much quicker with bullxmpi implementation. The last command gives the time spent for some temporal iterations. It is clear that bullxmpi fastens JOREK a lot compared to intelmpi. The first two iterations are dominated by the factorisation step and the intelmpi is much slower on this step.