Visualization of time-dependent dynamics of postglacial rebound

Abstract

Postglacial rebound is a major geological process which plays an important role in many areas in the earth sciences. Up to now, most of the images derived from studies of the glacial isostatic adjustment phenomenon have been concerned with surface signatures, such as the uplift and gravity anomalies and not much attention has been paid on the dynamical responses in the mantle. We will make use of the 3D visualization package Amira to depict both the external and internal deformation histories of the transient viscoelastic flow inside the mantle induced by postglacial uplift. Of particularly great interest are the transient displacement fields and shear heating inside the mantle. This same visualization technology can be brought to bear in the future for visualizing tsunami waves in ocean basins excited by earthquakes, volcanic eruptions and InSAR images. We have also integrated the visualization results into the Google Earth virtual globe by combining this scheme with the Amira package to provide a better geographical and dynamical context.

Appendices

Appendix A. Overlays on a virtual globe by means of Google Earth

Since its inception in 2005, Google Earth has become a popular server-client based virtual globe program (http://earth.google.com). Users can directly view the geological features in three-dimensional perspective projections, instead of just over flat maps. With the recent advent of Google Earth, we feel it timely to integrate the postglacial rebound results with this innovation in software engineering, which has many implications for digital map technology and web applications. Postglacial isostasy takes place over specific geographical areas on the globe. Therefore, it is helpful for the reader to be provided with contextual geographical information. In this work we have integrated the visualization results into Google Earth by using the image overlay function provided by Google Earth, which turns out to be very useful.

First, we have prepared data files in the form of a time series of AmiraMesh files with rectilinear coordinates. Then, within Amira, we employed the HeightField module to create appropriate views, which we saved to 2D bitmap images using the Snapshot tool. Unfortunately, Amira does not have the capability to save images with selected colors marked as transparent and the images have to be recoded into the PNG or GIF format in a third-party software, such as ImageMagick (http://www.imagemagick.org), if color transparency is desired. In our case, we made the black-and-white images with the white reserved for the ice coverage and the black marked as transparent. The vector graphics, like PostScript output from Generic Mapping Tools (http://gmt.soest.hawaii.edu), cannot be imported into the bitmap-oriented framework of Google Earth and needs to be converted beforehand.

The first image of the series we then imported into Google Earth using its “Add Image Overlay” module, which allows to place the bitmap on the spherical rectangle of the globe determined by the geographical latitudes and longitudes (Fig. 10). Note that there is also available a tool for setting the transparency level of the whole image which may be used to get the topography covered by ice sheets partially visible. Then we set up the “Time-Based Refresh” tool to force the automatic refresh of the overlaid image which we started to replace in parallel with the same frequency by means of a user script. The resulting movie-like effect can be recorded by the “Movie Maker” module or by taking snapshots of the images one by one and converting them into a movie by a third-party software (e.g., VirtualDub, http://www.virtualdub.org).

Fig. 10

Google Earth in action: a transparent GIF image with the ice coverage in the last glacial maximum (Peltier 1994) is overlaid on the present-day topography

Movie 1 (Electronic supplementary material) depicts the evolution of the ice coverage in the last 21 kyr as described by the ICE-4G model (Peltier 1994). The maps of the ice coverage prepared by Amira with the transparency of the black color added by ImageMagick are overlaid on the northern hemisphere of Google Earth. The movie is made from 22 JPG files with the resolution 1,000 × 800 pixels and size 170 KB each, with the total movie size of 520 KB after the encoding in VirtualDub with the DivX compression.

A service similar to Google Earth becomes recently available at the Windows Live web page (http://local.live.com). The 3D engine, Microsoft Virtual Earth 3D, is in its Beta version at present and we must wait for its further development.

Appendix B. Visualization on a sphere using Amira

Amira is an advanced modern tool for 4D visualization in both the 3D space and time (http://www.amiravis.com). It is a commercial package available on many platforms, ranging from Linux and Microsoft Windows to Macintosh. The extensive set of easy-to-use features includes data imaging on the Cartesian, curvilinear and finite-element grids, scalar and vector field visualization algorithms, computation of iso-surfaces, direct volume rendering, time series manipulation, creating movies, support for the Tcl scripting language (http://www.tcl.tk), batch programming and remote data processing and remote visualization (see Erlebacher et al. 2006). There is an active research front backing up Amira’s constant advancement in visualization. In contrast, Paraview (Parallel Visualization Application, http://www.paraview.org) is an open-source software, which has been applied, e.g., to 3D visualization of turbulence by Goldstein et al. (2005). Here we describe the steps made by us in visualizing with Amira the time evolution of a deformed Earth described by spherical coordinates, i.e., during preparation of Movies 2–7. The flowchart of the visualization process is given in Fig. 11, a screen dump of Amira running on the MacOs system in Fig. 12.

Fig. 11

Flowchart of the visualization process

Fig. 12

Screen dump of Amira running on MacOS

The first step is to prepare data files for Amira. These files, called AmiraMesh files, must contain properly formatted headers with details on enclosed physical 3D fields, including the grid size and (integer or real) data type. The spherical body, with which we deal, is best represented by a special kind of AmiraMesh format, which includes a section of all the grid coordinates. We have written a Fortran subroutine for data setup on a hollow shell, which consists of a spherical outer surface, an interior spherical surface (the core-mantle boundary) and up to three interior cuts through the mantle, as apparent from Fig. 13. These configurable hollow shells are advantageous for visualization of fields with an axial symmetry and can also be used for attractive insights into 3D fields. The main benefit of employing the hollow shells is a low memory requirement, which allows us to visualize time processes with a long duration.

Fig. 13

A hollow shell with two spherical surfaces and three interior cuts. The low-memory requirement for this object allows to visualize long series of time-dependent data. Here, the shell is deformed in accordance with the horizontal displacement of the toroidal normal mode ₂T₂

The next key step is the import of the time series of AmiraMesh files into Amira. We tested two techniques, each with its pros and cons. The more straightforward one is based on loading a large number of data files, each representing one time step. The Time module in Amira is automatically launched which allows easy handling data in time and attaching the MovieMaker module. However, the drawback emerges, when the number of data files is too large. The reading speed of a time series first drops, when a few hundred files are loaded, but this decrease can be avoided by turning off Amira’s data cache. (Cached files can be accessed around five times faster then the original data files, as far as the amount of data does not reach the physical memory size or the number of files is a few hundred. The caching management then can result in access times for cached files substantially worse then for non-cached files.) The reading speed drops again when around 1,000 files are read, apparently because of Amira’s implementation of internal file indexing, as it is independent on the total data size. Actually it prevents one from applying this method for visualizing such long time series.

The second technique makes use of the fact that our visualized data are only 2D shells. The unused capacity for the third spatial dimension can be used for the time instead. The whole time series can thus be saved in a single file, which can always be loaded fast. The animation of the coordinate planes along this “temporal dimension” can be performed by the Animate module and actually mimics the time evolution. There is no problem with the synchronization of more AmiraMesh files, because one Time module can master several Animate modules. Unfortunately, this technique is not applicable for all types of AmiraMesh files, namely for the line-segments format used for describing curves. This important file format does not provide a mean for selection of a particular piece of a curve, and curves evolving in time must be imported into Amira by the former technique. We employed the line segments to mimic the ice sheet in Fig. 4.

In both cases, the import speed of data files can be improved by a factor of 3, when the input files are binary. We point out that Amira internally stores all real data in double precision, no matter the precision of data in input files. This is a questionable feature: such a high accuracy might be redundant for visual output intended for a human eye, and even restricting, when the total size of data reaches the amount of available memory.

For most of our movies we employed the HeightField, LineSetView and several auxiliary modules (DisplayTime, DisplayColorMap, Annotation), configurable straightforwardly. The movies made by the Movie Maker module can be saved in the MPEG or AVI formats with low compression only. It is therefore worthwhile to prepare a script for taking a control of the Time module and saving snapshots into bitmap images (JPG, lossless TIFF or EPS). The resulting series of images can be converted into a movie by a third-party software (e.g., VirtualDub, http://www.virtualdub.org).

Beside imaging the spherical shells described by curvilinear coordinates, we also tested the capability of Amira for visualizing objects defined on unstructured grids used in finite element modelling of postglacial rebound. We present increasingly accurate approximations of a sphere by tetrahedral elements in Fig. 14. The finite-element grid generator (Everett 1997) is based on recurrent subdivision of tetrahedra which is started from the initial octahedral approximation of a sphere. The grid is stored in terms of node coordinates and quadruplets of indices pointing at the four vertices of each tetrahedron. This structure can be easily implemented using the binary AmiraMesh format.

Fig. 14

Tetrahedral finite-element mesh approximation of a sphere in Amira

A sample of a locally refined tetrahedral mesh for the sake of two-nested-spheres benchmark with analytical results is shown in Fig. 15 (Velimsky et al. 2006).

Fig. 15

A tetrahedral mesh of higher complexity with local refinement. The model of two nested spheres is used for benchmark purposes with analytical results

Material parameters, such as viscosity, density, Lamé’s elastic coefficients, and modelled variables, such as displacement, perturbed gravitational potential, and stress tensor components are assigned to nodes and tetrahedra, respectively, in piecewise-linear and piecewise-constant fashion and are stored in the same file. Moreover, we implemented local refinement and arbitrary positioning of radial interfaces. Visualization possibilities for tetrahedral grids in Amira comprise a wide spectrum of techniques including cross-sections, isolines, isosurfaces, streamlines, streamsurfaces and vector arrows.