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 | \input{definitions} |
---|
10 | |
---|
11 | |
---|
12 | \documentclass{manual} |
---|
13 | |
---|
14 | \title{\anuga User Manual} |
---|
15 | \author{Howard Silcock, Ole Nielsen, Duncan Gray, Jane Sexton} |
---|
16 | |
---|
17 | % Please at least include a long-lived email address; |
---|
18 | % the rest is at your discretion. |
---|
19 | \authoraddress{Geoscience Australia \\ |
---|
20 | Email: \email{ole.nielsen@ga.gov.au} |
---|
21 | } |
---|
22 | |
---|
23 | %Draft date |
---|
24 | \date{\today} % update before release! |
---|
25 | % Use an explicit date so that reformatting |
---|
26 | % doesn't cause a new date to be used. Setting |
---|
27 | % the date to \today can be used during draft |
---|
28 | % stages to make it easier to handle versions. |
---|
29 | |
---|
30 | \release{1.0} % release version; this is used to define the |
---|
31 | % \version macro |
---|
32 | |
---|
33 | \makeindex % tell \index to actually write the .idx file |
---|
34 | %\makemodindex % If this contains a lot of module sections. |
---|
35 | |
---|
36 | |
---|
37 | |
---|
38 | \begin{document} |
---|
39 | \maketitle |
---|
40 | |
---|
41 | % This makes the contents more accessible from the front page of the HTML. |
---|
42 | \ifhtml |
---|
43 | \chapter*{Front Matter\label{front}} |
---|
44 | \fi |
---|
45 | |
---|
46 | %Subversion keywords: |
---|
47 | % |
---|
48 | %$LastChangedDate: 2006-02-13 06:03:53 +0000 (Mon, 13 Feb 2006) $ |
---|
49 | %$LastChangedRevision: 2387 $ |
---|
50 | %$LastChangedBy: ole $ |
---|
51 | |
---|
52 | \input{copyright} |
---|
53 | |
---|
54 | |
---|
55 | \begin{abstract} |
---|
56 | |
---|
57 | \noindent |
---|
58 | \anuga\index{AnuGA} is a hydrodynamic modelling tool that |
---|
59 | allows users to model realistic flow problems in complex |
---|
60 | geometries. Examples include dam breaks or the effects of natural |
---|
61 | hazards such as riverine flooding, storm surges and tsunami. |
---|
62 | |
---|
63 | The user must specify a study area represented by a mesh of triangular |
---|
64 | cells, the topography and bathymetry, frictional resistance, initial |
---|
65 | values for water level (called \emph{stage}\index{stage} within \anuga), |
---|
66 | boundary |
---|
67 | conditions and forces such as windstress or pressure gradients if |
---|
68 | applicable. |
---|
69 | |
---|
70 | \anuga tracks the evolution of water depth and horizontal momentum |
---|
71 | within each cell over time by solving the shallow water wave equation |
---|
72 | governing equation using a finite-volume method. |
---|
73 | |
---|
74 | \anuga cannot model details of breaking waves, flow under ceilings such |
---|
75 | as pipes, turbulence and vortices, vertical convection or viscous |
---|
76 | flows. |
---|
77 | |
---|
78 | \anuga also incorporates a mesh generator, called \code{pmesh}, that |
---|
79 | allows the user to set up the geometry of the problem interactively as |
---|
80 | well as tools for interpolation and surface fitting, and a number of |
---|
81 | auxiliary tools for visualising and interrogating the model output. |
---|
82 | |
---|
83 | Most \anuga components are written in the object-oriented programming |
---|
84 | language Python and most users will interact with Anuga by writing |
---|
85 | small Python programs based on the \anuga library |
---|
86 | functions. Computationally intensive components are written for |
---|
87 | efficiency in C routines working directly with the Numerical Python |
---|
88 | structures. |
---|
89 | |
---|
90 | |
---|
91 | \end{abstract} |
---|
92 | |
---|
93 | \tableofcontents |
---|
94 | |
---|
95 | |
---|
96 | \chapter{Introduction} |
---|
97 | |
---|
98 | |
---|
99 | \section{Purpose} |
---|
100 | |
---|
101 | The purpose of this user manual is to introduce the new user to |
---|
102 | the software, describe what it can do and give step-by-step |
---|
103 | instructions for setting up, configuring and running the software. |
---|
104 | |
---|
105 | \section{Scope} |
---|
106 | |
---|
107 | This manual covers only what is needed to operate the software |
---|
108 | after installation. It does not includes instructions for |
---|
109 | installing the software or detailed API documentation, both of |
---|
110 | which will be covered in separate publications. |
---|
111 | |
---|
112 | \section{Audience} |
---|
113 | |
---|
114 | Readers are assumed to be familiar with the operating environment |
---|
115 | and have a general understanding of the problem background, as |
---|
116 | well as enough programming experience to adapt the code to |
---|
117 | different requirements, as described in this manual, and to |
---|
118 | understand the basic terminology of object-oriented programming. |
---|
119 | |
---|
120 | \section{Structure of This Manual} |
---|
121 | |
---|
122 | This manual is structured as follows: |
---|
123 | |
---|
124 | \begin{itemize} |
---|
125 | \item Background (What \anuga does) |
---|
126 | \item A \emph{Getting Started} section |
---|
127 | \item Anuga's overall architecture, components and file formats |
---|
128 | \item Detailed descriptions of the user interface |
---|
129 | \end{itemize} |
---|
130 | |
---|
131 | |
---|
132 | \pagebreak |
---|
133 | \chapter{Getting Started} |
---|
134 | |
---|
135 | This section is designed to assist the reader to get started with |
---|
136 | \anuga by working through a simple example. What follows |
---|
137 | is a discussion of the structure and operation of the file |
---|
138 | \code{bedslope.py}, with just enough detail to allow the reader |
---|
139 | to appreciate what's involved in setting up a scenario like the |
---|
140 | one it depicts. |
---|
141 | |
---|
142 | \section{Overview} |
---|
143 | |
---|
144 | This example carries out the solution of the shallow-water wave |
---|
145 | equation in the simple case of a configuration comprising a flat |
---|
146 | bed, sloping at a fixed angle in one direction and having a |
---|
147 | constant depth across each line in the perpendicular direction. |
---|
148 | |
---|
149 | The example demonstrates many of the basic ideas involved in |
---|
150 | setting up a more complex scenario. In the general case the user |
---|
151 | specifies the geometry (bathymetry and topography), the initial |
---|
152 | water level, boundary conditions such as tide, and any forcing |
---|
153 | terms that may drive the system such as wind stress or atmospheric |
---|
154 | pressure gradients. Frictional resistance from the different |
---|
155 | terrains in the model is represented by predefined forcing |
---|
156 | terms. The boundary is reflective on three sides and a time dependent wave on one side. |
---|
157 | |
---|
158 | The present example, as it represents a simple scenario, does not |
---|
159 | include any forcing term, nor is the data taken from a file as it |
---|
160 | would be in many typical cases. The quantities involved in the |
---|
161 | present problem are: |
---|
162 | \begin{itemize} |
---|
163 | \item elevation\index{elevation} |
---|
164 | \item friction\index{friction} |
---|
165 | \item depth\index{depth} |
---|
166 | \item stage\index{stage} |
---|
167 | \end{itemize} |
---|
168 | |
---|
169 | %\emph{[More details of the problem background]} |
---|
170 | |
---|
171 | \section{Outline of the Program} |
---|
172 | |
---|
173 | In outline, \code{bedslope.py} performs the following steps: |
---|
174 | |
---|
175 | \begin{enumerate} |
---|
176 | |
---|
177 | \item Sets up a triangular mesh. |
---|
178 | |
---|
179 | \item Sets certain parameters governing the mode of |
---|
180 | operation of the model-specifying, for instance, where to store the model output. |
---|
181 | |
---|
182 | |
---|
183 | \item Inputs various quantities describing physical measurements, such |
---|
184 | as the elevation, to be specified at each mesh point (vertex). |
---|
185 | |
---|
186 | \item Sets up the boundary conditions. |
---|
187 | |
---|
188 | \item Carries out the evolution of the model through a series of time |
---|
189 | steps and outputs the results, providing a results file that can |
---|
190 | be visualised. |
---|
191 | |
---|
192 | \end{enumerate} |
---|
193 | |
---|
194 | \section{The Code} |
---|
195 | |
---|
196 | %FIXME: we are using the \code function here. |
---|
197 | %This should be used whereever possible |
---|
198 | For reference we include below the complete code listing for |
---|
199 | \code{bedslope.py}. Subsequent paragraphs provide a `commentary' |
---|
200 | that describes each step of the program and explains it significance. |
---|
201 | |
---|
202 | |
---|
203 | {\scriptsize \begin{verbatim} |
---|
204 | from pyvolution.mesh_factory import rectangular |
---|
205 | from pyvolution.shallow_water import Domain, Reflective_boundary, |
---|
206 | Dirichlet_boundary, Time_boundary, Transmissive_boundary |
---|
207 | |
---|
208 | #Create basic mesh |
---|
209 | points, vertices, boundary = rectangular(10,10) |
---|
210 | |
---|
211 | #Create shallow water domain |
---|
212 | domain = Domain(points, vertices,boundary) |
---|
213 | domain.set_name('bedslope') |
---|
214 | |
---|
215 | |
---|
216 | ####################### |
---|
217 | # Initial conditions |
---|
218 | def f(x,y): |
---|
219 | return -x/2 |
---|
220 | |
---|
221 | domain.set_quantity('elevation', f) |
---|
222 | domain.set_quantity('friction', 0.1) |
---|
223 | |
---|
224 | h = 0.05 # Constant depth |
---|
225 | domain.set_quantity('stage', expression = 'elevation + %f' %h) |
---|
226 | |
---|
227 | |
---|
228 | # Boundary conditions |
---|
229 | from math import sin, pi |
---|
230 | Br = Reflective_boundary(domain) |
---|
231 | Bt = Transmissive_boundary(domain) |
---|
232 | Bd = Dirichlet_boundary([0.2,0.,0.]) |
---|
233 | |
---|
234 | Bw = Time_boundary(domain=domain, |
---|
235 | f=lambda t: [(0.1*sin(t*2*pi)), 0.0, 0.0]) |
---|
236 | |
---|
237 | |
---|
238 | domain.set_boundary({'left': Bd, 'right': Br, 'top': Br, 'bottom': Br}) |
---|
239 | |
---|
240 | |
---|
241 | ###################### |
---|
242 | #Evolution |
---|
243 | |
---|
244 | domain.check_integrity() |
---|
245 | |
---|
246 | for t in domain.evolve(yieldstep = 0.1, finaltime = 4.0): |
---|
247 | domain.write_time() |
---|
248 | |
---|
249 | |
---|
250 | \end{verbatim}} |
---|
251 | |
---|
252 | |
---|
253 | \section{Establishing the Mesh} |
---|
254 | |
---|
255 | The first task is to set up the triangular mesh to be used for the |
---|
256 | scenario. This is carried out through the statement: |
---|
257 | |
---|
258 | {\small \begin{verbatim} |
---|
259 | points, vertices, boundary = rectangular(10, 10) |
---|
260 | \end{verbatim}} |
---|
261 | |
---|
262 | The function \code{rectangular} is imported from a module |
---|
263 | \code{mesh\_factory} defined elsewhere. \anuga also |
---|
264 | contains several other schemes that can be used for setting up |
---|
265 | meshes, but we shall not discuss these now.) The above assignment |
---|
266 | sets up a $10 \times 10$ rectangular mesh, triangulated in a |
---|
267 | specific way. In general, the assignment |
---|
268 | |
---|
269 | {\small \begin{verbatim} |
---|
270 | points, vertices, boundary = rectangular(m, n) |
---|
271 | \end{verbatim}} |
---|
272 | |
---|
273 | returns: |
---|
274 | |
---|
275 | \begin{itemize} |
---|
276 | |
---|
277 | \item a list \code{points} of length $N$, where $N = (m + 1)(n + 1)$, |
---|
278 | comprising the coordinates $(x, y)$ of each of the $N$ mesh |
---|
279 | points, |
---|
280 | |
---|
281 | \item a list \code{vertices} of length $2mn$ (each entry specifies the three |
---|
282 | vertices of one of the triangles used in the triangulation) , and |
---|
283 | |
---|
284 | \item a dictionary \code{boundary}, used to tag the triangle edges on |
---|
285 | the boundaries. Each key corresponds to a triangle edge on one of |
---|
286 | the four boundaries and its value is one of \code{`left'}, |
---|
287 | \code{`right'}, \code{`top'} and \code{`bottom'}, indicating |
---|
288 | which boundary the edge in question belongs to. |
---|
289 | |
---|
290 | \end{itemize} |
---|
291 | |
---|
292 | |
---|
293 | \section{Initialising the domain} |
---|
294 | |
---|
295 | These variables are then used to set up a data structure |
---|
296 | \code{domain}, through the assignment: |
---|
297 | |
---|
298 | {\small \begin{verbatim} |
---|
299 | domain = Domain(points, vertices, boundary) |
---|
300 | \end{verbatim}} |
---|
301 | |
---|
302 | This uses a Python class \code{Domain}, imported from |
---|
303 | \code{shallow\_water}, which is an extension of a more generic |
---|
304 | class of the same name in the module \code{domain}, and inherits |
---|
305 | some methods from the generic class but has others specific to the |
---|
306 | shallow-water scenarios in which it is used. Specific options for domain |
---|
307 | are set at this point. One of them are to set the basename for the output file |
---|
308 | |
---|
309 | {\scriptsize \begin{verbatim} |
---|
310 | domain.set_name('bedslope') |
---|
311 | \end{verbatim}} |
---|
312 | |
---|
313 | |
---|
314 | \section{Specifying the Quantities} |
---|
315 | |
---|
316 | The next task is to specify a number of quantities that we wish to set |
---|
317 | for each mesh point. The class \code{Domain} has a method |
---|
318 | \code{set\_quantity}, used to specify these quantities. It is a |
---|
319 | particularly flexible method that allows the user to set quantities in |
---|
320 | a variety of ways---using constants, functions, numeric arrays or |
---|
321 | expressions involving other quantities, arbitrary data points with |
---|
322 | associated values, all of which can be passed as arguments. All |
---|
323 | quantities can be initialised using \code{set\_quantity}. For |
---|
324 | conserved quantities (\code{stage, xmomentum, ymomentum}) this is |
---|
325 | called the \emph{initial condition}, for other quantities that aren't |
---|
326 | updated by the equation, the same interface is used to assign their |
---|
327 | values. The code in the present example demonstrates a number of forms |
---|
328 | in which we can invoke \code{set\_quantity}. |
---|
329 | |
---|
330 | |
---|
331 | \subsection{Elevation} |
---|
332 | |
---|
333 | The elevation is set using a function, defined through the |
---|
334 | statements below, which is specific to this example and specifies |
---|
335 | a particularly simple initial configuration for demonstration |
---|
336 | purposes: |
---|
337 | |
---|
338 | {\small \begin{verbatim} |
---|
339 | def f(x,y): |
---|
340 | return -x/2 |
---|
341 | \end{verbatim}} |
---|
342 | |
---|
343 | This simply associates an elevation with each point $(x, y)$ of |
---|
344 | the plane. It specifies that the bed slopes linearly in the $x$ |
---|
345 | direction, with slope $-\frac{1}{2}$, and is constant in the $y$ |
---|
346 | direction.\\ %[screen shot?] |
---|
347 | \\ |
---|
348 | Once the function $f$ is specified, the quantity |
---|
349 | \code{elevation} is assigned through the simple statement: |
---|
350 | |
---|
351 | {\small \begin{verbatim} |
---|
352 | \begin{verbatim} |
---|
353 | domain.set_quantity('elevation', f) |
---|
354 | \end{verbatim}} |
---|
355 | |
---|
356 | |
---|
357 | \subsection{Friction} |
---|
358 | |
---|
359 | The assignment of the friction quantity demonstrates another way |
---|
360 | we can use \code{set\_quantity} to set quantities---namely, |
---|
361 | assign them to a constant numerical value: |
---|
362 | |
---|
363 | {\small \begin{verbatim} |
---|
364 | domain.set_quantity('friction', 0.1) |
---|
365 | \end{verbatim}} |
---|
366 | |
---|
367 | This just specifies that the Manning friction coefficient is set |
---|
368 | to 0.1 at every mesh point. |
---|
369 | |
---|
370 | \subsection{Depth} |
---|
371 | |
---|
372 | Assigning depth illustrates a more complex way to use |
---|
373 | \code{set\_quantity}, introducing an expression involving other |
---|
374 | quantities: |
---|
375 | |
---|
376 | {\small \begin{verbatim} |
---|
377 | h = 0.05 \# Constant depth |
---|
378 | domain.set_quantity('stage', expression = 'elevation + %f' %h) |
---|
379 | \end{verbatim}} |
---|
380 | |
---|
381 | Here the quantity \code{stage} is defined by taking the quantity |
---|
382 | elevation already defined and adding a constant value $h = 0.05$ |
---|
383 | to it everywhere. This expresses the fact that the water depth is |
---|
384 | everywhere constant, so the surface is a constant height above the |
---|
385 | elevation of the bed. |
---|
386 | |
---|
387 | \subsection{Boundary Conditions} |
---|
388 | |
---|
389 | The boundary conditions are specified as follows: |
---|
390 | |
---|
391 | {\small \begin{verbatim} |
---|
392 | Br = Reflective_boundary(domain) |
---|
393 | |
---|
394 | Bt = Transmissive_boundary(domain) |
---|
395 | |
---|
396 | Bd = Dirichlet_boundary([0.2,0.,0.]) |
---|
397 | |
---|
398 | Bw = Time_boundary(domain=domain, |
---|
399 | f=lambda t: [(0.1*sin(t*2*pi)), 0.0, 0.0]) |
---|
400 | \end{verbatim}} |
---|
401 | |
---|
402 | The effect of these statements is to set up four alternative |
---|
403 | boundary conditions and store them in variables that can be |
---|
404 | assigned as needed. Each boundary condition specifies the |
---|
405 | behaviour at a boundary in terms of the behaviour in neighbouring |
---|
406 | elements. The boundary conditions may be briefly described as |
---|
407 | follows: |
---|
408 | |
---|
409 | \begin{description} |
---|
410 | \item[Reflective boundary] Returns same \code{stage} as |
---|
411 | as present in its neighbour volume but momentum vector reversed 180 degrees (reflected). |
---|
412 | Specific to the shallow water equation as it works with the |
---|
413 | momentum quantities assumed to be the second and third conserved |
---|
414 | quantities. |
---|
415 | \item[Transmissive boundary]Returns same conserved quantities as |
---|
416 | those present in its neighbour volume. |
---|
417 | \item[Dirichlet boundary]Specifies a fixed value at the |
---|
418 | boundary. |
---|
419 | \item[Time boundary.]A Dirichlet boundary whose behaviour varies with time. |
---|
420 | \end{description} |
---|
421 | |
---|
422 | Once the four boundary types have been specified through the |
---|
423 | statements above, they can be applied through a statement of the |
---|
424 | form |
---|
425 | |
---|
426 | {\small \begin{verbatim} |
---|
427 | domain.set_boundary({'left': Bd, 'right': Br, 'top': Br, 'bottom': Br}) |
---|
428 | \end{verbatim}} |
---|
429 | |
---|
430 | This statement stipulates that, in the current example, the left |
---|
431 | boundary is fixed, with an elevation of 0.2, while the other |
---|
432 | boundaries are all reflective. |
---|
433 | |
---|
434 | |
---|
435 | \section{Evolution} |
---|
436 | |
---|
437 | The final statement \nopagebreak[3] |
---|
438 | {\small \begin{verbatim} |
---|
439 | for t in domain.evolve(yieldstep = 0.1, finaltime = 4.0): |
---|
440 | domain.write_time() |
---|
441 | \end{verbatim}} |
---|
442 | |
---|
443 | is the key step that causes the configuration of the domain to |
---|
444 | `evolve' in accordance with the model embodied in the code, over a |
---|
445 | series of steps indicated by the values of \code{yieldstep} and |
---|
446 | \code{finaltime}, which can be altered as required. |
---|
447 | The yieldstep control the time interval between model output. Behind the scenes more timesteps are generally taken. |
---|
448 | |
---|
449 | |
---|
450 | |
---|
451 | |
---|
452 | \section{Output} |
---|
453 | |
---|
454 | %Give details here of the form of the output and explain how it can |
---|
455 | %be used with swollen. Include screen shots.// |
---|
456 | |
---|
457 | The output is a NetCDF file with the extension \code{.sww}. It |
---|
458 | contains stage and momentum information and can be used with the |
---|
459 | \code{swollen} visualisation package to generate a visual display. |
---|
460 | |
---|
461 | |
---|
462 | \section{How to Run the Code} |
---|
463 | |
---|
464 | The code can be run in various ways: |
---|
465 | |
---|
466 | \begin{itemize} |
---|
467 | \item{from a Windows command line} as in \code{python bedslope.py} |
---|
468 | |
---|
469 | \item{within the Python IDLE environment} |
---|
470 | |
---|
471 | \item{within emacs} |
---|
472 | |
---|
473 | \item{from a Linux command line} as in \code{python bedslope.py} |
---|
474 | \end{itemize} |
---|
475 | |
---|
476 | |
---|
477 | \section{Example with real data} |
---|
478 | |
---|
479 | The following discussion builds on the \code{bedslope.py} example and |
---|
480 | shows how, using the same basic outline, we can incorporate many more |
---|
481 | complex features. |
---|
482 | |
---|
483 | The chief difference is in the method used to create the mesh. Instead of imposing a mesh |
---|
484 | structure on a rectangular grid, the technique used for this example involves building |
---|
485 | mesh structures inside polygons. |
---|
486 | |
---|
487 | In its simplest form, the mesh is created within a single polygon |
---|
488 | whose vertices are at geographical locations specified by the user. A |
---|
489 | triangular mesh is created using points inside the polygon selected |
---|
490 | through a random process, the user specifying the |
---|
491 | \emph{resolution}---that is, the maximal area of a triangle used for |
---|
492 | triangulation. |
---|
493 | |
---|
494 | Figure XXX shows a simple example, in which the triangulation is |
---|
495 | carried out within a pentagon. Instead of using the four tags |
---|
496 | \code{`left'}, \code{`right'}, \code{`bottom'} and |
---|
497 | \code{`top'} to distinguish boundary elements, the user can define |
---|
498 | tags appropriate to the configuration being modelled. |
---|
499 | |
---|
500 | While this offers more flexibility than the rectangular grid, it |
---|
501 | doesn't provide a way to adapt to geographic or other features in the |
---|
502 | landscape, for which we may require to vary the resolution. We achieve |
---|
503 | more flexibility by extending this method, allowing the user to |
---|
504 | specify a number of interior polygons which are triangulated |
---|
505 | separately, possibly using different resolutions. See Figure XXX. |
---|
506 | |
---|
507 | |
---|
508 | \chapter{ANUGA Public Interface} |
---|
509 | |
---|
510 | thoaedut |
---|
511 | |
---|
512 | |
---|
513 | |
---|
514 | \begin{itemize} |
---|
515 | |
---|
516 | \item \indexedcode{create_mesh_from_region}: Create mesh based on a bounding polygon and a number of internal polygons. Each polygon has a maximal area of triangles associated with it - the resolution. The bounding polygon also has symbolic \code{tags} associated with it. |
---|
517 | Arguments are: |
---|
518 | \item \indexedcode{pmesh_to_domain_instance}: Convert generated mesh file to domain object. Arguments are: Mesh file name and class specifying which domain class to instantiate. (Simpler) |
---|
519 | |
---|
520 | \item \indexedcode{file_function} %in util.py "High priority" |
---|
521 | \item \indexedcode{Interpolation_function} %In least_squares.py ("High priority") |
---|
522 | |
---|
523 | \item \indexedcode{set_region} ``Low priority. Will be merged into set\_quantity'' |
---|
524 | \item \indexedcode{set_quantity} ``Pretty mature'' |
---|
525 | \item \indexedcode{set_boundary} ``Pretty mature'' |
---|
526 | |
---|
527 | \end{itemize} |
---|
528 | |
---|
529 | |
---|
530 | Diagnostics |
---|
531 | \begin{itemize} |
---|
532 | \item \indexedcode{write_time} |
---|
533 | \item \indexedcode{write_boundary_statistics} |
---|
534 | |
---|
535 | |
---|
536 | \end{itemize} |
---|
537 | |
---|
538 | |
---|
539 | \subsection{Boundary conditions} |
---|
540 | |
---|
541 | ANUGA provides a large number of predefined boundary conditions to be used with |
---|
542 | \code{set_boundary} |
---|
543 | |
---|
544 | What do they do |
---|
545 | How are they used |
---|
546 | |
---|
547 | \begin{itemize} |
---|
548 | \item \indexedcode{Reflective_boundary} |
---|
549 | function, arguments |
---|
550 | |
---|
551 | \item \indexedcode{Transmissive_boundary} |
---|
552 | function, arguments, CAVEATS |
---|
553 | |
---|
554 | \item \indexedcode{Dirichlet_boundary} |
---|
555 | |
---|
556 | \item \indexedcode{Time_boundary} |
---|
557 | |
---|
558 | \item \indexedcode{File_boundary} |
---|
559 | Based on File\_function |
---|
560 | |
---|
561 | \item \indexedcode{} |
---|
562 | |
---|
563 | \item \indexedcode{} |
---|
564 | |
---|
565 | |
---|
566 | \item \indexedcode{User defined boundary conditions.} |
---|
567 | How to roll your own |
---|
568 | |
---|
569 | |
---|
570 | |
---|
571 | \end{itemize} |
---|
572 | |
---|
573 | |
---|
574 | |
---|
575 | \subsection{Initial conditions} |
---|
576 | |
---|
577 | ANUGA provides a number of predefined initial conditions to be used with |
---|
578 | \code{set_quantity}. |
---|
579 | |
---|
580 | \begin{itemize} |
---|
581 | |
---|
582 | |
---|
583 | \item \indexedcode{tsunami_slump} |
---|
584 | function, arguments |
---|
585 | |
---|
586 | \item \indexedcode{} |
---|
587 | |
---|
588 | \end{itemize} |
---|
589 | |
---|
590 | |
---|
591 | \subsection{Initial conditions} |
---|
592 | |
---|
593 | ANUGA provides a number of predefined forcing functions to be used with ..... |
---|
594 | |
---|
595 | \begin{itemize} |
---|
596 | |
---|
597 | |
---|
598 | \item \indexedcode{} |
---|
599 | function, arguments |
---|
600 | |
---|
601 | \item \indexedcode{} |
---|
602 | |
---|
603 | \end{itemize} |
---|
604 | |
---|
605 | |
---|
606 | |
---|
607 | |
---|
608 | \chapter{ANUGA system architecture} |
---|
609 | |
---|
610 | Take some stuff from pyvolution/documentation and update it. |
---|
611 | |
---|
612 | |
---|
613 | |
---|
614 | |
---|
615 | |
---|
616 | \appendix |
---|
617 | |
---|
618 | \chapter{Supporting tools} |
---|
619 | |
---|
620 | |
---|
621 | \section{caching} Could do now. |
---|
622 | |
---|
623 | |
---|
624 | |
---|
625 | \section{swollen} Could do now. |
---|
626 | |
---|
627 | |
---|
628 | \section{utilities/polygons} Could do now. |
---|
629 | |
---|
630 | \begin{itemize} |
---|
631 | \item \indexedcode{polygon_function} |
---|
632 | \item \indexedcode{read_polygon} |
---|
633 | \item \indexedcode{populate_polygon} |
---|
634 | \item \indexedcode{point_in_polygon} |
---|
635 | \item \indexedcode{inside_polygon} |
---|
636 | \item \indexedcode{outside_polygon} |
---|
637 | \item \indexedcode{point_on_line} |
---|
638 | \item \indexedcode{separate_points_by_polygon} |
---|
639 | \end{itemize} |
---|
640 | |
---|
641 | |
---|
642 | |
---|
643 | |
---|
644 | |
---|
645 | \section{coordinate_transforms} |
---|
646 | |
---|
647 | \section{geo_spatial_data} |
---|
648 | |
---|
649 | \section{pmesh GUI} |
---|
650 | |
---|
651 | \section{alpha_shape} |
---|
652 | |
---|
653 | |
---|
654 | |
---|
655 | |
---|
656 | |
---|
657 | \chapter{Glossary} |
---|
658 | |
---|
659 | \begin{itemize} |
---|
660 | \item \indexedbold{ANUGA} name of software (joint development between ANU and GA) |
---|
661 | |
---|
662 | \item \indexedbold{Conserved quantity} |
---|
663 | |
---|
664 | \item \indexedbold{Default order} is this really needed? |
---|
665 | |
---|
666 | \item \indexedbold{Domain} |
---|
667 | |
---|
668 | \item \indexedbold{Dirichlet boundary} |
---|
669 | |
---|
670 | \item \indexedbold{Elevation} - refers to bathymetry and topography |
---|
671 | |
---|
672 | \item \indexedbold{bathymetry} offshore |
---|
673 | |
---|
674 | \item \indexedbold{topography} onshore |
---|
675 | |
---|
676 | \item \indexedbold{Evolution} integration of the shallow water wave equations over time |
---|
677 | |
---|
678 | \item \indexedbold{Forcing term} |
---|
679 | |
---|
680 | \item \indexedbold{IDLE} development environment shipped with Python |
---|
681 | |
---|
682 | \item \indexedbold{Manning friction coefficient} |
---|
683 | |
---|
684 | \item \indexedbold{Mesh} triangulation of domain |
---|
685 | |
---|
686 | \item \indexedbold{Grid} evenly spaced |
---|
687 | |
---|
688 | \item \indexedbold{NetCDF} |
---|
689 | |
---|
690 | \item \indexedbold{pmesh} does this really need to be here? it's a class/module? |
---|
691 | |
---|
692 | \item \indexedbold{pyvolution} does this really need to be here? it's a class/module? |
---|
693 | |
---|
694 | \item \indexedbold{Quantity} conserved (state, x and y momentum) |
---|
695 | |
---|
696 | \item \indexedbold{Reflective boundary} |
---|
697 | |
---|
698 | \item \indexedbold{Smoothing} is this really needed? |
---|
699 | |
---|
700 | \item \indexedbold{Stage} |
---|
701 | |
---|
702 | \item \indexedbold{Swollen} visualisation tool |
---|
703 | |
---|
704 | \item \indexedbold{Time boundary} defined in the manual (flog from there) |
---|
705 | |
---|
706 | \item \indexedbold{Transmissive boundary} defined in the manual (flog from there) |
---|
707 | |
---|
708 | \item \indexedbold{xmomentum} conserved quantity (note, two-dimensional SWW equations say only x and y and NOT z) |
---|
709 | |
---|
710 | \item \indexedbold{ymomentum} conserved quantity |
---|
711 | |
---|
712 | \item \indexedbold{resolution} refers to the maximal area of each triangular cell in the mesh |
---|
713 | |
---|
714 | \item \indexedbold{polygon} A sequence of points in the plane. (Arbitrary polygons can be created in this way ) |
---|
715 | ANUGA represents polygons as either a list of 2-tuples, where the latter are either Python tuples or Python lists of length 2. The unit square, for example, would be represented by the polygon [ [0,0], [1,0], [1,1], [0,1] ]. Alternatively, polygons can be represented as $N \times 2$ Numeric arrays, where $N$ is the number of points. |
---|
716 | |
---|
717 | NOTE: More can be read in the module utilities/polygon.py .... |
---|
718 | |
---|
719 | \item \indexedbold{easting} |
---|
720 | |
---|
721 | \item \indexedbold{northing} |
---|
722 | |
---|
723 | \item \indexedbold{latitude} |
---|
724 | |
---|
725 | \item \indexedbold{longitude} |
---|
726 | |
---|
727 | \item \indexedbold{edge} |
---|
728 | |
---|
729 | \item \indexedbold{vertex} |
---|
730 | |
---|
731 | \item \indexedbold{finite volume} |
---|
732 | |
---|
733 | \item \indexedbold{flux} |
---|
734 | |
---|
735 | \item \indexedbold{Digital Elevation Model (DEM)} |
---|
736 | |
---|
737 | |
---|
738 | \end{itemize} |
---|
739 | |
---|
740 | The \code{\e appendix} markup need not be repeated for additional |
---|
741 | appendices. |
---|
742 | |
---|
743 | |
---|
744 | % |
---|
745 | % The ugly "%begin{latexonly}" pseudo-environments are really just to |
---|
746 | % keep LaTeX2HTML quiet during the \renewcommand{} macros; they're |
---|
747 | % not really valuable. |
---|
748 | % |
---|
749 | % If you don't want the Module Index, you can remove all of this up |
---|
750 | % until the second \input line. |
---|
751 | % |
---|
752 | |
---|
753 | %begin{latexonly} |
---|
754 | %\renewcommand{\indexname}{Module Index} |
---|
755 | %end{latexonly} |
---|
756 | %\input{mod\jobname.ind} % Module Index |
---|
757 | |
---|
758 | %begin{latexonly} |
---|
759 | \renewcommand{\indexname}{Index} |
---|
760 | %end{latexonly} |
---|
761 | \input{\jobname.ind} % Index |
---|
762 | |
---|
763 | |
---|
764 | |
---|
765 | \end{document} |
---|