FRIEDRICH-ALEXANDER-UNIVERSITAT¨ ERLANGEN-NURNBERG¨ INSTITUT FUR¨ INFORMATIK (MATHEMATISCHE MASCHINEN UND DATENVERARBEITUNG) Lehrstuhl f¨urInformatik 10 (Systemsimulation) waLBerla: Visualization of Fluid Simulation Data with POV-Ray Simon Bogner, Stefan Donath, Christian Feichtinger, Ulrich R¨ude Technical Report 09-13 waLBerla: Visualization of Fluid Simulation Data with POV-Ray Simon Bogner, Stefan Donath, Christian Feichtinger, Ulrich R¨ude Lehrstuhl f¨urSystemsimulation Friedrich-Alexander University of Erlangen-Nuremberg 91058 Erlangen, Germany [email protected] December 14, 2009 Contents 1 Introduction 3 2 Feature Outline 4 3 File Structure and Output Directory Structure5 3.1 Scene Composition........................................6 3.2 Resources and Visualization Types...............................6 4 pe Objects 9 5 DensFields 10 5.1 File Structure........................................... 10 5.2 Usage............................................... 10 6 CellFields 17 6.1 Usage and Output File Structure................................ 17 6.2 Porous Medium Example.................................... 17 7 Free Surface Visualization 20 7.1 Free Surface Extraction..................................... 20 7.2 Usage and Examples....................................... 20 8 Conclusion 23 1 Introduction The waLBerla framework is a versatile, parallel fluid solver based on the lattice Boltzmann method (LBM). The acronym waLBerla stands for widely applicable lattice Boltzmann solver from Erlangen. Besides simulation of simple fluid flow, it supports a variety of different applications involving multi-phase and free surface flows and particulate flows with fully resolved, moving particles [DGF+07, GFI+08]. To enable efficient analysis of the simulation outcome, waLBerla features different means of data visualization. Parallel generic modules [GDF+07b] enable plotting of computed values into XMGrace-compatible graphs and writing of arbitrary, cell-based data to file formats of the visualization tool kit (VTK) [VTK09] that can be viewed and further analyzed by VTK-based tools like ParaView [Par09]. Besides value-based validation, a realistic visualization of the flow and its characteristic quantities is important and of avail because human intuition is best proof for nature's behavior. Consequently, waLBerla has been extented by a generic module for output files that are readable by POV-Ray, which is a well-known ray tracer tool [oVPL04]. Thus, the motion would become visible by rendering images of different time steps with the POV-Ray raytracer. Initially developed to only visualize particulate flows, this waLBerla module has been enhanced in order to be compatible with free surface flows, too, and be able to visualize scientific relevant data like densities, velocities and forces. This report gives a detailed insight into the technical realization of a flexible interface between waLBerla and POV-Ray, using the POV-Ray scene description language (SDL). 3 2 Feature Outline WaLBerla can create special output data using the POV-Ray scene description language (SDL). SDL is a language used to define a 3-dimensional world consisting of various geometrical shapes, light sources, etc... The following list gives a rough summary of the output options currently provided by waLBerla. DensField: A DensField is a 3-dimensional array of floating point values. As described in [GDF+07a], waLBerla holds the simulation data in Fields. WaLBerla can be instructed to write out the values of any field of type ScalarField<Real> or type VecField<Real> (DensField1 and VelField, in which waLBerla stores the macroscopic values of density and fluid velocity, are also possible) in an axis-aligned subregion as a DensField. Typical application: Visualization of the velocity or density profile of a flow. CellField: CellFields can be used to visualize the waLBerla FlagField. A CellField is thus an axis-aligned subregion of the FlagField. Usually one is interested in cells of a certain flag state only. Typical application: Visualization of the geometry of a porous medium. FreeSurface: If a free surface flow is simulated, the behavior of the free surface may be visualized either by its surface normals, which can be shown as glyphs, or by a triangle mesh resembling the free surface. Typical application: Visualization of two-phase free surface flows, such as foams. Obstacles: The various kinds of obstacles (i.e. particles, walls, etc.) supported by waLBerla (see [GDF+07b]) can be visualized. Typical application: Visualization of particle suspensions. Ray tracing is a powerful way to create images from spatial information, but because of its computation- intensive nature it is far from being interactive. In spite of this limitation, one of the main design goals was to provide the user with as much flexibility as possible, i.e., to provide the output not only in a format adapted to POV-Ray, but also well-readable and modifiable for the user. The SDL files generated by waLBerla can be edited to adjust the output files to change the properties (point of view, light sources, colors and textures of objects, etc.) of the final images. The following section treats the activation of POV-Ray output via waLBerla parameter files. An overview of the most important output files and file dependencies is given. Also the incorporation of external resources, e.g. textures, to a visualization is explained. For the actual usage and visualization options of DensFields, CellFields, FreeSurfaces and Obstacles, respectively, own sections have been devoted. It is suggested to the reader to take a look on the next section carefully and then continue with a section of his interest. 1Name coincidence: There is also a waLBerla-internal scalar field called DensField! 4 3 File Structure and Output Directory Structure In order to facilitate POV-Ray visualizations, the various output options have been integrated in the waLBerla parameter file. A povray block has to be specified by the user in order to activate and control the POV-Ray specific output. Listing1 exemplarily shows a typical povray block that would create an output directory named /simdata/povray. In the output directory waLBerla creates the directory structure shown in Fig.3. Figure 1: Directory Structure ./dat contains the data to be rendered /0 objects/data written by process 1. /1 objects/data written by process 2. ... ./plane velocity planes (not subject of this report) /0 objects/data written by process 1. /1 objects/data written by process 2. ... ./png empty output directory for final images rendered by POV-Ray ./res include files for POV-Ray /resource1.inc user-declared include file 1 /resource2.inc user-declared include file 2 ... ./Globals.inc global declarations and scene composition for the POV-Ray visualization ./Cam0.pov Camera 0 ./Cam1.pov Camera 1 ... ./GenerateMPG.py a python script that calls FFmpeg to create animations from rendered images. ./GeneratePOV.py a python script that calls POV-Ray to render the final images. Inside the povray block, the spacing keyword specifies how often data is written to the ./dat direc- tory in the output directory specified by filename. Since a simulation may run on multiple processes in parallel, each process will store its data in a subdirectory named by the process number. All objects (DensFields, obstacles, etc.) for the visualization are stored in these subdirectories, depending on which process the respective data is computed. For more details on waLBerla parallelization, please refer to [GDF+07b]. The data output files of different time steps for each object are numbered in subsequent order starting from zero - irrespective of the setting of the spacing variable. To eventually compose the written objects to a scene, waLBerla creates the file ./Globals.inc, which will be described in the next subsection. Inside the povray block, one ore more cameras have to be defined in the form of camera blocks. For each camera, individual light sources can be added to the scene. Each camera block leads to the creation of a file ./Cam<number>.pov, where number is substituted by the number of the camera. The camera file automatically includes the scene file ./Globals.inc. For more information on cameras and light sources please refer to the POV-Ray documentation [oVPL04]. Additionally the user can instruct the inclusion of external POV-Ray resources to the file ./Globals.inc 5 Listing 1: Povray block example povray f spacing10; //writedataevery10.thtimestep filename /simdata/povray; // directory to create file −structure in camera f p o s i t i o n L <−25,−25,75>; // position of the camera l o o k A t L <25 ,25 ,25 >; //controlsthelook−direction of the camera p o i n t l i g h t f // automatically add a light source for this camera p o s i t i o n L <−25, −25, 75 >; // light position rgb <1 ,1 ,1 >; //lightcolor g a r e a l i g h t f // another type of light source p o s i t i o n L <10, 1 , 40 >; l o w e r l e f t L <15, 0 , 0>; t o p r i g h t L <0, 0 , 15 >; s a m p l e x 1 ; s a m p l e y 1 ; f a d e distance 120; f a d e p o w e r 1 ; g g // 'resource' blocks can be used to include additional sdl files in povray r e s o u r c e f file "textures.inc"; // povray standard textures g r e s o u r c e f file examples/povray/resources/Textures.dat; g // user defined textures g by specifying an arbitrary number of resource blocks. Each resource block must have one file pa- rameter defined, which is either the file name of a user-created file or a standard include file provided by POV-Ray. In the latter case, the file name must be given in the form ''<filename>''. In the former case, the external file will automatically be copied into the output directory as ./res/resource<number>.inc. Again, the files are tagged with a number <number>.