source: documentation/user_manual/anuga_user_manual.tex @ 2788

Last change on this file since 2788 was 2788, checked in by steve, 19 years ago
  • Property svn:keywords set to LastChangedDate LastChangedRevision LastChangedBy HeadURL Id
File size: 77.1 KB
Line 
1% Complete documentation on the extended LaTeX markup used for Python
2% documentation is available in ``Documenting Python'', which is part
3% of the standard documentation for Python.  It may be found online
4% at:
5%
6%     http://www.python.org/doc/current/doc/doc.html
7
8
9%labels
10%Sections and subsections \label{sec: }
11%Chapters \label{ch: }
12%Equations \label{eq: }
13%Figures \label{fig: }
14
15
16
17\documentclass{manual}
18
19\usepackage{graphicx}
20\usepackage{datetime}
21
22\input{definitions}
23
24\title{\anuga User Manual}
25\author{Geoscience Australia and the Australian National University}
26
27% Please at least include a long-lived email address;
28% the rest is at your discretion.
29\authoraddress{Geoscience Australia \\
30  Email: \email{ole.nielsen@ga.gov.au}
31}
32
33%Draft date
34
35% update before release!
36% Use an explicit date so that reformatting
37% doesn't cause a new date to be used.  Setting
38% the date to \today can be used during draft
39% stages to make it easier to handle versions.
40
41
42\longdate       % Make date format long using datetime.sty
43%\settimeformat{xxivtime} % 24 hour Format
44\settimeformat{oclock} % Verbose
45\date{\today, \ \currenttime}
46
47\ifhtml
48\date{\today} % latex2html does not know about datetime
49\fi
50
51
52
53
54
55\release{1.0}   % release version; this is used to define the
56                % \version macro
57
58\makeindex          % tell \index to actually write the .idx file
59\makemodindex       % If this contains a lot of module sections.
60
61\setcounter{tocdepth}{3}
62\setcounter{secnumdepth}{3}
63
64
65\begin{document}
66\maketitle
67
68
69% This makes the contents more accessible from the front page of the HTML.
70\ifhtml
71\chapter*{Front Matter\label{front}}
72\fi
73
74%Subversion keywords:
75%
76%$LastChangedDate: 2006-05-01 11:00:27 +0000 (Mon, 01 May 2006) $
77%$LastChangedRevision: 2788 $
78%$LastChangedBy: steve $
79
80\input{copyright}
81
82
83\begin{abstract}
84
85\noindent \anuga\index{\anuga} is a hydrodynamic modelling tool that
86allows users to model realistic flow problems in complex geometries.
87Examples include dam breaks or the effects of natural hazards such
88as riverine flooding, storm surges and tsunami.
89
90The user must specify a study area represented by a mesh of triangular
91cells, the topography and bathymetry, frictional resistance, initial
92values for water level (called \emph{stage}\index{stage} within \anuga),
93boundary
94conditions and forces such as windstress or pressure gradients if
95applicable.
96
97\anuga tracks the evolution of water depth and horizontal momentum
98within each cell over time by solving the shallow water wave equation
99governing equation using a finite-volume method.
100
101\anuga cannot model details of breaking waves, flow under ceilings such
102as pipes, turbulence and vortices, vertical convection or viscous
103flows.
104
105\anuga also incorporates a mesh generator, called \code{pmesh}, that
106allows the user to set up the geometry of the problem interactively as
107well as tools for interpolation and surface fitting, and a number of
108auxiliary tools for visualising and interrogating the model output.
109
110Most \anuga components are written in the object-oriented programming
111language Python and most users will interact with \anuga by writing
112small Python programs based on the \anuga library
113functions. Computationally intensive components are written for
114efficiency in C routines working directly with the Numerical Python
115structures.
116
117
118\end{abstract}
119
120\tableofcontents
121
122
123\chapter{Introduction}
124
125
126\section{Purpose}
127
128The purpose of this user manual is to introduce the new user to
129the software, describe what it can do and give step-by-step
130instructions for setting up and running hydrodynamic simulations.
131
132\section{Scope}
133
134This manual covers only what is needed to operate the software
135after installation and configuration. It does not includes instructions for
136installing the software or detailed API documentation, both of
137which will be covered in separate publications.
138
139\section{Audience}
140
141Readers are assumed to be familiar with the operating environment
142and have a general understanding of the problem background, as
143well as enough programming experience to adapt the code to
144different requirements, as described in this manual,  and to
145understand the basic terminology of object-oriented programming.
146
147\section{Structure of This Manual}
148
149This manual is structured as follows:
150
151\begin{itemize}
152  \item Background (What \anuga does)
153  \item A \emph{Getting Started} section
154  \item A detailed description of the public interface
155  \item \anuga 's overall architecture, components and file formats
156  \item Assumptions
157\end{itemize}
158
159
160\pagebreak
161\chapter{Background}
162
163\chapter{Getting Started}
164\label{ch:getstarted}
165
166This section is designed to assist the reader to get started with
167\anuga by working through simple examples. Two examples are discussed;
168the first is a simple but artificial example that is useful to illustrate
169many of the ideas, and the second is a more realistic example.
170
171\section{A Simple Example}
172
173\subsection{Overview}
174
175What follows is a discussion of the structure and operation of the
176file \file{bedslopephysical.py}, with just enough detail to allow
177the reader to appreciate what's involved in setting up a scenario
178like the one it depicts.
179
180This example carries out the solution of the shallow-water wave
181equation in the simple case of a configuration comprising a flat
182bed, sloping at a fixed angle in one direction and having a
183constant depth across each line in the perpendicular direction.
184
185The example demonstrates many of the basic ideas involved in
186setting up a more complex scenario. In the general case the user
187specifies the geometry (bathymetry and topography), the initial
188water level, boundary conditions such as tide, and any forcing
189terms that may drive the system such as wind stress or atmospheric
190pressure gradients. Frictional resistance from the different
191terrains in the model is represented by predefined forcing
192terms. The boundary is reflective on three sides and a time dependent wave on one side.
193
194The present example represents a simple scenario and does not
195include any forcing terms, nor is the data taken from a file as it
196would be in many typical cases.
197
198The conserved quantities involved in the
199problem are water depth, $x$-momentum and $y$-momentum. Other quantities
200involved in the computation are the friction, stage (absolute height of water surface)
201and elevation, the last two being related to
202the depth through the equation
203
204\begin{tabular}{rcrcl}
205  \code{stage} &=& \code{elevation} &+& \code{depth}
206\end{tabular}
207
208
209%\emph{[More details of the problem background]}
210
211\subsection{Outline of the Program}
212
213In outline, \file{bedslopephysical.py} performs the following steps:
214
215\begin{enumerate}
216
217   \item Sets up a triangular mesh.
218
219   \item Sets certain parameters governing the mode of
220operation of the model-specifying, for instance, where to store the model output.
221
222   \item Inputs various quantities describing physical measurements, such
223as the elevation, to be specified at each mesh point (vertex).
224
225   \item Sets up the boundary conditions.
226
227   \item Carries out the evolution of the model through a series of time
228steps and outputs the results, providing a results file that can
229be visualised.
230
231\end{enumerate}
232
233\subsection{The Code}
234
235%FIXME: we are using the \code function here.
236%This should be used wherever possible
237For reference we include below the complete code listing for
238\file{bedslopephysical.py}. Subsequent paragraphs provide a
239`commentary' that describes each step of the program and explains it
240significance.
241
242\verbatiminput{examples/bedslopephysical.py}
243%\verbatiminput{examples/bedslope.py}
244
245\subsection{Establishing the Mesh}
246
247The first task is to set up the triangular mesh to be used for the
248scenario. This is carried out through the statement:
249
250{\small \begin{verbatim}
251    points, vertices, boundary = rectangular(10, 10)
252\end{verbatim}}
253
254The function \function{rectangular} is imported from a module
255\module{mesh\_factory} defined elsewhere. (\anuga also contains
256several other schemes that can be used for setting up meshes, but we
257shall not discuss these now.) The above assignment sets up a $10
258\times 10$ rectangular mesh, triangulated in a specific way. In
259general, the assignment
260
261{\small \begin{verbatim}
262    points, vertices, boundary = rectangular(m, n)
263\end{verbatim}}
264
265returns:
266
267\begin{itemize}
268
269   \item a list \code{points} of length $N$, where $N = (m + 1)(n + 1)$,
270comprising the coordinates \code{(x, y)} of each of the $N$ mesh
271points,
272
273   \item a list \code{vertices} of length $2mn$ (each entry specifies the three
274vertices of one of the triangles used in the triangulation) , and
275
276   \item a dictionary \code{boundary}, used to tag the triangle edges on
277the boundaries. Each key corresponds to a triangle edge on one of
278the four boundaries and its value is one of \code{`left'},
279\code{`right'}, \code{`top'} and \code{`bottom'}, indicating
280which boundary the edge in question belongs to.
281
282\end{itemize}
283
284
285\subsection{Initialising the Domain}
286
287These variables are then used to set up a data structure
288\code{domain}, through the assignment:
289
290{\small \begin{verbatim}
291    domain = Domain(points, vertices, boundary)
292\end{verbatim}}
293
294This uses a Python class \class{Domain}, imported from
295\module{shallow\_water}, which is an extension of a more generic
296class of the same name in the module \refmodule{pyvolution.domain}
297(page \pageref{mod:pyvolution.domain}),
298and inherits
299some methods from the generic class but has others specific to the
300shallow-water scenarios in which it is used. Specific options for
301domain are set at this point. One of them is to set the basename for
302the output file:
303
304{\small \begin{verbatim}
305    domain.set_name('bedslope')
306\end{verbatim}}
307
308
309\subsection{Initial Conditions}
310
311The next task is to specify a number of quantities that we wish to
312set for each mesh point. The class \class{Domain} has a method
313\method{set\_quantity}, used to specify these quantities. It is a
314particularly flexible method that allows the user to set quantities
315in a variety of ways---using constants, functions, numeric arrays or
316expressions involving other quantities, arbitrary data points with
317associated values, all of which can be passed as arguments. All
318quantities can be initialised using \method{set\_quantity}. For
319conserved quantities (\code{stage, xmomentum, ymomentum}) this is
320called the \emph{initial condition}, for other quantities that
321aren't updated by the equation, the same interface is used to assign
322their values. The code in the present example demonstrates a number
323of forms in which we can invoke \method{set\_quantity}.
324
325
326\subsubsection{Elevation}
327
328The elevation, or height of the bed, is set using a function,
329defined through the statements below, which is specific to this
330example and specifies a particularly simple initial configuration
331for demonstration purposes:
332
333{\small \begin{verbatim}
334    def f(x,y):
335        return -x/2
336\end{verbatim}}
337
338This simply associates an elevation with each point \code{(x, y)} of
339the plane.  It specifies that the bed slopes linearly in the
340\code{x} direction, with slope $-\frac{1}{2}$,  and is constant in
341the \code{y} direction.  %[screen shot?]
342
343Once the function \function{f} is specified, the quantity
344\code{elevation} is assigned through the simple statement:
345
346{\small \begin{verbatim}
347    domain.set_quantity('elevation', f)
348\end{verbatim}}
349
350
351\subsubsection{Friction}
352
353The assignment of the friction quantity demonstrates another way we
354can use \method{set\_quantity} to set quantities---namely, assign
355them to a constant numerical value:
356
357{\small \begin{verbatim}
358    domain.set_quantity('friction', 0.1)
359\end{verbatim}}
360
361This just specifies that the Manning friction coefficient is set
362to 0.1 at every mesh point.
363
364\subsubsection{Stage}
365
366The stage (the height of the water surface) is related to the
367elevation and the depth at any time by the equation
368
369
370{\small \begin{verbatim}
371    stage = elevation + depth
372\end{verbatim}}
373
374
375For this example, we simply assign a constant value to \code{stage},
376using the statement
377
378{\small \begin{verbatim}
379    domain.set_quantity('stage', -.4)
380\end{verbatim}}
381
382which specifies that the surface level is set to a height of $-0.4$, i.e. 0.4 units
383below the zero level.
384
385(Although it is not necessary for this example, it may be useful to
386digress here and mention a variant to this requirement, which allows
387us to illustrate another way to use \method{set\_quantity}---namely,
388incorporating an expression involving other quantities. Suppose,
389instead of setting a constant value for the stage, we wished to
390specify a constant value for the \emph{depth}. For such a case we
391need to specify that \code{stage} is everywhere obtained by adding
392that value to the value already specified for \code{elevation}. We
393would do this by means of the statements:
394
395{\small \begin{verbatim}
396    h = 0.05 # Constant depth
397    domain.set_quantity('stage', expression = 'elevation + %f' %h)
398\end{verbatim}}
399
400That is, the value of \code{stage} is set to $\code{h} = 0.05$ plus
401the value of \code{elevation} already defined.
402
403The reader will probably appreciate that this capability to
404incorporate expressions into statements using \method{set\_quantity}
405greatly expands its power.)
406
407\subsection{Boundary Conditions}
408
409The boundary conditions are specified as follows:
410
411{\small \begin{verbatim}
412    Br = Reflective_boundary(domain)
413
414    Bt = Transmissive_boundary(domain)
415
416    Bd = Dirichlet_boundary([0.2,0.,0.])
417
418    Bw = Time_boundary(domain=domain,
419                f=lambda t: [(0.1*sin(t*2*pi)-0.3), 0.0, 0.0])
420\end{verbatim}}
421
422The effect of these statements is to set up four alternative
423boundary conditions and store them in variables that can be
424assigned as needed. Each boundary condition specifies the
425behaviour at a boundary in terms of the behaviour in neighbouring
426elements. The boundary conditions introduced here may be briefly described as
427follows:
428
429\begin{description}
430    \item[Reflective boundary] Returns same \code{stage} as
431    as present in its neighbour volume but momentum vector reversed 180 degrees (reflected).
432    Specific to the shallow water equation as it works with the
433    momentum quantities assumed to be the second and third conserved
434    quantities.
435
436    \item[Transmissive boundary]Returns same conserved quantities as
437    those present in its neighbour volume.
438
439    \item[Dirichlet boundary]Specifies a fixed value at the
440boundary and assigns initial values to the $x$-momentum and $y$-momentum.
441
442    \item[Time boundary.]A Dirichlet boundary whose behaviour varies with time.
443\end{description}
444
445Once the four boundary types have been specified through the
446statements above, they can be applied through a statement of the
447form
448
449{\small \begin{verbatim}
450    domain.set_boundary({'left': Br, 'right': Bw, 'top': Br, 'bottom': Br})
451\end{verbatim}}
452
453This statement stipulates that, in the current example, the right
454boundary varies with time, as defined by the equation, while the other
455boundaries are all reflective.
456
457The reader may wish to experiment by varying the choice of boundary
458types for one or more of the boundaries. In the case of \code{Bd}
459and \code{Bw}, the three arguments in each case represent the
460elevation, $x$-momentum and $y$-momentum, respectively.
461
462{\small \begin{verbatim}
463    Bw = Time_boundary(domain=domain,
464                f=lambda t: [(0.1*sin(t*2*pi)-0.3), 0.0, 0.0])
465\end{verbatim}}
466
467
468
469\subsection{Evolution}
470
471The final statement \nopagebreak[3]
472{\small \begin{verbatim}
473    for t in domain.evolve(yieldstep = 0.1, duration = 4.0):
474        print domain.timestepping_statistics()
475\end{verbatim}}
476
477is the key step that causes the configuration of the domain to
478`evolve' in accordance with the model embodied in the code, over a
479series of steps indicated by the values of \code{yieldstep} and
480\code{duration}, which can be altered as required.
481The value of \code{yieldstep} controls the time interval between successive model outputs.
482Behind the scenes more time steps are generally taken.
483
484
485\subsection{Output}
486
487%Give details here of the form of the output and explain how it can
488%be used with swollen. Include screen shots.//
489
490The output is a NetCDF file with the extension \code{.sww}. It
491contains stage and momentum information and can be used with the
492\code{swollen} visualisation package to generate a visual display.
493See Section \ref{sec:file formats} (page \pageref{sec:file formats})
494for more on NetCDF and other file formats.
495
496
497\section{How to Run the Code}
498
499The code can be run in various ways:
500
501\begin{itemize}
502  \item{from a Windows command line} as in \code{python bedslopephysical.py}
503  \item{within the Python IDLE environment}
504  \item{within emacs}
505  \item{from a Linux command line} as in \code{python bedslopephysical.py}
506\end{itemize}
507
508
509\section{Exploring the model output}
510
511Figure \ref{fig:bedslopestart} shows the \\
512Figure \ref{fig:bedslope2} shows later snapshots...
513
514
515
516\begin{figure}[hbt]
517
518  \centerline{ \includegraphics[width=75mm, height=75mm]{examples/bedslopestart.eps}}
519
520  \caption{Bedslope example viewed with Swollen}
521  \label{fig:bedslopestart}
522\end{figure}
523
524
525\begin{figure}[hbt]
526
527  \centerline{
528    \includegraphics[width=75mm, height=75mm]{examples/bedslopeduring.eps}
529    \includegraphics[width=75mm, height=75mm]{examples/bedslopeend.eps}
530   }
531
532  \caption{Bedslope example viewed with Swollen}
533  \label{fig:bedslope2}
534\end{figure}
535
536
537
538
539\clearpage
540
541%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
542
543\section{An Example with Real Data}
544
545The following discussion builds on the concepts introduced through
546the \file{bedslopephysical.py} example and introduces a second
547example, \file{run\_sydney\_smf.py}, that follows the same basic
548outline, but incorporates more complex features and refers to a
549real-life scenario, rather than the artificial illustrative one used
550in \file{bedslopephysical.py}. The domain of interest surrounds the
551Sydney region, and predominantly covers Sydney Harbour. A
552hypothetical tsunami wave is generated by a submarine mass failure
553situated on the edge of the continental shelf.
554
555\subsection{Overview}
556As in the case of \file{bedslopephysical.py}, the actions carried
557out by the program can be organised according to this outline:
558
559\begin{enumerate}
560
561   \item Set up a triangular mesh.
562
563   \item Set certain parameters governing the mode of
564operation of the model---specifying, for instance, where to store the
565model output.
566
567   \item Input various quantities describing physical measurements, such
568as the elevation, to be specified at each mesh point (vertex).
569
570   \item Set up the boundary conditions.
571
572   \item Carry out the evolution of the model through a series of time
573steps and outputs the results, providing a results file that can be
574visualised.
575
576\end{enumerate}
577
578
579
580\subsection{The Code}
581
582Here is the code for \file{run\_sydney\_smf.py}:
583
584%\verbatiminput{"runsydneysmf.py"}
585\verbatiminput{examples/runsydney.py}
586
587In discussing the details of this example, we follow the outline
588given above, discussing each major step of the code in turn.
589
590\subsection{Establishing the Mesh}
591
592One obvious way that the present example differs from
593\file{bedslopephysical.py} is in the use of a more complex method to
594create the mesh. Instead of imposing a mesh structure on a
595rectangular grid, the technique used for this example involves
596building mesh structures inside polygons specified by the user,
597using a mesh-generator referred to as \code{pmesh}.
598
599The following remarks may help the reader understand how
600\code{pmesh} is used.
601
602In its simplest form, \code{pmesh} creates the mesh within a single
603polygon whose vertices are at geographical locations specified by the
604user. The user specifies the \emph{resolution}---that is, the maximal
605area of a triangle used for triangulation---and mesh points are
606created inside the polygon through a random process. Figure
607\ref{fig:pentagon} shows a simple example of this, in which
608the triangulation is carried out within a pentagon.
609
610
611\begin{figure}[hbt]
612
613
614
615  \caption{Mesh points are created inside the polygon}
616  \label{fig:pentagon}
617\end{figure}
618
619Boundary tags are not restricted to \code{`left'}, \code{`right'},
620\code{`bottom'} and \code{`top'}, as in the case of
621\file{bedslopephysical.py}. Instead the user specifies a list of
622tags appropriate to the configuration being modelled.
623
624While a mesh created inside a polygon offers more flexibility than
625one based on a rectangular grid, using \code{pmesh} in the limited
626form we have described so far still doesn't provide a way to adapt
627to geographic or other features in the landscape, whose presence may
628require us to vary the resolution in the neighbourhood of the
629features. To cope with this requirement, \code{pmesh} also allows
630the user to specify a number of \emph{interior polygons}, which are
631triangulated separately, each according to a separately specified
632resolution. See Figure \ref{fig:interior meshes}.
633
634\begin{figure}[hbt]
635
636
637
638  \caption{Interior meshes with individual resolution}
639  \label{fig:interior meshes}
640\end{figure}
641
642In its general form, \code{pmesh} takes for its input a bounding
643polygon and (optionally) a list of interior polygons. The user
644specifies resolutions, both for the bounding polygon and for each of
645the interior polygons. Given this data, \code{pmesh} first creates a
646triangular mesh inside the bounding polygon, using the specified
647resolution, and then creates a separate triangulation inside each of
648the interior polygons, using the resolution specified for that
649polygon.
650
651The function used to implement this process is
652\function{create\_mesh\_from\_regions}. Its arguments include the
653bounding polygon and its resolution, a list of boundary tags, and a
654list of pairs \code{[polygon, resolution]}, specifying the interior
655polygons and their resolutions.
656
657In practice, the details of the polygons used are read from a
658separate file \file{project.py}. The resulting mesh is output to a
659\emph{meshfile}\index{meshfile}. This term is used to describe a
660file of a specific format used to store the data specifying a mesh.
661(There are in fact two possible formats for such a file: it can
662either be a binary file, with extension \code{.msh}, or an ASCII
663file, with extension \code{.tsh}. In the present case, the binary
664file format \code{.msh} is used. See Section \ref{sec:file formats}
665(page \pageref{sec:file formats}) for more on file formats.)
666\code{pmesh} assigns a name to the file by appending the extension
667\code{.msh} to the name specified in the input file
668\file{project.py}. This name is stored in the variable
669\code{meshname}.
670
671The statements
672
673{\small \begin{verbatim}
674    interior_res = 5000%
675    interior_regions = [[project.harbour_polygon_2, interior_res],
676                    [project.botanybay_polygon_2, interior_res]]
677\end{verbatim}}
678
679are used to read in the specific polygons \code{project.harbour\_polygon\_2} and
680\code{botanybay\_polygon\_2} from \file{project.py} and assign a
681common resolution of 5000 to each. The statement
682
683{\small \begin{verbatim}
684    create_mesh_from_regions(project.diffpolygonall,%
685                         boundary_tags= {'bottom': [0],%
686                                         'right1': [1],%
687                                         'right0': [2],%
688                                         'right2': [3],%
689                                         'top': [4],%
690                                         'left1': [5],%
691                                         'left2': [6],%
692                                         'left3': [7]},%
693                         maximum_triangle_area=100000,%
694                         filename=meshname,%
695                         interior_regions=interior_regions)
696\end{verbatim}}
697
698is then used to create the mesh, taking the bounding polygon to be the polygon
699\code{diffpolygonall} specified in \file{project.py}. The
700argument \code{boundary\_tags} assigns a dictionary, whose keys are the
701names of the boundary tags used for the bounding polygon---\code{`bottom'},
702`right0', `right1', `right2', `top', `left1', `left2' and `left3'---
703and whose values identify the indices of the segments associated with each of these
704tags. (The value associated with each boundary tag is a one-element list.)
705
706
707\subsection{Initialising the Domain}
708
709As with \file{bedslopephysical.py}, once we have created the mesh, the next
710step is to create the data structure \code{domain}. We did this for
711\file{bedslopephysical.py} by inputting lists of points and triangles and
712specifying the boundary tags directly. However, in the present case,
713we use a method that works directly with the meshfile
714\code{meshname}, as follows:
715
716{\small \begin{verbatim}
717    domain = pmesh_to_domain_instance(meshname,
718    Domain, use_cache = True, verbose = True)
719\end{verbatim}}
720
721The function \function{pmesh\_to\_domain\_instance} converts a meshfile
722\code{meshname} into an instance of the data structure
723\code{domain}, allowing us to use methods like \method{set\_quantity}
724to set quantities and to apply other operations. (In principle, the
725second argument of \function{pmesh\_to\_domain\_instance} can be any
726subclass of \class{Domain}, but for applications involving the
727shallow-water wave equation, the second argument of
728\function{pmesh\_to\_domain\_instance} can always be set simply to
729\class{Domain}.)
730
731The following statements specify a basename and data directory, and
732identify quantities to be stored. For the first two, values are
733taken from \file{project.py}.
734
735{\small \begin{verbatim}
736    domain.set_name(project.basename)%
737    domain.set_datadir(project.outputdir)%
738    domain.set_quantities_to_be_stored(['stage', 'xmomentum',
739        'ymomentum'])
740\end{verbatim}}
741
742
743\subsection{Initial Conditions}
744Quantities for \file{run\_sydney\_smf.py} are set
745using similar methods to those in \file{bedslopephysical.py}. However,
746in this case, many of the values are read from the auxiliary file
747\file{project.py} or, in the case of \code{elevation}, from an
748ancillary points file.
749
750
751
752\subsubsection{Stage}
753
754For the scenario we are modelling in this case, we use a callable
755object \code{tsunami\_source}, assigned by means of a function
756\function{slump\_tsunami}. This is similar to how we set elevation in
757\file{bedslopephysical.py} using a function---however, in this case the
758function is both more complex and more interesting.
759
760The function returns the water displacement for all \code{x} and
761\code{y} in the domain. The water displacement is a double Gaussian
762function that depends on the characteristics of the slump (length,
763thickness, slope, etc), its location (origin) and the depth at that
764location.
765
766
767\subsubsection{Friction}
768
769We assign the friction exactly as we did for \file{bedslopephysical.py}:
770
771{\small \begin{verbatim}
772    domain.set_quantity('friction', 0.03)
773\end{verbatim}}
774
775
776\subsubsection{Elevation}
777
778The elevation is specified by reading data from a file:
779
780{\small \begin{verbatim}
781    domain.set_quantity('elevation',
782                    filename = project.combineddemname + '.pts',
783                    use_cache = True,
784                    verbose = True)
785\end{verbatim}}
786
787However, before this step can be executed, some preliminary steps
788are needed to prepare the file from which the data is taken. Two
789source files are used for this data---their names are specified in
790the file \file{project.py}, in the variables \code{coarsedemname}
791and \code{finedemname}. They contain `coarse' and `fine' data,
792respectively---that is, data sampled at widely spaced points over a
793large region and data sampled at closely spaced points over a
794smaller subregion. The data in these files is combined through the
795statement
796
797{\small \begin{verbatim}
798combine_rectangular_points_files(project.finedemname + '.pts',
799                                 project.coarsedemname + '.pts',
800                                 project.combineddemname + '.pts')
801\end{verbatim}}
802
803The effect of this is simply to combine the datasets by eliminating
804any coarse data associated with points inside the smaller region
805common to both datasets. The name to be assigned to the resulting
806dataset is also derived from the name stored in the variable
807\code{combinedname} in the file \file{project.py}.
808
809\subsection{Boundary Conditions}
810
811Setting boundaries follows a similar pattern to the one used for
812\file{bedslopephysical.py}, except that in this case we need to associate a
813boundary type with each of the
814boundary tag names introduced when we established the mesh. In place of the four
815boundary types introduced for \file{bedslopephysical.py}, we use the reflective
816boundary for each of the
817eight tagged segments:
818
819{\small \begin{verbatim}
820    Br = Reflective_boundary(domain)
821    domain.set_boundary( {'bottom': Br, 'right1': Br, 'right0': Br,
822                          'right2': Br, 'top': Br, 'left1': Br,
823                          'left2': Br, 'left3': Br} )
824\end{verbatim}}
825
826\subsection{Evolution}
827
828With the basics established, the running of the `evolve' step is
829very similar to the corresponding step in \file{bedslopephysical.py}:
830
831{\small \begin{verbatim}
832    import time t0 = time.time()
833
834    for t in domain.evolve(yieldstep = 120, duration = 18000):
835        print domain.timestepping_statistics()
836        print domain.boundary_statistics(tags = 'bottom')
837
838    print 'That took %.2f seconds' %(time.time()
839\end{verbatim}}
840
841%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
842%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
843
844\chapter{\anuga Public Interface}
845
846This chapter gives an overview of the features of \anuga available
847to the user at the public interface. These are grouped under the
848following headings:
849
850\begin{itemize}
851    \item Establishing the Mesh
852    \item Initialising the Domain
853    \item Specifying the Quantities
854    \item Initial Conditions
855    \item Boundary Conditions
856    \item Forcing Functions
857    \item Evolution
858\end{itemize}
859
860The listings are intended merely to give the reader an idea of what
861each feature is, where to find it and how it can be used---they do
862not give full specifications. For these the reader
863may consult the code. The code for every function or class contains
864a documentation string, or `docstring', that specifies the precise
865syntax for its use. This appears immediately after the line
866introducing the code, between two sets of triple quotes.
867
868Each listing also describes the location of the module in which
869the code for the feature being described can be found. All modules
870are in the folder \file{inundation} or one of its subfolders, and the
871location of each module is described relative to \file{inundation}. Rather
872than using pathnames, whose syntax depends on the operating system,
873we use the format adopted for importing the function or class for
874use in Python code. For example, suppose we wish to specify that the
875function \function{create\_mesh\_from\_regions} is in a module called
876\module{mesh\_interface} in a subfolder of \module{inundation} called
877\code{pmesh}. In Linux or Unix syntax, the pathname of the file
878containing the function, relative to \file{inundation}, would be
879
880\begin{center}
881%    \code{pmesh/mesh\_interface.py}
882    \code{pmesh}$\slash$\code{mesh\_interface.py}
883\end{center}
884
885while in Windows syntax it would be
886
887\begin{center}
888    \code{pmesh}$\backslash$\code{mesh\_interface.py}
889\end{center}
890
891Rather than using either of these forms, in this chapter we specify
892the location simply as \code{pmesh.mesh_interface}, in keeping with
893the usage in the Python statement for importing the function,
894namely:
895\begin{center}
896    \code{from pmesh.mesh\_interface import create\_mesh\_from\_regions}
897\end{center}
898
899Each listing details the full set of parameters for the class or
900function; however, the description is generally limited to the most
901important parameters and the reader is again referred to the code
902for more details.
903
904The following parameters are common to many functions and classes
905and are omitted from the descriptions given below:
906
907\begin{tabular}{|l|l|}  \hline
908\textbf{Name } & \textbf{Description}\\
909\hline
910\code{usecache} & Specifies whether caching is to be used\\
911\code{verbose} & If \code{True}, provides detailed terminal output
912to the user\\   \hline
913\end{tabular}
914
915
916\section{Mesh Generation}
917\refmodindex[pmesh.meshinterface]{pmesh.mesh\_interface}
918\begin{funcdesc}  {create\_mesh\_from\_regions}{bounding_polygon,
919                             boundary_tags,
920                             maximum_triangle_area,
921                             filename=None,
922                             interior_regions=None,
923                             poly_geo_reference=None,
924                             mesh_geo_reference=None,
925                             minimum_triangle_angle=28.0}
926Module: \module{pmesh.mesh\_interface}
927
928
929% Translate following into layman's language
930This function is used to create a triangular mesh suitable for use with
931\anuga, within a specified region. The region is specified as the interior of a polygon
932(the \emph{bounding polygon}). The user specifies the bounding polygon and the
933\emph{resolution}---that is, maximal area of any triangle in the mesh. There is
934also an option to specify a number of internal polygons within each of which a
935separate mesh is created, generally with a smaller resolution. Additionally,
936the user specifies a list of boundary tags, one for each edge of the bounding
937polygon.
938\end{funcdesc}
939
940
941\begin{funcdesc}  {Mesh}{}
942Module: \module{pmesh.mesh}
943
944% Translate following into layman's language
945This function is used to create a Mesh instance.  This can then be
946used to build the outline of the mesh and then generate the
947mesh.
948\end{funcdesc}
949
950
951\begin{funcdesc}  {add_region_from_polygon}{self, polygon, tags=None,
952                                max_triangle_area=None, geo_reference=None}
953Module: \module{pmesh.mesh.Mesh}
954
955% Translate following into layman's language
956This method is used to add a region to a Mesh instance.  The region is
957described by the polygon passed in.  Additionally,
958the user specifies a list of boundary tags, one for each edge of the bounding
959polygon.
960\end{funcdesc}
961
962\begin{funcdesc}  {add_hole_from_polygon}{self, polygon, tags=None,
963    geo_reference=None}
964Module: \module{pmesh.mesh.Mesh}
965
966% Translate following into layman's language
967This method is used to add a region where the triangular mesh will not
968be generated to a Mesh instance.  The region is
969described by the polygon passed in.  Additionally,
970the user specifies a list of boundary tags, one for each edge of the bounding
971polygon.
972\end{funcdesc}
973
974\begin{funcdesc}  {generate_mesh}{self,
975                      maximum_triangle_area=None,
976                      minimum_triangle_angle=28.0,
977                      verbose=False}
978Module: \module{pmesh.mesh.Mesh}
979
980% Translate following into layman's language
981This method is used to generate the triangular mesh.  The  maximal area
982of any triangle in the mesh can be specified, along with the minimum
983angle of all triangles.
984\end{funcdesc}
985
986
987\begin{funcdesc}  {export_mesh_file}{self,ofile}
988Module: \module{pmesh.mesh.Mesh}
989
990% Translate following into layman's language
991This method is used to save the mesh to a file. \code{ofile} is the name of the mesh file to be writen,
992including the extension.  Use the extension \code{.msh} for the file to
993be in NetCDF format and \code{.tsh} for the file to be ASCII format.
994\end{funcdesc}
995
996%%%%%%
997\section{Initialising Domain}
998
999\begin{funcdesc}  {pmesh\_to\_domain\_instance}{file_name, DomainClass, use_cache = False, verbose = False}
1000Module: \module{pyvolution.pmesh2domain}
1001
1002Once the initial mesh file has been created, this function is applied
1003to convert it to a domain object---that is, to a member of
1004the special Python class Domain (or a subclass of Domain), which provides access to properties and
1005methods that allow quantities to be set and other operations to be carried out.
1006
1007\code{file\_name} is the name of the mesh file to be converted,
1008including the extension. \code{DomainClass} is the class to be
1009returned, which must be a subclass of \class{Domain} having the same
1010interface as \class{Domain}---in practice, it can usually be set
1011simply to \class{Domain}.
1012\end{funcdesc}
1013
1014
1015\subsection{Key Methods of Domain}
1016
1017\begin{funcdesc} {set\_name}{name}
1018    Module: \refmodule{pyvolution.domain}, page \pageref{mod:pyvolution.domain}  %\code{pyvolution.domain}
1019
1020    Assigns the name \code{name} to the domain.
1021\end{funcdesc}
1022
1023\begin{funcdesc} {get\_name}{}
1024    Module: \module{pyvolution.domain}
1025
1026    Returns the name assigned to the domain by \code{set_name}. If no name has been
1027    assigned, returns `domain'.
1028\end{funcdesc}
1029
1030\begin{funcdesc} {set\_datadir}{name}
1031    Module: \module{pyvolution.domain}
1032
1033    Specifies the directory used for data, assigning it to the pathname \code{name}. The default value, before
1034    \code{set\_datadir} has been run, is the value \code{default_datadir}
1035    specified in \code{config.py}.
1036
1037    Since different operating systems use different formats for specifying pathnames,
1038    it is necessary to specify path separators using the Python code \code{os.sep}, rather than
1039    the operating-specific ones such as `$\slash$' or `$\backslash$'.
1040    For this to work you will need to include the statement \code{import os}
1041    in your code, before the first appearance of \code{set\_datadir}.
1042
1043    For example, if you wished to set the data directory to a subdirectory
1044    \code{data} of the directory \code{project}, you might use
1045    statements of the following type:
1046
1047    {\small \begin{verbatim}
1048        import os
1049        domain.set_datadir{'project' + os.sep + 'data'}
1050    \end{verbatim}}
1051\end{funcdesc}
1052
1053\begin{funcdesc} {get_datadir}{}
1054    Module: \module{pyvolution.domain}
1055
1056    Returns the data directory set by \code{set\_datadir} or, if \code{set\_datadir} has not
1057    been run, returns the value \code{default_datadir} specified in
1058    \code{config.py}.
1059\end{funcdesc}
1060
1061\begin{funcdesc} {set_time}{time=0.0}
1062    Module: \module{pyvolution.domain}
1063
1064    Sets the initial time, in seconds, for the simulation. The
1065    default is 0.0.
1066\end{funcdesc}
1067
1068\begin{funcdesc} {set_default_order}{??}
1069\end{funcdesc}
1070
1071
1072%%%%%%
1073\section{Initial Conditions}
1074
1075\begin{funcdesc}{set\_quantity}{name,
1076    numeric = None,
1077    quantity = None,
1078    function = None,
1079    geospatial_data = None,
1080    filename = None,
1081    attribute_name = None,
1082    alpha = None,
1083    location = 'vertices',
1084    indices = None,
1085    verbose = False,
1086    use_cache = False}
1087  Module: \module{pyvolution.domain}
1088  (see also \module{pyvolution.quantity.set_values})
1089
1090This function is used to assign values to individual quantities for a
1091domain. It is very flexible and can be used with many data types: a
1092statement of the form \code{domain.set\_quantity(name, x)} can be used
1093to define a quantity having the name \code{name}, where the other
1094argument \code{x} can be any of the following:
1095
1096\begin{itemize}
1097\item a number, in which case all vertices in the mesh gets that for
1098the quantity in question.
1099\item a list of numbers or a Numeric array ordered the same way as the mesh vertices.
1100\item a function (e.g.\ see the samples introduced in Chapter 2)
1101\item an expression composed of other quantities and numbers, arrays, lists (for
1102example, a linear combination of quantities)
1103\item the name of a file from which the data can be read. In this case, the optional argument attribute_name will select which attribute to use from the file. If left out, set_quantity will pick one. This is useful in cases where there is only one attribute.
1104\item a geospatial dataset (See ?????). Optional argument attribute_name applies here as with files.
1105\end{itemize}
1106
1107
1108Exactly one of the arguments
1109  numeric, quantity, function, points, filename
1110must be present.
1111
1112
1113Set quantity will look at the type of the second argument (\code{numeric}) and
1114determine what action to take.
1115
1116Values can also be set using the appropriate keyword arguments.
1117If x is a function, for example, \code{domain.set\_quantity(name, x)}, \code{domain.set\_quantity(name, numeric=x)}, and \code{domain.set\_quantity(name, function=x)}
1118are all equivalent.
1119
1120
1121Other optional arguments are
1122\begin{itemize}
1123\item \code{indices} which is a list of ids of triangles to which set_quantity should apply its assignment of values.
1124\item \code{location} determines which part of the triangles to assign to. Options are 'vertices' (default), 'edges', and 'centroids'.
1125\end{itemize}
1126
1127
1128a number, in which case all vertices in the mesh gets that for
1129the quantity in question.
1130\item a list of numbers or a Numeric array ordered the same way as the mesh vertices.
1131
1132
1133\end{funcdesc}
1134
1135
1136
1137
1138
1139
1140
1141%%%
1142\anuga provides a number of predefined initial conditions to be used
1143with \code{set_quantity}.
1144
1145\begin{funcdesc}{tsunami_slump}{length, depth, slope, width=None, thickness=None,
1146                x0=0.0, y0=0.0, alpha=0.0,
1147                gravity=9.8, gamma=1.85,
1148                massco=1, dragco=1, frictionco=0, psi=0,
1149                dx=None, kappa=3.0, kappad=0.8, zsmall=0.01,
1150                domain=None,
1151                verbose=False}
1152This function returns a callable object representing an initial water
1153displacement generated by a submarine sediment failure. These failures can take the form of
1154a submarine slump or slide.
1155
1156The arguments include as a minimum, the slump or slide length, the water depth to the centre of sediment
1157mass, and the bathymetric slope. Other slump or slide parameters can be included if they are known.
1158\end{funcdesc}
1159
1160
1161%%%
1162\begin{funcdesc}{file_function}{filename,
1163                  domain = None,
1164                  quantities = None,
1165                  interpolation_points = None,
1166                  verbose = False,
1167                  use_cache = False}
1168Module: \module{pyvolution.util}
1169
1170Reads the time history of spatial data from NetCDF file and returns
1171a callable object. Returns interpolated values based on the input
1172file using the underlying \code{interpolation\_function}.
1173
1174\code{quantities} is either the name of a single quantity to be
1175interpolated or a list of such quantity names. In the second case, the resulting
1176function will return a tuple of values---one for each quantity.
1177
1178\code{interpolation\_points} is a list of absolute UTM coordinates
1179for points at which values are sought.
1180\end{funcdesc}
1181
1182%%%
1183\begin{classdesc}{Interpolation\_function}{self,
1184                 time,
1185                 quantities,
1186                 quantity_names = None,
1187                 vertex_coordinates = None,
1188                 triangles = None,
1189                 interpolation_points = None,
1190                 verbose = False}
1191Module: \module{pyvolution.least\_squares}
1192
1193Given a time series, either as a sequence of numbers or
1194defined at the vertices of a triangular mesh (such
1195as those stored in \code{sww} files), \code{Interpolation\_function}
1196is used to create a callable object that interpolates a value for
1197an arbitrary time \code{t} within the model limits and possibly a
1198point \code{(x, y)} within a mesh region.
1199
1200The actual time series at which data is available is specified by
1201means of an array \code{time} of monotonically increasing times. The
1202quantities containing the values to be interpolated are specified in
1203an array---or dictionary of arrays (used in conjunction with the
1204optional argument \code{quantity\_names}) --- called
1205\code{quantities}. The optional arguments \code{vertex_coordinates}
1206and \code{triangles} represent the spatial mesh associated with the
1207quantity arrays. If omitted the function created by
1208\code{Interpolation\_function} will be a function of \code{t} only.
1209
1210Since, in practice, values need to be computed at specified points,
1211the syntax allows the user to specify, once and for all, a list
1212\code{interpolation\_points} of points at which values are required.
1213In this case, the function may be called using the form \code{f(t,
1214id)}, where \code{id} is an index for the list
1215\code{interpolation\_points}.
1216
1217\end{classdesc}
1218
1219%%%
1220\begin{funcdesc}{set\_region}{functions}
1221[Low priority. Will be merged into set\_quantity]
1222
1223Module:\module{pyvolution.domain}
1224\end{funcdesc}
1225
1226
1227
1228%%%%%%
1229\section{Boundary Conditions}
1230
1231\anuga provides a large number of predefined boundary conditions,
1232represented by objects such as \code{Reflective\_boundary(domain)} and
1233\code{Dirichlet\_boundary([0.2, 0.0, 0.0])}, described in the examples
1234in Chapter 2. Alternatively, you may prefer to ``roll your own'',
1235following the method explained in Section \ref{sec:roll your own}.
1236
1237These boundary objects may be used with the function \code{set\_boundary} described below
1238to assign boundary conditions according to the tags used to label boundary segments.
1239
1240\begin{funcdesc}{set\_boundary}{boundary_map}
1241Module: \module{pyvolution.domain}
1242
1243This function allows you to assign a boundary object (corresponding to a
1244pre-defined or user-specified boundary condition) to every boundary segment that
1245has been assigned a particular tag.
1246
1247This is done by specifying a dictionary \code{boundary\_map}, whose values are the boundary objects
1248and whose keys are the symbolic tags.
1249
1250\end{funcdesc}
1251
1252\begin{funcdesc} {get_boundary_tags}{}
1253Module: \module{pyvolution.mesh}
1254\end{funcdesc}
1255
1256%%%
1257\subsection{Predefined boundary conditions}
1258
1259\begin{classdesc}{Reflective_boundary}{Boundary}
1260Module: \module{pyvolution.shallow\_water}
1261
1262Reflective boundary returns same conserved quantities as those present in
1263the neighbouring volume but reflected.
1264
1265This class is specific to the shallow water equation as it works with the
1266momentum quantities assumed to be the second and third conserved quantities.
1267\end{classdesc}
1268
1269%%%
1270\begin{classdesc}{Transmissive_boundary}{domain = None}
1271Module: \module{pyvolution.generic\_boundary\_conditions}
1272
1273A transmissive boundary returns the same conserved quantities as
1274those present in the neighbouring volume.
1275
1276The underlying domain must be specified when the boundary is instantiated.
1277\end{classdesc}
1278
1279%%%
1280\begin{classdesc}{Dirichlet_boundary}{conserved_quantities=None}
1281Module: \module{pyvolution.generic\_boundary\_conditions}
1282
1283A Dirichlet boundary returns constant values for the conserved
1284quantities.
1285\end{classdesc}
1286
1287%%%
1288\begin{classdesc}{Time_boundary}{domain = None, f = None}
1289Module: \module{pyvolution.generic\_boundary\_conditions}
1290
1291A time-dependent boundary returns values for the conserved
1292quantities as a function \code{f(t)} of time. The user must specify
1293the domain to get access to the model time.
1294\end{classdesc}
1295
1296%%%
1297\begin{classdesc}{File_boundary}{Boundary}
1298Module: \module{pyvolution.generic\_boundary\_conditions}
1299
1300The boundary values are obtained from a file and interpolated. The
1301file is assumed to contain a time series and possibly also spatial
1302information. The conserved quantities are given as a function of
1303time.
1304\end{classdesc}
1305
1306
1307\subsection{User-defined boundary conditions}
1308\label{sec:roll your own}
1309[How to roll your own]
1310
1311
1312
1313
1314
1315\section{Forcing Functions}
1316
1317\anuga provides a number of predefined forcing functions to be used with .....
1318
1319%\begin{itemize}
1320
1321
1322%  \item \indexedcode{}
1323%  [function, arguments]
1324
1325%  \item \indexedcode{}
1326
1327%\end{itemize}
1328
1329
1330
1331\section{Evolution}
1332
1333  \begin{funcdesc}{evolve}{yieldstep = None, finaltime = None, duration = None, skip_initial_step = False}
1334
1335  Module: \module{pyvolution.domain}
1336
1337  This function (a method of \class{domain}) is invoked once all the
1338  preliminaries have been completed, and causes the model to progress
1339  through successive steps in its evolution, storing results and
1340  outputting statistics whenever a user-specified period
1341  \code{yieldstep} is completed (generally during this period the
1342  model will evolve through several steps internally). The user
1343  specifies the total time period over which the evolution is to take
1344  place, by specifying values (in seconds) for either \code{duration}
1345  or \code{finaltime}, as well as the interval in seconds after which
1346  results are to be stored and statistics output.
1347
1348  You can include \method{evolve} in a statement of the type:
1349
1350  {\small \begin{verbatim}
1351      for t in domain.evolve(yieldstep, finaltime):
1352          <Do something with domain and t>
1353  \end{verbatim}}
1354
1355  \end{funcdesc}
1356
1357
1358
1359\subsection{Diagnostics}
1360
1361  \begin{funcdesc}{timestepping_statistics}{}
1362  Module: \module{pyvolution.domain}
1363
1364
1365  \end{funcdesc}
1366
1367
1368  \begin{funcdesc}{boundary\_statistics}{quantities = None, tags = None}
1369  Module: \module{pyvolution.domain}
1370
1371
1372  \end{funcdesc}
1373
1374
1375  \begin{funcdesc}{get_quantity}{name, location='vertices', indices = None}
1376  Module: \module{pyvolution.domain}
1377  Allow access to individual quantities and their methods
1378
1379  \end{funcdesc}
1380
1381
1382  \begin{funcdesc}{get_values}{location='vertices', indices = None}
1383  Module: \module{pyvolution.quantity}
1384
1385  Extract values for quantity as an array
1386
1387  \end{funcdesc}
1388
1389
1390  \begin{funcdesc}{get_integral}{}
1391  Module: \module{pyvolution.quantity}
1392
1393  Return computed integral over entire domain for this quantity
1394
1395  \end{funcdesc}
1396
1397
1398\section{Other}
1399
1400  \begin{funcdesc}{domain.create_quantity_from_expression}{???}
1401
1402  Handy for creating derived quantities on-the-fly.
1403  See \file{Analytical\_solution\_circular\_hydraulic\_jump.py} for an example of use.
1404  \end{funcdesc}
1405
1406
1407  \begin{funcdesc}{Geospatial_data}{???}
1408    Module: \module{geospatial_data.geo_spatial_data}
1409    Creates a georeferenced geospatial data object from either arrays or a file (pts or xya).
1410
1411    Objects of this class can be used with \method{set\_quantity}.
1412  \end{funcdesc}
1413
1414
1415
1416
1417
1418%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1419%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1420
1421\chapter{\anuga System Architecture}
1422
1423From pyvolution/documentation
1424
1425\section{File Formats}
1426\label{sec:file formats}
1427
1428\anuga makes use of a number of different file formats. The
1429following table lists all these formats, which are described in more
1430detail in the paragraphs below.
1431
1432\bigskip
1433
1434\begin{center}
1435
1436\begin{tabular}{|ll|}  \hline
1437
1438\textbf{Extension} & \textbf{Description} \\
1439\hline\hline
1440
1441\code{.sww} & NetCDF format for storing model output
1442\code{f(t,x,y)}\\
1443
1444\code{.tms} & NetCDF format for storing time series \code{f(t)}\\
1445
1446\code{.xya} & ASCII format for storing arbitrary points and
1447associated attributes\\
1448
1449\code{.pts} & NetCDF format for storing arbitrary points and
1450associated attributes\\
1451
1452\code{.asc} & ASCII format of regular DEMs as output from ArcView\\
1453
1454\code{.prj} & Associated ArcView file giving more metadata for
1455\code{.asc} format\\
1456
1457\code{.ers} & ERMapper header format of regular DEMs for ArcView\\
1458
1459\code{.dem} & NetCDF representation of regular DEM data\\
1460
1461\code{.tsh} & ASCII format for storing meshes and associated
1462boundary and region info\\
1463
1464\code{.msh} & NetCDF format for storing meshes and associated
1465boundary and region info\\
1466
1467\code{.nc} & Native ferret NetCDF format\\
1468
1469\code{.geo} & Houdinis ASCII geometry format (?) \\  \par \hline
1470%\caption{File formats used by \anuga}
1471\end{tabular}
1472
1473
1474\end{center}
1475
1476The above table shows the file extensions used to identify the
1477formats of files. However, typically, in referring to a format we
1478capitalise the extension and omit the initial full stop---thus, we
1479refer, for example, to `SWW files' or `PRJ files'.
1480
1481\bigskip
1482
1483A typical dataflow can be described as follows:
1484
1485\subsection{Manually Created Files}
1486
1487\begin{tabular}{ll}
1488ASC, PRJ & Digital elevation models (gridded)\\
1489TSH & Triangular meshes (e.g. created from \code{pmesh})\\
1490NC & Model outputs for use as boundary conditions (e.g. from MOST)
1491\end{tabular}
1492
1493\subsection{Automatically Created Files}
1494
1495\begin{tabular}{ll}
1496ASC, PRJ  $\rightarrow$  DEM  $\rightarrow$  PTS & Convert
1497DEMs to native \code{.pts} file\\
1498
1499NC $\rightarrow$ SWW & Convert MOST boundary files to
1500boundary \code{.sww}\\
1501
1502PTS + TSH $\rightarrow$ TSH with elevation & Least squares fit\\
1503
1504TSH $\rightarrow$ SWW & Convert TSH to \code{.sww}-viewable using
1505Swollen\\
1506
1507TSH + Boundary SWW $\rightarrow$ SWW & Simulation using
1508\code{pyvolution}
1509\end{tabular}
1510
1511
1512
1513
1514\bigskip
1515
1516\subsection{SWW and TMS Formats}
1517
1518The SWW and TMS formats are both NetCDF formats, and are of key
1519importance for \anuga.
1520
1521An SWW file is used for storing \anuga output and therefore pertains
1522to a set of points and a set of times at which a model is evaluated.
1523It contains, in addition to dimension information, the following
1524variables:
1525
1526\begin{itemize}
1527    \item \code{x} and \code{y}: coordinates of the points, represented as Numeric arrays
1528    \item \code{elevation}, a Numeric array storing bed-elevations
1529    \item \code{volumes}, a list specifying the points at the vertices of each of the
1530    triangles
1531    \item \code{time}, a Numeric array containing times for model
1532    evaluation
1533\end{itemize}
1534
1535
1536The contents of an SWW file may be viewed using the visualisation
1537tool \code{swollen}, which creates an on-screen geometric
1538representation. See section \ref{sec:swollen} (page
1539\pageref{sec:swollen}) in Appendix \ref{ch:supportingtools} for more
1540on \code{swollen}.
1541
1542Alternatively, there are tools, such as \code{ncdump}, that allow
1543you to convert an NetCDF file into a readable format such as the
1544Class Definition Language (CDL). The following is an excerpt from a
1545CDL representation of the output file \file{bedslope.sww} generated
1546from running the simple example \file{bedslopephysical.py} of
1547Chapter \ref{ch:getstarted}.
1548
1549\verbatiminput{examples/bedslopeexcerpt.cdl}
1550
1551A TMS file is used to store time series...
1552
1553
1554\subsection{Meshfile Formats}
1555
1556A meshfile is a file that has a specific format suited to specifying
1557mesh data for \anuga. A meshfile can have one of two formats: it can
1558be either a TSH file, which is an ASCII file, or an MSH file, which
1559is a NetCDF file.
1560
1561A meshfile describes the outline of the mesh---the vertices and line
1562segments that enclose the region in which the mesh is created---and
1563the triangular mesh itself, which is specified by listing the
1564triangles and their vertices, and the segments, which are those
1565sides of the triangles that are associated with boundary conditions.
1566
1567In addition, a meshfile may contain `holes' and/or `regions'. A hole
1568or region is defined by specifying a point and a number of segments
1569that enclose that point. A hole represents an area where no mesh is
1570to be created, while a region is a labelled area used for defining
1571properties of a mesh, such as friction values.
1572
1573A meshfile can also contain a georeference, which describes an
1574offset to be applied to $x$ and $y$ values---eg to the vertices.
1575
1576
1577\subsection{Formats for Storing Arbitrary Points and Attributes}
1578
1579An XYA file is used to store data representing arbitrary numerical
1580attributes associated with a set of points.
1581
1582The format for a .xya file is:
1583\begin{verbatim}
1584            1st line:     [attribute names]
1585            other lines:  x y [attributes]
1586
1587            for example:
1588            elevation, friction
1589            0.6, 0.7, 4.9, 0.3
1590            1.9, 2.8, 5, 0.3
1591            2.7, 2.4, 5.2, 0.3
1592
1593        The first two columns are always implicitly assumed to be x, y coordinates.
1594        Use the same delimiter for the attribute names and the data
1595
1596        An xya file can optionally end with
1597            #geo reference
1598            56
1599            466600.0
1600            8644444.0
1601
1602        When the 1st # is the zone,
1603        2nd # the xllcorner and
1604        3rd # the yllcorner
1605\end{verbatim}
1606
1607\subsection{ArcView Formats}
1608
1609
1610\subsection{Other Formats}
1611
1612\subsection{Basic File Conversions}
1613
1614  \begin{funcdesc}{sww2dem}{basename_in, basename_out = None,
1615            quantity = None,
1616            timestep = None,
1617            reduction = None,
1618            cellsize = 10,
1619            NODATA_value = -9999,
1620            easting_min = None,
1621            easting_max = None,
1622            northing_min = None,
1623            northing_max = None,
1624            expand_search = False,
1625            verbose = False,
1626            origin = None,
1627            datum = 'WGS84',
1628            format = 'ers'}
1629  Module: \module{pyvolution.data\_manager}
1630
1631  Takes data from an SWW file and converts it to DEM format (ASC or
1632  ERS)
1633  \end{funcdesc}
1634
1635
1636  \begin{funcdesc}{dem2pts}{basename_in, basename_out=None,
1637            easting_min=None, easting_max=None,
1638            northing_min=None, northing_max=None,
1639            use_cache=False, verbose=False}
1640  Module: \module{pyvolution.data\_manager}
1641
1642  Takes DEM data (a NetCDF file representation of data from a regular Digital
1643  Elevation Model) and converts it to PTS format.
1644  \end{funcdesc}
1645
1646
1647
1648%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1649%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1650
1651\chapter{Basic \anuga Assumptions}
1652
1653(From pyvolution/documentation)
1654
1655
1656Physical model time cannot be earlier than 1 Jan 1970 00:00:00.
1657If one wished to recreate scenarios prior to that date it must be done
1658using some relative time (e.g. 0).
1659
1660
1661All spatial data relates to the WGS84 datum (or GDA94) and has been
1662projected into UTM with false easting of 500000 and false northing of
16631000000 on the southern hemisphere (0 on the northern).
1664
1665It is assumed that all computations take place within one UTM zone.
1666
1667DEMs, meshes and boundary conditions can have different origins within
1668one UTM zone. However, the computation will use that of the mesh for
1669numerical stability.
1670
1671
1672%OLD
1673%The dataflow is: (See data_manager.py and from scenarios)
1674%
1675%
1676%Simulation scenarios
1677%--------------------%
1678%%
1679%
1680%Sub directories contain scrips and derived files for each simulation.
1681%The directory ../source_data contains large source files such as
1682%DEMs provided externally as well as MOST tsunami simulations to be used
1683%as boundary conditions.
1684%
1685%Manual steps are:
1686%  Creation of DEMs from argcview (.asc + .prj)
1687%  Creation of mesh from pmesh (.tsh)
1688%  Creation of tsunami simulations from MOST (.nc)
1689%%
1690%
1691%Typical scripted steps are%
1692%
1693%  prepare_dem.py:  Convert asc and prj files supplied by arcview to
1694%                   native dem and pts formats%
1695%
1696%  prepare_pts.py: Convert netcdf output from MOST to an sww file suitable
1697%                  as boundary condition%
1698%
1699%  prepare_mesh.py: Merge DEM (pts) and mesh (tsh) using least squares
1700%                   smoothing. The outputs are tsh files with elevation data.%
1701%
1702%  run_simulation.py: Use the above together with various parameters to
1703%                     run inundation simulation.
1704
1705
1706%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1707%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1708
1709\appendix
1710
1711\chapter{Supporting Tools}
1712\label{ch:supportingtools}
1713
1714This section describes a number of supporting tools, supplied with \anuga, that offer a
1715variety of types of functionality and enhance the basic capabilities of \anuga.
1716
1717\section{caching}
1718
1719  The \code{cache} function is used to provide supervised caching of function results. A Python
1720  function call of the form
1721
1722      {\small \begin{verbatim}
1723      result = func(arg1,...,argn)
1724      \end{verbatim}}
1725
1726  can be replaced by
1727
1728      {\small \begin{verbatim}
1729      from caching import cache
1730      result = cache(func,(arg1,...,argn))
1731      \end{verbatim}}
1732
1733  which returns the same output but reuses cached
1734  results if the function has been computed previously in the same context.
1735  \code{result} and the arguments can be simple types, tuples, list, dictionaries or
1736  objects, but not unhashable types such as functions or open file objects.
1737  The function \code{func} may be a member function of an object or a module.
1738
1739  This type of caching is particularly useful for computationally intensive
1740  functions with few frequently used combinations of input arguments. Note that
1741  if the inputs or output are very large caching may not save time because
1742  disc access may dominate the execution time.
1743
1744  If the function definition changes after a result has been cached, this will be
1745  detected by examining the functions \code{bytecode (co_code, co_consts,
1746  func_defualts, co_argcount)} and the function will be recomputed.
1747
1748  Options are set by means of the function \code{set_option(key, value)},
1749  where \code{key} is a key associated with a
1750  Python dictionary \code{options}. This dictionary stores settings such as the name of
1751  the directory used, the maximum
1752  number of cached files allowed, and so on.
1753
1754  The \code{cache} function allows the user also to specify a list of dependent files. If any of these
1755  have been changed, the function is recomputed and the results stored again.
1756
1757  %Other features include support for compression and a capability to \ldots
1758
1759
1760   \textbf{USAGE:}
1761
1762    {\small \begin{verbatim}
1763    result = cache(func, args, kwargs, dependencies, cachedir, verbose,
1764                   compression, evaluate, test, return_filename)
1765    \end{verbatim}}
1766
1767
1768\section{swollen}
1769\label{sec:swollen}
1770 The output generated by \anuga may be viewed by
1771means of the visualisation tool \code{swollen}, which takes the
1772\code{sww} file output by \anuga and creates a visual representation
1773of the data. Examples may be seen in Figures \ref{fig:bedslopestart}
1774and \ref{fig:bedslope2}. To view an \code{sww} file with
1775\code{swollen} in the Windows environment, you can simply drag the
1776icon representing the file over an icon on the desktop for the
1777\code{swollen} executable file (or a shortcut to it). Alternatively,
1778you can operate \code{swollen} from the command line, in both
1779Windows and Linux environments.
1780
1781On successful operation, you will see an interactive moving-picture display. You can use keys and the mouse
1782to slow down, speed up or stop the display, change the viewing position or carry out a number of other
1783simple operations.
1784
1785The main keys operating the interactive screen are:\\
1786
1787\begin{tabular}{|ll|}   \hline
1788
1789\code{w} & toggle wireframe\\
1790
1791space bar & start/stop\\
1792
1793up/down arrows & increase/decrease speed\\
1794
1795left/right arrows & direction in time \emph{(when running)}\\ & step through simulation \emph{(when stopped)}\\
1796
1797left mouse button & rotate\\
1798
1799middle mouse button & pan\\
1800
1801right mouse button & zoom\\  \hline
1802
1803\end{tabular}
1804
1805\vfill
1806
1807The following table describes how to operate swollen from the command line:
1808
1809Usage: \code{swollen [options] swwfile \ldots}\\  \nopagebreak
1810Options:\\  \nopagebreak
1811\begin{tabular}{ll}
1812  \code{--display <type>} & \code{MONITOR | POWERWALL | REALITY_CENTER |}\\
1813                                    & \code{HEAD_MOUNTED_DISPLAY}\\
1814  \code{--rgba} & Request a RGBA colour buffer visual\\
1815  \code{--stencil} & Request a stencil buffer visual\\
1816  \code{--stereo} & Use default stereo mode which is \code{ANAGLYPHIC} if not \\
1817                                    & overridden by environmental variable\\
1818  \code{--stereo <mode>} & \code{ANAGLYPHIC | QUAD_BUFFER | HORIZONTAL_SPLIT |}\\
1819                                    & \code{VERTICAL_SPLIT | LEFT_EYE | RIGHT_EYE |}\\
1820                                     & \code{ON | OFF} \\
1821  \code{-alphamax <float 0-1>} & Maximum transparency clamp value\\
1822  \code{-alphamin <float 0-1>} & Transparency value at \code{hmin}\\
1823  \code{-cullangle <float angle 0-90>} & Cull triangles steeper than this value\\
1824  \code{-help} & Display this information\\
1825  \code{-hmax <float>} & Height above which transparency is set to
1826                                     \code{alphamax}\\
1827  \code{-hmin <float>} & Height below which transparency is set to
1828                                     zero\\
1829  \code{-lightpos <float>,<float>,<float>} & $x,y,z$ of bedslope directional light ($z$ is
1830                                     up, default is overhead)\\
1831  \code{-loop}  & Repeated (looped) playback of \code{.swm} files\\
1832  \code{-movie <dirname>} & Save numbered images to named directory and
1833                                     quit\\
1834  \code{-nosky} & Omit background sky\\
1835  \code{-scale <float>} & Vertical scale factor\\
1836  \code{-texture <file>} & Image to use for bedslope topography\\
1837  \code{-tps <rate>} & Timesteps per second\\
1838  \code{-version} & Revision number and creation (not compile)
1839                                     date\\
1840\end{tabular}
1841
1842\section{utilities/polygons}
1843
1844  \begin{classdesc}{Polygon_function}{regions, default = 0.0, geo_reference = None}
1845  Module: \code{utilities.polygon}
1846
1847
1848  \end{classdesc}
1849
1850  \begin{funcdesc}{read_polygon}{filename}
1851  Module: \code{utilities.polygon}
1852
1853  Reads the specified file and returns a polygon. Each
1854  line of the file must contain exactly two numbers, separated by a comma, which are interpreted
1855  as coordinates of one vertex of the polygon.
1856  \end{funcdesc}
1857
1858  \begin{funcdesc}{populate_polygon}{polygon, number_of_points, seed = None, exclude = None}
1859  Module: \code{utilities.polygon}
1860
1861  Populates the interior of the specified polygon with the specified number of points,
1862  selected by means of a uniform distribution function.
1863  \end{funcdesc}
1864
1865  \begin{funcdesc}{point_in_polygon}{polygon, delta=1e-8}
1866  Module: \code{utilities.polygon}
1867
1868  Returns a point inside the specified polygon and close to the edge. The distance between
1869  the returned point and the nearest point of the polygon is less than $\sqrt{2}$ times the
1870  second argument \code{delta}, which is taken as $10^{-8}$ by default.
1871  \end{funcdesc}
1872
1873  \begin{funcdesc}{inside_polygon}{points, polygon, closed = True, verbose = False}
1874  Module: \code{utilities.polygon}
1875
1876  Used to test whether a single point---or the members of a list of points---
1877  are inside the specified polygon. If the first argument is a single point,
1878  returns \code{True} if the point is inside the polygon, or \code{False}
1879  otherwise. If the first argument is a list of points, returns a Numeric
1880  array comprising the indices of the points in the list that lie inside the polygon.
1881  (If none of the points are inside, returns \code{zeros((0,), 'l')}.)
1882  Points on the edges of the polygon are regarded as inside if
1883  \code{closed} is set to \code{True} or omitted; otherwise they are regarded as outside.
1884  \end{funcdesc}
1885
1886  \begin{funcdesc}{outside_polygon}{points, polygon, closed = True, verbose = False}
1887  Module: \code{utilities.polygon}
1888
1889  Exactly like \code{inside_polygon}, but with the words `inside' and `outside' interchanged.
1890  \end{funcdesc}
1891
1892  \begin{funcdesc}{point_on_line}{x, y, x0, y0, x1, y1}
1893  Module: \code{utilities.polygon}
1894
1895  Returns \code{True} or \code{False}, depending on whether the point with coordinates
1896  \code{x, y} is on the line passing through the points with coordinates \code{x0, y0}
1897  and \code{x1, y1} (extended if necessary at either end).
1898  \end{funcdesc}
1899
1900  \begin{funcdesc}{separate_points_by_polygon}{points, polygon,
1901                               closed = True, verbose = False}\indexedcode{separate_points_by_polygon}
1902  Module: \code{utilities.polygon}
1903
1904  \end{funcdesc}
1905
1906
1907
1908\section{coordinate_transforms}
1909
1910\section{geo_spatial_data}
1911
1912This describes a class that represents arbitrary point data in UTM
1913coordinates along with named attribute values.
1914
1915TBA
1916
1917\section{pmesh GUI}
1918
1919\section{alpha_shape}
1920
1921
1922\section{utilities/numerical_tools} Do now.
1923
1924\begin{itemize}
1925  \item \indexedcode{ensure_numeric}
1926  \item \indexedcode{mean}
1927  \item
1928\end{itemize}
1929
1930
1931\chapter{Modules available in \anuga}
1932
1933
1934\section{\module{pyvolution.general\_mesh} }
1935\declaremodule[pyvolution.generalmesh]{}{pyvolution.general\_mesh}
1936\label{mod:pyvolution.generalmesh}
1937
1938\section{\module{pyvolution.mesh} }
1939\declaremodule{}{pyvolution.mesh}
1940\label{mod:pyvolution.mesh}
1941
1942\section{\module{pyvolution.domain} --- Generic module for 2D triangular domains for finite-volume computations of conservation laws}
1943\declaremodule{}{pyvolution.domain}
1944\label{mod:pyvolution.domain}
1945
1946
1947\section{\module{pyvolution.quantity}}
1948\declaremodule{}{pyvolution.quantity}
1949\label{mod:pyvolution.quantity}
1950
1951
1952\section{\module{pyvolution.shallow\_water} --- 2D triangular domains for finite-volume computations of the shallow water wave equation. This module contains a specialisation of class Domain from module domain.py consisting of methods specific to the Shallow Water Wave Equation
1953}
1954\declaremodule[pyvolution.shallowwater]{}{pyvolution.shallow\_water}
1955\label{mod:pyvolution.shallowwater}
1956
1957
1958
1959
1960%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1961
1962\chapter{Frequently Asked Questions}
1963
1964
1965\section{General Questions}
1966
1967\subsubsection{What is \anuga?}
1968
1969\subsubsection{Why is it called \anuga?}
1970
1971\subsubsection{How do I obtain a copy of \anuga?}
1972
1973\subsubsection{What developments are expected for \anuga in the future?}
1974
1975\subsubsection{Are there any published articles about \anuga that I can reference?}
1976
1977\section{Modelling Questions}
1978
1979\subsubsection{Which type of problems are \anuga good for?}
1980
1981\subsubsection{Which type of problems are beyond the scope of \anuga?}
1982
1983\subsubsection{Can I start the simulation at an arbitrary time?}
1984Yes, using \code{domain.set_time()} you can specify an arbitrary starting time.
1985This is for example useful in conjunction with a file_boundary, which may start hours before anything hits the model boundary. By assigning a later time for the model to start, computational resources aren't wasted.
1986
1987\subsubsection{Can I change values for any quantity during the simulation?}
1988Yes, using \code{domain.set_quantity()} inside the domain.evolve loop you
1989can change values of any quantity. This is for example useful if you wish to
1990let the system settle for a while before assigning an initial condition. Another example would be changing the values for elevation to model e.g. erosion.
1991
1992\subsubsection{Can I change boundary conditions during the simulation?}
1993Not sure, but it would be nice :-)
1994
1995\subsubsection{Why does a file\_function return a list of numbers when evaluated?}
1996Currently, file\_function works by returning values for the conserved
1997quantities \code{stage}, \code{xmomentum} and \code{ymomentum} at a given point in time and space as a triplet. To access e.g.\ \code{stage} one must specify element 0 of the triplet returned by file\_function.
1998
1999\subsubsection{Which diagnostics are available to troubleshoot a simulation?}
2000
2001\subsubsection{How do I use a DEM in my simulation?}
2002You use \code{dem2pts} to convert your DEM to the required .pts format. This .pts file is then called When setting the elevation data to the mesh
2003in \code{domain.set_quantity}
2004
2005\subsubsection{What sort of DEM resolution should I use?}
2006Try and work with the "best" you have available. Onshore DEMs are typically available in 25m, 100m and 250m grids. Note, offshore data is often sparse,
2007or non-existant.
2008
2009\subsubsection{What sort of mesh resolution should I use?}
2010The mesh resolution should be commensurate with your DEM - it does not make sense to put in place a mesh which is finer than your DEM. As an example,
2011if your DEM is on a 25m grid, then the cell resolution should be of the order of 315$m^2$ (this represents half the area of the square grid). Ideally,
2012you need a fine mesh over regions where the DEM changes rapidly, and other areas of significant interest, such as the coast.
2013
2014\subsubsection{How often should I store the output?}
2015This will depend on what you are trying to answer with your model and how much memory you have available on your machine. If you need
2016to look in detail at the evolution, then you will need to balance against your storage requirements and the duration of the simulation.
2017If the sww file exceeds 1Gb, another sww file will be created until the end of the simulation. As an example, to store all the conserved
2018quantities on a mesh with approximately 300000 triangles on a 2 min interval for 5 hours will result in approximately 350Mb sww file.
2019
2020\subsection{Boundary Conditions}
2021
2022\subsubsection{How do I create a Dirichlet boundary condition?}
2023
2024\subsubsection{How do I know which boundary tags are available?}
2025The method \code{domain.get_boundary_tags()} will return a list of
2026available tags for use with \code{domain.set_boundary_condition()}.
2027
2028
2029
2030
2031
2032\chapter{Glossary}
2033
2034\begin{itemize}
2035    \item \indexedbold{\anuga} Name of software (joint development between ANU and GA)
2036
2037    \item \indexedbold{domain} The domain of a function is the set of all input values to the function.
2038
2039    \item \indexedbold{Dirichlet boundary} - A Dirichlet boundary condition imposed on a differential equation
2040 which specifies the values the solution is to take on the boundary of the domain.
2041
2042    \item \indexedbold{elevation} - refers to bathymetry and topography
2043
2044    \item \indexedbold{bathymetry} - offshore elevation
2045
2046    \item \indexedbold{topography} - onshore elevation
2047
2048    \item \indexedbold{evolution} - integration of the shallow water wave equations over time
2049
2050    \item \indexedbold{forcing term}
2051
2052    \item \indexedbold{IDLE} - Development environment shipped with Python
2053
2054    \item \indexedbold{Manning friction coefficient}
2055
2056    \item \indexedbold{mesh}    - Triangulation of domain
2057
2058    \item \indexedbold{meshfile}  [generic word for either .tsh or
2059    .msh file]
2060
2061    \item \indexedbold{points file}  [generic word for either .pts or
2062    .xya file]
2063
2064    \item \indexedbold{grid} - evenly spaced mesh
2065
2066    \item \indexedbold{NetCDF}
2067
2068    \item \indexedbold{pmesh} does this really need to be here? it's a class/module?
2069
2070    \item \indexedbold{pyvolution} does this really need to be here? it's a class/module?
2071
2072    \item \indexedbold{conserved quantity} conserved (stage, x and y momentum)
2073
2074    \item \indexedbold{reflective boundary}
2075
2076    \item \indexedbold{smoothing} is this really needed?
2077
2078    \item \indexedbold{stage}
2079
2080%    \item \indexedbold{try this}
2081
2082    \item \indexedbold{swollen} - visualisation tool
2083
2084    \item \indexedbold{time boundary} - defined in the manual (flog from there)
2085
2086    \item \indexedbold{transmissive boundary} - defined in the manual (flog from there)
2087
2088    \item \indexedbold{xmomentum} - conserved quantity (note, two-dimensional SWW equations say only x and y and NOT z)
2089
2090    \item \indexedbold{ymomentum}  - conserved quantity
2091
2092    \item \indexedbold{resolution} -  The maximal area of a triangular cell in a mesh
2093
2094    \item \indexedbold{polygon} - A sequence of points in the plane. (Arbitrary polygons can be created
2095    in this way.)
2096    \anuga represents a polygon in one of two ways. One way is to represent it as a
2097    list whose members are either Python tuples
2098    or Python lists of length 2. The unit square, for example, would be represented by the
2099    list
2100    [ [0,0], [1,0], [1,1], [0,1] ]. The alternative is to represent it as an
2101    $N \times 2$ Numeric array, where $N$ is the number of points.
2102
2103    NOTE: More can be read in the module utilities/polygon.py ....
2104
2105    \item \indexedbold{easting} - A rectangular (x,y) coordinate measurement of distance east from a north-south reference line,
2106usually a meridian used as the axis of origin within a map zone or projection. Easting is a UTM (Universal Transverse Mercator) Coordinate.
2107
2108    \item \indexedbold{northing} - A rectangular (x,y) coordinate measurement of distance north from a north-south reference line,
2109usually a meridian used as the axis of origin within a map zone or projection. Northing is a UTM (Universal Transverse Mercator) Coordinate.
2110
2111
2112    \item \indexedbold{latitude} - The angular distance on a mericlear north and south of the equator, expressed in degrees and minutes.
2113
2114    \item \indexedbold{longitude} - The angular distance east or west, between the meridian of a particular place on Earth and that of the
2115Prime Meridian (located in Greenwich, England) expressed in degrees or time.
2116
2117    \item \indexedbold{edge} - A triangulare cell within the computational mesh can be depicted as a set of vertices joined by lines (the edges).
2118
2119    \item \indexedbold{vertex} - A point at which edges meet.
2120
2121    \item \indexedbold{finite volume} - The method evaluates the terms in the shallow water wave equationas fluxes at the surfaces of each
2122finite volume. Because the flux entering a given volume is identical to that leaving the adjacent volume, these methods are conservative.
2123Another advantage of the finite volume method is that it is easily formulated to allow for unstructured meshes.
2124The method is used in many computational fluid dynamics packages.
2125
2126
2127    \item \indexedbold{flux} - the amount of flow through the volume per unit time
2128
2129    \item \indexedbold{Digital Elevation Model (DEM)} - DEMs are digital files consisting of points of elevations,
2130sampled systematically at equally spaced intervals.
2131
2132
2133\end{itemize}
2134
2135The \code{\e appendix} markup need not be repeated for additional
2136appendices.
2137
2138
2139%
2140%  The ugly "%begin{latexonly}" pseudo-environments are really just to
2141%  keep LaTeX2HTML quiet during the \renewcommand{} macros; they're
2142%  not really valuable.
2143%
2144%  If you don't want the Module Index, you can remove all of this up
2145%  until the second \input line.
2146%
2147
2148%begin{latexonly}
2149%\renewcommand{\indexname}{Module Index}
2150%end{latexonly}
2151%\input{mod\jobname.ind}        % Module Index
2152%
2153%begin{latexonly}
2154%\renewcommand{\indexname}{Index}
2155%end{latexonly}
2156%\input{\jobname.ind}            % Index
2157
2158
2159
2160\end{document}
Note: See TracBrowser for help on using the repository browser.