ScalSALE: Scalable SALE Benchmark Framework for Supercomputers

Supercomputers worldwide provide the necessary infrastructure for groundbreaking research. However, most supercomputers are not designed equally due to different desired figure of merit, which is derived from the computational bounds of the targeted scientific applications' portfolio. In turn, the design of such computers becomes an optimization process that strives to achieve the best performances possible in a multi-parameters search space. Therefore, verifying and evaluating whether a supercomputer can achieve its desired goal becomes a tedious and complex task. For this purpose, many full, mini, proxy, and benchmark applications have been introduced in the attempt to represent scientific applications. Nevertheless, as these benchmarks are hard to expand, and most importantly, are over-simplified compared to scientific applications that tend to couple multiple scientific domains, they fail to represent the true scaling capabilities. We suggest a new physical scalable benchmark framework, namely ScalSALE, based on the well-known SALE scheme. ScalSALE's main goal is to provide a simple, flexible, scalable infrastructure that can be easily expanded to include multi-physical schemes while maintaining scalable and efficient execution times. By expanding ScalSALE, the gap between the over-simplified benchmarks and scientific applications can be bridged. To achieve this goal, ScalSALE is implemented in Modern Fortran with simple OOP design patterns and supported by transparent MPI-3 blocking and non-blocking communication that allows such a scalable framework. ScalSALE is compared to LULESH via simulating the Sedov-Taylor blast wave problem using strong and weak scaling tests. ScalSALE is executed and evaluated with both rezoning options - Lagrangian and Eulerian.

A. Objectives and Designs of Supercomputers
The combination of high-performance computing (high resolution and fidelity) and storage (large outputs to be analyzed) in supercomputers provide the essential infrastructure for groundbreaking research, simulation modeling, and data analysis in various scientific domains [1].
Most, if not all, scientific applications' performance tends to be bounded by a computer component. For example, CPUbound applications are limited by the processing speed of the CPUs, thus, they can be sped up by adding more cores to the machine; I/O-bound applications are limited by the amount of time the application spends waiting for I/O operations; memory-bound applications are limited by the memory access speed and the amount of available memory; latency-bound applications are limited by the time it takes to retrieve data; bandwidth-bound are limited by the amount of data that needs to be retrieved (and transferred).
It is common to classify scientific applications into several algorithmic classes or kernels that can be associated with a specific bound [2]. For example, dense linear algebra [3] and structured grids with high flop/s rate are classified as computebound; sparse linear algebra and particle methods [4] with high-performance memory systems are classified as memorybound; FFTs [5] with high bisection bandwidth is classified as bandwidth-bound; unstructured grid or adaptive mesh refinement (AMR) [6] with a low latency network is classified as latency-bound; and data-intensive computations with storage and network access can be classified as memory and I/Obound. Nevertheless, most applications are associated with multiple algorithmic classes, thus making them multi-bound.
As the demand for performance enhancement of these algorithmic classes -and in turn, the associated scientific applications -constantly increases, new hardware architectures and designs have emerged over the years. For example, the introduction of Infiniband [7] -a high bandwidth and low-latency network, improved the performance of scientific applications that use unstructured or adaptive mesh refinement (AMR), such as in fusion [8], climate [9] and astrophysics [10]. In the same way, general-purposed GPUs (GPGPUs) [11] reduced the execution time of dense linear algebra and FFTs calculations common in material science, chemistry, astrophysics, and deep learning applications. In addition, the introduction of high bandwidth memory (HBM) [12] and DDR5 enhanced memory-bound kernels such as particle methods. Moreover, data-intensive calculations were boosted with the introduction of burst buffer storage [13]. Thus, it can be claimed that the targeted applications' work fashion drives supercomputers' designs and architectures.
Due to the wide variety of scientific applications and their corresponding optimal hardware, designing a supercomputer has become much more complex and diverse compared to previous generations [14] (as can also be seen in the Top500 list [15]), especially if it is designed under a budget. For example, the Fugaku [16] supercomputer, which holds the first spot in the HPCG list [17], contains only CPUs and a lowlatency network which makes it optimal for tightly-coupled simulations and modeling but not for artificial intelligence applications [18]. On the contrary, Frontier [19], the first exascale supercomputer, is heterogeneous -containing both CPUs and GPUs. More so, Facebook's supercomputer [20] is intended for AI modeling exclusively. Thus, it contains almost only GPUs. Furthermore, the new HPC as a service (HPCaaS) allows the formation of large-scale cloud clusters with low network capabilities (high latency) [21], [22], best for embarrassingly parallel and loosely coupled computations (with minor to moderate communication operations) [23]. Such a system is suited for deep learning applications and small-scale traditional simulations and modeling.

B. Assessment and Evaluation of Supercomputers
Over the years, the goals of supercomputers have become diverse -supporting a wide portfolio of scientific applications -and as such, the design and architectures are also varied. Thus, the crucial step of assessing, evaluating, and comparing supercomputers has become hard and complex.
To cope with this hard task, the evaluation is usually broken down into different steps, associated with its complexity, and representation of the entire app as a whole -from the most simple test to executing a whole application (an illustration of these steps can be seen in Figure 1): 1) Basic parameters and specifications -include: vendor (AMD, Intel, Cray), efficiency, Rpeak, architecture (SMP, SIMD), operating system (RHEL, SUSE, Ubuntu), interconnect family (Ethernet, Infiniband), number of cores, accelerators family, application area (academic, industry), and more. These parameters provide a general overview of the machine and its composition. As this step is not complex at all, it is represented in Figure 1 below the x-axis.  Fig. 1: The steps taken in order to evaluate and assess supercomputers as a function of their complexity and representation of scientific applications -based on [24]. SCALSALE extends the mini/proxy apps, such that it will maintain the same complexity as most mini-apps while overlapping and representing scientific applications.
to maintain and highly scalable. For example, IOR [25] (random I/O operations), ALCF [26] or MPIGraph [27] (basic MPI operations) and many more. These tests are simple and less representative of the supercomputer, hence its position in Figure 1.
3) Kernel Benchmarks -compute specific dedicated intensive calculations of actual scientific applications are executed to test the coupling and synergy between various components. The kernel benchmarks are supposed to be simple yet represent a small fragment of scientific applications. For example, SPEC [28] (tests sharedmemory parallelization scheme), BTIO [29] (MPI operations with I/O operations), high-performance Linpack (HPL, computes basic linear algebra operations) [30], high-performance conjugate gradients (HPCG, performs the conjugate gradients algorithm) [17] and more. The kernel benchmarks are slightly complex and more representative, as seen in Figure 1. 4) Mini/proxy apps -The kernel benchmarks fail to unveil the supercomputer's capabilities in real scientific applications [31]. For example, contrary to the HPL benchmark (a highly optimized compute-bound kernel), real scientific applications are usually multi-bound and not necessarily as optimized or as highly scalable as these benchmarks. This discrepancy only increases in time due to the rapid advancement in computation power and a relatively slow advancement in memory bandwidth and latency. As a result, proxy or mini-apps were devised over the years to bridge the gap between kernel benchmarks and the necessary evaluation of a supercomputer [32]- [34]. These mini-apps attempt to mimic a portion of the computational workflow of scientific applications. For example, AMG2013 [35] mimics a multi-grid linear system solver for unstructured mesh in physical applications; Quick-Silver [36] mimics a portion of the Mercury code [37]; and LULESH [38] that attempts to mimic a portion of ALE3D [39]. Nonetheless, most mini-apps still contain intrinsic differences compared to scientific applications. For example, miniapps do not necessarily couple multiple scientific domains, which is common in scientific applications, especially in their corresponding physical simulations known as multi-physical simulations. Coupling multiple domains under one application is crucial as it increases memory consumption -as more data structures are needed to describe the problem. Hence, the required amount of synchronization (MPI) operations that depend on the data structures per cycle increases. Furthermore, in some cases, coupling several domains might heavily change the scheme of the code. As a result, the scaling capabilities of mini-apps hardly reflect their counterpart application.

C. LULESH
The previously mentioned, well-known LULESH mini-app is highly simplified and hard-coded to simulate the Sedov-Taylor problem [40] -it solves hydrodynamic equations (Navier-Stokes) explicitly via an unstructured grid. Hence, it is latency and bandwidth bound [41]. In addition, LULESH supports multiple parallelization schemes and programming paradigms: MPI, OpenMP, CUDA, OpenACC and OpenCL [38]. LULESH was developed as part of one of the five challenge problems defined by the DARPA UHPC program [38], [42] and attempts to mimic a small portion of various multi-physics applications (specifically, ALE3D [39]) that consume up to 30% of the computing resources of the DoD and DoE [43]- [45].
Due to its popularity, LULESH is commonly used for testing new hardware, applying optimizations, parallelization schemes, APIs, and more [32], [43]. For example, Laney et al. [46] assessed the effects of data compression on the performance of LULESH and several other benchmarks -as they are the most representative of real scientific applications. Furthermore, Bercea et al. [43] evaluated the effectiveness of the OpenMP version on a GPU.
Nevertheless, there are still many crucial distinctions between LULESH and other common scientific applications such as the ALE3D (which LULESH is based upon). For example, contrary to LULESH, ALE3D simulates multi-physical phenomena. Therefore, ALE3D has a higher memory consumption corresponding to the number of physical quantities necessary to describe multi-physical phenomena. Moreover, multiphysical simulations also contain additional calculations for each cycle (corresponding to the additional equations), such as multi-phase transitions, thermal, advection, chemistry-related calculations, implicit schemes, and many more. These disparities were expressed and even quantified in [44]. LULESH was tuned and optimized on modern hardware, which resulted in an average of 60% decrease in total execution time compared to an unoptimized run. However, applying the same optimizations to ALE3D results in only a 20% time decrease for the same problem, suggesting that although LULESH provides a reasonable benchmark for multi-physics applications, it is far from representing the actual nature of such applications in supercomputers.
Therefore, similarly to kernel benchmarks, most mini-apps also fail to unveil the true scaling capabilities of supercomputers regarding common scientific applications such as the ALE3D, which, as mentioned, represents 30% of calculations in the DoD and DoE.

D. Contribution -SCALSALE
We propose a scalable mini-app benchmark framework, namely SCALSALE, that will attempt to bridge the gap between benchmarks and actual scientific applicationsor at the very least, provide a framework that will allow bridging this gap. The essence of this benchmark is to create a framework or infrastructure that can be easily expanded to include additional numerical algorithms, physical models, and alternative parallelization schemes with a special focus on scalability, i.e., the ability of this benchmark to maintain a scalable speedup and short execution times, especially compared to currently available benchmarks.
SCALSALE utilizes Modern Fortran [47] as the programming language. Modern Fortran provides excellent, if not the best, execution times for numerical calculations compared to most programming languages while also enabling modern object-oriented design patterns [48]- [50]. Although objectoriented design patterns provide valuable concepts that help the code be more maintainable, easy to modify, and expand (which is beneficial for SCALSALE as a framework), it does not go hand to hand with performance. Thus, SCAL-SALE employs a performance object-oriented programming paradigm that aims to utilize design patterns without harming the performance, i.e., favoring performance in the trade-off between design patterns and high-performance. Moreover, there are many legacy codes (that are still widely used) written in Fortran [51]- [53] (hence its popularity among scientists), contrary to the number of benchmarks in Fortran.
SCALSALE's infrastructure is composed of two independent layers that complement one another. The first and most important layer is the kernel. This layer implements the basic data structures, for example, a 3D array that can be accessed via a function. Moreover, this layer provides a transparent interface to the distributed parallelization scheme via transparent parallel objects implemented with the MPI-3 standard that further supports SCALSALE scaling capabilities. The layer is independent of the other layer and can be applied in different codes and projects. The second layer, the application, contains physical quantities and other related calculations, such as equation-of-state (EoS), and provides an abstraction layer to the data structures implemented in the kernel layer. Furthermore, the application utilizes the physical quantities to implement the physical and numerical models. The application layer is generic and can be replaced or added by any physical model, relying on the kernel as an infrastructure.
Currently, SCALSALE implements 1D, 2D and 3D multimaterial hydrodynamic scheme. The hydrodynamic scheme is  based on the well-known simplified arbitrary Lagrangian Euler (SALE) code [54], [55]. The SALE's simple structure is easy to follow, maintain, modify and expand. In order to support SCALSALE as a framework, the numerical calculations and functions in SALE were adapted to object-oriented design patterns and optimized to modern architectures and compilers.
In order to test the scaling capabilities, it was compared to the well-known hydrodynamic mini-app -LULESH. As mentioned, LULESH is extensively used, especially for evaluating supercomputers, which makes it highly suitable for evaluating SCALSALE. Moreover, both codes perform similar calculations: both solve the Navier-Stokes equations in 3D; can simulate the Sedov-Taylor problem (presented in Figure 2b); apply the ideal gas equation-of-state and more.
Nevertheless, SCALSALE is compared to LULESH only in terms of scaling capabilities, as the main goal of SCALSALE is to provide a scalable framework that can be expanded easily, especially for next-generation supercomputers in the exascale era. Contrary to LULESH, SCALSALE can also solve additional physical problems such as Sod shock-tube [56] (as seen in Figure 2a for Lagrangian rezoning), spherical divergent shocks (Noh) [57] and more. In addition, SCALSALE can simulate problems in 1D, 2D, and 3D, with more than one material (hence, multi-material) and its corresponding equationof-state. Furthermore, SCALSALE solves the equations via a structured grid, with Lagrangian or Eulerian (with an advection phase) rezoning. Thus, providing a wider range of problems that it can solve. The code-features of LULESH and SCAL-SALE are compared and presented in Table I.

II. FOUNDATIONS OF SCALSALE
A modern, scalable scientific benchmark, as a framework, should be readable, maintainable, extensible, well-tested, welldocumented, portable to modern architectures, and most importantly -be constructed in a way that will allow it to take advantage of the optimal parallelism schemes [58]. A benchmark that copes with these requirements must, on the one hand, be written in a programming language with highenough abstraction capabilities while, on the other hand, be as light-weighted as possible. This section presents the founda-  tions of SCALSALE, that enable such a scalable benchmark framework, based on [59].

A. High-performance Oriented Design and Code
The programming languages' abstraction-performance trade-off consists of very fast languages in one extreme and high abstraction level ones in the other. An example of the former languages is Assembly, which is very fast since it is close to the machine code and does not require many translations. However, programming in Assembly requires a very high effort and expertise and does not support OOP. Most importantly, it is not suitable as a benchmark since it does not represent most applications written in higher abstraction level programming languages. An example of the latter language is Python, which is very expressive and easy to use and maintain. Furthermore, it supports OOP but is much slower since it translates the programming abstractions into machine code in run-time. Between these two extremes, there is a range of languages, starting from Assembly, with a decreasing performance power coupled with increasing expressive power. This range includes, among others, Assembly, Fortran 66, Fortran 77, Fortran 90, C, Modern Fortran, C++, and Python. Fortran is used in many benchmarks and codes [52], [53], [60]- [62] mainly due to its low execution times while supporting sufficient programming abstraction.
Fortran underwent a major revision in 2003 and subsequently was re-branded as Modern Fortran. Modern Fortran supports object-oriented design patterns, thus enabling system design through modern design concepts [63], [64], while still benefiting from the fast execution time of the language. In addition, the language features the basic concepts of objectoriented programming (OOP): objects, inheritance, polymorphism, dynamic type allocation, type-bound procedures, and many more. In 2008, Modern Fortran was updated to support additional sub-modules, coarrays, DO CONCURRENT construct that hints to the compiler that a loop can be parallelized, and more. The latest version of Modern Fortran was released in 2018 and included further interoperability with C and additional parallelization features in Fortran.
Over the years, Fortran and C++ were compared to decide which language is best suited for large-scale codes, both in execution and in numerical capabilities, e.g., in multiphysics and scientific applications [48], [49], [65]- [68]. The initial conclusion was that even with the faster execution times of Fortran, C++ is preferred due to the poor support in OOP design patterns and the programming effort Fortran requires. Then, Modern Fortran was upgraded to support more design patterns, resulting in a preference for Modern Fortran over C++. Currently, Fortran is regarded as the indisputable leader for carrying out highly optimized scalable scientific applications in the shortest execution times -even more so since the introduction of Modern Fortran. Moreover, Fortran nowadays provides excellent interoperability with C and C++. Thus, applications written in Fortran, specifically with Modern Fortran object-oriented design patterns, can include modules written in C and C++ -providing the best from both worlds.
Although Modern Fortran does not fully support all objectoriented features such as generic types, pointers, and polymorphic arrays, these design patterns are not necessarily needed. Instead, they may be replaced with other available programming solutions -which usually require slightly higher programming effort. On the other hand, the lack of available abstractions offered in Modern Fortran guarantees the relatively thin implementation for OOP support. This abstraction deficiency demands higher programming effort but allows for an execution time reduction in general and in scientific codes specifically [69].

B. Transparent Parallel Class
Since the introduction of object-oriented programming, principles such as modularity, abstraction, encapsulation, and hierarchy have been encouraged. These principles make it easier to maintain and modify large software systems. Modular programming requires that the code follow decomposability and composability, among other concepts, which promote coupling data structures with their related functions within classes. These concepts allow new scientific applications' developers and users to easily understand these classes' functionality and the code's general structure, subsequently expanding them with additional functionalities [70], [71].
Modularity is beneficial for developing and composing new scientific applications and for decomposing conceptually independent implementations from each other. This is significantly useful for separating the implementations of parallel modules from the rest of the scientific application. Following this idea, the parallel implementation is abstracted by a class that can be updated locally instead of along the entire code to support, e.g., a new MPI standard. Abstraction of this sort also allows to optimize the parallel scheme and tune it tightly to given hardware in a single code region.
OOP is a powerful paradigm, but as a rule of thumb, it does not necessarily conform with performance. For example, abstract classes are great for defining functionality without a concrete implementation (such as EoS calculations). However, if a class that implements an abstract class is called multiple times in a single loop iteration, the memory and computation overhead, derived from the inheritance, becomes significant, which harms the total execution time. In contrast, a simple switch-case clause is thin computationally but lacks the benefits of OOP. Thus, creating a scalable scientific code based on OOP principles must be done carefully and with the right balance between design patterns and scalable execution time.
SCALSALE follows Object-Oriented Parallel Programming (OOPP) ideas which resemble other OOP-based scientific applications such as [72], [73], in which objects, specifically the data structures, are intrinsically parallel. Thus, developers can synchronize the data structures with ease. Nevertheless, developing an efficient and scalable scientific code may and usually will violate important OOP principles, such as object encapsulation, functional independence, and modularity. This trade-off is investigated with caution, but an OOP solution is often preferred if it does not come with substantial runningtime growth. Other works show OOPP variants that emphasize the importance of introducing OOP into HPC applications [74], [75], and thus keeping the benefits of OOP (without breaking too-many OOP principles) while preserving the efficiency required from modern scientific codes.

III. IMPLEMENTATION
SCALSALE is designed as a computational infrastructure for scalable multi-material and multi-physical numerical benchmarks. SCALSALE is written in Modern Fortran [76] (See subsection II-A) and implemented using simple yet practical design patterns from OOPP (See subsection II-B). Further implementation details and important concepts are presented.

A. High-performance Code Written in OOP
As discussed in section II, the foundations of SCALSALE paradigm is a balance between high programming effort and fast codes to easier to use and slower codes. SCALSALE as a benchmark was developed following general OOP principles, with exceptions that favor high-performance over OOP paradigms. Following are representative exceptions for each OOP main principle. 1) Encapsulation: Usually, only the object has the authority to access and modify its data attributes directly. The access to the object's data from other objects is done via public methods such as get/set. These functions might incur significant time and memory overheads since they require copying and setting the entire data attribute for each access. Since data attributes in scientific applications may be very large, this functionality is not desired. A workaround adapted in SCALSALE is to use Point to data functions, which return a pointer directly to the data attribute from outside the object. This eliminates the need to copy the data and serves as a "hand-shake" between the object that owns the data attribute with the code segment that accesses the data. Since cell boundary conditions on a given edge of the mesh do not change during the simulation, it might be convenient to initialize the specific cell boundary condition class at the beginning of the program and store an array with a polymorphic pointer to the specific cell boundary condition class for each edge of the mesh. A simple workaround would be to define a wrapper type with a single attribute, a polymorphic pointer, to the base cell boundary conditions class. An array of these wrapper types can implement the edge boundary conditions array. 3) Abstraction: Following this principle, objects should be exclusively responsible for their functionalities and data attributes. For example, it would be preferable for each physical quantity class in SCALSALE to contain a method called calculate. However, since each physical quantity's calculation should accept different quantities as parameters, and since the calculation depends on the actual physical/numerical scheme, these calculations are kept in a more global place. For example, Calculate density is placed in Hydro and not within the density class. 4) Inheritance: This principle allows classes to inherit from base classes and reuse or overload some basic functionalities from that base class. This property reduces programming time and requires more thorough computation and data analysis. However, since overloading functions come with an overhead cost, this functionality should be used cautiously. In SCALSALE there are scenarios in which inheritance is used and functions overloading is carried out, and in other cases in which a switch-case clause is used to determine the desired functionality (e.g., for determining whether to perform 2D or 3D rezoning).

B. SCALSALE as an Infrastructure
SCALSALE is implemented as two layers that are independent yet complementary to one another: the kernel layer and the application layer. This design provides a simple approach for expanding and modifying each of the two layers independently. An overview of the UML of SCALSALE is presented in Figure 3.
1) The Kernel: Handles the computational building blocks for the structured grid calculations. It consists of the data structures that are encapsulated in the classes Data3d and Data4d (as presented in Figure 3), and the parallelization schemes that are implemented in the Communication and CommParams classes (as presented in Figure 5, and will be explained in the following section). The interface between the data structures and the parallelization schemes is given by functions such as Point to data and Exchange blocking. Furthermore, the kernel layer contains third-party libraries, enums, linked list implementation, and more. 2) The Application: Handles all the physical-related computations such as thermodynamics, hydrodynamics, mesh rezoning, advection, and future models (as seen in Figure 3). Generally, each physical module should be associated with this layer and be implemented as an independent class. Associating physical modules with classes allows easily expanding these physical modules or overloading them with different schemes. Furthermore, every physical module utilizes different physical quantities represented by pointers to the relevant objects of physical quantities. The physical quantities and their related calculations further assist the encapsulation of the kernel layer from the physical models in the application layer, enhancing the simplicity and readability of both layers. Moreover, the numerical computations are written with minimal OOP intervention for minimal execution time reduction.

C. Communication Implementation
The parallelization scheme in SCALSALE distributes the mesh into cubes or tiles and uses ghost cells [77] for stencil calculations (in which each cell depends on its nearest neighbors). Each MPI process has 27, 8, or 2 neighbors in 3D, 2D, and 1D, respectively. When the processes synchronize in a 3D setting, O(N 2 ) while N is the problem size, values are sent to the closest face neighbors (presented in green in Figure 4 SCALSALE intent is to provide a scalable benchmark framework. Therefore, the synchronization overhead should be minimized as much as possible. To comply with this idea, non-blocking communication, and a communication topology were introduced to SCALSALE: 1) Non-blocking Communication: Naïvely, ghost cells should be synchronized across the ranks after each update of a physical quantity. The update process consists of sending and receiving MPI messages to the corresponding neighbors. The communication overhead increases as the number of ranks increases due to the higher probability of a delayed message in the system. A possible approach to diminish such a case is by introducing non-blocking communication to the code -validating that the received messages indeed arrived right before they are being used. The non-blocking communication grants the ability to perform other calculations between the two points of synchronization (send and receive). Thus, if an MPI message is delayed, the program performs other calculations instead of being idle, which minimizes the communication overhead. SCALSALE implements nonblocking communications via the asynchronous collective MPI operation Ineighbor alltoall.
2) Topology: In supercomputers, cores on the same node transfer messages via fast shared-memory communication, while cores from different nodes are connected via intercommunication devices such as Infiniband and Ethernet, which are slower by factors or orders of magnitude, respectively. Therefore, ranks that communicate frequently (for example, the green ranks in Figure 4) should be assigned to cores that reside in the same node -thus, lowering the communication overhead.
In SCALSALE, this idea is implemented via the communication topology function that was presented in MPI-3, MPI Dist graph create adjacent. This function creates a graph topology between the appropriated processes and initializes the communicator. Furthermore, the function receives a weight array that hints at the communication load between the ranks. In turn, the function may migrate the ranks (change their original identifiers) such that the ranks that heavily communicate will reside in the same node.
The parallelization scheme is associated with the kernel layer and is implemented via three classes (see Figure 5 a schematic overview of the three classes): 1) Optimized communication -Communication class: Handles and abstracts the communication operations. Each function implements a communication operation, for example, Send, Recv and Send Recv. These functions also handle the synchronization process of the ghost cells, which, as mentioned, is implemented via the MPI Ineighbor alltoall function [78]. 2) Topology and ranks -CommParams class: Initializes the communicator with the MPI Dist graph create adjacent function. Furthermore, the class handles the relevant parameters that describe the MPI messages, i.e., size of messages, the communication topology (communicator), and more. 3) Transparent communication -Data3d/Data4d class: Implements the basic data structure of SCALSALE. As such, it is also an inherently parallel data class that provides a transparent interface for exchanging and synchronizing data across the relevant ranks. Hence, encapsulating the parallel implementation from the rest of the program. The Data3d and Data4d classes provides three exchanging operations: a blocking operation (Exchange blocking), a non-blocking send operation (Exchange nonblocking) and a non-blocking receive operation (Exchange end). In addition, it contains the values of the data and the communication parameters via CommParams as a variable. The CommParams variable is provided by the physical quantity, thus, hiding the physical quantity type from Data3d and Data4d classes.

D. A Case Study -Stress Module
Physical attributes such as stress play an important role in describing the motion of solids in hydrodynamic codes. In non-compressible, visco-elastic, or visco-inelastic fluids, forces between the different layers of the fluid result in stress forces that oppose the fluid flow. The stress is strain and velocity dependent, influencing the fluid's momentum distribution and other hydrodynamic properties [80]. Hence, the stress-strain-velocity relation, which is material-dependent, is crucial for describing the motion of visco-fluids correctly.
As a case study, the following workflow describes how the stress module can be easily added to SCALSALE relatively. Firstly, adding new physical quantities, such as the stress tensor that inherits from the cell quantity base class, to the application layer (as seen in Figure 6a in lines 1-3). Afterward, implementing the yield and shear modulus calculations [81] to the application layer. The physical calculations are added as new procedures in the materials class as seen in Figure 6b from lines 4-44. In lines 40-41, the parallelization synchronization is done using a blocking manner. Finally, adding the physical stress calculation [82], and the correction to the acceleration due to stress, in a new stress model class in the application layer, as seen in the code in Figure 6c in lines 40-47.

IV. RESULTS
To evaluate the potential of SCALSALE as a scalable benchmark, it is compared to LULESH [83] -the wellknown mini-app benchmark. LULESH is a hydrodynamic code, highly optimized, that demonstrates excellent scaling capabilities. Moreover, both codes can simulate the same physical problem -3D Sedov-Taylor, providing comparable numerical workloads. Thus, it is the most suitable for comparing and evaluating SCALSALE.
Most (if not all) applications that aim to be executed in supercomputers are parallelized with MPI due to the need to scale enormously beyond a single node. However, the introduction of heterogeneous systems poses a challenge in obtaining maximum performance via MPI exclusively. As a result, the newer standards of MPI (especially MPI-3, the standard that is used in SCALSALE) supply comprehensive support and even inherently supports shared-memory environments, hence its popularity among hybrid parallelization paradigms (MPI+X) [84]. Nevertheless, evaluating the distributed parallelization scheme scaling capabilities exclusively (MPI) is a necessary step that must be taken independently to MPI+X. Therefore, although LULESH implements several parallelization paradigms, the MPI version was exclusively enabled and compared to SCALSALE. At the same time, SCALSALE could be easily extended to other paradigms without needing the transparent parallel class (for example, inserting an OpenMP directive in line 21 in Figure 6b). SCALSALE can simulate physical problems with Lagrangian or Eulerian rezoning (with an advection phase), contrary to LULESH which can simulate with Lagrangian rezoning exclusively. Thus, both rezoning must be considered to evaluate the full scaling capabilities of SCALSALE. Executing SCALSALE with Lagrangian rezoning provides a more comparable execution time to LULESH while Eulerian rezoning provides a more stressful and realistic calculation as the advection phase results in additional numerical calculations and synchronization points.
Another point of reference between the two physical schemes is that in Lagrangian rezoning, there are approximately 45 calls to a function in Communication i.e., 45 MPI collective operations per cycle, while Eulerian rezoning performs 60 calls per cycle. Each call to a function performs a communication operation of a single physical quantity. In contrary, LULESH performs approximately 5 calls to a similar function per cycle (basic MPI IRecv and MPI ISend functions), while each call transfers multiple physical quantity at once. Moreover, as SCALSALE is based on the multimaterial SALE scheme, it contains additional material-related quantities. As a result, SCALSALE not only performs more communication operations but sends more data per cycle. Nevertheless, due to the utilization of non-blocking collective communication and topology distribution via the MPI-3 standard, SCALSALE achieves comparable results to LULESH.
The weak and strong scaling tests are used to compare SCALSALE and LULESH. The strong scaling test is performed by creating a fixed size problem, considering it has a sufficient workload and increasing the number of cores. The weak scaling test is performed by creating a fixed size problem per core and increasing the number of cores. Both scaling tests are important to understand the scaling capabilities of the parallelization scheme and, in turn, the communication overhead of the code. The efficiency is calculated as follows: Weak scaling,

T ime1 n·T imen
Strong scaling whereas T ime 1 is the execution time of a single core, T ime n is the execution time where n is equal to the number of cores.
In Lagrangian rezoning, the amount of numerical operations per cycle is constant. Thus, the evaluation was carried out over only 20 cycles, without the initialization time (similar to [85]). In contrast, in Eulerian rezoning, the number of operations per cycle fluctuates due to the advection phase. Hence, 200 cycles were performed for more precise estimation.
The two codes were compiled with Intel's oneAPI [86] MPI Fortran (Modern Fortran 2018), and C++ compilers [87]. oneAPI provides wide support to multiple programming languages [88] and parallelization paradigms, especially for heterogeneous nodes, thus allowing further local implementation of MPI+X strategy using Intel's oneAPI OpenMP* [89]. The codes were compiled with no compiler optimization (O0) to allow a fair comparison of the raw scaling capabilities. The codes were executed on NegevHPC [90] on Intel Xeon Gold 6130 compute nodes. Each node has 32 cores and 128GB of RAM.

A. Strong Scale
For the strong scale testing, a 3D Sedov-Taylor problem with a mesh size of 480 3 = 110, 592, 000 (480 cells in each axis) was defined. The total memory consumption of the problem is 80GB in SCALSALE and 71GB in LULESH. Figure 7a presents the total execution time of the strong scaling problem and Figure 7b presents the strong scaling efficiency.
As expected, the execution time of LULESH is the shortest as it is a highly optimized dedicated Sedov-Taylor hydrodynamic computation software. Nevertheless, the execution time of SCALSALE with Lagrangian rezoning is comparable to LULESH.   Although Eulerian rezoning achieves the slowest execution time, it still presents excellent scaling capabilities even when normalized per cycle. Most importantly, Eulerian rezoning provides a broader range of hydrodynamic problems to be solved while maintaining the same speedup presented for the Sedov-Taylor problem.
A decrease in efficiency can be spotted at 1-8 cores due to the transition from a serial execution with no communication overhead to a distributed execution. Due to the nature of the parallelization scheme in 3D simulations, there is another decrease in efficiency at 8-27 cores, as 27 cores are the minimal number of processes to achieve the maximum amount of communication (exactly one process has 27 neighbors). Next, a slight decrease in efficiency can also be spotted at 27-64 cores for all three executions due to the introduction of a slightly slower medium that connects processes from different compute nodes. The final decrease in efficiency occurs at 216 cores (dashed line). For a fixed problem size, as the number of cores increases, the numerical workload of each MPI process decreases -i.e., the number of cells per MPI process decreases. Although the message size also decreases (message size is of the size O(N 2 )), it is less dramatic than the decrease in the numerical workload (of size O(N 3 )). Hence, the communication overhead outweighs the numerical calculations, and the efficiencies of both benchmarks decrease.
In addition, at 216-1,000 cores, due to the additional synchronization operations in SCALSALE, the margin between the two codes increase as the workload decreases faster than the communication overhead.
Nonetheless, SCALSALE presents excellent strong scaling capabilities in both Lagrangian and Eulerian rezoning compared to LULESH.

B. Weak Scale
For the weak scale comparison, the mesh of each MPI process was set to 120 3 = 1, 728, 000 (120 cells in each axis), similarly to [91]. A mesh size of 120 3 is equivalent to approximately 1.7GB in SCALSALE and 1.1GB in LULESH. As each computational node contains 32 cores, at full capacity, each node would consume up to 55GB in SCALSALE and 35GB in LULESH. Figure 7c presents the total execution time of the weak scaling problem, and Figure 7d presents the weak scaling efficiency.
Similar to the strong scaling, LULESH achieves the best execution time, while SCALSALE with Lagrangian rezoning achieves a comparable execution time. However, contrary to strong scaling, each MPI process computes the same amount of numerical operations in weak scaling. Thus, the efficiency does not exhibit the a decrease in the efficiency. Nevertheless, the efficiency does tend to decrease slightly due to the additional cores that need to communicate with one another.
Moreover, as the MPI implementation is generic and associated with the data structures and not the physical calculation, it has the potential to exhibit the same speedups on other problems in different domains. Thus achieving its targeted goal as a scalable benchmark framework.

V. CONCLUSION
In this work, the problem with existing benchmarks was tackled by introducing a new scalable benchmark framework named SCALSALE. The main objective of such a benchmark is to provide a more representative benchmark for scientific applications while maintaining simplicity. Contrary to existing benchmarks, SCALSALE is flexible and designed such that it is easy to introduce new physical models, all while maintaining scalable speedups and low execution time.
SCALSALE is based on the well-known SALE scheme and is currently capable of solving the 1D, 2D, and 3D hydrodynamic equations in a structured grid with multi-material ALE capabilities (with an advection phase). A code with multimaterial and ALE capabilities has the basic foundations for a code similar to hydrodynamic scientific applications.
SCALSALE is written in Modern Fortran, utilizing objectoriented design patterns that provide the infrastructure to further develop the benchmark as a framework and the fast execution times of Fortran to support the code as optimized and scalable. Furthermore, Modern Fortran provides a wellbalanced combination of fast execution times, especially for numerical computations, and sufficient support for objectoriented design patterns that allow easy modification and expansion of code.
In order to further support the code as a framework, SCAL-SALE is implemented with a two-layer design, the kernel and the application. The former handles the inherently parallel data structures (consequently, the physical quantities) that provide a transparent interface to the implementation of the distributed parallelization scheme. While the latter handles the numerical implementation and utilizes the parallel data structures to synchronize and keep up-to-date values.
SCALSALE parallelization scheme is based on the MPI-3 standard and utilizes two important features necessary for large-scale executions -non-blocking collective communication and the processes/cores topology. Moreover, the MPI-3 standard provides wide support for hybrid parallelization schemes. Along with the separation of the numerical computations and the MPI implementation, MPI+X schemes can be added easily.
To evaluate SCALSALE scaling capabilities, it was tested via the weak and strong scaling tests and compared to the well-known benchmark -LULESH. Despite performing more communication operations, SCALSALE achieves excellent and comparable scaling results compared to LULESH in both rezoning options. Moreover, as the parallelization scheme's implementation is independent of the numerical simulation, SCALSALE can exhibit the same scaling capabilities for other physical domains. Hence, SCALSALE achieves its targeted goal as a multi-material, multi-physical scalable benchmark framework.


ConTEXT: Context-aware Adaptive SMS Client for Drivers to Reduce Risky Driving Behaviors

Text messaging while driving has been considered a dangerous activity that may lead to serious injuries and trac fatalities. Several assistive technologies and solutions have been developed to simplify texting activity. However, due to inconsistent and complex interface design, lack of logical navigational order, lack of context, complicated text-entry layouts, and laborious activities, the existing texting-related activities can lead to accidents. This paper recognized the risky driving patterns using the real-time AutoLog application. Based on this risky driving behavior, we have proposed ConTEXT, a usable SMS client, to overcome the issues pertaining to the usability of textual activities on smartphones while driving. ConTEXT application is evaluated both empirically as well as through real-time AutoLog application. We have collected data from 117 drivers through a questionnaire. The results show that the data is found reliable also alpha scores for all factors seem internally consistent as it ranges from 0.70 to 0.79 which is good. Similarly, we have reported Principal Component Factor Analysis (PCFA), which was found satised and appropriate as the Eigenvalue for all the factors is greater than zero. Furthermore, results obtained from the AutoLog dataset show an improved user experience, better control over the touch screen with minimum visual, physical, and mental load.

Introduction
Using a smartphone while driving is a global phenomenon, which has been acknowledged as a major source of accidents [1]. Using a smartphone while driving can potentially cause drivers to take their eyes and minds off the road and their hands off the steering wheel [2]. Generally, the usage of a smartphone while driving adversely affects driving performance in different ways [3], including (1) impairing driver ability to maintain the road lane positioning; (2) impairing to maintain the predictable speed; (3) resulting in missing tra c signals; (4) resulting into longer reaction time to an unexpected hazard or event; (5) minimizing the functional visual eld-of-view; (6) resulting in to not keeping minimum following distance to a vehicle ahead; and (7) increasing driver mental workload. Despite known catastrophes, people are habitual of using a smartphone while driving [1]. For example, 0.66 million drivers use smartphones at a particular instant while driving [4]. However, using a smartphone while driving is discouraged and banned in most countries and societies due to the leading distraction for accidents [5]. The National Safety Council has reported that annually 1.6 million accidents and 0.39 million injuries are caused due to using a smartphone while driving [6].
Text messaging has been the main distracting and dangerous activity among all smartphone activities while driving [7] and has attracted considerable public and media attention. The sources have explored that crashes resulting in injuries and possible drivers' deaths are mainly due to text messaging while driving [8]. For instance, one experimental study suggests that younger drivers spend more than an hour every day talking on phones compared to a global average of 27 minutes, with 49% using mobile phones for text messages weekly [2]. The reason for text messages increasing frequency might be as it is cheaper than talking on the phone. Investigating the effects of using a smartphone on driving performance has been the prime interest of research communities. It has been found that young drivers engaged with a smartphone for text messaging spent up to 400% more time not focusing on the road and being inconsistent in lane position up to 50% [9]. A comprehensive study of 348 drivers has shown that 70% of the drivers initiate text messages, 92% read text messages, and 81% reply to text messages [10]. An-other research [8] illustrated that typing and reading text messages seriously affect eye movements, reaction time, lane positioning, stimulus detection, speed, and headway. Typing and reading messages while driving can adequately affect the driver's ability to redirect attention outside the roadway.
Technically, drivers have limited freedom to move their hands, heads, eyes, and minds from the primary task while driving. Using a smartphone while driving can in-crease cognitive overload and seriously affect eye movement, head movement, hand movement, reaction time, lane positioning, stimulus detection, speed, and headway [8]. On-Road research [11] has observed driver activities using a camera and found that drivers using a smartphone while driving could have 23 times more accidents. Similarly, taking eyes off the road for 2 seconds increases accident chances 24 times [12]. Typing and reading messages while driving can affect a driver's capability to redirect the attention to the outside roadway adequately. For example, National Highway Tra c Safety Administration (NHTSA) 2013 Cell Phone Naturalistic Driving has reported that interacting with texting activity takes 36.4 seconds on average [13]. Moreover, using a smartphone for text messaging diverts focus off the road for 23 seconds on average, meaning that a text message sent or received will take a driver's eyes off the road for more than half of a kilometer if traveling with the speed of 90 km/h [13].
The already developed smartphone applications for performing these activities are complex and time-consuming, which could be limiting a driver's safe driving. For example, SMS contains several further sub-activities, including composing, replying, reading, forwarding, searching, and closing. Therefore, using these complex applications may lead to excessive head and hand movement, off the road visual engagement, loss of concentration, and may increase cognitive overload. Similarly, these limitations could vary due to different driving contexts (i.e., road type, bad weather, tra c density, and night driving.). The complex nature of SMS applications may produce frustrations, which are timeconsuming and lead to risky driving, leading to accidents.
The idea of universal design advocates the usage of technology accessible for all [14]. Technology should serve people with special needs according to their requirements and limitations. This can be accomplished through a process of adaptation in assistive technologies [15]. However, the available applications used by the drivers are designed with the perspective of normal people to be used in normal routine life, which are not suitable for drivers due to their limitations. Researchers have emphasized developing adaptive, context-aware user interfaces based on the Human-Computer Interaction (HCI) guidelines [16][17][18][19]. The organization of SMS-related activities such as reading, writing, deleting, and forwarding requires considerable visual, physical, and mental attention. Most of the available solutions, such as Android Auto and CarPlay, use text-to-speech and speech-to-text metaphors instead of visualmanual interactions [20]. However, the researchers have suggested drivers still face issues while driving as voice interfaces require a little bit visual-manual demands, interior glance time, and higher mental demand than baseline drive [1]. In addition, cognitive demands are high for tasks using voice interfaces [21]. This paper proposed a context-aware adaptive SMS client for drivers based on the DriverSense framework [22]. The proposed solution is implemented in the android platform, namely which means contextual texting. The proposed solution aims to accommodate the ConTEXT user interface requirements according to different driving contexts. For example, the proposed solution will e ciently use a smartphone and vehicular sensing technology to capture and identify different driving contexts, including vehicle speed, tra c status, noise level, driver's preferences, and road status to adapt user interfaces automatically. The context-dependent simpli ed interfaces can be generated using adaption rules to improve the drive's safety by minimizing visual, manual, and cognitive interactions. The proposed solution may help the drivers manage the SMS activities in a speci c order, resulting in quick memorization of shortcuts, perception clues, and minimal visual and physical engagement. The proposed ConTEXT solution has been evaluated by 117 drivers by performing different tasks. Results showed an improved user experience in terms of minimal visual, physical, and mental engagements, task completion accuracy, less navigational loss, and automatic adaptation of user interfaces. In addition, the proposed solution is compared with smartphone native SMS interfaces leveraging a signi cant correlation.

Related Work
Researchers indicated that using a smartphone for text messaging while maneuvering a vehicle can impair driving performance and lead to road accidents [23]. Increasing the usage of a smartphone while driving leads to an increase the tra c accidents [24]. For example, the research found that distraction-related fatalities increased from 10.9% in 1999 to 15.8% in 2008 due to increased texting while driving [7]. The risk postured by text messaging while driving has attracted considerable research attention among legislators, automakers, safety researchers, and developers to come up with distracted-free solutions [23]. On one side, text messaging is a dangerous activity while driving, and on the other side, it lacks context-awareness that automatically detects the context and responds accordingly.
The term context-aware computing was rst coined by Schilit et al. in 1964 [25]. Since then, it has been popular and used continuously by researchers. According to Zimmermann et al. [26], the term "context" can include the location, time, and temperature. An-other researcher [27] de nes the context as the location of the user's, who they are with, the time of the day, the season of the year, and the temperature. Schilit describes the con-text-sensitive systems that are aware of and adapt the location of use, detecting nearby objects and people according to time [28]. Similarly, Ryan et al. [29] de ne context as location, temperature, time, and user identity. Some researchers [28,29] also described the context as the computing environment or the environment that the computers know about [30,31]. In this regard, phone context was particularly used to allow users to de ne personal con-text rules (e.g., switching to meeting mode when the phone lies still or face down) [31].
Researchers have investigated several ways to sense contextual and emotional information in instant messaging applications [32]. Recently wearable and physiological sensors have been utilized to uplift the effect of contextawareness in text messaging. Researchers have used various smartphone, environmental, and on-body sensors to sense different contexts such as location, temperature, and activities [32][33][34]. Similarly, the researchers have used text analysis to sense the context and emotions in chatting applications. For example, [35][36][37], have used text analysis to surmise the mood in instant messaging applications. Some researchers [38][39][40] have used facial recognition in text messaging applications to communicate in-chat emotional states via avatars and images. Furthermore, for contexts (i.e., location, temperature, and activities) sensing and detecting, the researchers have used various smartphone sensors, environmental sensors, and a combination of on-body sensors. For example, ConChat [41], a contextsensitive chat application, captures and integrates information from the environment using embedded sensors, such as several people in the room, room temperature, and currently running application. Hong et al. [42] used four different sensors: accelerometer sensor, physiological sensors, GPS, and smartphone sensors to extract and analyzed emotions, location, stress, weather, movement, and time of the day using dynamic Bayesian network in the ConaMSN messenger. However, these solutions suffer from a lack of real-time contexts and adaptation to minimize the drivers physical, visual, and mental engagements. There is a dire need to make the interaction simpli ed and automatic using an adaptive user interface paradigm.

Adaptive User Interfaces
The adaptive user interfaces use a context-awareness approach and generate new interfaces according to changes in environment, user preferences, and device usage [43]. This approach will help drivers personalize their smartphone user interfaces irrespective of their visual, physical, and cognitive limitations. ICCS [44,45], an in-car communication system intended to minimize driver distraction when drivers are engaging with their cell phones with the help of speech input and output. However, this system is not widely adopted because of not using the vehicle contextual information for generating automatic UI. The researchers from different domains have emphasized adaptive user interfaces and have designed easy-to-use, user-friendly, and accessible interfaces according to the HCI guidelines to solve real-world problems in the different domains [46]. For example, a system called "Supple System" [47] generates user interfaces for the users based on their tasks, preferences, and cognitive abilities. The ndings have shown that novice users can complete a complex task in less than 20 minutes using the proposed user interface. A multipath user interface system is developed, using XML to generate user interfaces based on current contexts [48]. The Egoki system is a user interface generator system designed for people with disabilities [49]. The purpose of the system was to recommend appropriate user interfaces to select multimedia content to the users based on their needs. The MARIA system proposed a model-based user interface description language to automatically generate user interfaces and customize for the different devices in run time [50]. The ODESEeW system is a semantic web portal that automatically uses the WebODE platform and an ontology application to generate a knowledge portal of interests [51]. For example, it generates different menus based on the users' interests and adjusts the visibility of contents according to the users' needs.
A generic interface infrastructure has been presented in the MyUI system, aiming to increase accessibility through an adaptive user interface [52]. The MyUI provides a run-time adaptation to user preferences, device usages, and work conditions. An XML-based pervasive multimodal user interface framework is proposed, which helps the designer to design a wide range of platforms that support multi-languages [53]. The aim was mainly on how to change the monomodal web-oriented environment of a simpli ed interface for a variety of platforms. The ViMoS system has proposed a context-aware framework to provide information about adapted embedded in the user devices according to the environment [54]. The system is composed of a set of available widgets to render different data patterns on various visualization techniques to adapt and customize visual layouts in the available area. In this research work, we have used the context-awareness and the adaptation approach to simplify the interaction between driver and smartphone.

Assistive Technologies
Different assistive technologies (as shown in Table 1) have been used to reduce distractions. The main aim of these technologies is to simplify smartphone functionalities [1,20]. This approach is aimed to reduce visual interactions by simplifying driver interactions with smartphone applications. For example, a smartphone-based system, namely Safe Driving App: Drivemode, provides a simpli ed yet effective interface to smartphone usages and minimizes visual and motor demands by providing shortcuts to the apps and using voice commands for interactions. Following the idea, several smartphone systems are developed to support safe interaction between driver and mobile phones, such as Car assistant, is an external device linked with the smartphone via Bluetooth, providing the features of text messages, calls, and operate music without physical interaction by using voice commands or gestures. However, these solutions can result in excessive cognitive overload due to voice commands as discussed earlier, off-road visual engagement, and navigational complexity [68]. Furthermore, the latest study [20] found no empirical evidence regarding these applications in minimizing the risk of crashes. The existing user interfaces have numerous challenges due to heterogeneity issues. The heterogeneity can broadly be de ned as the multiplicity of the driver, input/out capabilities, environmental conditions, contextual variability, interaction modalities, and computing platforms. The multiplicity of the drivers is based on their physical, visual, and cognitive limitations.
These solutions are vital by considering the leading cause of deaths due to smartphone usages. However, these solutions still have certain limitations which might not be excluded. For example, operating the smartphone using voice commands still requires more visual-manual demands, interior glance time, and higher mental demand than baseline drive [1]. Similarly, this approach may fail to reduce cognitive overload in case of excessive tra c [44,45].
Privacy could also be an issue when using voice commands, especially when other passengers are in the vehicle.
Moreover, installing external hands-free systems is often a barrier due to usability, cost, and lack of practicality [20].

Context: A Usable Sms Client For Drivers
The ConTEXT SMS client has been named after the idea of contextual texting. Con-textual texting means texting based on various factors, including weather, location, vehicle speed, and time. The motivation behind the design of this solution was assisting the drivers by automatically managing their textual activities. We designed a driver-friendly SMS client to minimize distraction as texting using a handheld smartphone frequently requires physical, mental, and visual engagements. Usually, most people prefer to use the default messaging applications for text messaging, which are not according to the NHTSA guidelines. The default messaging applications consist of many activities that are either redundant, repetitive, complex, and require a longer route to follow. These applications are designed with the intention of being used by people in their daily routines. However, in driving scenarios, the usage of these applications is not suitable. The context-aware adaptive UI paradigm can potentially solve the distractions and increase the usability of a smartphone texting activity while driving. Figure 1 presents the schematic diagram of the proposed solution. The methodology mainly focuses on driver interaction, sensors data sources, creating the models, adaptation rule manager, and adaptive user interface generator.

Logging the Driver Interactions
In the beginning, the driver input could be captured through touches, gestures, or voice commands and stored in the user interactions-log for further operations. These interactions, i.e., a number of inputs or activities on a smartphone, could be extracted automatically based on driver preferences, the context of use, and the environment. Data could be collected in real-time through different sensors, i.e., gestures, vocals, and touches, while the driver interacts with the system and stored in the interaction log.

Sensors Data Sources
Sensory input could be captured from different devices, including the vehicle. For example, sensors can obtain information from various sensors, including Global Position System (GPS), accelerometer sensors, light, noise, and gyroscope. The GPS is used to nd the location, altitude, direction, speed of the car. Information from online sources, i.e., web services, are also used to obtained weather information, temperature, speed of the wind, and humidity. The vehicular data could be obtained from the Controller Area Network (CAN) using the standard Onboard Diagnostic (OBD-II) port [23,55]. This data will be further processed to obtain meaningful full context, and based on contextual values, a new mode of interaction or user interface will be generated for the driver while driving.

Generating Information Models
Different models (i.e., driver, vehicle, device, and context models) have been created, which could be considered the baseline for generating adaptive user interfaces. The driver model contains information related to driver demographics, experience, sensing power, and cognition. Similarly, the Vehicle model stores information related to vehicle data, i.e., type of vehicle, type of transmission, capacity, safety features, and types of telematics. Type of vehicle includes the company of the vehicle model, and transmission system involved automatic or manual gear system which will also affect the interaction with the system. Capacity can be modeled as the number of maximum passengers in the car. Safety features include brake assist, automatic emergency braking, and adaptive cruise control.
The device information could be stored in the device model, e.g., device type (i.e., smartphone, Smartwatch, or other infotainment systems), screen size, screen resolutions, display type, interaction mode, input/output capabilities, and connectivity. This information is essential for the e cient adaptation of the user interface. Furthermore, the user preferred mode of interaction also contributes to the better user interface adaption. Context model stores information about different contexts such as road condition, weather, noise, light, temperature, location, time, speed, and tra c condition. This contextual information could be collected using smartphone sensors, vehicle sensors, and other online sources. Once the contextual model is built, it will be passed to the adaptation rule manager.

Generating Adaptive UIs
The information obtained from the models can be input into the adaptation module, where the adaptation rules can be applied to generate new user interfaces. The adaptation rules can be speci ed in the form of events, conditions, and actions [56]. This approach has been used by many researchers, for example [57,58]. The event part of the rule should be composed of the associated event whose manifestation activates the evolution of the rules. The condition part comprises a Boolean condition, which needs to be satis ed to execute the action part. For contextual texting, we have proposed the following different adaptation rules. These adaptation rules have been used in a real-time android application called ConTEXT. The proposed application will handle the drives texting activity according to the different driving contexts. The interfaces and mode of interaction of the ConTEXT application will be automatically changed according to different vehicle speed variations, environmental conditions, and road conditions. For example, if low speed is detected, short messages will be visible with adjustable font size, whereas lengthy messages will be placed in the reading later queue. When medium speed is detected, short messages will be allowed through vocal modality. However, an auto-reply message will be generated for the lengthy and unknown contacts. The SMS reply will be divided into some categories in low and high speed, where the driver will choose an option through voice or touch. For example, an SMS reply could be shown in three parts: standard reply (I am driving), personal reply where you can write a short message or just press an auto-reply button, and fun reply (gossip type message from friends which may be skipped). Similarly, when high speed is detected, an auto-reply message will be generated for short and long messages and saved and unsaved contacts. The threshold values for the different contexts are presented in Table 2.

Rule 1
If the vehicle speed reaches 100km/h or more than 100km/h, then the mode of interaction for the SMS needs will be changed to auto-reply Rule 2 If the vehicle speed reaches low-speed (e.g., 30km/h), then short messages will be visible with adjustable font size, and lengthy messages will be placed at reading later queue. Rule 3 If the vehicle speed reaches medium-speed (e.g., 60km/h), short messages will be allowed to read through vocal modality, and lengthy messages will be placed at reading later queue Rule 4 If the vehicle speed is low, the driver will choose an option among the three parts (Standard Reply, Personal Reply, and Fun Reply) Rule 5 If the vehicle speed is high, then auto-reply message will be generated for short and long messages Rule 6 If the environmental noise is 25 decibels and speed is low, then the mode will be switched to graphical mode

ConTEXT Prototype
ConTEXT is implemented as an Android application to be installed on any smartphone operating system. ConTEXT is primarily tested on Android-based smartphones. However, it can be equally tested and installed on any Android-based infotainment system. Figure 2 shows the screenshots of the ConTEXT application. The ConTEXT application is developed with the intention to keep track of all the design considerations, including privacy and security, energy consumption, and speci cally the accessibility. ConTEXT application is exible to accommodate the new technologies related to accessibility. The ConTEXT application runs as a service in the background and is automatically launched when the driver starts driving. The application will only be activated when an SMS is received while driving. Reading and writing SMS is based on different driving contexts. For example, short messages with maximum adjustable font size will be displayed when the vehicle's speed is low. Similarly, the driver may also choose the text to speech option by simply clicking the speaker icon. It is to be noted that there is only minimum interaction of the driver with the ConTEXT application at low speed.
The ConTEXT application will intelligently have addressed the SMS reply activity as it diverts focus off the road for maximum time. For example, the auto-reply message will be initiated in case of high speed and medium speed.
Similarly, the SMS reply will be divided into three parts i.e., standard reply, personal reply, and fun reply for lower speed. In Standard reply, the driver may just click this option, and an auto SMS will be sent automatically to the receipt. In case of a personal reply, the driver may have an option to write a short message or reply using the voice option. Similarly, in a fun reply, the message may be skipped.

Recognizing Risky Driving Patterns
The AutoLog application has been used to log data about drivers' interactions with common smartphone applications to recognize drivers' risky driving behavior. The logged data containing information about different operations carried out by smartphone applications, such as the number of activities used to perform tasks, number of input taps, etc. The common smartphone applications include Calls, SMS, Email, WhatsApp, Navigation, Weather, etc. As discussed earlier, the applications and their interfaces are designed from the perspective of a normal user as the number of activities is redundant, repetitive, has a complex structure, long route to follow, etc. The logged data obtained from smartphone native interfaces are analyzed and compared with the data obtained from ConTEXT for using common smartphone activities.

Recognizing Steering Wheel Variations
The datasets also captured steering wheel control variation while driving. The steering wheel control has been analyzed while the driver performed smartphone activities both in smartphone native interfaces and ConTEXT. A comparatively high steering wheel variations have been observed when drivers performed common activities such as SMS using smartphone native SMS interfaces. However, signi cantly minimum steering wheel variations have been observed when the drivers performed the same activities on ConTEXT. A comparison of the steering wheel control variations while receiving voice calls is depicted in Fig. 3.

Recognizing Speed Variations
The speed variations data is also captured while performing activities like attending the call, reading, and replying to text messaging using both smartphone native interfaces and ConTEXT interfaces. The signi cant speed variations are observed when the drivers read and replied to text messages on smartphone native messenger. The speed is found degraded from approximately 80km/h to 50km/h. On the other hand, the data extracted from the DriverSense dataset have shown less speed variations than smartphone native interfaces. A comparison of the speed variations is depicted in Fig. 4.

Recognizing Throttle Position
The throttle position was captured and analyzed. Comparing with call logs we found that using the smartphone during the greater than average (22.54) throttle value have higher distractions and may be extremely dangerous. The reason is that more throttle value means, more engine Rotation Per Minute (RPM). The throttle values are depicted in Fig. 5.
The RPM values are depicted in Fig. 5. The average of the engine RPM is 1738.82. Figure 5 shows that the more throttle value means the more engine RPM. Hence, attending the calls or reading textual data at higher engine RPM or throttle value may increase the ratio of the incident with savior damages to driver and vehicles.

Results
The main theme of this contribution was to provide an adaptive and contextual prototype of an SMS client for the drives that can be effectively used on smartphones and Head-Up-Displays (HUD). The proposed solution may help drivers in managing their textual activities according to different driving contexts. The usability of the design has been evaluated using standards HCI usability and accessibility parameters. The proposed solution is also evaluated empirically using a questionnaire and a dataset created using the AutoLog [22,59,60] application. We have extended the HCI model in our proposed interfaces and tested different parameters, including the degree of accuracy, level of easiness, and user satisfaction.

Empirical Evaluation
The ConTEXT has been evaluated through an empirical study on drivers. while some (i.e., 20.51%, n = 24) use voice-based interfaces, e.g., Google Assistant. The participants daily traveling frequency was 66.67% (n = 78), and random or sometimes traveling frequency was 33.33% (n = 39). We have normally modeled the purpose of traveling as an employee (workplace) mostly, shopping mostly, and business mostly. According to traveling type, the participants, 57.26% (n = 67), were employees mostly, 25.64% (n = 30) were shopping mostly, and 17.10% (n = 20) were business mostly.

Evaluation Process
We have evaluated the proposed methodology using the real-world ConTEXT and AutoLog application. These two applications have been installed on participant's smartphones. We have educated the respondents that the AutoLog application will work as a service in the background and will collect and record the driver's smartphone activities, including activity duration time, activity completion time, changes in vehicle dynamics such as variations in speed, steering wheel, braking, and accelerator), and environmental data such as tra c status, location, weather, temperature, road condition, and light intensity. The respondents were assured that the data would be automatically anonymized before storing it in a database to avoid privacy disclosure. Similarly, it has further clari ed to the participants that the logged data will only be used for the research evaluation. After using the proposed solution for three months, the respondents were asked to ll a questionnaire to investigate the usefulness of the ConTEXT application.

Results And Discussion
We have used STATA, SPSS, and Excel to carry out different tests and analyzed the statistical data. In the initial phase, we used descriptive statistics to report the percentages and frequencies of the latent variables. We have also performed a cross-tabulation with cell percentages and cell Likelihood Ratio Chi2 tests. Similarly, a Cronbach alpha test has been carried out to check the reliability scales of the variables. We have also performed factor analysis as the

Empirical Observations
The participants' responses have been complied with and described each latent variable in the separated line graph. It should be noted that each latent variable contains several different questions, and participants have been educated to select one of the ve Likert Scale options ranging from 1 to 5. As shown in Fig. 6, the participants have a positive attitude towards using the ConTEXT application as most of the reported scales are higher than 3, which means that the idea is good and they have a positive attitude.
In terms of the System Usability Scale, the participants have been asked to answer seven questions. According to the analysis, the participants were con dent and happy to use the system frequently as they reported that the system is not too complex and components are well integrated, and they do not need a technical supporter to operate. The participants also showed their responses about the complexity and learnability of the systems. As shown in Fig. 7, maximum participants reported scales 1 and 2 (see bluish lines), which seems that the system is not too cumbersome, and they do not need other things to learn before operating the proposed systems.
One of the important aspects of safe driving is the cognitive load, as performing concurrent activities while driving may increase the cognitive load, leading to accidents. Most texting activities could be performed automatically so that it will not increase the drivers' cognitive load. As shown in Fig. 8, maximum participants have reported that the ConTEXT application has been designed to make every icon and description easy to interpret. Only a few participants have reported that it does not provide aids for entering hierarchic data.
Participants have reported that using ConTEXT as a client SMS application will minimize the visual interaction as most activities would be performed automatically in the background. As shown in Fig. 9 the scales of 4 to 5 (see. Figure 10). According to the participant's responses, the interaction has been minimized due to automatic responses and adaptation.

Factor Analysis
We have conducted the Cronbach alpha test to check the internal consistency and reliability of the measurement items. As shown in Table 3, the obtained alpha score of all factors seems to be consistent and reliable as it ranges from 0.70 to 0.79, which is considered good [65,66]. According to our results, the PCFA was found satis ed and appropriate compared to Iterated Principal Factor Analysis, Factor Analysis, and Maximum Likelihood. As shown in Table 4, the retained factors in PCFA express the contribution of variations by a speci c factor in total variations. The Eigenvalue of all factors is greater than 0, which have been considered as important factors. Total factors have been retained and contributed to total variation as no factor has a negative Eigenvalue.   These values indicate that the estimated covariance metrics of the observed model and the proposed model are found signi cant and good. The estimated structure model values and their recommended ranges are depicted in Table 5.

Observation through AutoLog Dataset
We have used the AutoLog application for evaluating the ConTEXT application. The AutoLog data about the ConTEXT during the normal use has been compared and analyzed with a dataset obtained from the Smartphone Native Messenger application. After evaluation, we have concluded that texting via ConTEXT requires comparatively less mental, physical, and visual attention than a native messenger. ConTEXT has shown comparatively minimum efforts, a minimum number of input taps, and touches. The main reason of driver's minimum engagements is that ConTEXT intelligently categorizes the SMS activity according to a different context. For example, composing an SMS by typing is not allowed in any context. However, the voice option will only be available for the drivers if they are driving at a very low speed. Similarly, this option will be disabled in case of medium or high speed. A voice interface will only be visible to drivers in case of low and medium speeds. However, at high speed, SMS will be stored at reading later queue. There are three categories in SMS reply (1) Standard reply, (2) Personal Reply, (3), and Fun Reply. In conclusion, the ConTEXT application requires no extra efforts, driver's engagements to perform a textual activity. On the other hand, as shown in Table 6, smartphone native interfaces are complex and require maximum input taps, touches, and efforts. Similarly, the ndings reveal that ConTEXT requires minimum physical, visual, and mental attention compared to Native Messenger.

Conclusions And Future Work
The available SMS applications are speci cally designed for ordinary people to use in their daily routine lives and do not explicitly meet drivers' requirements. While driving, drivers cannot afford to access the touchscreen for interaction as eyes off the road for two seconds increase the chances of accidents to twenty-four times. Due to this fact, the use of SMS applications is challenging for drivers. The proposed ConTEXT application has addressed these issues by adapting the user interfaces according to the different driving contexts. The proposed solution will e ciently use smartphone and vehicular sensing technology to automatically capture and identify different driving contexts, including vehicle speed, tra c status, noise level, driver's preferences, and road status, to adapt user interfaces automatically. The context-dependent simpli ed interfaces can be generated using adaption rules to improve safety by minimizing visual, manual, and cognitive interactions. The proposed solution is evaluated both empirically and using the AutoLog dataset. The results indicate that ConTEXT will help drivers manage textual activity with limited physical, visual, and mental interventions.
In the future, we intend to adapt the UI to the driving mode to include applications of machine learning. We are also planning to incorporate more adaptation rules to enhance the functionality of the proposed solution further.

Declarations
Funding Statement: There is no funding for this research Con icts of Interest: The authors declare that they have no con icts of interest Attitude of participants after using the ConTEXT Visual engagements while using the ConTEXT Figure 10 Physical engagements while using the ConTEXT