[2329] | 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 | |
---|
[2277] | 9 | %\newcommand{\code}[1]{{\small \tt #1}} %For use with one-line code snippets |
---|
| 10 | |
---|
[2329] | 11 | \documentclass{manual} |
---|
[2274] | 12 | |
---|
| 13 | \title{AnuGA User Manual} |
---|
[2284] | 14 | \author{Howard Silcock, Ole Nielsen, Duncan Gray, Jane Sexton} |
---|
[2274] | 15 | |
---|
[2329] | 16 | % Please at least include a long-lived email address; |
---|
| 17 | % the rest is at your discretion. |
---|
| 18 | \authoraddress{Geoscience Australia \\ |
---|
| 19 | Email: \email{ole.nielsen@ga.gov.au} |
---|
| 20 | } |
---|
| 21 | |
---|
| 22 | \date{2 February, 2006} % update before release! |
---|
| 23 | % Use an explicit date so that reformatting |
---|
| 24 | % doesn't cause a new date to be used. Setting |
---|
| 25 | % the date to \today can be used during draft |
---|
| 26 | % stages to make it easier to handle versions. |
---|
| 27 | |
---|
| 28 | \release{1.0} % release version; this is used to define the |
---|
| 29 | % \version macro |
---|
| 30 | |
---|
| 31 | \makeindex % tell \index to actually write the .idx file |
---|
| 32 | %\makemodindex % If this contains a lot of module sections. |
---|
| 33 | |
---|
| 34 | |
---|
| 35 | |
---|
| 36 | |
---|
[2274] | 37 | % Can we get rid of indenting and put a blank line before each para? |
---|
| 38 | % Find out how to change date format |
---|
| 39 | % Relabel sections, subsections |
---|
[2355] | 40 | Make conflict here |
---|
[2329] | 41 | %\setlength{\parindent}{0mm} %\setlength{\parskip}{3pt} |
---|
| 42 | %\setlength{\oddsidemargin}{0.6in}\setlength{\evensidemargin}{0.6in} |
---|
| 43 | %\addtolength{\textheight}{1in} \addtolength{\textwidth}{0.5in} |
---|
| 44 | %\setlength{\marginparwidth}{0in} |
---|
| 45 | %\setlength{\topmargin}{0mm}\setlength{\headheight}{0in} |
---|
[2274] | 46 | |
---|
| 47 | \begin{document} |
---|
| 48 | \maketitle |
---|
| 49 | |
---|
[2329] | 50 | % This makes the contents more accessible from the front page of the HTML. |
---|
| 51 | \ifhtml |
---|
| 52 | \chapter*{Front Matter\label{front}} |
---|
| 53 | \fi |
---|
[2285] | 54 | |
---|
| 55 | %Subversion keywords: |
---|
| 56 | % |
---|
| 57 | %$LastChangedDate: 2006-01-13 16:43:01 +1100 (Fri, 13 Jan 2006) $ |
---|
| 58 | %$LastChangedRevision: 2206 $ |
---|
| 59 | %$LastChangedBy: steve $ |
---|
| 60 | |
---|
[2274] | 61 | |
---|
[2329] | 62 | \begin{abstract} |
---|
| 63 | |
---|
| 64 | \noindent |
---|
| 65 | \textbf{AnuGA}\index{AnuGA} is a hydrodynamic modelling tool that |
---|
[2283] | 66 | allows users to model realistic flow problems in complex geometries. Examples include dam breaks or |
---|
| 67 | the effects of natural hazards such as riverine flooding, storm surges and tsunami. |
---|
[2274] | 68 | |
---|
[2283] | 69 | The user must specify a study area represented by a mesh of triangular |
---|
| 70 | cells, the topography and bathymetry, frictional resistance, initial |
---|
[2329] | 71 | values for water level (called \emph{stage}\index{stage} within Anuga), |
---|
| 72 | boundary |
---|
[2283] | 73 | conditions and forces such as windstress or pressure gradients if |
---|
| 74 | applicable. |
---|
| 75 | |
---|
| 76 | Anuga tracks the evolution of water depth and horizontal momentum |
---|
| 77 | within each cell over time by solving the shallow water wave equation |
---|
| 78 | governing equation using a finite-volume method. |
---|
| 79 | |
---|
| 80 | Anuga cannot model details of breaking waves, flow under ceilings such |
---|
| 81 | as pipes, turbulence and vortices, vertical convection or viscous |
---|
| 82 | flows. |
---|
| 83 | |
---|
| 84 | Anuga also incorporates a mesh generator, called \texttt{pmesh}, that |
---|
| 85 | allows the user to set up the geometry of the problem interactively as |
---|
| 86 | well as tools for interpolation and surface fitting, and a number of |
---|
| 87 | auxiliary tools for visualising and interrogating the model output. |
---|
| 88 | |
---|
| 89 | Most AnuGA components are written in the object-oriented programming |
---|
| 90 | language Python and most users will interact with Anuga by writing |
---|
| 91 | small Python programs based on the Anuga library |
---|
| 92 | functions. Computationally intensive components are written for |
---|
| 93 | efficiency in C routines working directly with the Numerical Python |
---|
| 94 | structures. |
---|
| 95 | |
---|
| 96 | |
---|
[2329] | 97 | \end{abstract} |
---|
[2283] | 98 | |
---|
[2329] | 99 | \tableofcontents |
---|
[2283] | 100 | |
---|
[2274] | 101 | |
---|
[2329] | 102 | \chapter{Introduction} |
---|
| 103 | |
---|
| 104 | |
---|
| 105 | \section{Purpose} |
---|
| 106 | |
---|
[2274] | 107 | The purpose of this user manual is to introduce the new user to |
---|
| 108 | the software, describe what it can do and give step-by-step |
---|
| 109 | instructions for setting up, configuring and running the software. |
---|
| 110 | |
---|
[2329] | 111 | \section{Scope} |
---|
[2274] | 112 | |
---|
| 113 | This manual covers only what is needed to operate the software |
---|
| 114 | after installation. It does not includes instructions for |
---|
| 115 | installing the software or detailed API documentation, both of |
---|
| 116 | which will be covered in separate publications. |
---|
| 117 | |
---|
[2329] | 118 | \section{Audience} |
---|
[2274] | 119 | |
---|
[2283] | 120 | Readers are assumed to be familiar with the operating environment |
---|
[2274] | 121 | and have a general understanding of the problem background, as |
---|
| 122 | well as enough programming experience to adapt the code to |
---|
| 123 | different requirements, as described in this manual, and to |
---|
| 124 | understand the basic terminology of object-oriented programming. |
---|
| 125 | |
---|
[2329] | 126 | \section{Structure of This Manual} |
---|
[2274] | 127 | |
---|
| 128 | This manual is structured as follows: |
---|
| 129 | |
---|
| 130 | \begin{itemize} |
---|
[2283] | 131 | \item Background (What Anuga does) |
---|
| 132 | \item A \emph{Getting Started} section |
---|
| 133 | \item Anuga's overall architecture, components and file formats |
---|
[2284] | 134 | \item Detailed descriptions of the user interface |
---|
[2274] | 135 | \end{itemize} |
---|
| 136 | |
---|
| 137 | |
---|
[2329] | 138 | \pagebreak |
---|
| 139 | \chapter{Getting Started} |
---|
[2274] | 140 | |
---|
| 141 | This section is designed to assist the reader to get started with |
---|
| 142 | \textbf{AnuGA} by working through a simple example. What follows |
---|
| 143 | is a discussion of the structure and operation of the file |
---|
| 144 | \texttt{bedslope.py}, with just enough detail to allow the reader |
---|
| 145 | to appreciate what's involved in setting up a scenario like the |
---|
| 146 | one it depicts. |
---|
| 147 | |
---|
[2329] | 148 | \section{Overview} |
---|
[2274] | 149 | |
---|
| 150 | This example carries out the solution of the shallow-water wave |
---|
| 151 | equation in the simple case of a configuration comprising a flat |
---|
| 152 | bed, sloping at a fixed angle in one direction and having a |
---|
[2283] | 153 | constant depth across each line in the perpendicular direction. |
---|
| 154 | |
---|
[2274] | 155 | The example demonstrates many of the basic ideas involved in |
---|
| 156 | setting up a more complex scenario. In the general case the user |
---|
| 157 | specifies the geometry (bathymetry and topography), the initial |
---|
| 158 | water level, boundary conditions such as tide, and any forcing |
---|
| 159 | terms that may drive the system such as wind stress or atmospheric |
---|
| 160 | pressure gradients. Frictional resistance from the different |
---|
| 161 | terrains in the model is represented by predefined forcing |
---|
[2283] | 162 | terms. The boundary is reflective on three sides and a time dependent wave on one side. |
---|
| 163 | |
---|
[2274] | 164 | The present example, as it represents a simple scenario, does not |
---|
| 165 | include any forcing term, nor is the data taken from a file as it |
---|
| 166 | would be in many typical cases. The quantities involved in the |
---|
| 167 | present problem are: |
---|
| 168 | \begin{itemize} |
---|
[2329] | 169 | \item elevation\index{elevation} |
---|
| 170 | \item friction\index{friction} |
---|
| 171 | \item depth\index{depth} |
---|
| 172 | \item stage\index{stage} |
---|
[2274] | 173 | \end{itemize} |
---|
| 174 | |
---|
| 175 | %\emph{[More details of the problem background]} |
---|
| 176 | |
---|
[2329] | 177 | \section{Outline of the Program} |
---|
[2274] | 178 | |
---|
| 179 | In outline, \texttt{bedslope.py} performs the following steps: |
---|
| 180 | |
---|
| 181 | \begin{enumerate} |
---|
| 182 | |
---|
| 183 | \item Sets up a triangular mesh. |
---|
| 184 | |
---|
| 185 | \item Sets certain parameters governing the mode of |
---|
[2283] | 186 | operation of the model-specifying, for instance, where to store the model output. |
---|
[2274] | 187 | |
---|
[2283] | 188 | |
---|
[2274] | 189 | \item Inputs various quantities describing physical measurements, such |
---|
[2283] | 190 | as the elevation, to be specified at each mesh point (vertex). |
---|
[2274] | 191 | |
---|
| 192 | \item Sets up the boundary conditions. |
---|
| 193 | |
---|
| 194 | \item Carries out the evolution of the model through a series of time |
---|
| 195 | steps and outputs the results, providing a results file that can |
---|
| 196 | be visualised. |
---|
| 197 | |
---|
| 198 | \end{enumerate} |
---|
| 199 | |
---|
[2329] | 200 | \section{The Code} |
---|
[2274] | 201 | |
---|
[2329] | 202 | %FIXME: we are using the \code function here. This should be used whereever possible |
---|
[2274] | 203 | For reference we include below the complete code listing for |
---|
[2329] | 204 | \code{bedslope.py}. Subsequent paragraphs provide a `commentary' |
---|
[2283] | 205 | that describes each step of the program and explains it significance. |
---|
[2274] | 206 | |
---|
[2283] | 207 | |
---|
| 208 | %\emph{[Can't work out how to prevent \LaTeX (or WinEdt) from |
---|
| 209 | %wrapping lines, even in \emph{verbatim} mode, without putting} |
---|
| 210 | %\verb+\\+\emph{s at the ends of lines!]} |
---|
| 211 | |
---|
[2277] | 212 | {\scriptsize \begin{verbatim} |
---|
| 213 | from pyvolution.mesh_factory import rectangular |
---|
[2274] | 214 | from pyvolution.shallow_water import Domain, Reflective_boundary, |
---|
| 215 | Dirichlet_boundary, Time_boundary, Transmissive_boundary |
---|
| 216 | |
---|
| 217 | #Create basic mesh |
---|
| 218 | points, vertices, boundary = rectangular(10,10) |
---|
| 219 | |
---|
[2277] | 220 | #Create shallow water domain |
---|
| 221 | domain = Domain(points, vertices,boundary) |
---|
[2289] | 222 | domain.set_name('bedslope') |
---|
[2274] | 223 | |
---|
[2289] | 224 | |
---|
[2274] | 225 | ####################### |
---|
| 226 | # Initial conditions |
---|
| 227 | def f(x,y): |
---|
| 228 | return -x/2 |
---|
| 229 | |
---|
| 230 | domain.set_quantity('elevation', f) |
---|
| 231 | domain.set_quantity('friction', 0.1) |
---|
| 232 | |
---|
| 233 | h = 0.05 # Constant depth |
---|
| 234 | domain.set_quantity('stage', expression = 'elevation + %f' %h) |
---|
| 235 | |
---|
| 236 | |
---|
[2277] | 237 | # Boundary conditions |
---|
| 238 | from math import sin, pi |
---|
| 239 | Br = Reflective_boundary(domain) |
---|
| 240 | Bt = Transmissive_boundary(domain) |
---|
| 241 | Bd = Dirichlet_boundary([0.2,0.,0.]) |
---|
[2274] | 242 | |
---|
| 243 | Bw = Time_boundary(domain=domain, |
---|
| 244 | f=lambda t: [(0.1*sin(t*2*pi)), 0.0, 0.0]) |
---|
| 245 | |
---|
| 246 | |
---|
[2277] | 247 | domain.set_boundary({'left': Bd, 'right': Br, 'top': Br, 'bottom': Br}) |
---|
[2274] | 248 | |
---|
| 249 | |
---|
[2277] | 250 | ###################### |
---|
[2274] | 251 | #Evolution |
---|
| 252 | |
---|
| 253 | domain.check_integrity() |
---|
| 254 | |
---|
| 255 | for t in domain.evolve(yieldstep = 0.1, finaltime = 4.0): |
---|
| 256 | domain.write_time() |
---|
| 257 | |
---|
| 258 | |
---|
[2277] | 259 | \end{verbatim}} |
---|
[2274] | 260 | |
---|
| 261 | |
---|
[2329] | 262 | \section{Establishing the Mesh} |
---|
[2274] | 263 | |
---|
| 264 | The first task is to set up the triangular mesh to be used for the |
---|
| 265 | scenario. This is carried out through the statement: |
---|
| 266 | |
---|
[2277] | 267 | {\small \begin{verbatim} |
---|
[2283] | 268 | points, vertices, boundary = rectangular(10, 10) |
---|
[2277] | 269 | \end{verbatim}} |
---|
[2274] | 270 | |
---|
| 271 | The function \texttt{rectangular} is imported from a module |
---|
| 272 | \texttt{mesh\_factory} defined elsewhere. (\textbf{AnuGA} also |
---|
| 273 | contains several other schemes that can be used for setting up |
---|
| 274 | meshes, but we shall not discuss these now.) The above assignment |
---|
| 275 | sets up a $10 \times 10$ rectangular mesh, triangulated in a |
---|
| 276 | specific way. In general, the assignment |
---|
| 277 | |
---|
[2277] | 278 | {\small \begin{verbatim} |
---|
[2274] | 279 | points, vertices, boundary = rectangular(m, n) |
---|
[2277] | 280 | \end{verbatim}} |
---|
[2274] | 281 | |
---|
| 282 | returns: |
---|
| 283 | |
---|
| 284 | \begin{itemize} |
---|
| 285 | |
---|
| 286 | \item a list \texttt{points} of length $N$, where $N = (m + 1)(n + 1)$, |
---|
| 287 | comprising the coordinates $(x, y)$ of each of the $N$ mesh |
---|
| 288 | points, |
---|
| 289 | |
---|
| 290 | \item a list \texttt{vertices} of length $2mn$ (each entry specifies the three |
---|
| 291 | vertices of one of the triangles used in the triangulation) , and |
---|
| 292 | |
---|
| 293 | \item a dictionary \texttt{boundary}, used to tag the triangle edges on |
---|
| 294 | the boundaries. Each key corresponds to a triangle edge on one of |
---|
| 295 | the four boundaries and its value is one of \texttt{`left'}, |
---|
| 296 | \texttt{`right'}, \texttt{`top'} and \texttt{`bottom'}, indicating |
---|
| 297 | which boundary the edge in question belongs to. |
---|
| 298 | |
---|
| 299 | \end{itemize} |
---|
| 300 | |
---|
| 301 | |
---|
[2329] | 302 | \section{Initialising the domain} |
---|
[2274] | 303 | |
---|
| 304 | These variables are then used to set up a data structure |
---|
| 305 | \texttt{domain}, through the assignment: |
---|
| 306 | |
---|
[2277] | 307 | {\small \begin{verbatim} |
---|
[2274] | 308 | domain = Domain(points, vertices, boundary) |
---|
[2277] | 309 | \end{verbatim}} |
---|
[2274] | 310 | |
---|
| 311 | This uses a Python class \texttt{Domain}, imported from |
---|
| 312 | \texttt{shallow\_water}, which is an extension of a more generic |
---|
| 313 | class of the same name in the module \texttt{domain}, and inherits |
---|
| 314 | some methods from the generic class but has others specific to the |
---|
[2289] | 315 | shallow-water scenarios in which it is used. Specific options for domain |
---|
| 316 | are set at this point. One of them are to set the basename for the output file |
---|
[2274] | 317 | |
---|
[2277] | 318 | {\scriptsize \begin{verbatim} |
---|
[2289] | 319 | domain.set_name('bedslope') |
---|
[2277] | 320 | \end{verbatim}} |
---|
[2274] | 321 | |
---|
| 322 | |
---|
[2329] | 323 | \section{Specifying the Quantities} |
---|
[2274] | 324 | |
---|
[2283] | 325 | The next task is to specify a number of quantities that we wish to set |
---|
| 326 | for each mesh point. The class \texttt{Domain} has a method |
---|
[2274] | 327 | \texttt{set\_quantity}, used to specify these quantities. It is a |
---|
[2283] | 328 | particularly flexible method that allows the user to set quantities in |
---|
| 329 | a variety of ways---using constants, functions, numeric arrays or |
---|
| 330 | expressions involving other quantities, arbitrary data points with |
---|
| 331 | associated values, all of which can be passed as arguments. All |
---|
| 332 | quantities can be initialised using \texttt{set\_quantity}. For |
---|
| 333 | conserved quantities (\texttt{stage, xmomentum, ymomentum}) this is |
---|
| 334 | called the \emph{initial condition}, for other quantities that aren't |
---|
| 335 | updated by the equation, the same interface is used to assign their |
---|
| 336 | values. The code in the present example demonstrates a number of forms |
---|
| 337 | in which we can invoke \texttt{set\_quantity}. |
---|
[2274] | 338 | |
---|
| 339 | |
---|
[2329] | 340 | \subsection{Elevation} |
---|
[2274] | 341 | |
---|
| 342 | The elevation is set using a function, defined through the |
---|
| 343 | statements below, which is specific to this example and specifies |
---|
| 344 | a particularly simple initial configuration for demonstration |
---|
| 345 | purposes: |
---|
| 346 | |
---|
[2277] | 347 | {\small \begin{verbatim} |
---|
[2274] | 348 | def f(x,y): |
---|
| 349 | return -x/2 |
---|
[2277] | 350 | \end{verbatim}} |
---|
[2274] | 351 | |
---|
| 352 | This simply associates an elevation with each point $(x, y)$ of |
---|
| 353 | the plane. It specifies that the bed slopes linearly in the $x$ |
---|
| 354 | direction, with slope $-\frac{1}{2}$, and is constant in the $y$ |
---|
| 355 | direction.\\ %[screen shot?] |
---|
| 356 | \\ |
---|
| 357 | Once the function $f$ is specified, the quantity |
---|
| 358 | \texttt{elevation} is assigned through the simple statement: |
---|
| 359 | |
---|
[2277] | 360 | {\small \begin{verbatim} |
---|
[2274] | 361 | \begin{verbatim} |
---|
| 362 | domain.set_quantity('elevation', f) |
---|
[2277] | 363 | \end{verbatim}} |
---|
[2274] | 364 | |
---|
| 365 | |
---|
[2329] | 366 | \subsection{Friction} |
---|
[2274] | 367 | |
---|
| 368 | The assignment of the friction quantity demonstrates another way |
---|
| 369 | we can use \texttt{set\_quantity} to set quantities---namely, |
---|
| 370 | assign them to a constant numerical value: |
---|
| 371 | |
---|
[2277] | 372 | {\small \begin{verbatim} |
---|
[2274] | 373 | domain.set_quantity('friction', 0.1) |
---|
[2277] | 374 | \end{verbatim}} |
---|
[2274] | 375 | |
---|
| 376 | This just specifies that the Manning friction coefficient is set |
---|
| 377 | to 0.1 at every mesh point. |
---|
| 378 | |
---|
[2329] | 379 | \subsection{Depth} |
---|
[2274] | 380 | |
---|
| 381 | Assigning depth illustrates a more complex way to use |
---|
| 382 | \texttt{set\_quantity}, introducing an expression involving other |
---|
| 383 | quantities: |
---|
| 384 | |
---|
[2277] | 385 | {\small \begin{verbatim} |
---|
[2274] | 386 | h = 0.05 \# Constant depth |
---|
| 387 | domain.set_quantity('stage', expression = 'elevation + %f' %h) |
---|
[2277] | 388 | \end{verbatim}} |
---|
[2274] | 389 | |
---|
| 390 | Here the quantity \texttt{stage} is defined by taking the quantity |
---|
| 391 | elevation already defined and adding a constant value $h = 0.05$ |
---|
| 392 | to it everywhere. This expresses the fact that the water depth is |
---|
| 393 | everywhere constant, so the surface is a constant height above the |
---|
| 394 | elevation of the bed. |
---|
| 395 | |
---|
[2329] | 396 | \subsection{Boundary Conditions} |
---|
[2274] | 397 | |
---|
| 398 | The boundary conditions are specified as follows: |
---|
| 399 | |
---|
[2277] | 400 | {\small \begin{verbatim} |
---|
[2274] | 401 | Br = Reflective_boundary(domain) |
---|
| 402 | |
---|
| 403 | Bt = Transmissive_boundary(domain) |
---|
| 404 | |
---|
| 405 | Bd = Dirichlet_boundary([0.2,0.,0.]) |
---|
| 406 | |
---|
| 407 | Bw = Time_boundary(domain=domain, |
---|
| 408 | f=lambda t: [(0.1*sin(t*2*pi)), 0.0, 0.0]) |
---|
[2277] | 409 | \end{verbatim}} |
---|
[2274] | 410 | |
---|
| 411 | The effect of these statements is to set up four alternative |
---|
| 412 | boundary conditions and store them in variables that can be |
---|
| 413 | assigned as needed. Each boundary condition specifies the |
---|
| 414 | behaviour at a boundary in terms of the behaviour in neighbouring |
---|
| 415 | elements. The boundary conditions may be briefly described as |
---|
| 416 | follows: |
---|
| 417 | |
---|
| 418 | \begin{description} |
---|
[2283] | 419 | \item[Reflective boundary] Returns same \texttt{stage} as |
---|
| 420 | as present in its neighbour volume but momentum vector reversed 180 degrees (reflected). |
---|
| 421 | Specific to the shallow water equation as it works with the |
---|
| 422 | momentum quantities assumed to be the second and third conserved |
---|
| 423 | quantities. |
---|
[2274] | 424 | \item[Transmissive boundary]Returns same conserved quantities as |
---|
| 425 | those present in its neighbour volume. |
---|
| 426 | \item[Dirichlet boundary]Specifies a fixed value at the |
---|
| 427 | boundary. |
---|
| 428 | \item[Time boundary.]A Dirichlet boundary whose behaviour varies with time. |
---|
| 429 | \end{description} |
---|
| 430 | |
---|
| 431 | Once the four boundary types have been specified through the |
---|
| 432 | statements above, they can be applied through a statement of the |
---|
| 433 | form |
---|
| 434 | |
---|
[2277] | 435 | {\small \begin{verbatim} |
---|
| 436 | domain.set_boundary({'left': Bd, 'right': Br, 'top': Br, 'bottom': Br}) |
---|
| 437 | \end{verbatim}} |
---|
[2274] | 438 | |
---|
| 439 | This statement stipulates that, in the current example, the left |
---|
| 440 | boundary is fixed, with an elevation of 0.2, while the other |
---|
| 441 | boundaries are all reflective. |
---|
| 442 | |
---|
| 443 | |
---|
[2329] | 444 | \section{Evolution} |
---|
[2274] | 445 | |
---|
| 446 | The final statement \nopagebreak[3] |
---|
[2277] | 447 | {\small \begin{verbatim} |
---|
[2274] | 448 | for t in domain.evolve(yieldstep = 0.1, finaltime = 4.0): |
---|
| 449 | domain.write_time() |
---|
[2277] | 450 | \end{verbatim}} |
---|
[2274] | 451 | |
---|
| 452 | is the key step that causes the configuration of the domain to |
---|
| 453 | `evolve' in accordance with the model embodied in the code, over a |
---|
| 454 | series of steps indicated by the values of \texttt{yieldstep} and |
---|
| 455 | \texttt{finaltime}, which can be altered as required. |
---|
[2283] | 456 | The yieldstep control the time interval between model output. Behind the scenes more timesteps are generally taken. |
---|
[2274] | 457 | |
---|
| 458 | |
---|
[2283] | 459 | |
---|
| 460 | |
---|
[2329] | 461 | \section{Output} |
---|
[2274] | 462 | |
---|
| 463 | %Give details here of the form of the output and explain how it can |
---|
| 464 | %be used with swollen. Include screen shots.// |
---|
| 465 | |
---|
| 466 | The output is a NetCDF file with the extension \texttt{.sww}. It |
---|
| 467 | contains stage and momentum information and can be used with the |
---|
[2283] | 468 | \texttt{swollen} visualisation package to generate a visual display. |
---|
[2274] | 469 | |
---|
| 470 | |
---|
[2329] | 471 | \section{How to Run the Code} |
---|
[2274] | 472 | |
---|
| 473 | The code can be run in various ways: |
---|
| 474 | |
---|
| 475 | \begin{itemize} |
---|
[2283] | 476 | \item{from a Windows command line} as in \texttt{python bedslope.py} |
---|
[2274] | 477 | |
---|
| 478 | \item{within the Python IDLE environment} |
---|
| 479 | |
---|
| 480 | \item{within emacs} |
---|
| 481 | |
---|
[2283] | 482 | \item{from a Linux command line} as in \texttt{python bedslope.py} |
---|
[2274] | 483 | \end{itemize} |
---|
| 484 | |
---|
| 485 | |
---|
| 486 | |
---|
| 487 | |
---|
[2329] | 488 | \appendix |
---|
| 489 | \chapter{Glossary} |
---|
[2274] | 490 | |
---|
| 491 | \begin{description} |
---|
| 492 | |
---|
[2328] | 493 | \item[AnuGA] name of software (joint development between ANU and GA) |
---|
[2283] | 494 | |
---|
| 495 | \item[Conserved quantity] |
---|
[2274] | 496 | |
---|
[2328] | 497 | \item[Default order] is this really needed? |
---|
[2274] | 498 | |
---|
| 499 | \item[Domain] |
---|
| 500 | |
---|
| 501 | \item[Dirichlet boundary] |
---|
| 502 | |
---|
[2328] | 503 | \item[Elevation] - refers to bathymetry and topography |
---|
[2274] | 504 | |
---|
[2328] | 505 | \item[bathymetry] offshore |
---|
[2274] | 506 | |
---|
[2328] | 507 | \item[topography] onshore |
---|
| 508 | |
---|
| 509 | \item[Evolution] integration of the shallow water wave equations over time |
---|
| 510 | |
---|
[2283] | 511 | \item[Forcing term] |
---|
[2274] | 512 | |
---|
[2328] | 513 | \item[IDLE] development environment shipped with Python |
---|
[2274] | 514 | |
---|
| 515 | \item[Manning friction coefficient] |
---|
[2283] | 516 | |
---|
[2328] | 517 | \item[Mesh] triangulation of domain |
---|
[2274] | 518 | |
---|
[2328] | 519 | \item[Grid] evenly spaced |
---|
| 520 | |
---|
[2274] | 521 | \item[NetCDF] |
---|
| 522 | |
---|
[2328] | 523 | \item[pmesh] does this really need to be here? it's a class/module? |
---|
[2274] | 524 | |
---|
[2328] | 525 | \item[pyvolution] does this really need to be here? it's a class/module? |
---|
[2274] | 526 | |
---|
[2328] | 527 | \item[Quantity] conserved (state, x and y momentum) |
---|
[2274] | 528 | |
---|
| 529 | \item[Reflective boundary] |
---|
| 530 | |
---|
[2328] | 531 | \item[Smoothing] is this really needed? |
---|
[2274] | 532 | |
---|
| 533 | \item[Stage] |
---|
| 534 | |
---|
[2328] | 535 | \item[Swollen] visualisation tool |
---|
[2274] | 536 | |
---|
[2328] | 537 | \item[Time boundary] defined in the manual (flog from there) |
---|
[2274] | 538 | |
---|
[2328] | 539 | \item[Transmissive boundary] defined in the manual (flog from there) |
---|
[2274] | 540 | |
---|
[2328] | 541 | \item[xmomentum] conserved quantity (note, two-dimensional SWW equations say only x and y and NOT z) |
---|
[2283] | 542 | |
---|
[2328] | 543 | \item[ymomentum] conserved quantity |
---|
[2274] | 544 | |
---|
[2328] | 545 | \item[resolution] refers to the maximal area of each triangular cell in the mesh |
---|
[2274] | 546 | |
---|
[2328] | 547 | \item[easting] |
---|
| 548 | |
---|
| 549 | \item[northing] |
---|
| 550 | |
---|
| 551 | \item[latitude] |
---|
| 552 | |
---|
| 553 | \item[longitude] |
---|
| 554 | |
---|
| 555 | \item[edge] |
---|
| 556 | |
---|
| 557 | \item[vertex] |
---|
| 558 | |
---|
| 559 | \item[finite volume] |
---|
| 560 | |
---|
| 561 | \item[flux] |
---|
| 562 | |
---|
| 563 | \item[Digital Elevation Model (DEM)] |
---|
| 564 | |
---|
| 565 | |
---|
[2274] | 566 | \end{description} |
---|
| 567 | |
---|
[2329] | 568 | The \code{\e appendix} markup need not be repeated for additional |
---|
| 569 | appendices. |
---|
| 570 | |
---|
| 571 | |
---|
| 572 | % |
---|
| 573 | % The ugly "%begin{latexonly}" pseudo-environments are really just to |
---|
| 574 | % keep LaTeX2HTML quiet during the \renewcommand{} macros; they're |
---|
| 575 | % not really valuable. |
---|
| 576 | % |
---|
| 577 | % If you don't want the Module Index, you can remove all of this up |
---|
| 578 | % until the second \input line. |
---|
| 579 | % |
---|
| 580 | |
---|
| 581 | %begin{latexonly} |
---|
| 582 | %\renewcommand{\indexname}{Module Index} |
---|
| 583 | %end{latexonly} |
---|
| 584 | %\input{mod\jobname.ind} % Module Index |
---|
| 585 | |
---|
| 586 | %begin{latexonly} |
---|
| 587 | \renewcommand{\indexname}{Index} |
---|
| 588 | %end{latexonly} |
---|
| 589 | \input{\jobname.ind} % Index |
---|
| 590 | |
---|
| 591 | |
---|
| 592 | |
---|
[2274] | 593 | \end{document} |
---|