Benoit Lange
email: benoit.lange@inria.fr

Toan Nguyen
email: toan.nguyen@inria.fr

Big Data architecture for large-scale scientific computing

Keywords: Big Data architecture, Scientific simulation, VE-LaSSCo, Hadoop

Today, the scientific community uses massively simulations to test their theories and to understand physical phenomena. Simulation is however limited by two important factors: the number of elements used and the number of time-steps which are computed and stored. Both limits are constrained by hardware capabilities (computation nodes and/or storage).

From this observation arises the VELaSSCo project 1 . The goal is to design, implement and deploy a platform to store data for DEM (Discrete Element Method) and FEM (Finite Element Method) simulations. These simulations can produce huge amounts of data regarding to the number of elements (particles in DEM) which are computed, and also regarding to the number of time-steps processed. The VELaSSCo platform solves this problem by providing a framework fulfilling the application needs and running on any available hardware. This platform is composed of different software modules: a Hadoop distribution and some specific plug-ins. The plugins which are designed deal with the data produced by the simulations. The output of the platform is designed to fit with requirements of available visualization software.

I. INTRODUCTION

The data production rate has followed a path similar to computation hardware (based on Moores law). The amount of information has an exponential growth while hardware storage capabilities does not follow a similar path. Moreover, the data produced has also an impact on which architecture is needed. This amount of data is extracted by several sources: sensors, simulations, users, etc. For example, the LSST produces 30 terabytes of astrophysics data every night [START_REF] Claver | Project status of the 8.4-m lsst[END_REF]. Simulations can also create large amount of data as in [START_REF] Lange | Parallel dual tree traversal on multi-core and many-core architectures for astrophysical n-body simulations[END_REF], where the authors present a parallel implementation of the Denhen algorithm [START_REF] Dehnen | A hierarchical o (n) force calculation algorithm[END_REF], an astrophysical N -body simulator. This implementation produces 500 Megabytes of data in 1.19 seconds (for a plummer distribution with 10 M particles, and only one timestep). HPC facilities, which are used by scientists to perform simulations, are not currently designed to store such important amounts of data: these systems are only suitable to provide efficient computation capabilities. This paper presents the VELaSSCo project: it provides a BigData architecture to store the data produced by various simulation engines. This data must be visualized by specific tools. For this purpose, two visualization software are targeted: GID2 from CIMNE3 and I-FX 4 from Fraunhofer IGD 5 .

The project is also focused on specific data produced by two different simulation engines: FEM and DEM data. An example of visualization of FEM simulation data is presented in Figure 1. This simulation deals with the decomposition of space using a mesh structure, and it is used to understand the dynamic of specific objects. For the DEM, a particle example is presented in Figure 2 (The figure has be produced by the University of Edinburg6 ). Both of these solutions produce important amounts of information: for 10 millions particles and 1 billion of time-steps, DEM uses 1 Petabytes of data, or 1 billion elements with 25000 time-steps, whereas FEM produces 50 T B of data. Currently, all the data produced by these simulations data are simply not stored, and several timesteps are deleted from storage device. This paper focuses on the Big Data architecture designed for the VELaSSCo project. The platform is designed to be scalable regarding to which IT capabilities are available (HPC, Clouds, etc.). It also interfaces visualization tools. It must also interface some commercial tools specifically designed to deal with engineering data.

Section II is an overview of related work on Big Data. Section III addresses the architecture of the VELaSSCo platform. Section IV is a conclusion.

II. RELATED WORK

This section is mainly focused on Big Data for engineering applications. Problematics linked with this field are not widely developed in the literature. Most of Big Data related problems concentrate on Web crawling and analytics. Further, simple visualization queries for engineering simulations are similar to Web crawling. Therefore, we assume that using solutions provided for Web search can enhance engineering applications and visualization queries.

MapReduce computation has been massively studied and developed recently. Traditional Big Data approaches are mainly based on MapReduce computations to extract information. Strict implementations have been proposed for this computation model. But evolutions have also been presented and follow two different paths: Hadoop compliant and none Hadoop compliant software. Hadoop 7 is an open-source project which implements all the needs with respect to distribute processing systems for large-scale data. This project was mainly inspired by Google papers [START_REF] Ghemawat | The google file system[END_REF] and [START_REF] Dean | Mapreduce: simplified data processing on large clusters[END_REF].

At the same time, non-Hadoop compliant solutions have been developed, which have been designed by database providers, e.g., to propose a BigData platform based on existing products. In other cases, these solutions are developed to deal with other requirements than Hadoop does. An example is to store big data on HPC facilities without dedicate storage, and run MapReduce jobs on the HPC nodes. These strategies have been designed to provide solutions for running big data applications on traditional data-centers. Also, the MapReduce programming model has been ported to HPC facilities, while Hadoop is mainly developed to run on a dedicated storage nodes. In [START_REF] Fadika | Mariane: Mapreduce implementation adapted for hpc environments[END_REF], [START_REF] Dede | Marissa: Mapreduce implementation for streaming science applications[END_REF], authors present two implementations of MapReduce dedicated to HPC facilities. Their strategies allow to apply MapReduce jobs on POSIX compliant file systems, and an abstract layer is not necessary (like HDFS). A deeper study of these methods is not possible, because the code source is not directly available and the extensibility of these solutions is not discussed.

Global frameworks like Hadoop have also been proposed by the scientific community. One of them is Dryad, [START_REF] Isard | Dryad: data-parallel programs from sequential building blocks[END_REF]. This solution is designed to extend the standard MapReduce model by adding intermediate layers between the Map phase and the Reduce phase. Now, this implementation has been ported to the Hadoop ecosystem, and Dryad is a full extension of Hadoop using YARN. This software is available on the GitHub repository at Microsoft8 .

Regarding our needs, our interest is focused on the Hadoop ecosystem and more precisely on two extensions. The first one shows the usage of Hadoop over HPC, and the second one deals with an extension of the Hadoop storage with an existing database system.

The paper [START_REF] Krishnan | myhadoop-hadoop-on-demand on traditional hpc resources[END_REF] presents how Hadoop is used over a traditional HPC system. This solution is decomposed as follows: Hadoop services are started, then the necessary files are transferred to HDFS, then the computation is run. After the computation, Hadoop services are stopped and the HDFS partition is destroyed. This solution highlights some bottlenecks: data transfers between HDFS and the HPC file system. Due to the HPC structure, authors do not use local storage of the HPC: indeed this storage can only be used as a temporary repository.

The second paper [START_REF] Abouzeid | Hadoopdb: An architectural hybrid of mapreduce and dbms technologies for analytical workloads[END_REF] presents a Hadoop extension which uses a RDBMS (Relational Data Base Management System) to store the data. This storage system is used instead of the traditional HDFS solution. The goal is to improve the query speed over Hadoop using the SQL engine of the RDBMS. Their example stores data into a Postgresql database, but any database system can be used instead.

III. ARCHITECTURE

This section presents the architecture used for the VE LaSSCo platform. It is designed to fit with specific requirements of engineering data simulations. These requirements are:

• the platform has to be compatible with various computing infrastructure: HPC, clouds, grids, etc.,

• the data produced by the simulation engines can be computed by several nodes,

• the visualization queries can be simple or complex,

• the visualization queries will be performed in batch or in real-time,

• the architecture has to be extensible, scalable and supported by a large community of users.

For the first requirement, we are currently extending the solution presented in [START_REF] Krishnan | myhadoop-hadoop-on-demand on traditional hpc resources[END_REF]. This tool provides a solution to deploy a Hadoop ecosystem on any kind of computation infrastructure, and moreover it reduces the bottleneck due to numerous file transfers between the virtual file system (FS) and the HPC FS. Regarding to our partners requirements, it is necessary to provide a solution which can be parameterized to deal with the specifics of their computing facilities. This solution is designed to be suitable for three different cases: 1) HPC and dedicated storage nodes, 2) HPC nodes with dedicated local storage, 3) HPC nodes with an existing distributed storage system.

For the first point, a HPC infrastructure coexists with storage facilities. This solution is quite new for users from data simulation. It implies to have two data-centers topologies with dedicated nodes for both sides (HPC and Hadoop). To avoid deployment of such an architecture, it is possible to extend an existing datacenter using external providers like Amazon (with EC2 9 and S3 10 ).

The second approach uses dedicated storage for storing data. All the nodes in the HPC have a specific local storage dedicated to Big Data. A local hard disk is already used to store local data during computations. For these HPC facilities, it is possible to add a specific storage. In this architecture, we dedicate this local storage to all necessary information concerning the BigData architecture. This solution can only be implemented on private computing facilities, with possible hardware modifications.

The last solution uses the distributed FS of the actual HPC to store the data. This approach is the most suitable solution for public computing facilities without extensibility for users. With this approach the data transfers are an important bottleneck.

To fit with all these cases, we extend the myHadoop implementation [START_REF] Krishnan | myhadoop-hadoop-on-demand on traditional hpc resources[END_REF], by providing all the necessary modules to deploy a VELaSSCo platform on all kind of computing facilities. This tool also provides the necessary interfaces to deal with visualization queries, using pre-installed extensions.

The second step of our project is to gather information from computation nodes. The computation of a specific job can imply splitting the data among different nodes: for example FEM simulations decompose the space into elements, which are distributed among the nodes. A representation of decomposition is presented in Figure 3, where each colored area is assigned to a particular node. Thus, for each time-step, it is necessary to gather all the information produced by each node. For this purpose, we use an Apache Flume agent which is in charge of storing information into the VELaSSCo platform.

The third and fourth points concern visualization, and more precisely queries. Visualization has two query layers: the simple one and the complex one.

Simple queries are very similar to traditional information search over Big Data sets. A query has to find a specific subset of information at a specific time-step. This model is well-known and can be efficiently translated into MapReduce jobs. To reduce the complexity of the query model (avoid to define the MapReduce jobs), we use Hive with Tez. But we also have to deal with more complex queries which imply complex computations. For this, specific scripts are developed. Examples of these computations are: extract spline, iso-surface, interpolate information, provide a multi-resolution models, etc. The fourth point concerns the queries rate: queries have to be performed in batch (SQL is well suited for this specific case), but queries can also be triggered dynamically from specific visualization points of view. Displacements of the camera in the 3D space thus produce a queries sent to the platform. For this specific case, we use Storm to stream the data. Different approaches have been proposed in the computer graphic literature, one of them is presented in [START_REF] Lindstrom | Real-time, continuous level of detail rendering of height fields[END_REF]. This solution presents a continuous multi-resolution method for terrain visualization. Information is sent to the viewer in realtime depending on the camera location. To use efficiently this method, it is necessary to store data using a multi-level approach. In VELaSSCO, we plan to store the data at different resolutions to provide real-time answers to the visualization software. This decomposition of data will be inspired by the method presented by Hoppe in [START_REF] Hoppe | Progressive meshes[END_REF], where a base mesh is used to encode all information related to a higher resolution.

The storage architecture of the VELaSSCo platform has to deal with this multi-resolution characteristics and hierarchical decomposition. Moreover, the computational model used to extract information has also to be suitable with these assets. This part of the project is the trickier part, and most of our future contributions will be focused on these specific points.

The last point concerns the extensibility and support. We are looking for an extensible framework which supports extensions for specific usage: queries, data locality and the management of specific storage. Hadoop is the best choice for this purpose. The framework already provides a large set of extensions, and scientific communities continuously provide new contributions. Moreover, this solution is well suited to our needs: we provide a plugin to store data into a partner database named EDM (Express Data Manager). The plug-in is inspired by the solution presented in [START_REF] Krishnan | myhadoop-hadoop-on-demand on traditional hpc resources[END_REF]. The EDM database is an object-oriented database designed to store AP209 standard compliant files. It is a database dedicated to engineering applications.

To summarize the whole VELaSSCo platform is depicted in the Figure 4. It enhances the myHadoop software, with preinstalled plugins. It can be deployed on various IT architectures. This solution has been designed to store data from multiple sources using Flume. We plan to extend the current query engine, and improve it to support complex interactive visualization queries. Another part is dedicated to storage facilities using a specific database system for engineering data. In Figure 4, some extensions are not defined for example: applications and complex queries. The Application component is dedicated to specific computations which run on the storage nodes; for example the computation of multi-resolutions objects. For the complex queries, not all of them have been yet selected, thus the future plugin has not been yet chosen. As stated in this Figure 4, the platform also supports different file systems: HDFS and Lustre for example. We also use the EDM database system, and provide a wrapper between the abstract file system layer in Hadoop and EDM.

IV. CONCLUSION

We introduce the VELaSSCo project. Simulations produce exponentially growing volumes of data, and it is not possible to store them anymore into existing IT systems. Therefore, VELaSSCo aims to develop new concepts for integrated enduser visual analysis with advanced management and postprocessing algorithms for engineering applications, dedicated to scalable, real-time and petabyte level simulations. Data in this project are produced by two simulation sources: DEM and FEM applications. VELaSSCo is a solution to provide a complete platform to answer these needs.

We introduce the architecture of the platform, which is composed of a specific Hadoop distribution related to engineering data processing. The choice was made with respect to some requirements: support complex architectures, support multisources aggregation, query lead by visualization, scalability and extensibility. It is be composed of an open-source Hadoop distribution, using myHadoop and preinstalled extensions and scripts for visual queries. We plan to extend the storage by providing a plugin to use the EDM commercial database system as a file system. This software is an engineering database which supports large and complex engineering applications.

Our future work will be mainly focused on complex visual queries on Big Data, and more precisely on real-time streaming queries according to dynamic camera locations.

Fig. 1 .

 1 Fig. 1. Visualization of FEM simulation (Air flow), produced by GID (CIMNE).

Fig. 2 .

 2 Fig. 2. Visualization of DEM data (UEDIN), silo discharge.

Fig. 3 .

 3 Fig. 3. Different partition of space for a FEM simulation (provided by CIMNE).

Fig. 4 .

 4 Fig. 4. Expected architecture of the VELaSSCo platform.

http://www.velassco.eu

http://www.gidhome.com

http://www.cimne.com

http://www.i-fx.net

https://www.igd.fraunhofer.de

http://www.ed.ac.uk

http://hadoop.apache.org

https://github.com/MicrosoftResearchSVC/Dryad

ACKNOWLEDGMENTS

This work was supported in part by the EU FP7 project VELaSSCo, project number: 619439, FP7-ICT-2013-11.


Brice Miard

Pierre Rouanet

Jonathan Grizou

Manuel Lopes

Jacqueline Gottlieb

Adrien Baranes

Pierre-Yves Oudeyer

A new experimental setup to study the structure of curiosity-driven exploration in humans

I. INTRODUCTION

Curiosity is a key element of human development, driving us to explore spontaneously novel objects, activities and environments [START_REF] Gottlieb | Information-seeking, curiosity, and attention: computational and neural mechanisms[END_REF]. Curiosity-driven exploration strategies permit us to interact, learn and evolve quickly in an open ended world. It is thus an important challenge to understand the fundamental mechanisms of spontaneous exploration and curiosity in humans.

One of the first experiments on this topic was made by Harlow, where monkeys played with simple 2D puzzles to highlight the relation between complexity, motivation and learning [START_REF] Harlow | Learning and satiation of response in intrinsically motivated complex puzzle performance by monkeys[END_REF]. Another early example is McReynolds et al. who created the "curiosity box" where identical boxes, with different toys inside, are presented to young children [START_REF] Mcreynolds | Relation of object curiosity to psychological adjustment in children[END_REF]. Recently, an experiment was made with infants to study action selection guided by intrinsic motivations with a mechatronic board. In this study, subjects have to learn the relation between actions on pushbuttons and the opening of boxes [START_REF] Taffoni | Development of goal-directed action selection guided by intrinsic motivations: an experiment with children[END_REF]. They showed significant differences in exploration strategy (sensorimotor vs a more learning directed exploration) between three and four years old infants. Despite a number of other psychology and neuroscience experiments in humans and monkeys, we still know little about the precise mechanisms of curiosity [START_REF] Gottlieb | Information-seeking, curiosity, and attention: computational and neural mechanisms[END_REF].

Many computational models of curiosity have been elaborated [START_REF] Gottlieb | Information-seeking, curiosity, and attention: computational and neural mechanisms[END_REF], [START_REF] Baldassarre | Intrinsically motivated learning in natural and artificial systems[END_REF]. Some of these models specifically targeted the modeling of curiosity and its role in human sensorimotor and cognitive development, showing how it can generate automatically behavioral and cognitive developmental structures sharing interesting similarities with infant development [START_REF] Moulin-Frier | Self-Organization of Early Vocal Development in Infants and Machines: The Role of Intrinsic Motivation[END_REF], [START_REF] Oudeyer | How evolution may work through curiosity-driven developmental process[END_REF]. These lines of work allowed to identify the wide diversity of potential mechanisms that could be at play to drive spontaneous exploration [START_REF] Oudeyer | What is intrinsic motivation? a typology of computational approaches[END_REF]. We focus here on the intrinsic motivation mechanisms driving exploration, i.e. the processes allowing an agent to choose itself goals when freely involved in a task.

Novel hypotheseses have been formulated such that curiosity-driven sensorimotor exploration could be organized as to maximize learning progress [START_REF] Schmidhuber | Curious model-building control systems[END_REF], [START_REF] Oudeyer | Intrinsic motivation systems for autonomous mental development[END_REF], which is different from more classical hypothesis conceptualizing curiosity as a drive to maximize uncertainty of novelty. Yet, experimental setups designed so far in the literature do not allow to separate between these hypotheses. A major research challenge is thus to design experimental setups which could allow to confirm or invalidate individual hypotheses. Furthermore, it is important to note that intrinsic motivation mechanisms could be influenced when asked to behave according to a specific protocol. This will be discussed in details when describing our experimental setup.

Here, we make a step in this direction by presenting an exploratory study with humans designed to analyze and measure properties of curiosity-driven exploration of a priori unknown sensorimotor spaces. More specifically, we are interested in the relation between exploration and learning progress. This experimental setup is designed as a game setting human subjects into an intrinsically motivated activity [START_REF] Malone | Making learning fun: A taxonomy of intrinsic motivations for learning[END_REF]. Participants can freely explore and shift between several games, each being about finding a mapping between their movements (body joints tracked by a kinect) and a 2D shape displayed on a screen (an ellipsis). We will first describe the setup, then present the ongoing users study and preliminary results. In each game, they have to match the shape they control with randomly generated goals (see figure 1b). When reached, i.e. when the controlled shape is maintained close enough of the target for one second, a new goal is automatically generated. Objectives change every 30 seconds when not reached. Additional performance indicators were added on the screen interface in order to improve the subject's, implication and comprehension (see figure 1b) [START_REF] Malone | Making learning fun: A taxonomy of intrinsic motivations for learning[END_REF].

II. EXPERIMENTAL SETUP

Each of the four games, while visually similar, differs by the difficulty of the underlying mapping (more or less easy to learn). Typically, for each of these mappings, the axes of the ellipsis are controlled by one of the body's joint: e.g. the major axis will be controlled by the pitch angle of the left shoulder while the minor axis will be controlled by the yaw angle of the right elbow. Note that in one of the game, a single joint is used to control both axis making the ellipsis a circle. Users are entirely free to change from one game to another one, thanks to a tablet, when and how often they want. It is important to note here that while they are extrinsically motivated to play each game (protocol, score...), they are entirely free to change games whenever they want. Thus, as we focus on the transition and how they divide their time among those four games, we assume that we are still measuring intrinsically motivated behaviors.

The following protocol was used for the ongoing user's study, so far about twenty participants played our game. First, participants had to fill in a questionnaire (on a five Likert scale) aiming at highlighting personality and skill profiles (e.g. practice of body expression activities such as dance or theatre). This pre-questionnaire also include the CEI2 questionnaire [START_REF] Kashdan | The curiosity and exploration inventory-ii: Development, factor structure, and psychometrics[END_REF], a psychological test designed to evaluate level of curiosity. Then, they could play the four different games for a total of 15 minutes. Afterwards, they had to do a quick test, play each game for one minute and reach the highest score as possible. Finally, they had to fill in another questionnaire to collect their subjective point of view of their user's experience (difficulty, time spent on each games, progress, expected progress).

During all the experiments, we also record each time they reach a goal and each time they change games. We can thus compute their learning progression by summing the number of objectives succeeded in a time window. We also recorded the movement of their 20 articulations of their bodies in 3D at 10Hz allowing the study of exploration strategy such as the freezing/unfreezing of degrees of freedom. A video presenting the setup and the experiments is available here: https://vimeo.com/95383753. We analyzed data from 20 participants selected among staffs and students at Inria. We observe a different repartition of the time spent per game. Our future work will consist of trying to infer the reasons from the when and why the participants change game from the data. We particularly want to investigate whether or not the hyphothesis that activity change is related to learning progress.

III. FUTURE WORK

Fig. 1 .

 1 Fig. 1. a) Subjects are exploring how to control an ellipsis displayed on the screen in front of them by moving their body joints tracked by a Kinect device. b) Details of the interface shown to the user on a screen in front of them: in particular, you can see the controlled ellipsis (in red) and the target one (in brown).

Fig. 2 .

 2 Fig. 2. Percentage of time spent by subjects on the 4 differents games.

ACKNOWLEDGEMENT

We would like to thanks Julie Golliot for helping us designing the experimental setup and protocol. This research was partially funded by Inria Neurocuriosity and ERC 2400007.