source: documentation/user_manual/anuga_user_manual.tex @ 2747

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

Minor additions to Chap 4

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