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