The Gap between Visualization Research and Visualization Software (VisGap) (2020) C. Gillmann, M. Krone, G. Reina, T. Wischgoll (Editors) Lessons Learned from Large Data Visualization Software Development for the K computer Jorji Nonaka1 and Naohisa Sakamoto2;1 1RIKEN R-CCS, Operations and Computer Technologies Division, Japan 2Kobe University, Graduate School of System Informatics, Japan Abstract High Performance Computing (HPC) always had a close relationship with visualization as we can remember the landmark report on “Visualization in Scientific Computing”, which was credited to have coined the term Scientific Visualization (SciVis). K computer, a Japanese flagship HPC system, appeared in 2011 as the most powerful supercomputer in the Top500 list, and as other similar HPC systems in that ranking, it was designed to enable “Grand Challenge” scientific computing with unprece- dented scale and size. RIKEN Center for Computational Science (RIKEN R-CCS) operated and provided the K computer’s computational resources to the HPC community for almost 8 years until it was decommissioned in 2019. Considering that most of the scientific computing results were publicly presented in the form of visual images and movies, we can infer that the SciVis was widely applied for assisting the domain scientists with their end-to-end scientific computing workflows. In addition to the traditional visualization applications, various others large data visualization software development were conducted in order to tackle the increased size and amount of the simulation outputs. RIKEN R-CCS participated in some of these development and deployment dealing with several environmental and human factors. Although we have no precise statistics regarding the visualization software usage, in this paper, we would like to present some findings and lessons learned from the large data visualization software development in the K computer environment. CCS Concepts • Human-centered computing ! Visualization systems and tools; • Applied computing ! Physical sciences and engineer- ing; • Computing methodologies ! Parallel computing methodologies; 1. Introduction Visualization Environmental Factors RIKEN R-CCS is a leadership-class Japanese HPC Center, estab- Developers lished in 2010, and has led the co-development of the two most Hardware Environment recent Japanese flagship supercomputers, the K computer decom- - CPU and GPU missioned in 2019, and Fugaku expected to be operational in 2021. ISA Compatibility The K computer was a SPARC64-based HPC system, and origi- Human Factors nated two generations of commercial HPC systems based on such Skills and Minds - Users x86 Post- CPU architecture (Fujitsu PRIMEHPC FX-10 and FX-100), which Processing were installed at different HPC sites throughout Japan. RIKEN R- Ease of use K computer Server - Customizers (SPARC64) (No GPU) CCS was responsible to operate and to provide computational re- Install and Setup sources to the designated HPC users, or more specifically, to the - Partners Software Ecosystem Co-development - Compilers, Libraries, and Tools Japanese HPCI (HPC Infrastructure) user community. It is worth Supported Versions noting that we just provided the computational resources with no Targets Availability of OSMesa - Specialized control about how these resources were used. Thus we have no pre- 2D and 3D Operational Policies cise statistics about the software utilized by the users. We gathered - General public Local FS - Access some information from different sources, and found that several ef- Mostly 3D Animation Compute System Global FS forts have been done on the porting and development of different Immersive I/O System large data visualization applications, libraries, and tools. We also participated in the development and deployment of some of them, Figure 1: Some examples of human and environmental factors that and we listed, in Fig. 1, some of the external factors that influenced can influence the visualization software development. in the visualization software development process. c 2020 The Author(s) Eurographics Proceedings c 2020 The Eurographics Association. DOI: 10.2312/visgap.20201113 https://www.eg.org https://diglib.eg.org 78 J. Nonaka & N. Sakamoto / K computer Visualization Software Development We could perceive that the specialized hardware environment, in addition to the restrictions brought by the operational policy (usu- Initial Viz Environment Ray Tracing ally specific to each HPC site), have the potential to impact the Fujitsu LuxRender smooth visualization software development, thus impeding to pro- Visualization Library vide the required visualization capabilities. For the specific case of the K computer environment, we can cite the CPU architec- • AVS Data HIVE (SURFACE) ture (SPARC64) with no ISA compatibility with other traditional • O-PBR • GLES 2.0 compatible API CPU; the provided set of customized compilers, libraries, and tools • 2-3 Swap • GLSL AoT compilation • In situ API with low version number and without including the OSMesa func- tionality; the runtime access policy to the compute nodes and I/O system that impedes interactive in situ or in transit processing ca- PBR pabilities [BAA∗16]. We should also take into consideration that • different users may have different expectations and goals regarding O-PBR • I-PBR visualization. We grouped them into three categories: Users those • Integrated Full Nodes Power-of- two just expect the visualization tasks being as simple as possible; Cus- • O-PBR & I-PBR (82,944) (65,536) tomizers as a group of skilled people that works by their own using available software and information; and Partners as a group of peo- Figure 2: Initially available visualization environment, and some ple who considers the visualization researchers as collaborators for of the attempted visualization software development. assisting their visualization and analysis tasks. We probably cannot generalize due to the small universe of sam- ples, but we also observed that the objective of the visualization 3. Actual HPC Users’ Needs (Fugaku Environment) tasks as well as the target audience of the visualization results have Before discussing some of the large data visualization development a great influence on the expectations regarding the visualization ap- done for the K computer environment, we would like to present plications. For instance, there were cases where 2D plots or a sim- a more clear picture about the actual Japanese HPC users’ needs ple slice rendering were considered sufficient when targeting aca- regarding visualization. It may sound like just an excuse, but we demic publications, but CG-like rendering and effects as well as im- have almost no interaction with the HPC users in daily usage, and mersive rendering were desired when targeting non-researchers and the main communication channel was the Help Desk, but the vi- general public. In this paper, we will focus on the SciVis [McC87] sualization related contacts was almost none, and as a result, we oriented visualization applications for assisting the end-to-end sci- have not much information about the visualization related activi- entific computing workflow, and those that use partially or totally ties done by the K computer users. However, the Fugaku super- the HPC computational resources [BCH12]. computer development program made a survey questionnaire, with the Japanese HPCI (High Performance Computing Infrastructure) 2. K computer Environment users, about the list of open source software expected to be avail- able in the future Fugaku HPC environment. Table1 shows only the The main characteristic of the K computer is probably the SPARC visualization related software extracted from the entire list shown (Scalable Processor Architecture) [MMMA11] based CPU with in [Ish19]. From this list, we can infer the existence of groups no instruction set compatibility with other HPC oriented CPU ar- with different expectations and target goals: “Users” group look- chitectures at that time, such as the IBM PowerPC and Intel x86. ing for ease of use visualization applications; “Customizers” group The K computer was a massively parallel HPC system composed looking for libraries and tools for integrating with their simula- of 82,944 CPUs (or Nodes) for the computation, and the hard- tion codes by taking into consideration the in situ API such as the ware developer (Fujitsu) provided a customized set of compil- ParaView-Catalyst [ABG∗15], VisIt-libsim [WFM11], and In situ ers, libraries and tools for the software development, and among PBR [KNI16]; and the “Developers” group looking for libraries and them, we can cite the GCC 4.8.5 based Fujitsu compiler suite tools for their own visualization application developments. From and the lack of the Mesa library (OSMesa functionality). Instead this list, we will discuss in the next sections, the PBR and OSMesa of providing the Mesa library, Fujitsu opted to provide a “Visu- based development done for the K computer in addition to the Ray alization Library” [OMKO12] by implementing a parallel version Tracing approach. of the Object-based Particle Based Rendering (O-PBR) described in [SNKT07], and using the 2-3 Swap [YWM08] parallel image composition (Fig.2 ). It provided an AVS field (structured data) Table 1: Summarized list of the desired visualization oriented open and UCD (unstructured data) format data loader for the traditional source software for the Fugaku environment. post-hoc visualization on the K computer, and also provided an in- Probably “Users” Probably “Users” “Developers”