source: documentation/user_manual/anuga_user_manual.tex @ 2779

Last change on this file since 2779 was 2779, checked in by howard, 18 years ago

Some material on file formats added to Chapter 5

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