Visualize spectral element data while maintaining a responsive UI
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
project
src/main
.gitignore
LICENSE
README.md
build.sbt

README.md

DgView

Visualize spectral element data while maintaining a responsive UI. Expensive rendering computations are performed by an Akka ActorSystem that interfaces with SwingWorker. Interpolation to pixels is done with full spectral accuracy.

Dependencies

DgView is written in Scala and requires an SBT launcher compatible with version 0.13.0 and a Java SE 6 (or later) JDK.

DgView can render animations of your data in both GIF and MP4 AVC formats. Generating GIFs requires the convert tool from ImageMagick. Generating MP4 AVC video requires x264. DgView can also render PNG frames and raw I420 video without any additional tools.

Configuration

Options not hard-coded into the application (including the path to the domain file to plot) are specified in application.conf.

The use of JNI by the "netlib-java" dependency can cause portability issues. If you encounter JNI errors, try commenting or uncommenting the com.github.fommil.netlib options.

Distribution

DgView uses the Native Packager Plugin for SBT in order to create distributable binaries that only depend on a JVM (SBT and a full JDK are not required). To create such a package, run sbt universal:package-bin; this will create a file named target/universal/dgview-1.0-SNAPSHOT.zip, which can be extracted on the target system. Running bin/dgview will execute DgView.

Data format

DgView currently reads its data from an ad hoc plain-text file format. Domains must be composed of 2D rectangular Legendre-Gauss-Lobatto elements. These elements may be arbitrarily scaled and shifted and need not conform to their neighbors, but they may not be rotated or otherwise have their coordinates mapped, and they should not overlap one another.

Each timestep must be stored in a separate file, and the files must be named VarsTime<step_num>.data, where <step_num> is an integer representing the the timestep of the data. These files must be located in the same directory. For example, the directory /path/to/run/data might contain the files VarsTime0.data, VarsTime100.data, etc.. One could then specify dgview.domain-dir=/path/to/run/data in application.conf.

The top of each file consists of a header indicating the fields present in the data. Each line of the header begins with a number sign # followed by a space, followed by the column number in square brackets (starting with 1), followed by a space, followed by the field name (an arbitrary string). The first two fields must correspond to the x and y coordinates of a gridpoint. An example header might look like:

# [1] X[0]
# [2] X[1]
# [3] rho
# [4] Pressure

Following the header is the data, one line per gridpoint. Each line is divided into columns by whitespace. Each column contains a floating-point number representing the corresponding field in the header. Data points appear in row-major order: left-to-right, bottom-to-top. Each row of an element (constant y-value) must be separated by a blank line. Each element must be separated by two blank lines, and elements may be listed in any order. An example consisting of two 2x3 elements might look like:

0.0  0.0  1.0  2.0
0.5  0.0  2.0  8.0

0.0  0.5  1.0  2.0
0.5  0.5  2.0  8.0

0.0  1.0  1.0  2.0
0.5  1.0  2.0  8.0


0.5  0.0  2.0  8.0
1.0  0.0  3.0  18.0

0.5  0.5  2.0  8.0
1.0  0.5  3.0  18.0

0.5  1.0  2.0  8.0
1.0  1.0  3.0  18.0