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 | \input{definitions} |
---|
17 | |
---|
18 | |
---|
19 | \documentclass{manual} |
---|
20 | |
---|
21 | \title{\anuga User Manual} |
---|
22 | \author{Howard Silcock, Ole Nielsen, Duncan Gray, Jane Sexton} |
---|
23 | |
---|
24 | % Please at least include a long-lived email address; |
---|
25 | % the rest is at your discretion. |
---|
26 | \authoraddress{Geoscience Australia \\ |
---|
27 | Email: \email{ole.nielsen@ga.gov.au} |
---|
28 | } |
---|
29 | |
---|
30 | %Draft date |
---|
31 | \date{\today} % update before release! |
---|
32 | % Use an explicit date so that reformatting |
---|
33 | % doesn't cause a new date to be used. Setting |
---|
34 | % the date to \today can be used during draft |
---|
35 | % stages to make it easier to handle versions. |
---|
36 | |
---|
37 | \release{1.0} % release version; this is used to define the |
---|
38 | % \version macro |
---|
39 | |
---|
40 | \makeindex % tell \index to actually write the .idx file |
---|
41 | %\makemodindex % If this contains a lot of module sections. |
---|
42 | |
---|
43 | \setcounter{tocdepth}{3} |
---|
44 | |
---|
45 | \begin{document} |
---|
46 | \maketitle |
---|
47 | |
---|
48 | % This makes the contents more accessible from the front page of the HTML. |
---|
49 | \ifhtml |
---|
50 | \chapter*{Front Matter\label{front}} |
---|
51 | \fi |
---|
52 | |
---|
53 | %Subversion keywords: |
---|
54 | % |
---|
55 | %$LastChangedDate: 2006-03-02 23:57:05 +0000 (Thu, 02 Mar 2006) $ |
---|
56 | %$LastChangedRevision: 2474 $ |
---|
57 | %$LastChangedBy: howard $ |
---|
58 | |
---|
59 | \input{copyright} |
---|
60 | |
---|
61 | |
---|
62 | \begin{abstract} |
---|
63 | |
---|
64 | \noindent \anuga\index{\anuga} is a hydrodynamic modelling tool that |
---|
65 | allows users to model realistic flow problems in complex geometries. |
---|
66 | Examples include dam breaks or the effects of natural hazards such |
---|
67 | as riverine flooding, storm surges and tsunami. |
---|
68 | |
---|
69 | The user must specify a study area represented by a mesh of triangular |
---|
70 | cells, the topography and bathymetry, frictional resistance, initial |
---|
71 | values for water level (called \emph{stage}\index{stage} within \anuga), |
---|
72 | boundary |
---|
73 | conditions and forces such as windstress or pressure gradients if |
---|
74 | applicable. |
---|
75 | |
---|
76 | \anuga tracks the evolution of water depth and horizontal momentum |
---|
77 | within each cell over time by solving the shallow water wave equation |
---|
78 | governing equation using a finite-volume method. |
---|
79 | |
---|
80 | \anuga cannot model details of breaking waves, flow under ceilings such |
---|
81 | as pipes, turbulence and vortices, vertical convection or viscous |
---|
82 | flows. |
---|
83 | |
---|
84 | \anuga also incorporates a mesh generator, called \code{pmesh}, that |
---|
85 | allows the user to set up the geometry of the problem interactively as |
---|
86 | well as tools for interpolation and surface fitting, and a number of |
---|
87 | auxiliary tools for visualising and interrogating the model output. |
---|
88 | |
---|
89 | Most \anuga components are written in the object-oriented programming |
---|
90 | language Python and most users will interact with \anuga by writing |
---|
91 | small Python programs based on the \anuga library |
---|
92 | functions. Computationally intensive components are written for |
---|
93 | efficiency in C routines working directly with the Numerical Python |
---|
94 | structures. |
---|
95 | |
---|
96 | |
---|
97 | \end{abstract} |
---|
98 | |
---|
99 | \tableofcontents |
---|
100 | |
---|
101 | |
---|
102 | \chapter{Introduction} |
---|
103 | |
---|
104 | |
---|
105 | \section{Purpose} |
---|
106 | |
---|
107 | The purpose of this user manual is to introduce the new user to |
---|
108 | the software, describe what it can do and give step-by-step |
---|
109 | instructions for setting up, configuring and running the software. |
---|
110 | |
---|
111 | \section{Scope} |
---|
112 | |
---|
113 | This manual covers only what is needed to operate the software |
---|
114 | after installation. It does not includes instructions for |
---|
115 | installing the software or detailed API documentation, both of |
---|
116 | which will be covered in separate publications. |
---|
117 | |
---|
118 | \section{Audience} |
---|
119 | |
---|
120 | Readers are assumed to be familiar with the operating environment |
---|
121 | and have a general understanding of the problem background, as |
---|
122 | well as enough programming experience to adapt the code to |
---|
123 | different requirements, as described in this manual, and to |
---|
124 | understand the basic terminology of object-oriented programming. |
---|
125 | |
---|
126 | \section{Structure of This Manual} |
---|
127 | |
---|
128 | This manual is structured as follows: |
---|
129 | |
---|
130 | \begin{itemize} |
---|
131 | \item Background (What \anuga does) |
---|
132 | \item A \emph{Getting Started} section |
---|
133 | \item A detailed description of the public interface |
---|
134 | \item \anuga 's overall architecture, components and file formats |
---|
135 | \item Assumptions |
---|
136 | \end{itemize} |
---|
137 | |
---|
138 | |
---|
139 | \pagebreak |
---|
140 | \chapter{Getting Started} |
---|
141 | |
---|
142 | This section is designed to assist the reader to get started with |
---|
143 | \anuga by working through simple examples. Two examples are discussed; |
---|
144 | the first is a simple but artificial example that is useful to illustrate |
---|
145 | many of the ideas, and the second is a real-life example. |
---|
146 | |
---|
147 | \section{A Simple Example} |
---|
148 | |
---|
149 | \subsection{Overview} |
---|
150 | |
---|
151 | What follows |
---|
152 | is a discussion of the structure and operation of the file |
---|
153 | \code{bedslope.py}, with just enough detail to allow the reader |
---|
154 | to appreciate what's involved in setting up a scenario like the |
---|
155 | one it depicts. |
---|
156 | |
---|
157 | This example carries out the solution of the shallow-water wave |
---|
158 | equation in the simple case of a configuration comprising a flat |
---|
159 | bed, sloping at a fixed angle in one direction and having a |
---|
160 | constant depth across each line in the perpendicular direction. |
---|
161 | |
---|
162 | The example demonstrates many of the basic ideas involved in |
---|
163 | setting up a more complex scenario. In the general case the user |
---|
164 | specifies the geometry (bathymetry and topography), the initial |
---|
165 | water level, boundary conditions such as tide, and any forcing |
---|
166 | terms that may drive the system such as wind stress or atmospheric |
---|
167 | pressure gradients. Frictional resistance from the different |
---|
168 | terrains in the model is represented by predefined forcing |
---|
169 | terms. The boundary is reflective on three sides and a time dependent wave on one side. |
---|
170 | |
---|
171 | The present example, as it represents a simple scenario, does not |
---|
172 | include any forcing term, nor is the data taken from a file as it |
---|
173 | would be in many typical cases. The quantities involved in the |
---|
174 | present problem are: |
---|
175 | \begin{itemize} |
---|
176 | \item elevation\index{elevation} |
---|
177 | \item friction\index{friction} |
---|
178 | \item depth\index{depth} |
---|
179 | \item stage\index{stage} |
---|
180 | \end{itemize} |
---|
181 | |
---|
182 | %\emph{[More details of the problem background]} |
---|
183 | |
---|
184 | \subsection{Outline of the Program} |
---|
185 | |
---|
186 | In outline, \code{bedslope.py} performs the following steps: |
---|
187 | |
---|
188 | \begin{enumerate} |
---|
189 | |
---|
190 | \item Sets up a triangular mesh. |
---|
191 | |
---|
192 | \item Sets certain parameters governing the mode of |
---|
193 | operation of the model-specifying, for instance, where to store the model output. |
---|
194 | |
---|
195 | \item Inputs various quantities describing physical measurements, such |
---|
196 | as the elevation, to be specified at each mesh point (vertex). |
---|
197 | |
---|
198 | \item Sets up the boundary conditions. |
---|
199 | |
---|
200 | \item Carries out the evolution of the model through a series of time |
---|
201 | steps and outputs the results, providing a results file that can |
---|
202 | be visualised. |
---|
203 | |
---|
204 | \end{enumerate} |
---|
205 | |
---|
206 | \subsection{The Code} |
---|
207 | |
---|
208 | %FIXME: we are using the \code function here. |
---|
209 | %This should be used wherever possible |
---|
210 | For reference we include below the complete code listing for |
---|
211 | \code{bedslope.py}. Subsequent paragraphs provide a `commentary' |
---|
212 | that describes each step of the program and explains it significance. |
---|
213 | |
---|
214 | \verbatiminput{../../inundation/examples/bedslope.py} |
---|
215 | |
---|
216 | \subsection{Establishing the Mesh} |
---|
217 | |
---|
218 | The first task is to set up the triangular mesh to be used for the |
---|
219 | scenario. This is carried out through the statement: |
---|
220 | |
---|
221 | {\small \begin{verbatim} |
---|
222 | points, vertices, boundary = rectangular(10, 10) |
---|
223 | \end{verbatim}} |
---|
224 | |
---|
225 | The function \code{rectangular} is imported from a module |
---|
226 | \code{mesh\_factory} defined elsewhere. (\anuga also contains |
---|
227 | several other schemes that can be used for setting up meshes, but we |
---|
228 | shall not discuss these now.) The above assignment sets up a $10 |
---|
229 | \times 10$ rectangular mesh, triangulated in a specific way. In |
---|
230 | general, the assignment |
---|
231 | |
---|
232 | {\small \begin{verbatim} |
---|
233 | points, vertices, boundary = rectangular(m, n) |
---|
234 | \end{verbatim}} |
---|
235 | |
---|
236 | returns: |
---|
237 | |
---|
238 | \begin{itemize} |
---|
239 | |
---|
240 | \item a list \code{points} of length $N$, where $N = (m + 1)(n + 1)$, |
---|
241 | comprising the coordinates $(x, y)$ of each of the $N$ mesh points, |
---|
242 | |
---|
243 | \item a list \code{vertices} of length $2mn$ (each entry specifies the three |
---|
244 | vertices of one of the triangles used in the triangulation) , and |
---|
245 | |
---|
246 | \item a dictionary \code{boundary}, used to tag the triangle edges on |
---|
247 | the boundaries. Each key corresponds to a triangle edge on one of |
---|
248 | the four boundaries and its value is one of \code{`left'}, |
---|
249 | \code{`right'}, \code{`top'} and \code{`bottom'}, indicating |
---|
250 | which boundary the edge in question belongs to. |
---|
251 | |
---|
252 | \end{itemize} |
---|
253 | |
---|
254 | |
---|
255 | \subsection{Initialising the Domain} |
---|
256 | |
---|
257 | These variables are then used to set up a data structure |
---|
258 | \code{domain}, through the assignment: |
---|
259 | |
---|
260 | {\small \begin{verbatim} |
---|
261 | domain = Domain(points, vertices, boundary) |
---|
262 | \end{verbatim}} |
---|
263 | |
---|
264 | This uses a Python class \code{Domain}, imported from |
---|
265 | \code{shallow\_water}, which is an extension of a more generic |
---|
266 | class of the same name in the module \code{domain}, and inherits |
---|
267 | some methods from the generic class but has others specific to the |
---|
268 | shallow-water scenarios in which it is used. Specific options for domain |
---|
269 | are set at this point. One of them is to set the basename for the output file: |
---|
270 | |
---|
271 | {\small \begin{verbatim} |
---|
272 | domain.set_name('bedslope') |
---|
273 | \end{verbatim}} |
---|
274 | |
---|
275 | |
---|
276 | \subsection{Specifying the Quantities} |
---|
277 | |
---|
278 | The next task is to specify a number of quantities that we wish to set |
---|
279 | for each mesh point. The class \code{Domain} has a method |
---|
280 | \code{set\_quantity}, used to specify these quantities. It is a |
---|
281 | particularly flexible method that allows the user to set quantities in |
---|
282 | a variety of ways---using constants, functions, numeric arrays or |
---|
283 | expressions involving other quantities, arbitrary data points with |
---|
284 | associated values, all of which can be passed as arguments. All |
---|
285 | quantities can be initialised using \code{set\_quantity}. For |
---|
286 | conserved quantities (\code{stage, xmomentum, ymomentum}) this is |
---|
287 | called the \emph{initial condition}, for other quantities that aren't |
---|
288 | updated by the equation, the same interface is used to assign their |
---|
289 | values. The code in the present example demonstrates a number of forms |
---|
290 | in which we can invoke \code{set\_quantity}. |
---|
291 | |
---|
292 | |
---|
293 | \subsubsection{Elevation} |
---|
294 | |
---|
295 | The elevation, or height of the bed, is set using a function, |
---|
296 | defined through the statements below, which is specific to this |
---|
297 | example and specifies a particularly simple initial configuration |
---|
298 | for demonstration purposes: |
---|
299 | |
---|
300 | {\small \begin{verbatim} |
---|
301 | def f(x,y): |
---|
302 | return -x/2 |
---|
303 | \end{verbatim}} |
---|
304 | |
---|
305 | This simply associates an elevation with each point $(x, y)$ of |
---|
306 | the plane. It specifies that the bed slopes linearly in the $x$ |
---|
307 | direction, with slope $-\frac{1}{2}$, and is constant in the $y$ |
---|
308 | direction.\\ %[screen shot?] |
---|
309 | \\ |
---|
310 | Once the function $f$ is specified, the quantity |
---|
311 | \code{elevation} is assigned through the simple statement: |
---|
312 | |
---|
313 | {\small \begin{verbatim} |
---|
314 | domain.set_quantity('elevation', f) |
---|
315 | \end{verbatim}} |
---|
316 | |
---|
317 | |
---|
318 | \subsubsection{Friction} |
---|
319 | |
---|
320 | The assignment of the friction quantity demonstrates another way |
---|
321 | we can use \code{set\_quantity} to set quantities---namely, |
---|
322 | assign them to a constant numerical value: |
---|
323 | |
---|
324 | {\small \begin{verbatim} |
---|
325 | domain.set_quantity('friction', 0.1) |
---|
326 | \end{verbatim}} |
---|
327 | |
---|
328 | This just specifies that the Manning friction coefficient is set |
---|
329 | to 0.1 at every mesh point. |
---|
330 | |
---|
331 | \subsubsection{Stage} |
---|
332 | |
---|
333 | The stage (the height of the water surface) is related to the |
---|
334 | elevation and the depth at any time by the equation \[\code{stage} = |
---|
335 | \code{elevation} + \code{depth}\] To specify a constant depth of a |
---|
336 | particular value, therefore, we need to specify that \code{stage} is |
---|
337 | everywhere obtained by adding that constant value to the already |
---|
338 | specified \code{elevation}. Doing this allows us to illustrate |
---|
339 | another way to use \code{set\_quantity}, introducing an expression |
---|
340 | involving other quantities: |
---|
341 | |
---|
342 | {\small \begin{verbatim} |
---|
343 | h = 0.05 \# Constant depth |
---|
344 | domain.set_quantity('stage', expression = 'elevation + %f' %h) |
---|
345 | \end{verbatim}} |
---|
346 | |
---|
347 | Here we are stipulating that the quantity \code{stage} is defined by |
---|
348 | taking the quantity elevation already defined and adding a constant |
---|
349 | value $h = 0.05$ to it everywhere. |
---|
350 | |
---|
351 | \subsubsection{Boundary Conditions} |
---|
352 | |
---|
353 | The boundary conditions are specified as follows: |
---|
354 | |
---|
355 | {\small \begin{verbatim} |
---|
356 | Br = Reflective_boundary(domain) |
---|
357 | |
---|
358 | Bt = Transmissive_boundary(domain) |
---|
359 | |
---|
360 | Bd = Dirichlet_boundary([0.2,0.,0.]) |
---|
361 | |
---|
362 | Bw = Time_boundary(domain=domain, |
---|
363 | f=lambda t: [(0.1*sin(t*2*pi)), 0.0, 0.0]) |
---|
364 | \end{verbatim}} |
---|
365 | |
---|
366 | The effect of these statements is to set up four alternative |
---|
367 | boundary conditions and store them in variables that can be |
---|
368 | assigned as needed. Each boundary condition specifies the |
---|
369 | behaviour at a boundary in terms of the behaviour in neighbouring |
---|
370 | elements. The boundary conditions may be briefly described as |
---|
371 | follows: |
---|
372 | |
---|
373 | \begin{description} |
---|
374 | \item[Reflective boundary] Returns same \code{stage} as |
---|
375 | as present in its neighbour volume but momentum vector reversed 180 degrees (reflected). |
---|
376 | Specific to the shallow water equation as it works with the |
---|
377 | momentum quantities assumed to be the second and third conserved |
---|
378 | quantities. |
---|
379 | |
---|
380 | \item[Transmissive boundary]Returns same conserved quantities as |
---|
381 | those present in its neighbour volume. |
---|
382 | |
---|
383 | \item[Dirichlet boundary]Specifies a fixed value at the |
---|
384 | boundary. |
---|
385 | |
---|
386 | \item[Time boundary.]A Dirichlet boundary whose behaviour varies with time. |
---|
387 | \end{description} |
---|
388 | |
---|
389 | Once the four boundary types have been specified through the |
---|
390 | statements above, they can be applied through a statement of the |
---|
391 | form |
---|
392 | |
---|
393 | {\small \begin{verbatim} |
---|
394 | domain.set_boundary({'left': Bd, 'right': Br, 'top': Br, 'bottom': Br}) |
---|
395 | \end{verbatim}} |
---|
396 | |
---|
397 | This statement stipulates that, in the current example, the left |
---|
398 | boundary is fixed, with an elevation of 0.2, while the other |
---|
399 | boundaries are all reflective. |
---|
400 | |
---|
401 | |
---|
402 | \subsection{Evolution} |
---|
403 | |
---|
404 | The final statement \nopagebreak[3] |
---|
405 | {\small \begin{verbatim} |
---|
406 | for t in domain.evolve(yieldstep = 0.1, finaltime = 4.0): |
---|
407 | domain.write_time() |
---|
408 | \end{verbatim}} |
---|
409 | |
---|
410 | is the key step that causes the configuration of the domain to |
---|
411 | `evolve' in accordance with the model embodied in the code, over a |
---|
412 | series of steps indicated by the values of \code{yieldstep} and |
---|
413 | \code{finaltime}, which can be altered as required. |
---|
414 | The value of \code{yieldstep} controls the time interval between successive model outputs. |
---|
415 | Behind the scenes more time steps are generally taken. |
---|
416 | |
---|
417 | |
---|
418 | \subsection{Output} |
---|
419 | |
---|
420 | %Give details here of the form of the output and explain how it can |
---|
421 | %be used with swollen. Include screen shots.// |
---|
422 | |
---|
423 | The output is a NetCDF file with the extension \code{.sww}. It |
---|
424 | contains stage and momentum information and can be used with the |
---|
425 | \code{swollen} visualisation package to generate a visual display. |
---|
426 | |
---|
427 | |
---|
428 | \section{How to Run the Code} |
---|
429 | |
---|
430 | The code can be run in various ways: |
---|
431 | |
---|
432 | \begin{itemize} |
---|
433 | \item{from a Windows command line} as in \code{python bedslope.py} |
---|
434 | \item{within the Python IDLE environment} |
---|
435 | \item{within emacs} |
---|
436 | \item{from a Linux command line} as in \code{python bedslope.py} |
---|
437 | \end{itemize} |
---|
438 | |
---|
439 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
440 | |
---|
441 | \section{An Example with Real Data} |
---|
442 | |
---|
443 | The following discussion builds on the concepts introduced through |
---|
444 | the \code{bedslope.py} example and introduces a second example, |
---|
445 | \code{run\_sydney\_smf.py}, that follows the same basic outline, but |
---|
446 | incorporates more complex features and refers to a real-life |
---|
447 | scenario, rather than the artificial illustrative one used in |
---|
448 | \code{bedslope.py}. [Include details of the scenario to which it |
---|
449 | refers??] |
---|
450 | |
---|
451 | \subsection{Overview} |
---|
452 | As in the case of \code{bedslope.py}, the actions carried out by the |
---|
453 | program can be organised according to this outline: |
---|
454 | |
---|
455 | \begin{enumerate} |
---|
456 | |
---|
457 | \item Set up a triangular mesh. |
---|
458 | |
---|
459 | \item Set certain parameters governing the mode of |
---|
460 | operation of the model-specifying, for instance, where to store the |
---|
461 | model output. |
---|
462 | |
---|
463 | \item Input various quantities describing physical measurements, such |
---|
464 | as the elevation, to be specified at each mesh point (vertex). |
---|
465 | |
---|
466 | \item Set up the boundary conditions. |
---|
467 | |
---|
468 | \item Carry out the evolution of the model through a series of time |
---|
469 | steps and outputs the results, providing a results file that can be |
---|
470 | visualised. |
---|
471 | |
---|
472 | \end{enumerate} |
---|
473 | |
---|
474 | |
---|
475 | |
---|
476 | \subsection{The Code} |
---|
477 | |
---|
478 | Here is the code for \code{run\_sydney\_smf.py}: |
---|
479 | |
---|
480 | \verbatiminput{"runsydneysmf.py"} |
---|
481 | |
---|
482 | In discussing the details of this example, we follow the outline |
---|
483 | given above, discussing each major step of the code in turn. |
---|
484 | |
---|
485 | \subsection{Establishing the Mesh} |
---|
486 | |
---|
487 | One obvious way that the present example differs from |
---|
488 | \code{bedslope.py} is in the use of a more complex method to create |
---|
489 | the mesh. Instead of imposing a mesh structure on a rectangular |
---|
490 | grid, the technique used for this example involves building mesh |
---|
491 | structures inside polygons specified by the user, using a |
---|
492 | mesh-generator referred to as \code{pmesh}. |
---|
493 | |
---|
494 | The following remarks may help the reader understand how |
---|
495 | \code{pmesh} is used. |
---|
496 | |
---|
497 | In its simplest form, \code{pmesh} creates the mesh within a single |
---|
498 | polygon whose vertices are at geographical locations specified by |
---|
499 | the user. The user specifies the \emph{resolution}---that is, the |
---|
500 | maximal area of a triangle used for triangulation---and mesh points |
---|
501 | are created inside the polygon through a random process. Figure XXX |
---|
502 | shows a simple example of this, in which the triangulation is |
---|
503 | carried out within a pentagon. |
---|
504 | |
---|
505 | Boundary tags are not restricted to \code{`left'}, \code{`right'}, |
---|
506 | \code{`bottom'} and \code{`top'}, as in the case of |
---|
507 | \code{bedslope.py}. Instead the user specifies a list of tags |
---|
508 | appropriate to the configuration being modelled. |
---|
509 | |
---|
510 | While a mesh created inside a polygon offers more flexibility than |
---|
511 | one based on a rectangular grid, using \code{pmesh} in the limited |
---|
512 | form we have described so far still doesn't provide a way to adapt |
---|
513 | to geographic or other features in the landscape, whose presence may |
---|
514 | require us to vary the resolution in the neighbourhood of the |
---|
515 | features. To cope with this requirement, \code{pmesh} also allows |
---|
516 | the user to specify a number of \emph{interior polygons}, which are |
---|
517 | triangulated separately, each according to a separately specified |
---|
518 | resolution. See Figure XXX. |
---|
519 | |
---|
520 | In its general form, \code{pmesh} takes for its input a bounding |
---|
521 | polygon and (optionally) a list of interior polygons. The user |
---|
522 | specifies resolutions, both for the bounding polygon and for each of |
---|
523 | the interior polygons. Given this data, \code{pmesh} first creates a |
---|
524 | triangular mesh inside the bounding polygon, using the specified |
---|
525 | resolution, and then creates a separate triangulation inside each of |
---|
526 | the interior polygons, using the resolution specified for that |
---|
527 | polygon. |
---|
528 | |
---|
529 | The function used to implement this process is |
---|
530 | \code{create\_mesh\_from\_regions}. Its arguments include the |
---|
531 | bounding polygon and its resolution, a list of boundary tags, and a |
---|
532 | list of pairs \code{[polygon, resolution]}, specifying the interior |
---|
533 | polygons and their resolutions. |
---|
534 | |
---|
535 | In practice, the details of the polygons used are read from a |
---|
536 | separate file \code{project.py}. The resulting mesh is output to a |
---|
537 | \emph{meshfile}\index{meshfile}. This term is used to describe a |
---|
538 | file of a specific format used to store the data specifying a mesh. |
---|
539 | (There are in fact two possible formats for such a file: it can |
---|
540 | either be a binary file, with extension \code{.msh}, or an ASCII |
---|
541 | file, with extension \code{.tsh}. In the present case, the binary |
---|
542 | file format \code{.msh} is used. See Section \ref{sec:file formats} |
---|
543 | (p. \pageref{sec:file formats}) for more on file formats.) |
---|
544 | \code{pmesh} assigns a name to the file by appending the extension |
---|
545 | \code{.msh} to the name specified in the input file |
---|
546 | \code{project.py}. This name is stored in the variable |
---|
547 | \code{meshname}. |
---|
548 | |
---|
549 | |
---|
550 | \subsection{Initialising the Domain} |
---|
551 | |
---|
552 | As with \code{bedslope.py}, once we have created the mesh, the next |
---|
553 | step is to create the data structure \code{domain}. We did this for |
---|
554 | \code{bedslope.py} by inputting lists of points and triangles and |
---|
555 | specifying the boundary tags directly. However, in the present case, |
---|
556 | we use a method that works directly with the meshfile |
---|
557 | \code{meshname}, as follows: |
---|
558 | |
---|
559 | {\small \begin{verbatim} |
---|
560 | domain = pmesh_to_domain_instance(meshname, |
---|
561 | Domain, use_cache = True, verbose = True) |
---|
562 | \end{verbatim}} |
---|
563 | |
---|
564 | The function \code{pmesh\_to\_domain\_instance} converts a meshfile |
---|
565 | \code{meshname} into an instance of the data structure |
---|
566 | \code{domain}, allowing us to use methods like \code{set\_quantity} |
---|
567 | to set quantities and to apply other operations. (In principle, the |
---|
568 | second argument of \code{pmesh\_to\_domain\_instance} can be any |
---|
569 | subclass of \code{Domain}, but for applications involving the |
---|
570 | shallow-water wave equation, the second argument of |
---|
571 | \code{pmesh\_to\_domain\_instance} can always be set simply to |
---|
572 | \code{Domain}.) |
---|
573 | |
---|
574 | \subsection{Specifying the Quantities} |
---|
575 | Setting quantities for \code{run\_sydney\_smf.py} is accomplished |
---|
576 | using similar methods to those used in \code{bedslope.py}. However, |
---|
577 | in this case, many of the values are read from the auxiliary file |
---|
578 | \code{project.py} or, in the case of \code{elevation}, from an |
---|
579 | ancillary points file. |
---|
580 | |
---|
581 | |
---|
582 | \subsubsection{Fundamental Quantities} |
---|
583 | |
---|
584 | The following statements specify a basename and data directory, and |
---|
585 | identify quantities to be stored. For the first two, values are |
---|
586 | taken from \code{project.py}. |
---|
587 | |
---|
588 | {\small \begin{verbatim} domain.set_name(project.basename) |
---|
589 | domain.set_datadir(project.outputdir) |
---|
590 | domain.set_quantities_to_be_stored(['stage', 'xmomentum', |
---|
591 | 'ymomentum']) |
---|
592 | \end{verbatim}} |
---|
593 | |
---|
594 | \subsubsection{Stage} |
---|
595 | |
---|
596 | For the scenario we are modelling in this case, we use a callable |
---|
597 | object \code{tsunami\_source}, assigned by means of a function |
---|
598 | \code{slump\_tsunami}. This is similar to how we set elevation in |
---|
599 | \code{bedslope.py} using a function---however, in this case the |
---|
600 | function is both more complex and more interesting. |
---|
601 | |
---|
602 | {\small \begin{verbatim} |
---|
603 | #------------------------------------------------------------------------------- |
---|
604 | # Set up scenario (tsunami_source is a callable object used with |
---|
605 | set_quantity) |
---|
606 | #------------------------------------------------------------------------------- |
---|
607 | |
---|
608 | tsunami_source = slump_tsunami(length=30000.0, |
---|
609 | depth=400.0, |
---|
610 | slope=6.0, |
---|
611 | thickness=176.0, |
---|
612 | radius=3330, |
---|
613 | dphi=0.23, |
---|
614 | x0=project.slump_origin[0], |
---|
615 | y0=project.slump_origin[1], |
---|
616 | alpha=0.0, |
---|
617 | domain=domain) |
---|
618 | |
---|
619 | |
---|
620 | #------------------------------------------------------------------------------- |
---|
621 | # Set up initial conditions |
---|
622 | #------------------------------------------------------------------------------- |
---|
623 | |
---|
624 | domain.set_quantity('stage', tsunami_source) |
---|
625 | \end{verbatim}} |
---|
626 | |
---|
627 | \subsubsection{Friction} |
---|
628 | |
---|
629 | Assigning the friction is exactly parallel to what we did for |
---|
630 | \code{bedslope.py}: |
---|
631 | |
---|
632 | {\small \begin{verbatim} |
---|
633 | domain.set_quantity('friction', 0.03) |
---|
634 | #supplied by Benfield |
---|
635 | \end{verbatim}} |
---|
636 | |
---|
637 | |
---|
638 | \subsubsection{Elevation} |
---|
639 | |
---|
640 | In this example, the elevation is specified by reading data from a |
---|
641 | file. |
---|
642 | |
---|
643 | {\small \begin{verbatim} |
---|
644 | domain.set_quantity('elevation', |
---|
645 | filename = project.combineddemname + '.pts', |
---|
646 | use_cache = True, |
---|
647 | verbose = True) |
---|
648 | \end{verbatim}} |
---|
649 | |
---|
650 | However, before this step can be executed, some preliminary steps |
---|
651 | are needed to prepare the file from which the data is taken. Two |
---|
652 | source files are used for this data---their names are specified in |
---|
653 | the file \code{project.py}, in the variables \code{coarsedemname} |
---|
654 | and \code{finedemname}. They contain `coarse' and `fine' data, |
---|
655 | respectively---that is, data sampled at widely spaced points over a |
---|
656 | large region and data sampled at closely spaced points over a |
---|
657 | smaller subregion. The data in these files is combined through the |
---|
658 | statement |
---|
659 | |
---|
660 | {\small \begin{verbatim} |
---|
661 | combine_rectangular_points_files(project.finedemname + '.pts', |
---|
662 | project.coarsedemname + '.pts', |
---|
663 | project.combineddemname + '.pts') |
---|
664 | \end{verbatim}} |
---|
665 | |
---|
666 | The effect of this is simply to combine the datasets by eliminating |
---|
667 | any coarse data associated with points inside the smaller region |
---|
668 | common to both datasets. The name to be assigned to the resulting |
---|
669 | dataset is also derived from the name stored in the variable |
---|
670 | \code{combinedname} in the file \code{project.py}. |
---|
671 | |
---|
672 | \subsection{Boundary Conditions} |
---|
673 | |
---|
674 | Setting boundaries in \code{run\_sydney\_smf.py} is very similar to |
---|
675 | what we did in \code{bedslope.py}, except that we now have a larger |
---|
676 | number of boundary tags: |
---|
677 | |
---|
678 | {\small \begin{verbatim} |
---|
679 | Br = Reflective_boundary(domain) |
---|
680 | domain.set_boundary( {'bottom': Br, 'right1': Br, 'right0': Br, |
---|
681 | 'right2': Br, 'top': Br, 'left1': Br, |
---|
682 | 'left2': Br, 'left3': Br} ) |
---|
683 | \end{verbatim}} |
---|
684 | |
---|
685 | \subsection{Evolution} |
---|
686 | |
---|
687 | With the basics established, the running of the `evolve' step is |
---|
688 | very similar to the corresponding step in \code{bedslope.py}: |
---|
689 | |
---|
690 | {\small \begin{verbatim} |
---|
691 | import time t0 = time.time() |
---|
692 | |
---|
693 | for t in domain.evolve(yieldstep = 120, finaltime = 18000): |
---|
694 | domain.write_time() |
---|
695 | domain.write_boundary_statistics(tags = 'bottom') |
---|
696 | |
---|
697 | print 'That took %.2f seconds' %(time.time()-t0) |
---|
698 | \end{verbatim}} |
---|
699 | |
---|
700 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
701 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
702 | |
---|
703 | \chapter{\anuga Public Interface} |
---|
704 | |
---|
705 | This chapter gives an overview of the features of \anuga available |
---|
706 | to the user at the public interface. These are grouped under the |
---|
707 | following headings: |
---|
708 | |
---|
709 | \begin{itemize} |
---|
710 | \item Functions and Classes |
---|
711 | \item Diagnostics |
---|
712 | \item Boundary Conditions |
---|
713 | \item Initial Conditions |
---|
714 | \item Forcing Functions. |
---|
715 | \end{itemize} |
---|
716 | |
---|
717 | The listings do not give full specifications of the features, for |
---|
718 | which the reader may consult the docstrings provided in the code. |
---|
719 | They are intended merely to give the reader an idea of what each |
---|
720 | feature is and how it can be used. |
---|
721 | |
---|
722 | \section{Functions and Classes} |
---|
723 | |
---|
724 | %\indexedcodeheader{create\_mesh\_from\_regions}\label{codehdr:createmeshfromregions} |
---|
725 | |
---|
726 | % Creates a triangular mesh based on a bounding polygon and |
---|
727 | % a number of internal polygons. For each polygon the user specifies a resolution---that is, the maximal area |
---|
728 | % of triangles in the mesh. The bounding polygon also has symbolic \code{tags} associated with it. |
---|
729 | |
---|
730 | % \textbf{Arguments:} |
---|
731 | |
---|
732 | % \begin{itemize} |
---|
733 | % \item the bounding polygon, %do we need to spell out how a polygon is specified? |
---|
734 | % \item a dictionary of boundary tags, for all segments of the bounding polygon, |
---|
735 | % \emph{[not clear what the keys and values of this dictionary are]} |
---|
736 | % \item the resolution for the bounding polygon, |
---|
737 | % \item (optional) a filename, \emph{[what is the file for?]} |
---|
738 | % \item a list of 2-tuples \code{(polygon, resolution)}, specifying the interior polygons and |
---|
739 | % their associated resolutions. |
---|
740 | % \end{itemize} |
---|
741 | |
---|
742 | %********************************************************************************************* |
---|
743 | |
---|
744 | %\emph{\textbf{[The following is how the description of |
---|
745 | %\emph{\code{create\_mesh\_from\_regions}} would be presented using |
---|
746 | %the Python documentation system's \emph{\code{funcdesc}} environment |
---|
747 | %for describing a module-level function.]}} |
---|
748 | |
---|
749 | \begin{funcdesc} {create\_mesh\_from\_regions}{bounding_polygon, |
---|
750 | boundary_tags, |
---|
751 | maximum_triangle_area, |
---|
752 | filename=None, |
---|
753 | interior_regions=None, |
---|
754 | poly_geo_reference=None, |
---|
755 | mesh_geo_reference=None, |
---|
756 | minimum_triangle_angle=28.0} |
---|
757 | Creates a triangular mesh based on a bounding polygon and a number |
---|
758 | of internal polygons. For each polygon the user specifies a |
---|
759 | resolution---that is, the maximal area of triangles in the mesh. The |
---|
760 | bounding polygon also has symbolic \code{tags} associated with it. |
---|
761 | \end{funcdesc} |
---|
762 | |
---|
763 | %********************************************************************************************* |
---|
764 | |
---|
765 | %\indexedcodeheader{pmesh\_to\_domain\_instance} \nopagebreak |
---|
766 | |
---|
767 | % Converts a generated mesh file to a domain object. |
---|
768 | |
---|
769 | % \textbf{Arguments:} |
---|
770 | |
---|
771 | % \begin{itemize} |
---|
772 | % \item \code{file\_name} is the name of the mesh file to convert, including the extension |
---|
773 | % \item \code{DomainClass} is the Class that will be returned. |
---|
774 | % It must be a subclass of \code{Domain}, with the same interface as |
---|
775 | % domain. In practice, it can usually be set simply to |
---|
776 | % \code{Domain}. |
---|
777 | % \item \code{use\_cache}: \code{True} means that caching is attempted for the computed domain. |
---|
778 | % \end{itemize} |
---|
779 | |
---|
780 | |
---|
781 | % \begin{itemize} |
---|
782 | % \item Mesh file name |
---|
783 | % \item Class name, specifying the domain class to be instantiated. |
---|
784 | % \end{itemize} |
---|
785 | % |
---|
786 | %********************************************************************************************* |
---|
787 | |
---|
788 | \begin{funcdesc} {pmesh\_to\_domain\_instance}{file_name, DomainClass, use_cache = False, verbose = False} |
---|
789 | Converts a generated mesh file to a domain object. |
---|
790 | |
---|
791 | \code{file\_name} is the name of the mesh file to convert, including |
---|
792 | the extension. \code{DomainClass} is the class to be returned, which |
---|
793 | must be a subclass of \code{Domain}, with the same interface as |
---|
794 | \code{Domain}---in practice, it can usually be set simply to |
---|
795 | \code{Domain}. |
---|
796 | |
---|
797 | \end{funcdesc} |
---|
798 | %********************************************************************************************* |
---|
799 | |
---|
800 | |
---|
801 | %\indexedcodeheader{file\_function} %in util.py "High priority" |
---|
802 | |
---|
803 | % Reads the time history of spatial data from NetCDF file and returns a callable object. |
---|
804 | |
---|
805 | % \textbf{Arguments:} |
---|
806 | |
---|
807 | % \code{filename} -- Name of \code{sww} or \code{tms} file (see |
---|
808 | % Section \ref{sec:file formats} on page \pageref{sec:file formats} |
---|
809 | % for details about file formats). |
---|
810 | |
---|
811 | % \begin{quote} |
---|
812 | % If the file has extension \code{sww} then it is assumed to be spatio-temporal |
---|
813 | % or temporal and the callable object will have the form \code{f(t,x,y)} or \code{f(t)} |
---|
814 | % depending on whether the file contains spatial data. |
---|
815 | |
---|
816 | % If the file has extension \code{tms} then it is assumed to be temporal only |
---|
817 | % and the callable object will have the form \code{f(t)}. |
---|
818 | |
---|
819 | % Either form will return interpolated values based on the input file |
---|
820 | % using the underlying \code{interpolation\_function}. |
---|
821 | % \end{quote} |
---|
822 | |
---|
823 | % \code{domain} -- Associated domain object |
---|
824 | % If domain is specified, model time (\code{domain.starttime}) |
---|
825 | % will be checked and possibly modified. |
---|
826 | |
---|
827 | % \begin{quote} |
---|
828 | % All times are assumed to be in UTC. |
---|
829 | |
---|
830 | % All spatial information is assumed to be in absolute UTM coordinates. |
---|
831 | % \end{quote} |
---|
832 | |
---|
833 | % \code{quantities} -- the name of the quantity to be interpolated or a |
---|
834 | % list of quantity names. The resulting function will return |
---|
835 | % a tuple of values -- one for each quantity. |
---|
836 | |
---|
837 | % \code{interpolation\_points} -- list of absolute UTM coordinates for points at |
---|
838 | % which values are sought |
---|
839 | |
---|
840 | % \code{use\_cache}: \code{True} means that caching of intermediate result of |
---|
841 | % \code{Interpolation\_function} is attempted |
---|
842 | |
---|
843 | |
---|
844 | \begin{funcdesc}{file_function}{filename, |
---|
845 | domain = None, |
---|
846 | quantities = None, |
---|
847 | interpolation_points = None, |
---|
848 | verbose = False, |
---|
849 | use_cache = False} |
---|
850 | |
---|
851 | Reads the time history of spatial data from NetCDF file and returns a callable object. Returns |
---|
852 | interpolated values based on the input file |
---|
853 | using the underlying \code{interpolation\_function}. |
---|
854 | |
---|
855 | \code{quantities} is either the name of a single quantity to be interpolated or a |
---|
856 | list of such quantity names. The resulting function will return |
---|
857 | a tuple of values---one for each quantity. |
---|
858 | |
---|
859 | \code{interpolation\_points} is a list of absolute UTM coordinates for points at |
---|
860 | which values are sought. |
---|
861 | |
---|
862 | \end{funcdesc} |
---|
863 | |
---|
864 | |
---|
865 | % See Interpolation function for further documentation |
---|
866 | %\indexedcodeheader{Interpolation\_function} |
---|
867 | % Creates a callable object \code{f(t, id)} or \code{f(t,x,y)} |
---|
868 | % interpolated from a time series defined at the vertices of |
---|
869 | % a triangular mesh (such as those stored in \code{sww} files). |
---|
870 | |
---|
871 | % Let $m$ be the number of vertices, $n$ the number of triangles |
---|
872 | % and $p$ the number of time steps. |
---|
873 | |
---|
874 | % \textbf{Mandatory Arguments:} |
---|
875 | |
---|
876 | % \begin{tabular}{ll} |
---|
877 | % \code{time}: & $p \times 1$ array of monotonously increasing times (Float)\\ |
---|
878 | |
---|
879 | |
---|
880 | % \code{quantities}: & Dictionary of arrays or one array (Float). The arrays must \\ |
---|
881 | % & have dimensions either $p \times m$ or $m \times 1$. The resulting function \\ |
---|
882 | % & will be time dependent in the former case and constant with respect to time \\ |
---|
883 | % & in the latter case.\\ |
---|
884 | % \end{tabular} |
---|
885 | |
---|
886 | |
---|
887 | % \textbf{Optional Arguments:} |
---|
888 | |
---|
889 | % \begin{tabular}{ll} |
---|
890 | % \code{quantity\_names}: & List of keys into the quantities dictionary\\ |
---|
891 | |
---|
892 | % \code{vertex\_coordinates}: & $m \times 2$ array of coordinates (Float)\\ |
---|
893 | |
---|
894 | % \code{triangles}: & $n \times 3$ array of indices into \code{vertex\_coordinates} (Int)\\ |
---|
895 | |
---|
896 | % \code{interpolation\_points}: & $N \times 2$ array of coordinates to be interpolated to \\ |
---|
897 | |
---|
898 | % \code{verbose}: & Level of reporting\\ |
---|
899 | % \end{tabular} |
---|
900 | |
---|
901 | % The quantities returned by the callable object are specified by |
---|
902 | % the list \code{quantities} which must contain the names of the |
---|
903 | % quantities to be returned and also reflect the order, e.g. for |
---|
904 | % the shallow water wave equation, one would have |
---|
905 | % \code{quantities = ['stage', 'xmomentum', 'ymomentum']}. |
---|
906 | |
---|
907 | % The parameter \code{interpolation_points} decides at which points interpolated |
---|
908 | % quantities are to be computed whenever the object is called. |
---|
909 | % If \code{None}, returns average value. |
---|
910 | |
---|
911 | \begin{classdesc}{Interpolation_function}{self, |
---|
912 | time, |
---|
913 | quantities, |
---|
914 | quantity_names = None, |
---|
915 | vertex_coordinates = None, |
---|
916 | triangles = None, |
---|
917 | interpolation_points = None, |
---|
918 | verbose = False} |
---|
919 | Creates a callable object \code{f(t, id)} or \code{f(t,x,y)} |
---|
920 | interpolated from a time series defined at the vertices of a |
---|
921 | triangular mesh (such as those stored in \code{sww} files). |
---|
922 | |
---|
923 | \code{time} is an array of monotonically increasing times and |
---|
924 | \code{quantities} is an array, or dictionary of arrays, of values to |
---|
925 | be interpolated. The parameter \code{interpolation_points} may be |
---|
926 | used to specify at which points interpolated |
---|
927 | quantities are to be computed whenever the object is called. |
---|
928 | If the default value \code{None} is used, returns average value. |
---|
929 | \end{classdesc} |
---|
930 | |
---|
931 | |
---|
932 | \begin{funcdesc}{set\_region}{???} |
---|
933 | [Low priority. Will be merged into set\_quantity] |
---|
934 | \end{funcdesc} |
---|
935 | |
---|
936 | \begin{funcdesc}{set\_quantity}{???} |
---|
937 | [Pretty mature] |
---|
938 | \end{funcdesc} |
---|
939 | |
---|
940 | \begin{funcdesc}{set\_boundary}{???} |
---|
941 | [Pretty mature] |
---|
942 | \end{funcdesc} |
---|
943 | |
---|
944 | |
---|
945 | |
---|
946 | \section{Diagnostics} |
---|
947 | |
---|
948 | \begin{funcdesc}{write\_time}{???} |
---|
949 | |
---|
950 | \end{funcdesc} |
---|
951 | |
---|
952 | |
---|
953 | \begin{funcdesc}{write\_boundary\_statistics}{???} |
---|
954 | |
---|
955 | \end{funcdesc} |
---|
956 | |
---|
957 | |
---|
958 | |
---|
959 | \section{Boundary Conditions} |
---|
960 | |
---|
961 | \anuga provides a large number of predefined boundary conditions to |
---|
962 | be used with \code{set\_boundary}. |
---|
963 | |
---|
964 | \subsection{Predefined boundary conditions} |
---|
965 | |
---|
966 | \begin{classdesc}{Reflective_boundary}{Boundary} |
---|
967 | Reflective boundary returns same conserved quantities as those present in |
---|
968 | the neighbouring volume but reflected. |
---|
969 | |
---|
970 | This class is specific to the shallow water equation as it works with the |
---|
971 | momentum quantities assumed to be the second and third conserved quantities. |
---|
972 | \end{classdesc} |
---|
973 | |
---|
974 | |
---|
975 | \begin{classdesc}{Transmissive_boundary}{domain = None} |
---|
976 | A transmissive boundary returns the same conserved quantities as |
---|
977 | those present in the neighbouring volume. |
---|
978 | |
---|
979 | The underlying domain must be specified when the boundary is instantiated. |
---|
980 | \end{classdesc} |
---|
981 | |
---|
982 | |
---|
983 | \begin{classdesc}{Dirichlet_boundary}{conserved_quantities=None} |
---|
984 | A Dirichlet boundary returns constant values for the conserved |
---|
985 | quantities. |
---|
986 | \end{classdesc} |
---|
987 | |
---|
988 | |
---|
989 | \begin{classdesc}{Time_boundary}{domain = None, f = None} |
---|
990 | A time-dependent boundary returns values for the conserved quantities as a |
---|
991 | function \code{f(t)} of time. The user must specify the domain to get access to the model |
---|
992 | time. |
---|
993 | \end{classdesc} |
---|
994 | |
---|
995 | |
---|
996 | \begin{classdesc}{File_boundary}{Boundary} |
---|
997 | The boundary values are obtained from a file and interpolated. The file is |
---|
998 | assumed to contain a time series and possibly also spatial information. |
---|
999 | The conserved quantities are given as a function of time. |
---|
1000 | \end{classdesc} |
---|
1001 | |
---|
1002 | |
---|
1003 | \subsection{User-defined boundary conditions} |
---|
1004 | [How to roll your own] |
---|
1005 | |
---|
1006 | |
---|
1007 | |
---|
1008 | \section{Initial Conditions} |
---|
1009 | |
---|
1010 | \anuga provides a number of predefined initial conditions to be used with |
---|
1011 | \code{set_quantity}. |
---|
1012 | |
---|
1013 | \begin{funcdesc}{tsunami_slump}{length, depth, slope, width=None, thickness=None, \ |
---|
1014 | x0=0.0, y0=0.0, alpha=0.0, \ |
---|
1015 | gravity=9.8, gamma=1.85, \ |
---|
1016 | massco=1, dragco=1, frictionco=0, psi=0, \ |
---|
1017 | dx=None, kappa=3.0, kappad=0.8, zsmall=0.01, \ |
---|
1018 | domain=None, |
---|
1019 | verbose=False} |
---|
1020 | This function returns a callable object representing an initial water |
---|
1021 | displacement generated by a submarine sediment slide. |
---|
1022 | |
---|
1023 | The arguments include the downslope slide length, the water depth to the slide centre of mass, |
---|
1024 | and the bathymetric slope. |
---|
1025 | \end{funcdesc} |
---|
1026 | |
---|
1027 | \section{Forcing Functions} |
---|
1028 | |
---|
1029 | \anuga provides a number of predefined forcing functions to be used with ..... |
---|
1030 | |
---|
1031 | %\begin{itemize} |
---|
1032 | |
---|
1033 | |
---|
1034 | % \item \indexedcode{} |
---|
1035 | % [function, arguments] |
---|
1036 | |
---|
1037 | % \item \indexedcode{} |
---|
1038 | |
---|
1039 | %\end{itemize} |
---|
1040 | |
---|
1041 | |
---|
1042 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
1043 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
1044 | |
---|
1045 | \chapter{\anuga System Architecture} |
---|
1046 | |
---|
1047 | From pyvolution/documentation |
---|
1048 | |
---|
1049 | \section{File Formats} |
---|
1050 | \label{sec:file formats} |
---|
1051 | |
---|
1052 | \anuga makes use of a number of different file formats. The |
---|
1053 | following table lists all these formats, which are described in more |
---|
1054 | detail in the paragraphs below. |
---|
1055 | |
---|
1056 | \begin{tabular}{|ll|} \hline |
---|
1057 | \code{.sww} & NetCDF format for storing model output |
---|
1058 | \code{f(t,x,y)}\\ |
---|
1059 | |
---|
1060 | \code{.tms} & NetCDF format for storing time series \code{f(t)}\\ |
---|
1061 | |
---|
1062 | \code{.xya} & ASCII format for storing arbitrary points and |
---|
1063 | associated attributes\\ |
---|
1064 | |
---|
1065 | \code{.pts} & NetCDF format for storing arbitrary points and |
---|
1066 | associated attributes\\ |
---|
1067 | |
---|
1068 | \code{.asc} & ASCII format of regular DEMs as output from ArcView\\ |
---|
1069 | |
---|
1070 | \code{.prj} & Associated ArcView file giving more metadata for |
---|
1071 | \code{.asc} format\\ |
---|
1072 | |
---|
1073 | \code{.ers} & ERMapper header format of regular DEMs for ArcView\\ |
---|
1074 | |
---|
1075 | \code{.dem} & NetCDF representation of regular DEM data\\ |
---|
1076 | |
---|
1077 | \code{.tsh} & ASCII format for storing meshes and associated |
---|
1078 | boundary and region info\\ |
---|
1079 | |
---|
1080 | \code{.msh} & NetCDF format for storing meshes and associated |
---|
1081 | boundary and region info\\ |
---|
1082 | |
---|
1083 | \code{.nc} & Native ferret NetCDF format\\ |
---|
1084 | |
---|
1085 | \code{.geo} & Houdinis ASCII geometry format (?) \\ \par \hline |
---|
1086 | %\caption{File formats used by \anuga} |
---|
1087 | \end{tabular} |
---|
1088 | |
---|
1089 | |
---|
1090 | A typical dataflow can be described as follows: |
---|
1091 | |
---|
1092 | \subsection{Manually Created Files} |
---|
1093 | |
---|
1094 | \begin{tabular}{ll} |
---|
1095 | ASC, PRJ & Digital elevation models (gridded)\\ |
---|
1096 | TSH & Triangular |
---|
1097 | meshes (e.g. created from \code{pmesh})\\ |
---|
1098 | NC & Model outputs for use as boundary conditions (e.g. from MOST) |
---|
1099 | \end{tabular} |
---|
1100 | |
---|
1101 | \subsection{Automatically Created Files} |
---|
1102 | |
---|
1103 | \begin{tabular}{ll} |
---|
1104 | ASC, PRJ $\rightarrow$ DEM $\rightarrow$ PTS & Convert |
---|
1105 | DEMs to native \code{.pts} file\\ |
---|
1106 | |
---|
1107 | NC $\rightarrow$ SWW & Convert MOST boundary files to |
---|
1108 | boundary \code{.sww}\\ |
---|
1109 | |
---|
1110 | PTS + TSH $\rightarrow$ TSH with elevation & Least squares fit\\ |
---|
1111 | |
---|
1112 | TSH $\rightarrow$ SWW & Convert TSH to \code{.sww}-viewable using |
---|
1113 | Swollen\\ |
---|
1114 | |
---|
1115 | TSH + Boundary SWW $\rightarrow$ SWW & Simulation using |
---|
1116 | \code{pyvolution} |
---|
1117 | \end{tabular} |
---|
1118 | |
---|
1119 | %\[ |
---|
1120 | % \left[ |
---|
1121 | % \begin{array}{ccr} |
---|
1122 | % 2 & 4 & 4\\ |
---|
1123 | % 1 & 1 & 1 |
---|
1124 | % \end{array} |
---|
1125 | % \right] |
---|
1126 | %\] |
---|
1127 | |
---|
1128 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
1129 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
1130 | |
---|
1131 | \chapter{Basic \anuga Assumptions} |
---|
1132 | |
---|
1133 | (From pyvolution/documentation) |
---|
1134 | |
---|
1135 | |
---|
1136 | Physical model time cannot be earlier than 1 Jan 1970 00:00:00. |
---|
1137 | If one wished to recreate scenarios prior to that date it must be done |
---|
1138 | using some relative time (e.g. 0). |
---|
1139 | |
---|
1140 | |
---|
1141 | All spatial data relates to the WGS84 datum (or GDA94) and has been |
---|
1142 | projected into UTM with false easting of 500000 and false northing of |
---|
1143 | 1000000 on the southern hemisphere (0 on the northern). |
---|
1144 | |
---|
1145 | It is assumed that all computations take place within one UTM zone. |
---|
1146 | |
---|
1147 | DEMs, meshes and boundary conditions can have different origins within |
---|
1148 | one UTM zone. However, the computation will use that of the mesh for |
---|
1149 | numerical stability. |
---|
1150 | |
---|
1151 | |
---|
1152 | %OLD |
---|
1153 | %The dataflow is: (See data_manager.py and from scenarios) |
---|
1154 | % |
---|
1155 | % |
---|
1156 | %Simulation scenarios |
---|
1157 | %--------------------% |
---|
1158 | %% |
---|
1159 | % |
---|
1160 | %Sub directories contain scrips and derived files for each simulation. |
---|
1161 | %The directory ../source_data contains large source files such as |
---|
1162 | %DEMs provided externally as well as MOST tsunami simulations to be used |
---|
1163 | %as boundary conditions. |
---|
1164 | % |
---|
1165 | %Manual steps are: |
---|
1166 | % Creation of DEMs from argcview (.asc + .prj) |
---|
1167 | % Creation of mesh from pmesh (.tsh) |
---|
1168 | % Creation of tsunami simulations from MOST (.nc) |
---|
1169 | %% |
---|
1170 | % |
---|
1171 | %Typical scripted steps are% |
---|
1172 | % |
---|
1173 | % prepare_dem.py: Convert asc and prj files supplied by arcview to |
---|
1174 | % native dem and pts formats% |
---|
1175 | % |
---|
1176 | % prepare_pts.py: Convert netcdf output from MOST to an sww file suitable |
---|
1177 | % as boundary condition% |
---|
1178 | % |
---|
1179 | % prepare_mesh.py: Merge DEM (pts) and mesh (tsh) using least squares |
---|
1180 | % smoothing. The outputs are tsh files with elevation data.% |
---|
1181 | % |
---|
1182 | % run_simulation.py: Use the above together with various parameters to |
---|
1183 | % run inundation simulation. |
---|
1184 | |
---|
1185 | |
---|
1186 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
1187 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
1188 | |
---|
1189 | \appendix |
---|
1190 | |
---|
1191 | \chapter{Supporting Tools} |
---|
1192 | |
---|
1193 | |
---|
1194 | \section{caching} |
---|
1195 | |
---|
1196 | The \code{cache} function is used to provide supervised caching of function results. A Python |
---|
1197 | function call of the form |
---|
1198 | |
---|
1199 | {\small \begin{verbatim} |
---|
1200 | result = func(arg1,...,argn) |
---|
1201 | \end{verbatim}} |
---|
1202 | |
---|
1203 | can be replaced by |
---|
1204 | |
---|
1205 | {\small \begin{verbatim} |
---|
1206 | from caching import cache |
---|
1207 | result = cache(func,(arg1,...,argn)) |
---|
1208 | \end{verbatim}} |
---|
1209 | |
---|
1210 | which returns the same output but reuses cached |
---|
1211 | results if the function has been computed previously in the same context. |
---|
1212 | \code{result} and the arguments can be simple types, tuples, list, dictionaries or |
---|
1213 | objects, but not unhashable types such as functions or open file objects. |
---|
1214 | The function \code{func} may be a member function of an object or a module. |
---|
1215 | |
---|
1216 | This type of caching is particularly useful for computationally intensive |
---|
1217 | functions with few frequently used combinations of input arguments. Note that |
---|
1218 | if the inputs or output are very large caching might not save time because |
---|
1219 | disc access may dominate the execution time. |
---|
1220 | |
---|
1221 | If the function definition changes after a result has been cached it will be |
---|
1222 | detected by examining the functions \code{bytecode (co_code, co_consts, |
---|
1223 | func_defualts, co_argcount)} and it will be recomputed. |
---|
1224 | |
---|
1225 | Options are set |
---|
1226 | by means of the function \code{set_option(key, value)}, where \code{key} is a key associated with a |
---|
1227 | Python dictionary \code{options} that stores settings such as the name of the directory used, the maximum |
---|
1228 | number of cached files allowed, and so on. |
---|
1229 | |
---|
1230 | The \code{cache} function allows the user also to specify a list of dependent files. If any of these |
---|
1231 | have been changed, the function is recomputed and the results stored again. |
---|
1232 | |
---|
1233 | Other features include support for compression and a capability to \ldots |
---|
1234 | |
---|
1235 | |
---|
1236 | \textbf{USAGE:} |
---|
1237 | |
---|
1238 | {\small \begin{verbatim} |
---|
1239 | result = cache(func, args, kwargs, dependencies, cachedir, verbose, |
---|
1240 | compression, evaluate, test, return_filename)} |
---|
1241 | \end{verbatim}} |
---|
1242 | |
---|
1243 | \textbf{ARGUMENTS:} |
---|
1244 | |
---|
1245 | \begin{tabular}{ll} |
---|
1246 | \code{func} & Function object (Required)\\ |
---|
1247 | \code{args} & Arguments to func (Default: ())\\ |
---|
1248 | \code{kwargs} & Keyword arguments to func (Default: {}) \\ |
---|
1249 | \code{dependencies} & Filenames that func depends on (Default: \code{None})\\ |
---|
1250 | \code{cachedir} & Directory for cache files (Default: \code{options['cachedir']})\\ |
---|
1251 | \code{verbose} & Flag verbose output to stdout |
---|
1252 | (Default: \code{options['verbose']})\\ |
---|
1253 | \code{compression} & Flag zlib compression (Default: \code{options['compression']})\\ |
---|
1254 | \code{evaluate} & Flag forced evaluation of func (Default: 0)\\ |
---|
1255 | \code{test} & Flag test for cached results (Default: 0)\\ |
---|
1256 | \code{clear} & Flag delete cached results (Default: 0)\\ |
---|
1257 | \code{return_filename} & Flag return of cache filename (Default: 0)\\ |
---|
1258 | \end{tabular} |
---|
1259 | |
---|
1260 | |
---|
1261 | \textbf{LIMITATIONS:} |
---|
1262 | |
---|
1263 | \begin{itemize} |
---|
1264 | \item Caching uses the apply function and will work with anything that can be |
---|
1265 | pickled, so any limitation in apply or pickle extends to caching. |
---|
1266 | |
---|
1267 | \item A function to be cached should not depend on global variables |
---|
1268 | as wrong results may occur if globals are changed after a result has |
---|
1269 | been cached. |
---|
1270 | \end{itemize} |
---|
1271 | |
---|
1272 | |
---|
1273 | |
---|
1274 | |
---|
1275 | \section{swollen} |
---|
1276 | |
---|
1277 | |
---|
1278 | The main keys operating the interactive screen are:\\ |
---|
1279 | |
---|
1280 | \begin{tabular}{|ll|} \hline |
---|
1281 | |
---|
1282 | \code{w} & toggle wireframe\\ |
---|
1283 | |
---|
1284 | space bar & start/stop\\ |
---|
1285 | |
---|
1286 | up/down arrows & increase/decrease speed\\ |
---|
1287 | |
---|
1288 | left/right arrows & direction in time \emph{(when running)}\\ & step through simulation \emph{(when stopped)}\\ |
---|
1289 | |
---|
1290 | left mouse button & rotate\\ |
---|
1291 | |
---|
1292 | middle mouse button & pan\\ |
---|
1293 | |
---|
1294 | right mouse button & zoom\\ \hline |
---|
1295 | |
---|
1296 | \end{tabular} |
---|
1297 | |
---|
1298 | \vfill |
---|
1299 | |
---|
1300 | The following table describes how to operate swollen from the command line: |
---|
1301 | |
---|
1302 | Usage: \code{swollen [options] swwfile \ldots}\\ \nopagebreak |
---|
1303 | Options:\\ \nopagebreak |
---|
1304 | \begin{tabular}{ll} |
---|
1305 | \code{--display <type>} & \code{MONITOR | POWERWALL | REALITY_CENTER |}\\ |
---|
1306 | & \code{HEAD_MOUNTED_DISPLAY}\\ |
---|
1307 | \code{--rgba} & Request a RGBA colour buffer visual\\ |
---|
1308 | \code{--stencil} & Request a stencil buffer visual\\ |
---|
1309 | \code{--stereo} & Use default stereo mode which is \code{ANAGLYPHIC} if not \\ |
---|
1310 | & overridden by environmental variable\\ |
---|
1311 | \code{--stereo <mode>} & \code{ANAGLYPHIC | QUAD_BUFFER | HORIZONTAL_SPLIT |}\\ |
---|
1312 | & \code{VERTICAL_SPLIT | LEFT_EYE | RIGHT_EYE |}\\ |
---|
1313 | & \code{ON | OFF} \\ |
---|
1314 | \code{-alphamax <float 0-1>} & Maximum transparency clamp value\\ |
---|
1315 | \code{-alphamin <float 0-1>} & Transparency value at \code{hmin}\\ |
---|
1316 | \code{-cullangle <float angle 0-90>} & Cull triangles steeper than this value\\ |
---|
1317 | \code{-help} & Display this information\\ |
---|
1318 | \code{-hmax <float>} & Height above which transparency is set to |
---|
1319 | \code{alphamax}\\ |
---|
1320 | \code{-hmin <float>} & Height below which transparency is set to |
---|
1321 | zero\\ |
---|
1322 | \code{-lightpos <float>,<float>,<float>} & $x,y,z$ of bedslope directional light ($z$ is |
---|
1323 | up, default is overhead)\\ |
---|
1324 | \code{-loop} & Repeated (looped) playback of \code{.swm} files\\ |
---|
1325 | \code{-movie <dirname>} & Save numbered images to named directory and |
---|
1326 | quit\\ |
---|
1327 | \code{-nosky} & Omit background sky\\ |
---|
1328 | \code{-scale <float>} & Vertical scale factor\\ |
---|
1329 | \code{-texture <file>} & Image to use for bedslope topography\\ |
---|
1330 | \code{-tps <rate>} & Timesteps per second\\ |
---|
1331 | \code{-version} & Revision number and creation (not compile) |
---|
1332 | date\\ |
---|
1333 | \end{tabular} |
---|
1334 | |
---|
1335 | \section{utilities/polygons} Could do now. |
---|
1336 | |
---|
1337 | \begin{itemize} |
---|
1338 | \item \indexedcode{polygon_function} |
---|
1339 | \item \indexedcode{read_polygon} |
---|
1340 | \item \indexedcode{populate_polygon} |
---|
1341 | \item \indexedcode{point_in_polygon} |
---|
1342 | \item \indexedcode{inside_polygon} |
---|
1343 | \item \indexedcode{outside_polygon} |
---|
1344 | \item \indexedcode{point_on_line} |
---|
1345 | \item \indexedcode{separate_points_by_polygon} |
---|
1346 | \end{itemize} |
---|
1347 | |
---|
1348 | \section{coordinate_transforms} |
---|
1349 | |
---|
1350 | \section{geo_spatial_data} |
---|
1351 | |
---|
1352 | \section{pmesh GUI} |
---|
1353 | |
---|
1354 | \section{alpha_shape} |
---|
1355 | |
---|
1356 | |
---|
1357 | \section{utilities/numerical_tools} Could do now. |
---|
1358 | |
---|
1359 | \begin{itemize} |
---|
1360 | \item \indexedcode{ensure_numeric} |
---|
1361 | \item \indexedcode{mean} |
---|
1362 | \item |
---|
1363 | \end{itemize} |
---|
1364 | |
---|
1365 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
1366 | |
---|
1367 | \chapter{Glossary} |
---|
1368 | |
---|
1369 | \begin{itemize} |
---|
1370 | \item \indexedbold{\anuga} Name of software (joint development between ANU and GA) |
---|
1371 | |
---|
1372 | \item \indexedbold{domain} |
---|
1373 | |
---|
1374 | \item \indexedbold{Dirichlet boundary} |
---|
1375 | |
---|
1376 | \item \indexedbold{elevation} - refers to bathymetry and topography |
---|
1377 | |
---|
1378 | \item \indexedbold{bathymetry} offshore |
---|
1379 | |
---|
1380 | \item \indexedbold{topography} onshore |
---|
1381 | |
---|
1382 | \item \indexedbold{evolution} integration of the shallow water wave equations over time |
---|
1383 | |
---|
1384 | \item \indexedbold{forcing term} |
---|
1385 | |
---|
1386 | \item \indexedbold{IDLE} Development environment shipped with Python |
---|
1387 | |
---|
1388 | \item \indexedbold{Manning friction coefficient} |
---|
1389 | |
---|
1390 | \item \indexedbold{mesh} Triangulation of domain |
---|
1391 | |
---|
1392 | \item \indexedbold{meshfile} [generic word for either .tsh or |
---|
1393 | .msh file] |
---|
1394 | |
---|
1395 | \item \indexedbold{points file} [generic word for either .pts or |
---|
1396 | .xya file] |
---|
1397 | |
---|
1398 | \item \indexedbold{grid} evenly spaced |
---|
1399 | |
---|
1400 | \item \indexedbold{NetCDF} |
---|
1401 | |
---|
1402 | \item \indexedbold{pmesh} does this really need to be here? it's a class/module? |
---|
1403 | |
---|
1404 | \item \indexedbold{pyvolution} does this really need to be here? it's a class/module? |
---|
1405 | |
---|
1406 | \item \indexedbold{conserved quantity} conserved (state, x and y momentum) |
---|
1407 | |
---|
1408 | \item \indexedbold{reflective boundary} |
---|
1409 | |
---|
1410 | \item \indexedbold{smoothing} is this really needed? |
---|
1411 | |
---|
1412 | \item \indexedbold{stage} |
---|
1413 | |
---|
1414 | % \item \indexedbold{try this} |
---|
1415 | |
---|
1416 | \item \indexedbold{swollen} visualisation tool |
---|
1417 | |
---|
1418 | \item \indexedbold{time boundary} defined in the manual (flog from there) |
---|
1419 | |
---|
1420 | \item \indexedbold{transmissive boundary} defined in the manual (flog from there) |
---|
1421 | |
---|
1422 | \item \indexedbold{xmomentum} conserved quantity (note, two-dimensional SWW equations say only x and y and NOT z) |
---|
1423 | |
---|
1424 | \item \indexedbold{ymomentum} conserved quantity |
---|
1425 | |
---|
1426 | \item \indexedbold{resolution} The maximal area of a triangular cell in a mesh |
---|
1427 | |
---|
1428 | \item \indexedbold{polygon} A sequence of points in the plane. (Arbitrary polygons can be created |
---|
1429 | in this way.) |
---|
1430 | \anuga represents a polygon in one of two ways. One way is to represent it as a |
---|
1431 | list whose members are either Python tuples |
---|
1432 | or Python lists of length 2. The unit square, for example, would be represented by the |
---|
1433 | list |
---|
1434 | [ [0,0], [1,0], [1,1], [0,1] ]. The alternative is to represent it as an |
---|
1435 | $N \times 2$ Numeric array, where $N$ is the number of points. |
---|
1436 | |
---|
1437 | NOTE: More can be read in the module utilities/polygon.py .... |
---|
1438 | |
---|
1439 | \item \indexedbold{easting} |
---|
1440 | |
---|
1441 | \item \indexedbold{northing} |
---|
1442 | |
---|
1443 | \item \indexedbold{latitude} |
---|
1444 | |
---|
1445 | \item \indexedbold{longitude} |
---|
1446 | |
---|
1447 | \item \indexedbold{edge} |
---|
1448 | |
---|
1449 | \item \indexedbold{vertex} |
---|
1450 | |
---|
1451 | \item \indexedbold{finite volume} |
---|
1452 | |
---|
1453 | \item \indexedbold{flux} |
---|
1454 | |
---|
1455 | \item \indexedbold{Digital Elevation Model (DEM)} |
---|
1456 | |
---|
1457 | |
---|
1458 | \end{itemize} |
---|
1459 | |
---|
1460 | The \code{\e appendix} markup need not be repeated for additional |
---|
1461 | appendices. |
---|
1462 | |
---|
1463 | |
---|
1464 | % |
---|
1465 | % The ugly "%begin{latexonly}" pseudo-environments are really just to |
---|
1466 | % keep LaTeX2HTML quiet during the \renewcommand{} macros; they're |
---|
1467 | % not really valuable. |
---|
1468 | % |
---|
1469 | % If you don't want the Module Index, you can remove all of this up |
---|
1470 | % until the second \input line. |
---|
1471 | % |
---|
1472 | |
---|
1473 | %begin{latexonly} |
---|
1474 | %\renewcommand{\indexname}{Module Index} |
---|
1475 | %end{latexonly} |
---|
1476 | %\input{mod\jobname.ind} % Module Index |
---|
1477 | |
---|
1478 | %begin{latexonly} |
---|
1479 | \renewcommand{\indexname}{Index} |
---|
1480 | %end{latexonly} |
---|
1481 | \input{\jobname.ind} % Index |
---|
1482 | |
---|
1483 | |
---|
1484 | |
---|
1485 | \end{document} |
---|