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