source: inundation/parallel/documentation/visualisation.tex @ 2786

Last change on this file since 2786 was 2786, checked in by linda, 18 years ago

Continued working on parallel documentation. Finished (waiting on feedback) description of how to parallelise the code and example codes

File size: 2.9 KB
Line 
1
2\chapter{Visualisation}
3The real-time visualisation component of the ANUGA system originally
4used VPython (\url{http://www.vpython.org}). This implementation is being
5superceded by a VTK-based (\url{http://www.vtk.org/}) visualiser which is
6faster, capable of handling larger data sets and more configurable. At
7the time of writing, the Domain class that uses the VTK visualiser
8resides in ga/inundation/pyvolution/shallow\_water\_vtk.py. It has been
9tested to work under Linux and Windows.
10
11The visualiser class itself resides in
12ga/inundation/pyvolution/vtk\_realtime\_visualiser.py.
13
14Customisation options for the visualiser are members of the visualiser
15class and their functions are as follows:
16\begin{itemize}
17\item setup: Dictionary mapping quantity name $\rightarrow$ boolean.
18  if setup[q] is true, draw the quantity when the visualiser starts.
19\item updating: Dictionary mapping quantity name $\rightarrow$
20  boolean.  if updating[q] is true, update the rendering of this
21  quantity each timestep.
22\item qcolor: Dictionary mapping quantity name $\rightarrow$ (float,
23  float, float). If the name of a quantity is found in qcolor, the
24  colour specified (in (r, g, b) from 0.0 to 1.0) is used for display
25  of that quantity instead of (0.5, 0.5, 0.5) (the default)
26\item scale\_z: Dictionary mapping quantity name $\rightarrow$ float.
27  Override the $z$ scaling of this quantity with the float specified.
28\item default\_scale\_z: float. Multiply all $z$ coordinates by this
29  amount unless an overriding value exists in scale\_z.
30\end{itemize}
31Screenshot:\\
32\includegraphics{figures/vis-screenshot.eps}\\
33
34Unlike the old VPython visualiser, the behaviour of the VTK
35interaction classes completely tie up the thread that they are running
36in. The solution was to use the TK interactor, and build a TKinter gui
37around the render window.
38
39Even using TK around the VTK interactor, this still ties up the thread
40for TK's main loop. This was worked around by making the visualiser
41use its own thread for rendering. This worked fine under Linux, but
42under Windows the visualiser is `starved' by the CPU-bound thread that
43contains the call to evolve(). To rectify this, the visualiser and the
44main thread are explicitly synchronised: The visualiser waits on a
45condition variable to signify that the evolve thread has finished
46computation for its yieldstep. The visualiser then updates the VTK
47data structures, while the evolving thread waits on another condition
48variable for the visualiser to finish.  The visualiser then informs
49the evolve thread that it is finished and returns to waiting. While
50this does reduce the potential for concurrency, it still maintains an
51acceptable level of interactivity.
52
53Currently, the rendering method is only suitable for quantities for
54which the concept of height makes sense (e.g. stage and elevation in the
55Shallow Water domain). Adding support for alternate rendering methods
56would be a welcome enhancement to this visualiser.
Note: See TracBrowser for help on using the repository browser.