[3275] | 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 | |
---|
[3449] | 15 | % Is latex failing with; |
---|
| 16 | % `modanuga_user_manual.ind' not found? |
---|
| 17 | % try this command-line |
---|
| 18 | % makeindex modanuga_user_manual.idx |
---|
| 19 | % To produce the modanuga_user_manual.ind file. |
---|
[3275] | 20 | |
---|
| 21 | |
---|
| 22 | \documentclass{manual} |
---|
| 23 | |
---|
| 24 | \usepackage{graphicx} |
---|
| 25 | \usepackage{datetime} |
---|
| 26 | |
---|
| 27 | \input{definitions} |
---|
| 28 | |
---|
| 29 | \title{\anuga User Manual} |
---|
| 30 | \author{Geoscience Australia and the Australian National University} |
---|
| 31 | |
---|
| 32 | % Please at least include a long-lived email address; |
---|
| 33 | % the rest is at your discretion. |
---|
| 34 | \authoraddress{Geoscience Australia \\ |
---|
| 35 | Email: \email{ole.nielsen@ga.gov.au} |
---|
| 36 | } |
---|
| 37 | |
---|
| 38 | %Draft date |
---|
| 39 | |
---|
| 40 | % update before release! |
---|
| 41 | % Use an explicit date so that reformatting |
---|
| 42 | % doesn't cause a new date to be used. Setting |
---|
| 43 | % the date to \today can be used during draft |
---|
| 44 | % stages to make it easier to handle versions. |
---|
| 45 | |
---|
| 46 | |
---|
| 47 | \longdate % Make date format long using datetime.sty |
---|
| 48 | %\settimeformat{xxivtime} % 24 hour Format |
---|
| 49 | \settimeformat{oclock} % Verbose |
---|
| 50 | \date{\today, \ \currenttime} |
---|
| 51 | %\hyphenation{set\_datadir} |
---|
| 52 | |
---|
| 53 | \ifhtml |
---|
| 54 | \date{\today} % latex2html does not know about datetime |
---|
| 55 | \fi |
---|
| 56 | |
---|
| 57 | |
---|
| 58 | |
---|
| 59 | |
---|
| 60 | |
---|
| 61 | \release{1.0} % release version; this is used to define the |
---|
| 62 | % \version macro |
---|
| 63 | |
---|
| 64 | \makeindex % tell \index to actually write the .idx file |
---|
| 65 | \makemodindex % If this contains a lot of module sections. |
---|
| 66 | |
---|
| 67 | \setcounter{tocdepth}{3} |
---|
| 68 | \setcounter{secnumdepth}{3} |
---|
| 69 | |
---|
| 70 | |
---|
| 71 | \begin{document} |
---|
| 72 | \maketitle |
---|
| 73 | |
---|
| 74 | |
---|
| 75 | % This makes the contents more accessible from the front page of the HTML. |
---|
| 76 | \ifhtml |
---|
| 77 | \chapter*{Front Matter\label{front}} |
---|
| 78 | \fi |
---|
| 79 | |
---|
| 80 | %Subversion keywords: |
---|
| 81 | % |
---|
| 82 | %$LastChangedDate: 2006-08-29 07:12:03 +0000 (Tue, 29 Aug 2006) $ |
---|
| 83 | %$LastChangedRevision: 3541 $ |
---|
| 84 | %$LastChangedBy: duncan $ |
---|
| 85 | |
---|
| 86 | \input{copyright} |
---|
| 87 | |
---|
| 88 | |
---|
| 89 | \begin{abstract} |
---|
| 90 | \label{def:anuga} |
---|
| 91 | |
---|
| 92 | \noindent \anuga\index{\anuga} is a hydrodynamic modelling tool that |
---|
| 93 | allows users to model realistic flow problems in complex geometries. |
---|
| 94 | Examples include dam breaks or the effects of natural hazards such |
---|
| 95 | as riverine flooding, storm surges and tsunami. |
---|
| 96 | |
---|
| 97 | The user must specify a study area represented by a mesh of triangular |
---|
| 98 | cells, the topography and bathymetry, frictional resistance, initial |
---|
| 99 | values for water level (called \emph{stage}\index{stage} within \anuga), |
---|
| 100 | boundary |
---|
| 101 | conditions and forces such as windstress or pressure gradients if |
---|
| 102 | applicable. |
---|
| 103 | |
---|
| 104 | \anuga tracks the evolution of water depth and horizontal momentum |
---|
| 105 | within each cell over time by solving the shallow water wave equation |
---|
| 106 | governing equation using a finite-volume method. |
---|
| 107 | |
---|
| 108 | \anuga cannot model details of breaking waves, flow under ceilings such |
---|
| 109 | as pipes, turbulence and vortices, vertical convection or viscous |
---|
| 110 | flows. |
---|
| 111 | |
---|
| 112 | \anuga also incorporates a mesh generator, called \code{pmesh}, that |
---|
| 113 | allows the user to set up the geometry of the problem interactively as |
---|
| 114 | well as tools for interpolation and surface fitting, and a number of |
---|
| 115 | auxiliary tools for visualising and interrogating the model output. |
---|
| 116 | |
---|
| 117 | Most \anuga components are written in the object-oriented programming |
---|
| 118 | language Python and most users will interact with \anuga by writing |
---|
| 119 | small Python programs based on the \anuga library |
---|
| 120 | functions. Computationally intensive components are written for |
---|
| 121 | efficiency in C routines working directly with the Numerical Python |
---|
| 122 | structures. |
---|
| 123 | |
---|
| 124 | |
---|
| 125 | \end{abstract} |
---|
| 126 | |
---|
| 127 | \tableofcontents |
---|
| 128 | |
---|
| 129 | |
---|
| 130 | \chapter{Introduction} |
---|
| 131 | |
---|
| 132 | |
---|
| 133 | \section{Purpose} |
---|
| 134 | |
---|
| 135 | The purpose of this user manual is to introduce the new user to the |
---|
| 136 | inundation software, describe what it can do and give step-by-step |
---|
| 137 | instructions for setting up and running hydrodynamic simulations. |
---|
| 138 | |
---|
| 139 | \section{Scope} |
---|
| 140 | |
---|
| 141 | This manual covers only what is needed to operate the software after |
---|
| 142 | installation and configuration. It does not includes instructions |
---|
| 143 | for installing the software or detailed API documentation, both of |
---|
| 144 | which will be covered in separate publications and by documentation |
---|
| 145 | in the source code. |
---|
| 146 | |
---|
| 147 | \section{Audience} |
---|
| 148 | |
---|
| 149 | Readers are assumed to be familiar with the operating environment |
---|
| 150 | and have a general understanding of the subject matter, as well as |
---|
| 151 | enough programming experience to adapt the code to different |
---|
| 152 | requirements and to understand the basic terminology of |
---|
| 153 | object-oriented programming. |
---|
| 154 | |
---|
| 155 | \pagebreak |
---|
| 156 | \chapter{Background} |
---|
| 157 | |
---|
| 158 | |
---|
| 159 | Modelling the effects on the built environment of natural hazards such |
---|
| 160 | as riverine flooding, storm surges and tsunami is critical for |
---|
| 161 | understanding their economic and social impact on our urban |
---|
| 162 | communities. Geoscience Australia and the Australian National |
---|
| 163 | University are developing a hydrodynamic inundation modelling tool |
---|
| 164 | called \anuga to help simulate the impact of these hazards. |
---|
| 165 | |
---|
| 166 | The core of \anuga is the fluid dynamics module, called pyvolution, |
---|
| 167 | which is based on a finite-volume method for solving the shallow water |
---|
| 168 | wave equation. The study area is represented by a mesh of triangular |
---|
| 169 | cells. By solving the governing equation within each cell, water |
---|
| 170 | depth and horizontal momentum are tracked over time. |
---|
| 171 | |
---|
| 172 | A major capability of pyvolution is that it can model the process of |
---|
| 173 | wetting and drying as water enters and leaves an area. This means |
---|
| 174 | that it is suitable for simulating water flow onto a beach or dry land |
---|
| 175 | and around structures such as buildings. Pyvolution is also capable |
---|
| 176 | of modelling hydraulic jumps due to the ability of the finite-volume |
---|
| 177 | method to accommodate discontinuities in the solution. |
---|
| 178 | |
---|
| 179 | To set up a particular scenario the user specifies the geometry |
---|
| 180 | (bathymetry and topography), the initial water level (stage), |
---|
| 181 | boundary conditions such as tide, and any forcing terms that may |
---|
| 182 | drive the system such as wind stress or atmospheric pressure |
---|
| 183 | gradients. Gravity and frictional resistance from the different |
---|
| 184 | terrains in the model are represented by predefined forcing terms. |
---|
| 185 | |
---|
| 186 | A mesh generator, called pmesh, allows the user to set up the geometry |
---|
| 187 | of the problem interactively and to identify boundary segments and |
---|
| 188 | regions using symbolic tags. These tags may then be used to set the |
---|
| 189 | actual boundary conditions and attributes for different regions |
---|
| 190 | (e.g. the Manning friction coefficient) for each simulation. |
---|
| 191 | |
---|
| 192 | Most \anuga components are written in the object-oriented programming |
---|
| 193 | language Python. Software written in Python can be produced quickly |
---|
| 194 | and can be readily adapted to changing requirements throughout its |
---|
| 195 | lifetime. Computationally intensive components are written for |
---|
| 196 | efficiency in C routines working directly with the Numerical Python |
---|
| 197 | structures. The animation tool developed for \anuga is based on |
---|
| 198 | OpenSceneGraph, an Open Source Software (OSS) component allowing high |
---|
| 199 | level interaction with sophisticated graphics primitives. |
---|
| 200 | See \cite{nielsen2005} for more background on \anuga. |
---|
| 201 | |
---|
| 202 | \chapter{Restrictions and limitations on \anuga} |
---|
| 203 | |
---|
| 204 | Although a powerful and flexible tool for hydrodynamic modelling, \anuga has a |
---|
| 205 | number of limitations that any potential user need to be aware of. They are |
---|
| 206 | |
---|
| 207 | \begin{itemize} |
---|
| 208 | \item The mathematical model is the 2D shallow water wave equation. |
---|
| 209 | As such it cannot resolve vertical convection and consequently not breaking |
---|
| 210 | waves or 3D turbulence (e.g.\ vorticity). |
---|
| 211 | \item The finite volume is a very robust and flexible numerical technique, |
---|
| 212 | but it is not the fastest method around. If the geometry is sufficiently |
---|
| 213 | simple and if there is no need for wetting or drying, a finite-difference |
---|
| 214 | method may be able to solve the problem faster than \anuga. |
---|
| 215 | %\item Mesh resolutions near coastlines with steep gradients need to be... |
---|
| 216 | \item Frictional resistance is implemented using Manning's formula, but |
---|
| 217 | \anuga has not yet been validated in regard to bottom roughness |
---|
| 218 | \end{itemize} |
---|
| 219 | |
---|
| 220 | |
---|
| 221 | |
---|
| 222 | \chapter{Getting Started} |
---|
| 223 | \label{ch:getstarted} |
---|
| 224 | |
---|
| 225 | This section is designed to assist the reader to get started with |
---|
| 226 | \anuga by working through some examples. Two examples are discussed; |
---|
| 227 | the first is a simple example to illustrate many of the ideas, and |
---|
| 228 | the second is a more realistic example. |
---|
| 229 | |
---|
| 230 | \section{A Simple Example} |
---|
| 231 | \label{sec:simpleexample} |
---|
| 232 | |
---|
| 233 | \subsection{Overview} |
---|
| 234 | |
---|
| 235 | What follows is a discussion of the structure and operation of a |
---|
| 236 | script called \file{runup.py}. |
---|
| 237 | |
---|
| 238 | This example carries out the solution of the shallow-water wave |
---|
| 239 | equation in the simple case of a configuration comprising a flat |
---|
| 240 | bed, sloping at a fixed angle in one direction and having a |
---|
| 241 | constant depth across each line in the perpendicular direction. |
---|
| 242 | |
---|
| 243 | The example demonstrates the basic ideas involved in setting up a |
---|
| 244 | complex scenario. In general the user specifies the geometry |
---|
| 245 | (bathymetry and topography), the initial water level, boundary |
---|
| 246 | conditions such as tide, and any forcing terms that may drive the |
---|
| 247 | system such as wind stress or atmospheric pressure gradients. |
---|
| 248 | Frictional resistance from the different terrains in the model is |
---|
| 249 | represented by predefined forcing terms. In this example, the |
---|
| 250 | boundary is reflective on three sides and a time dependent wave on |
---|
| 251 | one side. |
---|
| 252 | |
---|
| 253 | The present example represents a simple scenario and does not |
---|
| 254 | include any forcing terms, nor is the data taken from a file as it |
---|
| 255 | would typically be. |
---|
| 256 | |
---|
| 257 | The conserved quantities involved in the |
---|
| 258 | problem are stage (absolute height of water surface), |
---|
| 259 | $x$-momentum and $y$-momentum. Other quantities |
---|
| 260 | involved in the computation are the friction and elevation. |
---|
| 261 | |
---|
| 262 | Water depth can be obtained through the equation |
---|
| 263 | |
---|
| 264 | \begin{tabular}{rcrcl} |
---|
| 265 | \code{depth} &=& \code{stage} &$-$& \code{elevation} |
---|
| 266 | \end{tabular} |
---|
| 267 | |
---|
| 268 | |
---|
| 269 | \subsection{Outline of the Program} |
---|
| 270 | |
---|
| 271 | In outline, \file{runup.py} performs the following steps: |
---|
| 272 | |
---|
| 273 | \begin{enumerate} |
---|
| 274 | |
---|
| 275 | \item Sets up a triangular mesh. |
---|
| 276 | |
---|
| 277 | \item Sets certain parameters governing the mode of |
---|
| 278 | operation of the model-specifying, for instance, where to store the model output. |
---|
| 279 | |
---|
| 280 | \item Inputs various quantities describing physical measurements, such |
---|
| 281 | as the elevation, to be specified at each mesh point (vertex). |
---|
| 282 | |
---|
| 283 | \item Sets up the boundary conditions. |
---|
| 284 | |
---|
| 285 | \item Carries out the evolution of the model through a series of time |
---|
| 286 | steps and outputs the results, providing a results file that can |
---|
| 287 | be visualised. |
---|
| 288 | |
---|
| 289 | \end{enumerate} |
---|
| 290 | |
---|
| 291 | \subsection{The Code} |
---|
| 292 | |
---|
| 293 | %FIXME: we are using the \code function here. |
---|
| 294 | %This should be used wherever possible |
---|
| 295 | For reference we include below the complete code listing for |
---|
| 296 | \file{runup.py}. Subsequent paragraphs provide a |
---|
| 297 | `commentary' that describes each step of the program and explains it |
---|
| 298 | significance. |
---|
| 299 | |
---|
| 300 | \verbatiminput{examples/runup.py} |
---|
| 301 | %\verbatiminput{examples/bedslope.py} |
---|
| 302 | |
---|
| 303 | \subsection{Establishing the Mesh}\index{mesh, establishing} |
---|
| 304 | |
---|
| 305 | The first task is to set up the triangular mesh to be used for the |
---|
| 306 | scenario. This is carried out through the statement: |
---|
| 307 | |
---|
| 308 | {\small \begin{verbatim} |
---|
| 309 | points, vertices, boundary = rectangular(10, 10) |
---|
| 310 | \end{verbatim}} |
---|
| 311 | |
---|
| 312 | The function \function{rectangular} is imported from a module |
---|
| 313 | \module{mesh\_factory} defined elsewhere. (\anuga also contains |
---|
| 314 | several other schemes that can be used for setting up meshes, but we |
---|
| 315 | shall not discuss these.) The above assignment sets up a $10 \times |
---|
| 316 | 10$ rectangular mesh, triangulated in a regular way. The assignment |
---|
| 317 | |
---|
| 318 | {\small \begin{verbatim} |
---|
| 319 | points, vertices, boundary = rectangular(m, n) |
---|
| 320 | \end{verbatim}} |
---|
| 321 | |
---|
| 322 | returns: |
---|
| 323 | |
---|
| 324 | \begin{itemize} |
---|
| 325 | |
---|
| 326 | \item a list \code{points} giving the coordinates of each mesh point, |
---|
| 327 | |
---|
| 328 | \item a list \code{vertices} specifying the three vertices of each triangle, and |
---|
| 329 | |
---|
| 330 | \item a dictionary \code{boundary} that stores the edges on |
---|
| 331 | the boundary and associates each with one of the symbolic tags \code{`left'}, \code{`right'}, |
---|
| 332 | \code{`top'} or \code{`bottom'}. |
---|
| 333 | |
---|
| 334 | \end{itemize} |
---|
| 335 | |
---|
| 336 | (For more details on symbolic tags, see page |
---|
| 337 | \pageref{ref:tagdescription}.) |
---|
| 338 | |
---|
| 339 | An example of a general unstructured mesh and the associated data |
---|
| 340 | structures \code{points}, \code{vertices} and \code{boundary} is |
---|
| 341 | given in Section \ref{sec:meshexample}. |
---|
| 342 | |
---|
| 343 | |
---|
| 344 | |
---|
| 345 | |
---|
| 346 | \subsection{Initialising the Domain} |
---|
| 347 | |
---|
| 348 | These variables are then used to set up a data structure |
---|
| 349 | \code{domain}, through the assignment: |
---|
| 350 | |
---|
| 351 | {\small \begin{verbatim} |
---|
| 352 | domain = Domain(points, vertices, boundary) |
---|
| 353 | \end{verbatim}} |
---|
| 354 | |
---|
| 355 | This creates an instance of the \class{Domain} class, which |
---|
| 356 | represents the domain of the simulation. Specific options are set at |
---|
| 357 | this point, including the basename for the output file and the |
---|
| 358 | directory to be used for data: |
---|
| 359 | |
---|
| 360 | {\small \begin{verbatim} |
---|
| 361 | domain.set_name('bedslope') |
---|
| 362 | \end{verbatim}} |
---|
| 363 | |
---|
| 364 | {\small \begin{verbatim} |
---|
| 365 | domain.set_datadir('.') |
---|
| 366 | \end{verbatim}} |
---|
| 367 | |
---|
| 368 | In addition, the following statement now specifies that the |
---|
| 369 | quantities \code{stage}, \code{xmomentum} and \code{ymomentum} are |
---|
| 370 | to be stored: |
---|
| 371 | |
---|
| 372 | {\small \begin{verbatim} |
---|
| 373 | domain.set_quantities_to_be_stored(['stage', 'xmomentum', |
---|
| 374 | 'ymomentum']) |
---|
| 375 | \end{verbatim}} |
---|
| 376 | |
---|
| 377 | |
---|
| 378 | \subsection{Initial Conditions} |
---|
| 379 | |
---|
| 380 | The next task is to specify a number of quantities that we wish to |
---|
| 381 | set for each mesh point. The class \class{Domain} has a method |
---|
| 382 | \method{set\_quantity}, used to specify these quantities. It is a |
---|
| 383 | flexible method that allows the user to set quantities in a variety |
---|
| 384 | of ways---using constants, functions, numeric arrays, expressions |
---|
| 385 | involving other quantities, or arbitrary data points with associated |
---|
| 386 | values, all of which can be passed as arguments. All quantities can |
---|
| 387 | be initialised using \method{set\_quantity}. For a conserved |
---|
| 388 | quantity (such as \code{stage, xmomentum, ymomentum}) this is called |
---|
| 389 | an \emph{initial condition}. However, other quantities that aren't |
---|
| 390 | updated by the equation are also assigned values using the same |
---|
| 391 | interface. The code in the present example demonstrates a number of |
---|
| 392 | forms in which we can invoke \method{set\_quantity}. |
---|
| 393 | |
---|
| 394 | |
---|
| 395 | \subsubsection{Elevation} |
---|
| 396 | |
---|
| 397 | The elevation, or height of the bed, is set using a function, |
---|
| 398 | defined through the statements below, which is specific to this |
---|
| 399 | example and specifies a particularly simple initial configuration |
---|
| 400 | for demonstration purposes: |
---|
| 401 | |
---|
| 402 | {\small \begin{verbatim} |
---|
| 403 | def f(x,y): |
---|
| 404 | return -x/2 |
---|
| 405 | \end{verbatim}} |
---|
| 406 | |
---|
| 407 | This simply associates an elevation with each point \code{(x, y)} of |
---|
| 408 | the plane. It specifies that the bed slopes linearly in the |
---|
| 409 | \code{x} direction, with slope $-\frac{1}{2}$, and is constant in |
---|
| 410 | the \code{y} direction. |
---|
| 411 | |
---|
| 412 | Once the function \function{f} is specified, the quantity |
---|
| 413 | \code{elevation} is assigned through the simple statement: |
---|
| 414 | |
---|
| 415 | {\small \begin{verbatim} |
---|
| 416 | domain.set_quantity('elevation', f) |
---|
| 417 | \end{verbatim}} |
---|
| 418 | |
---|
| 419 | |
---|
| 420 | \subsubsection{Friction} |
---|
| 421 | |
---|
| 422 | The assignment of the friction quantity (a forcing term) |
---|
| 423 | demonstrates another way we can use \method{set\_quantity} to set |
---|
| 424 | quantities---namely, assign them to a constant numerical value: |
---|
| 425 | |
---|
| 426 | {\small \begin{verbatim} |
---|
| 427 | domain.set_quantity('friction', 0.1) |
---|
| 428 | \end{verbatim}} |
---|
| 429 | |
---|
| 430 | This specifies that the Manning friction coefficient is set to 0.1 |
---|
| 431 | at every mesh point. |
---|
| 432 | |
---|
| 433 | \subsubsection{Stage} |
---|
| 434 | |
---|
| 435 | The stage (the height of the water surface) is related to the |
---|
| 436 | elevation and the depth at any time by the equation |
---|
| 437 | |
---|
| 438 | {\small \begin{verbatim} |
---|
| 439 | stage = elevation + depth |
---|
| 440 | \end{verbatim}} |
---|
| 441 | |
---|
| 442 | |
---|
| 443 | For this example, we simply assign a constant value to \code{stage}, |
---|
| 444 | using the statement |
---|
| 445 | |
---|
| 446 | {\small \begin{verbatim} |
---|
| 447 | domain.set_quantity('stage', -.4) |
---|
| 448 | \end{verbatim}} |
---|
| 449 | |
---|
| 450 | which specifies that the surface level is set to a height of $-0.4$, |
---|
| 451 | i.e. 0.4 units (m) below the zero level. |
---|
| 452 | |
---|
| 453 | Although it is not necessary for this example, it may be useful to |
---|
| 454 | digress here and mention a variant to this requirement, which allows |
---|
| 455 | us to illustrate another way to use \method{set\_quantity}---namely, |
---|
| 456 | incorporating an expression involving other quantities. Suppose, |
---|
| 457 | instead of setting a constant value for the stage, we wished to |
---|
| 458 | specify a constant value for the \emph{depth}. For such a case we |
---|
| 459 | need to specify that \code{stage} is everywhere obtained by adding |
---|
| 460 | that value to the value already specified for \code{elevation}. We |
---|
| 461 | would do this by means of the statements: |
---|
| 462 | |
---|
| 463 | {\small \begin{verbatim} |
---|
| 464 | h = 0.05 # Constant depth |
---|
| 465 | domain.set_quantity('stage', expression = 'elevation + %f' %h) |
---|
| 466 | \end{verbatim}} |
---|
| 467 | |
---|
| 468 | That is, the value of \code{stage} is set to $\code{h} = 0.05$ plus |
---|
| 469 | the value of \code{elevation} already defined. |
---|
| 470 | |
---|
| 471 | The reader will probably appreciate that this capability to |
---|
| 472 | incorporate expressions into statements using \method{set\_quantity} |
---|
| 473 | greatly expands its power.) See Section \ref{sec:Initial Conditions} for more |
---|
| 474 | details. |
---|
| 475 | |
---|
| 476 | \subsection{Boundary Conditions}\index{boundary conditions} |
---|
| 477 | |
---|
| 478 | The boundary conditions are specified as follows: |
---|
| 479 | |
---|
| 480 | {\small \begin{verbatim} |
---|
| 481 | Br = Reflective_boundary(domain) |
---|
| 482 | |
---|
| 483 | Bt = Transmissive_boundary(domain) |
---|
| 484 | |
---|
| 485 | Bd = Dirichlet_boundary([0.2,0.,0.]) |
---|
| 486 | |
---|
| 487 | Bw = Time_boundary(domain=domain, |
---|
| 488 | f=lambda t: [(0.1*sin(t*2*pi)-0.3), 0.0, 0.0]) |
---|
| 489 | \end{verbatim}} |
---|
| 490 | |
---|
| 491 | The effect of these statements is to set up a selection of different |
---|
| 492 | alternative boundary conditions and store them in variables that can be |
---|
| 493 | assigned as needed. Each boundary condition specifies the |
---|
| 494 | behaviour at a boundary in terms of the behaviour in neighbouring |
---|
| 495 | elements. The boundary conditions introduced here may be briefly described as |
---|
| 496 | follows: |
---|
| 497 | |
---|
| 498 | \begin{itemize} |
---|
| 499 | \item \textbf{Reflective boundary}\label{def:reflective boundary} Returns same \code{stage} as |
---|
| 500 | as present in its neighbour volume but momentum vector |
---|
| 501 | reversed 180 degrees (reflected). |
---|
| 502 | Specific to the shallow water equation as it works with the |
---|
| 503 | momentum quantities assumed to be the second and third conserved |
---|
| 504 | quantities. A reflective boundary condition models a solid wall. |
---|
| 505 | \item \textbf{Transmissive boundary}\label{def:transmissive boundary} Returns same conserved quantities as |
---|
| 506 | those present in its neighbour volume. This is one way of modelling |
---|
| 507 | outflow from a domain, but it should be used with caution if flow is |
---|
| 508 | not steady state as replication of momentum at the boundary |
---|
| 509 | may cause occasional spurious effects. If this occurs, |
---|
| 510 | consider using e.g. a Dirichlet boundary condition. |
---|
| 511 | \item \textbf{Dirichlet boundary}\label{def:dirichlet boundary} Specifies |
---|
| 512 | constant values for stage, $x$-momentum and $y$-momentum at the boundary. |
---|
| 513 | \item \textbf{Time boundary}\label{def:time boundary} Like a Dirichlet |
---|
| 514 | boundary but with behaviour varying with time. |
---|
| 515 | \end{itemize} |
---|
| 516 | |
---|
| 517 | \label{ref:tagdescription}Before describing how these boundary |
---|
| 518 | conditions are assigned, we recall that a mesh is specified using |
---|
| 519 | three variables \code{points}, \code{vertices} and \code{boundary}. |
---|
| 520 | In the code we are discussing, these three variables are returned by |
---|
| 521 | the function \code{rectangular}; however, the example given in |
---|
| 522 | Section \ref{sec:realdataexample} illustrates another way of |
---|
| 523 | assigning the values, by means of the function |
---|
| 524 | \code{create\_mesh\_from\_regions}. |
---|
| 525 | |
---|
| 526 | These variables store the data determining the mesh as follows. (You |
---|
| 527 | may find that the example given in Section \ref{sec:meshexample} |
---|
| 528 | helps to clarify the following discussion, even though that example |
---|
| 529 | is a \emph{non-rectangular} mesh.) |
---|
| 530 | |
---|
| 531 | \begin{itemize} |
---|
| 532 | \item The variable \code{points} stores a list of 2-tuples giving the |
---|
| 533 | coordinates of the mesh points. |
---|
| 534 | |
---|
| 535 | \item The variable \code{vertices} stores a list of 3-tuples of |
---|
| 536 | numbers, representing vertices of triangles in the mesh. In this |
---|
| 537 | list, the triangle whose vertices are \code{points[i]}, |
---|
| 538 | \code{points[j]}, \code{points[k]} is represented by the 3-tuple |
---|
| 539 | \code{(i, j, k)}. |
---|
| 540 | |
---|
| 541 | \item The variable \code{boundary} is a Python dictionary that |
---|
| 542 | not only stores the edges that make up the boundary but also assigns |
---|
| 543 | symbolic tags to these edges to distinguish different parts of the |
---|
| 544 | boundary. An edge with endpoints \code{points[i]} and |
---|
| 545 | \code{points[j]} is represented by the 2-tuple \code{(i, j)}. The |
---|
| 546 | keys for the dictionary are the 2-tuples \code{(i, j)} corresponding |
---|
| 547 | to boundary edges in the mesh, and the values are the tags are used |
---|
| 548 | to label them. In the present example, the value \code{boundary[(i, |
---|
| 549 | j)]} assigned to \code{(i, j)]} is one of the four tags |
---|
| 550 | \code{`left'}, \code{`right'}, \code{`top'} or \code{`bottom'}, |
---|
| 551 | depending on whether the boundary edge represented by \code{(i, j)} |
---|
| 552 | occurs at the left, right, top or bottom of the rectangle bounding |
---|
| 553 | the mesh. The function \code{rectangular} automatically assigns |
---|
| 554 | these tags to the boundary edges when it generates the mesh. |
---|
| 555 | \end{itemize} |
---|
| 556 | |
---|
| 557 | The tags provide the means to assign different boundary conditions |
---|
| 558 | to an edge depending on which part of the boundary it belongs to. |
---|
| 559 | (In Section \ref{sec:realdataexample} we describe an example that |
---|
| 560 | uses different boundary tags---in general, the possible tags are not |
---|
| 561 | limited to `left', `right', `top' and `bottom', but can be specified |
---|
| 562 | by the user.) |
---|
| 563 | |
---|
| 564 | Using the boundary objects described above, we assign a boundary |
---|
| 565 | condition to each part of the boundary by means of a statement like |
---|
| 566 | |
---|
| 567 | {\small \begin{verbatim} |
---|
| 568 | domain.set_boundary({'left': Br, 'right': Bw, 'top': Br, 'bottom': Br}) |
---|
| 569 | \end{verbatim}} |
---|
| 570 | |
---|
| 571 | This statement stipulates that, in the current example, the right |
---|
| 572 | boundary varies with time, as defined by the lambda function, while the other |
---|
| 573 | boundaries are all reflective. |
---|
| 574 | |
---|
| 575 | The reader may wish to experiment by varying the choice of boundary |
---|
| 576 | types for one or more of the boundaries. (In the case of \code{Bd} |
---|
| 577 | and \code{Bw}, the three arguments in each case represent the |
---|
| 578 | \code{stage}, $x$-momentum and $y$-momentum, respectively.) |
---|
| 579 | |
---|
| 580 | {\small \begin{verbatim} |
---|
| 581 | Bw = Time_boundary(domain=domain, |
---|
| 582 | f=lambda t: [(0.1*sin(t*2*pi)-0.3), 0.0, 0.0]) |
---|
| 583 | \end{verbatim}} |
---|
| 584 | |
---|
| 585 | |
---|
| 586 | |
---|
| 587 | \subsection{Evolution}\index{evolution} |
---|
| 588 | |
---|
| 589 | The final statement \nopagebreak[3] |
---|
| 590 | {\small \begin{verbatim} |
---|
| 591 | for t in domain.evolve(yieldstep = 0.1, duration = 4.0): |
---|
| 592 | print domain.timestepping_statistics() |
---|
| 593 | \end{verbatim}} |
---|
| 594 | |
---|
| 595 | causes the configuration of the domain to `evolve', over a series of |
---|
| 596 | steps indicated by the values of \code{yieldstep} and |
---|
| 597 | \code{duration}, which can be altered as required. The value of |
---|
| 598 | \code{yieldstep} controls the time interval between successive model |
---|
| 599 | outputs. Behind the scenes more time steps are generally taken. |
---|
| 600 | |
---|
| 601 | |
---|
| 602 | \subsection{Output} |
---|
| 603 | |
---|
| 604 | The output is a NetCDF file with the extension \code{.sww}. It |
---|
| 605 | contains stage and momentum information and can be used with the |
---|
| 606 | \code{swollen} (see Section \ref{sec:swollen}) visualisation package |
---|
| 607 | to generate a visual display. See Section \ref{sec:file formats} |
---|
| 608 | (page \pageref{sec:file formats}) for more on NetCDF and other file |
---|
| 609 | formats. |
---|
| 610 | |
---|
| 611 | The following is a listing of the screen output seen by the user |
---|
| 612 | when this example is run: |
---|
| 613 | |
---|
| 614 | \verbatiminput{examples/runupoutput.txt} |
---|
| 615 | |
---|
| 616 | |
---|
| 617 | \section{How to Run the Code} |
---|
| 618 | |
---|
| 619 | The code can be run in various ways: |
---|
| 620 | |
---|
| 621 | \begin{itemize} |
---|
| 622 | \item{from a Windows or Unix command line} as in\ \code{python runup.py} |
---|
| 623 | \item{within the Python IDLE environment} |
---|
| 624 | \item{within emacs} |
---|
| 625 | \item{within Windows, by double-clicking the \code{runup.py} |
---|
| 626 | file.} |
---|
| 627 | \end{itemize} |
---|
| 628 | |
---|
| 629 | |
---|
| 630 | \section{Exploring the Model Output} |
---|
| 631 | |
---|
| 632 | The following figures are screenshots from the \anuga visualisation |
---|
| 633 | tool \code{swollen}. Figure \ref{fig:runupstart} shows the domain |
---|
| 634 | with water surface as specified by the initial condition, $t=0$. |
---|
| 635 | Figure \ref{fig:bedslope2} shows later snapshots for $t=2.3$ and |
---|
| 636 | $t=4$ where the system has been evolved and the wave is encroaching |
---|
| 637 | on the previously dry bed. All figures are screenshots from an |
---|
| 638 | interactive animation tool called Swollen which is part of \anuga. |
---|
| 639 | Swollen is described in more detail is Section \ref{sec:swollen}. |
---|
| 640 | |
---|
| 641 | \begin{figure}[hbt] |
---|
| 642 | |
---|
| 643 | \centerline{\includegraphics[width=75mm, height=75mm] |
---|
| 644 | {examples/runupstart.eps}} |
---|
| 645 | |
---|
| 646 | \caption{Bedslope example viewed with Swollen} |
---|
| 647 | \label{fig:runupstart} |
---|
| 648 | \end{figure} |
---|
| 649 | |
---|
| 650 | |
---|
| 651 | \begin{figure}[hbt] |
---|
| 652 | |
---|
| 653 | \centerline{ |
---|
| 654 | \includegraphics[width=75mm, height=75mm]{examples/runupduring.eps} |
---|
| 655 | \includegraphics[width=75mm, height=75mm]{examples/runupend.eps} |
---|
| 656 | } |
---|
| 657 | |
---|
| 658 | \caption{Bedslope example viewed with Swollen} |
---|
| 659 | \label{fig:bedslope2} |
---|
| 660 | \end{figure} |
---|
| 661 | |
---|
| 662 | |
---|
| 663 | |
---|
| 664 | |
---|
| 665 | \clearpage |
---|
| 666 | |
---|
| 667 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 668 | |
---|
| 669 | \section{An Example with Real Data} |
---|
| 670 | \label{sec:realdataexample} The following discussion builds on the |
---|
| 671 | concepts introduced through the \file{runup.py} example and |
---|
| 672 | introduces a second example, \file{run\_sydney.py}. This refers to |
---|
| 673 | a real-life scenario, in which the domain of interest surrounds the |
---|
| 674 | Sydney region, and predominantly covers Sydney Harbour. A |
---|
| 675 | hypothetical tsunami wave is generated by a submarine mass failure |
---|
| 676 | situated on the edge of the continental shelf. |
---|
| 677 | |
---|
| 678 | \subsection{Overview} |
---|
| 679 | As in the case of \file{runup.py}, the actions carried |
---|
| 680 | out by the program can be organised according to this outline: |
---|
| 681 | |
---|
| 682 | \begin{enumerate} |
---|
| 683 | |
---|
| 684 | \item Set up a triangular mesh. |
---|
| 685 | |
---|
| 686 | \item Set certain parameters governing the mode of |
---|
| 687 | operation of the model---specifying, for instance, where to store the |
---|
| 688 | model output. |
---|
| 689 | |
---|
| 690 | \item Input various quantities describing physical measurements, such |
---|
| 691 | as the elevation, to be specified at each mesh point (vertex). |
---|
| 692 | |
---|
| 693 | \item Set up the boundary conditions. |
---|
| 694 | |
---|
| 695 | \item Carry out the evolution of the model through a series of time |
---|
| 696 | steps and output the results, providing a results file that can be |
---|
| 697 | visualised. |
---|
| 698 | |
---|
| 699 | \end{enumerate} |
---|
| 700 | |
---|
| 701 | |
---|
| 702 | |
---|
| 703 | \subsection{The Code} |
---|
| 704 | |
---|
| 705 | Here is the code for \file{run\_sydney\_smf.py}: |
---|
| 706 | |
---|
| 707 | \verbatiminput{examples/runsydney.py} |
---|
| 708 | |
---|
| 709 | In discussing the details of this example, we follow the outline |
---|
| 710 | given above, discussing each major step of the code in turn. |
---|
| 711 | |
---|
| 712 | \subsection{Establishing the Mesh}\index{mesh, establishing} |
---|
| 713 | |
---|
| 714 | One obvious way that the present example differs from |
---|
| 715 | \file{runup.py} is in the use of a more complex method to |
---|
| 716 | create the mesh. Instead of imposing a mesh structure on a |
---|
| 717 | rectangular grid, the technique used for this example involves |
---|
| 718 | building mesh structures inside polygons specified by the user, |
---|
| 719 | using a mesh-generator referred to as \code{pmesh}. |
---|
| 720 | |
---|
| 721 | In its simplest form, \code{pmesh} creates the mesh within a single |
---|
| 722 | polygon whose vertices are at geographical locations specified by |
---|
| 723 | the user. The user specifies the \emph{resolution}---that is, the |
---|
| 724 | maximal area of a triangle used for triangulation---and a triangular |
---|
| 725 | mesh is created inside the polygon using a mesh generation engine. |
---|
| 726 | On any given platform, the same mesh will be returned. Figure |
---|
| 727 | \ref{fig:pentagon} shows a simple example of this, in which the |
---|
| 728 | triangulation is carried out within a pentagon. |
---|
| 729 | |
---|
| 730 | |
---|
| 731 | \begin{figure}[hbt] |
---|
| 732 | |
---|
| 733 | \caption{Mesh points are created inside the polygon} |
---|
| 734 | \label{fig:pentagon} |
---|
| 735 | \end{figure} |
---|
| 736 | |
---|
| 737 | Boundary tags are not restricted to \code{`left'}, \code{`right'}, |
---|
| 738 | \code{`bottom'} and \code{`top'}, as in the case of |
---|
| 739 | \file{runup.py}. Instead the user specifies a list of |
---|
| 740 | tags appropriate to the configuration being modelled. |
---|
| 741 | |
---|
| 742 | In addition, \code{pmesh} provides a way to adapt to geographic or |
---|
| 743 | other features in the landscape, whose presence may require an |
---|
| 744 | increase in resolution. This is done by allowing the user to specify |
---|
| 745 | a number of \emph{interior polygons}, each with a specified |
---|
| 746 | resolution, see Figure \ref{fig:interior meshes}. It is also |
---|
| 747 | possible to specify one or more `holes'---that is, areas bounded by |
---|
| 748 | polygons in which no triangulation is required. |
---|
| 749 | |
---|
| 750 | \begin{figure}[hbt] |
---|
| 751 | |
---|
| 752 | |
---|
| 753 | |
---|
| 754 | \caption{Interior meshes with individual resolution} |
---|
| 755 | \label{fig:interior meshes} |
---|
| 756 | \end{figure} |
---|
| 757 | |
---|
| 758 | In its general form, \code{pmesh} takes for its input a bounding |
---|
| 759 | polygon and (optionally) a list of interior polygons. The user |
---|
| 760 | specifies resolutions, both for the bounding polygon and for each of |
---|
| 761 | the interior polygons. Given this data, \code{pmesh} first creates a |
---|
| 762 | triangular mesh with varying resolution. |
---|
| 763 | |
---|
| 764 | The function used to implement this process is |
---|
| 765 | \function{create\_mesh\_from\_regions}. Its arguments include the |
---|
| 766 | bounding polygon and its resolution, a list of boundary tags, and a |
---|
| 767 | list of pairs \code{[polygon, resolution]}, specifying the interior |
---|
| 768 | polygons and their resolutions. |
---|
| 769 | |
---|
| 770 | In practice, the details of the polygons used are read from a |
---|
| 771 | separate file \file{project.py}. Here is a complete listing of |
---|
| 772 | \file{project.py}: |
---|
| 773 | |
---|
| 774 | \verbatiminput{examples/project.py} |
---|
| 775 | |
---|
| 776 | The resulting mesh is output to a \emph{mesh file}\index{mesh |
---|
| 777 | file}\label{def:mesh file}. This term is used to describe a file of |
---|
| 778 | a specific format used to store the data specifying a mesh. (There |
---|
| 779 | are in fact two possible formats for such a file: it can either be a |
---|
| 780 | binary file, with extension \code{.msh}, or an ASCII file, with |
---|
| 781 | extension \code{.tsh}. In the present case, the binary file format |
---|
| 782 | \code{.msh} is used. See Section \ref{sec:file formats} (page |
---|
| 783 | \pageref{sec:file formats}) for more on file formats.) |
---|
| 784 | |
---|
| 785 | The statements |
---|
| 786 | |
---|
| 787 | {\small \begin{verbatim} |
---|
| 788 | interior_res = 5000 |
---|
| 789 | interior_regions = [[project.northern_polygon, interior_res], |
---|
| 790 | [project.harbour_polygon, interior_res], |
---|
| 791 | [project.southern_polygon, interior_res], |
---|
| 792 | [project.manly_polygon, interior_res], |
---|
| 793 | [project.top_polygon, interior_res]] |
---|
| 794 | \end{verbatim}} |
---|
| 795 | |
---|
| 796 | are used to read in the specific polygons \code{project.harbour\_polygon\_2} and |
---|
| 797 | \code{botanybay\_polygon\_2} from \file{project.py} and assign a |
---|
| 798 | common resolution of to each. The statement |
---|
| 799 | |
---|
| 800 | {\small \begin{verbatim} |
---|
| 801 | create_mesh_from_regions(project.demopoly, |
---|
| 802 | boundary_tags= {'oceannorth': [0], |
---|
| 803 | 'onshorenorth1': [1], |
---|
| 804 | 'onshorenorthwest1': [2], |
---|
| 805 | 'onshorenorthwest2': [3], |
---|
| 806 | 'onshorenorth2': [4], |
---|
| 807 | 'onshorewest': [5], |
---|
| 808 | 'onshoresouth': [6], |
---|
| 809 | 'oceansouth': [7], |
---|
| 810 | 'oceaneast': [8]}, |
---|
| 811 | maximum_triangle_area=100000, |
---|
| 812 | filename=meshname, |
---|
| 813 | interior_regions=interior_regions) |
---|
| 814 | \end{verbatim}} |
---|
| 815 | |
---|
| 816 | is then used to create the mesh, taking the bounding polygon to be |
---|
| 817 | the polygon \code{diffpolygonall} specified in \file{project.py}. |
---|
| 818 | The argument \code{boundary\_tags} assigns a dictionary, whose keys |
---|
| 819 | are the names of the boundary tags used for the bounding |
---|
| 820 | polygon---\code{`bottom'}, \code{`right0'}, \code{`right1'}, |
---|
| 821 | \code{`right2'}, \code{`top'}, \code{`left1'}, \code{`left2'} and |
---|
| 822 | \code{`left3'}--- and whose values identify the indices of the |
---|
| 823 | segments associated with each of these tags. (The value associated |
---|
| 824 | with each boundary tag is a one-element list.) |
---|
| 825 | |
---|
| 826 | |
---|
| 827 | \subsection{Initialising the Domain} |
---|
| 828 | |
---|
| 829 | As with \file{runup.py}, once we have created the mesh, the next |
---|
| 830 | step is to create the data structure \code{domain}. We did this for |
---|
| 831 | \file{runup.py} by inputting lists of points and triangles and |
---|
| 832 | specifying the boundary tags directly. However, in the present case, |
---|
| 833 | we use a method that works directly with the mesh file |
---|
| 834 | \code{meshname}, as follows: |
---|
| 835 | |
---|
| 836 | |
---|
| 837 | {\small \begin{verbatim} |
---|
| 838 | domain = Domain(meshname, use_cache=True, verbose=True) |
---|
| 839 | \end{verbatim}} |
---|
| 840 | |
---|
| 841 | Providing a filename instead of the lists used in \file{runup.py} |
---|
| 842 | above causes \code{Domain} to convert a mesh file \code{meshname} |
---|
| 843 | into an instance of \code{Domain}, allowing us to use methods like |
---|
| 844 | \method{set\_quantity} to set quantities and to apply other |
---|
| 845 | operations. |
---|
| 846 | |
---|
| 847 | %(In principle, the |
---|
| 848 | %second argument of \function{pmesh\_to\_domain\_instance} can be any |
---|
| 849 | %subclass of \class{Domain}, but for applications involving the |
---|
| 850 | %shallow-water wave equation, the second argument of |
---|
| 851 | %\function{pmesh\_to\_domain\_instance} can always be set simply to |
---|
| 852 | %\class{Domain}.) |
---|
| 853 | |
---|
| 854 | The following statements specify a basename and data directory, and |
---|
| 855 | identify quantities to be stored. For the first two, values are |
---|
| 856 | taken from \file{project.py}. |
---|
| 857 | |
---|
| 858 | {\small \begin{verbatim} |
---|
| 859 | domain.set_name(project.basename) |
---|
| 860 | domain.set_datadir(project.outputdir) |
---|
| 861 | domain.set_quantities_to_be_stored(['stage', 'xmomentum', |
---|
| 862 | 'ymomentum']) |
---|
| 863 | \end{verbatim}} |
---|
| 864 | |
---|
| 865 | |
---|
| 866 | \subsection{Initial Conditions} |
---|
| 867 | Quantities for \file{runsydney.py} are set |
---|
| 868 | using similar methods to those in \file{runup.py}. However, |
---|
| 869 | in this case, many of the values are read from the auxiliary file |
---|
| 870 | \file{project.py} or, in the case of \code{elevation}, from an |
---|
| 871 | ancillary points file. |
---|
| 872 | |
---|
| 873 | |
---|
| 874 | |
---|
| 875 | \subsubsection{Stage} |
---|
| 876 | |
---|
| 877 | For the scenario we are modelling in this case, we use a callable |
---|
| 878 | object \code{tsunami\_source}, assigned by means of a function |
---|
| 879 | \function{slump\_tsunami}. This is similar to how we set elevation in |
---|
| 880 | \file{runup.py} using a function---however, in this case the |
---|
| 881 | function is both more complex and more interesting. |
---|
| 882 | |
---|
| 883 | The function returns the water displacement for all \code{x} and |
---|
| 884 | \code{y} in the domain. The water displacement is a double Gaussian |
---|
| 885 | function that depends on the characteristics of the slump (length, |
---|
| 886 | thickness, slope, etc), its location (origin) and the depth at that |
---|
| 887 | location. |
---|
| 888 | |
---|
| 889 | |
---|
| 890 | \subsubsection{Friction} |
---|
| 891 | |
---|
| 892 | We assign the friction exactly as we did for \file{runup.py}: |
---|
| 893 | |
---|
| 894 | {\small \begin{verbatim} |
---|
| 895 | domain.set_quantity('friction', 0.0) |
---|
| 896 | \end{verbatim}} |
---|
| 897 | |
---|
| 898 | |
---|
| 899 | \subsubsection{Elevation} |
---|
| 900 | |
---|
| 901 | The elevation is specified by reading data from a file: |
---|
| 902 | |
---|
| 903 | {\small \begin{verbatim} |
---|
| 904 | domain.set_quantity('elevation', |
---|
| 905 | filename = project.combineddemname + '.pts', |
---|
| 906 | use_cache = True, |
---|
| 907 | verbose = True) |
---|
| 908 | \end{verbatim}} |
---|
| 909 | |
---|
| 910 | However, before this step can be executed, some preliminary steps |
---|
| 911 | are needed to prepare the file from which the data is taken. Two |
---|
| 912 | source files are used for this data---their names are specified in |
---|
| 913 | the file \file{project.py}, in the variables \code{coarsedemname} |
---|
| 914 | and \code{finedemname}. They contain `coarse' and `fine' data, |
---|
| 915 | respectively---that is, data sampled at widely spaced points over a |
---|
| 916 | large region and data sampled at closely spaced points over a |
---|
| 917 | smaller subregion. The data in these files is combined through the |
---|
| 918 | statement |
---|
| 919 | |
---|
| 920 | {\small \begin{verbatim} |
---|
| 921 | combine_rectangular_points_files(project.finedemname + '.pts', |
---|
| 922 | project.coarsedemname + '.pts', |
---|
| 923 | project.combineddemname + '.pts') |
---|
| 924 | \end{verbatim}} |
---|
| 925 | |
---|
| 926 | The effect of this is simply to combine the datasets by eliminating |
---|
| 927 | any coarse data associated with points inside the smaller region |
---|
| 928 | common to both datasets. The name to be assigned to the resulting |
---|
| 929 | dataset is also derived from the name stored in the variable |
---|
| 930 | \code{combinedname} in the file \file{project.py}. |
---|
| 931 | |
---|
| 932 | \subsection{Boundary Conditions}\index{boundary conditions} |
---|
| 933 | |
---|
| 934 | Setting boundaries follows a similar pattern to the one used for |
---|
| 935 | \file{runup.py}, except that in this case we need to associate a |
---|
| 936 | boundary type with each of the |
---|
| 937 | boundary tag names introduced when we established the mesh. In place of the four |
---|
| 938 | boundary types introduced for \file{runup.py}, we use the reflective |
---|
| 939 | boundary for each of the |
---|
| 940 | eight tagged segments defined by \code{create_mesh_from_regions}: |
---|
| 941 | |
---|
| 942 | {\small \begin{verbatim} |
---|
| 943 | Bd = Dirichlet_boundary([0.0,0.0,0.0]) |
---|
| 944 | domain.set_boundary( {'oceannorth': Bd, |
---|
| 945 | 'onshorenorth1': Bd, |
---|
| 946 | 'onshorenorthwest1': Bd, |
---|
| 947 | 'onshorenorthwest2': Bd, |
---|
| 948 | 'onshorenorth2': Bd, |
---|
| 949 | 'onshorewest': Bd, |
---|
| 950 | 'onshoresouth': Bd, |
---|
| 951 | 'oceansouth': Bd, |
---|
| 952 | 'oceaneast': Bd} ) |
---|
| 953 | \end{verbatim}} |
---|
| 954 | |
---|
| 955 | \subsection{Evolution} |
---|
| 956 | |
---|
| 957 | With the basics established, the running of the `evolve' step is |
---|
| 958 | very similar to the corresponding step in \file{runup.py}. Here, |
---|
| 959 | the simulation is run for five hours (18000 seconds) with |
---|
| 960 | the output stored every two minutes (120 seconds). |
---|
| 961 | |
---|
| 962 | {\small \begin{verbatim} |
---|
| 963 | import time t0 = time.time() |
---|
| 964 | |
---|
| 965 | for t in domain.evolve(yieldstep = 120, duration = 18000): |
---|
| 966 | print domain.timestepping_statistics() |
---|
| 967 | print domain.boundary_statistics(tags = 'bottom') |
---|
| 968 | |
---|
| 969 | print 'That took %.2f seconds' %(time.time() |
---|
| 970 | \end{verbatim}} |
---|
| 971 | |
---|
| 972 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 973 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 974 | |
---|
| 975 | \chapter{\anuga Public Interface} |
---|
| 976 | \label{ch:interface} |
---|
| 977 | |
---|
| 978 | This chapter gives an overview of the features of \anuga available |
---|
| 979 | to the user at the public interface. These are grouped under the |
---|
| 980 | following headings, which correspond to the outline of the examples |
---|
| 981 | described in Chapter \ref{ch:getstarted}: |
---|
| 982 | |
---|
| 983 | \begin{itemize} |
---|
| 984 | \item Establishing the Mesh |
---|
| 985 | \item Initialising the Domain |
---|
| 986 | \item Specifying the Quantities |
---|
| 987 | \item Initial Conditions |
---|
| 988 | \item Boundary Conditions |
---|
| 989 | \item Forcing Functions |
---|
| 990 | \item Evolution |
---|
| 991 | \end{itemize} |
---|
| 992 | |
---|
| 993 | The listings are intended merely to give the reader an idea of what |
---|
| 994 | each feature is, where to find it and how it can be used---they do |
---|
| 995 | not give full specifications; for these the reader |
---|
| 996 | may consult the code. The code for every function or class contains |
---|
| 997 | a documentation string, or `docstring', that specifies the precise |
---|
| 998 | syntax for its use. This appears immediately after the line |
---|
| 999 | introducing the code, between two sets of triple quotes. |
---|
| 1000 | |
---|
| 1001 | Each listing also describes the location of the module in which |
---|
| 1002 | the code for the feature being described can be found. All modules |
---|
| 1003 | are in the folder \file{inundation} or one of its subfolders, and the |
---|
| 1004 | location of each module is described relative to \file{inundation}. Rather |
---|
| 1005 | than using pathnames, whose syntax depends on the operating system, |
---|
| 1006 | we use the format adopted for importing the function or class for |
---|
| 1007 | use in Python code. For example, suppose we wish to specify that the |
---|
| 1008 | function \function{create\_mesh\_from\_regions} is in a module called |
---|
| 1009 | \module{mesh\_interface} in a subfolder of \module{inundation} called |
---|
| 1010 | \code{pmesh}. In Linux or Unix syntax, the pathname of the file |
---|
| 1011 | containing the function, relative to \file{inundation}, would be |
---|
| 1012 | |
---|
| 1013 | \begin{center} |
---|
| 1014 | % \code{pmesh/mesh\_interface.py} |
---|
| 1015 | \code{pmesh}$\slash$\code{mesh\_interface.py} |
---|
| 1016 | \end{center} |
---|
| 1017 | |
---|
| 1018 | while in Windows syntax it would be |
---|
| 1019 | |
---|
| 1020 | \begin{center} |
---|
| 1021 | \code{pmesh}$\backslash$\code{mesh\_interface.py} |
---|
| 1022 | \end{center} |
---|
| 1023 | |
---|
| 1024 | Rather than using either of these forms, in this chapter we specify |
---|
| 1025 | the location simply as \code{pmesh.mesh\_interface}, in keeping with |
---|
| 1026 | the usage in the Python statement for importing the function, |
---|
| 1027 | namely: |
---|
| 1028 | \begin{center} |
---|
| 1029 | \code{from pmesh.mesh\_interface import create\_mesh\_from\_regions} |
---|
| 1030 | \end{center} |
---|
| 1031 | |
---|
| 1032 | Each listing details the full set of parameters for the class or |
---|
| 1033 | function; however, the description is generally limited to the most |
---|
| 1034 | important parameters and the reader is again referred to the code |
---|
| 1035 | for more details. |
---|
| 1036 | |
---|
| 1037 | The following parameters are common to many functions and classes |
---|
| 1038 | and are omitted from the descriptions given below: |
---|
| 1039 | |
---|
| 1040 | %\begin{center} |
---|
| 1041 | \begin{tabular}{ll} %\hline |
---|
| 1042 | %\textbf{Name } & \textbf{Description}\\ |
---|
| 1043 | %\hline |
---|
| 1044 | \emph{use\_cache} & Specifies whether caching is to be used for improved performance. See Section \ref{sec:caching} for details on the underlying caching functionality\\ |
---|
| 1045 | \emph{verbose} & If \code{True}, provides detailed terminal output |
---|
| 1046 | to the user\\ % \hline |
---|
| 1047 | \end{tabular} |
---|
| 1048 | %\end{center} |
---|
| 1049 | |
---|
| 1050 | \section{Mesh Generation} |
---|
| 1051 | |
---|
| 1052 | Before discussing the part of the interface relating to mesh |
---|
| 1053 | generation, we begin with a description of a simple example of a |
---|
| 1054 | mesh and use it to describe how mesh data is stored. |
---|
| 1055 | |
---|
| 1056 | \label{sec:meshexample} Figure \ref{fig:simplemesh} represents a |
---|
| 1057 | very simple mesh comprising just 11 points and 10 triangles. |
---|
| 1058 | |
---|
| 1059 | |
---|
| 1060 | \begin{figure}[h] |
---|
| 1061 | \begin{center} |
---|
| 1062 | \includegraphics[width=90mm, height=90mm]{triangularmesh.eps} |
---|
| 1063 | \end{center} |
---|
| 1064 | |
---|
| 1065 | \caption{A simple mesh} |
---|
| 1066 | \label{fig:simplemesh} |
---|
| 1067 | \end{figure} |
---|
| 1068 | |
---|
| 1069 | |
---|
| 1070 | The variables \code{points}, \code{vertices} and \code{boundary} |
---|
| 1071 | represent the data displayed in Figure \ref{fig:simplemesh} as |
---|
| 1072 | follows. The list \code{points} stores the coordinates of the |
---|
| 1073 | points, and may be displayed schematically as in Table |
---|
| 1074 | \ref{tab:points}. |
---|
| 1075 | |
---|
| 1076 | |
---|
| 1077 | \begin{table} |
---|
| 1078 | \begin{center} |
---|
| 1079 | \begin{tabular}[t]{|c|cc|} \hline |
---|
| 1080 | index & \code{x} & \code{y}\\ \hline |
---|
| 1081 | 0 & 1 & 1\\ |
---|
| 1082 | 1 & 4 & 2\\ |
---|
| 1083 | 2 & 8 & 1\\ |
---|
| 1084 | 3 & 1 & 3\\ |
---|
| 1085 | 4 & 5 & 5\\ |
---|
| 1086 | 5 & 8 & 6\\ |
---|
| 1087 | 6 & 11 & 5\\ |
---|
| 1088 | 7 & 3 & 6\\ |
---|
| 1089 | 8 & 1 & 8\\ |
---|
| 1090 | 9 & 4 & 9\\ |
---|
| 1091 | 10 & 10 & 7\\ \hline |
---|
| 1092 | \end{tabular} |
---|
| 1093 | \end{center} |
---|
| 1094 | |
---|
| 1095 | \caption{Point coordinates for mesh in |
---|
| 1096 | Figure \protect \ref{fig:simplemesh}} |
---|
| 1097 | \label{tab:points} |
---|
| 1098 | \end{table} |
---|
| 1099 | |
---|
| 1100 | The list \code{vertices} specifies the triangles that make up the |
---|
| 1101 | mesh. It does this by specifying, for each triangle, the indices |
---|
| 1102 | (the numbers shown in the first column above) that correspond to the |
---|
| 1103 | three points at its vertices, taken in an anti-clockwise order |
---|
| 1104 | around the triangle. Thus, in the example shown in Figure |
---|
| 1105 | \ref{fig:simplemesh}, the variable \code{vertices} contains the |
---|
| 1106 | entries shown in Table \ref{tab:vertices}. The starting point is |
---|
| 1107 | arbitrary so triangle $(0,1,3)$ is considered the same as $(1,3,0)$ |
---|
| 1108 | and $(3,0,1)$. |
---|
| 1109 | |
---|
| 1110 | |
---|
| 1111 | \begin{table} |
---|
| 1112 | \begin{center} |
---|
| 1113 | \begin{tabular}{|c|ccc|} \hline |
---|
| 1114 | index & \multicolumn{3}{c|}{\code{vertices}}\\ \hline |
---|
| 1115 | 0 & 0 & 1 & 3\\ |
---|
| 1116 | 1 & 1 & 2 & 4\\ |
---|
| 1117 | 2 & 2 & 5 & 4\\ |
---|
| 1118 | 3 & 2 & 6 & 5\\ |
---|
| 1119 | 4 & 4 & 5 & 9\\ |
---|
| 1120 | 5 & 4 & 9 & 7\\ |
---|
| 1121 | 6 & 3 & 4 & 7\\ |
---|
| 1122 | 7 & 7 & 9 & 8\\ |
---|
| 1123 | 8 & 1 & 4 & 3\\ |
---|
| 1124 | 9 & 5 & 10 & 9\\ \hline |
---|
| 1125 | \end{tabular} |
---|
| 1126 | \end{center} |
---|
| 1127 | |
---|
| 1128 | \caption{Vertices for mesh in Figure \protect \ref{fig:simplemesh}} |
---|
| 1129 | \label{tab:vertices} |
---|
| 1130 | \end{table} |
---|
| 1131 | |
---|
| 1132 | Finally, the variable \code{boundary} identifies the boundary |
---|
| 1133 | triangles and associates a tag with each. |
---|
| 1134 | |
---|
| 1135 | \refmodindex[pmesh.meshinterface]{pmesh.mesh\_interface}\label{sec:meshgeneration} |
---|
| 1136 | |
---|
| 1137 | \begin{funcdesc} {create\_mesh\_from\_regions}{bounding_polygon, |
---|
| 1138 | boundary_tags, |
---|
| 1139 | maximum_triangle_area, |
---|
| 1140 | filename=None, |
---|
| 1141 | interior_regions=None, |
---|
| 1142 | poly_geo_reference=None, |
---|
| 1143 | mesh_geo_reference=None, |
---|
| 1144 | minimum_triangle_angle=28.0} |
---|
| 1145 | Module: \module{pmesh.mesh\_interface} |
---|
| 1146 | |
---|
| 1147 | This function allows a user to initiate the automatic creation of a |
---|
| 1148 | mesh inside a specified polygon (input \code{bounding_polygon}). |
---|
| 1149 | Among the parameters that can be set are the \emph{resolution} |
---|
| 1150 | (maximal area for any triangle in the mesh) and the minimal angle |
---|
| 1151 | allowable in any triangle. The user can specify a number of internal |
---|
| 1152 | polygons within each of which a separate mesh is to be created, |
---|
| 1153 | generally with a smaller resolution. \code{interior_regions} is a |
---|
| 1154 | paired list containing the interior polygon and its resolution. |
---|
| 1155 | Additionally, the user specifies a list of boundary tags, one for |
---|
| 1156 | each edge of the bounding polygon. |
---|
| 1157 | |
---|
| 1158 | \textbf{WARNING}. Note that the dictionary structure used for the |
---|
| 1159 | parameter \code{boundary\_tags} is different from that used for the |
---|
| 1160 | variable \code{boundary} that occurs in the specification of a mesh. |
---|
| 1161 | In the case of \code{boundary}, the tags are the \emph{values} of |
---|
| 1162 | the dictionary, whereas in the case of \code{boundary_tags}, the |
---|
| 1163 | tags are the \emph{keys} and the \emph{value} corresponding to a |
---|
| 1164 | particular tag is a list of numbers identifying boundary edges |
---|
| 1165 | labelled with that tag. Because of this, it is theoretically |
---|
| 1166 | possible to assign the same edge to more than one tag. However, an |
---|
| 1167 | attempt to do this will cause an error. |
---|
| 1168 | \end{funcdesc} |
---|
| 1169 | |
---|
| 1170 | |
---|
| 1171 | |
---|
| 1172 | |
---|
| 1173 | \begin{classdesc} {Mesh}{userSegments=None, |
---|
| 1174 | userVertices=None, |
---|
| 1175 | holes=None, |
---|
| 1176 | regions=None, |
---|
| 1177 | geo_reference=None} |
---|
| 1178 | Module: \module{pmesh.mesh} |
---|
| 1179 | |
---|
| 1180 | A class used to build a mesh outline and generate a two-dimensional |
---|
| 1181 | triangular mesh. The mesh outline is used to describe features on the |
---|
| 1182 | mesh, such as the mesh boundary. Many of this classes methods are used |
---|
| 1183 | to build a mesh outline, such as \code{add\_vertices} and |
---|
| 1184 | \code{add\_region\_from\_polygon}. |
---|
| 1185 | |
---|
| 1186 | \end{classdesc} |
---|
| 1187 | |
---|
| 1188 | |
---|
| 1189 | \subsection{Key Methods of Class Mesh} |
---|
| 1190 | |
---|
| 1191 | |
---|
| 1192 | \begin{methoddesc} {add\_hole}{x,y, geo_reference=None} |
---|
| 1193 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1194 | |
---|
| 1195 | This method is used to build the mesh outline. It defines a hole, |
---|
| 1196 | when the boundary of the hole has already been defined, by selecting a |
---|
| 1197 | point within the boundary. |
---|
| 1198 | |
---|
| 1199 | \end{methoddesc} |
---|
| 1200 | |
---|
| 1201 | |
---|
| 1202 | \begin{methoddesc} {add\_hole\_from\_polygon}{self, polygon, tags=None, |
---|
| 1203 | geo_reference=None} |
---|
| 1204 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1205 | |
---|
| 1206 | This method is used to add a `hole' within a region ---that is, to |
---|
| 1207 | define a interior region where the triangular mesh will not be |
---|
| 1208 | generated---to a \class{Mesh} instance. The region boundary is described by |
---|
| 1209 | the polygon passed in. Additionally, the user specifies a list of |
---|
| 1210 | boundary tags, one for each edge of the bounding polygon. |
---|
| 1211 | \end{methoddesc} |
---|
| 1212 | |
---|
| 1213 | |
---|
[3541] | 1214 | \begin{methoddesc} {add\_points_and_segments}{self, points, segments, |
---|
| 1215 | segment\_tags=None} |
---|
| 1216 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1217 | |
---|
| 1218 | This method is used to build the mesh outline. It adds some points and |
---|
| 1219 | segments connecting some points. A tag for each point can optionally |
---|
| 1220 | be added. |
---|
| 1221 | |
---|
| 1222 | \end{methoddesc} |
---|
| 1223 | |
---|
[3275] | 1224 | \begin{methoddesc} {add\_region}{x,y, geo_reference=None} |
---|
| 1225 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1226 | |
---|
| 1227 | This method is used to build the mesh outline. It defines a region, |
---|
| 1228 | when the boundary of the region has already been defined, by selecting |
---|
| 1229 | a point within the boundary. A region instance is returned. This can |
---|
| 1230 | be used to set the resolution. |
---|
| 1231 | |
---|
| 1232 | \end{methoddesc} |
---|
| 1233 | |
---|
| 1234 | \begin{methoddesc} {add\_region\_from\_polygon}{self, polygon, tags=None, |
---|
| 1235 | max_triangle_area=None, geo_reference=None} |
---|
| 1236 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1237 | |
---|
| 1238 | This method is used to build the mesh outline. It adds a region to a |
---|
| 1239 | \class{Mesh} instance. Regions are commonly used to describe an area |
---|
| 1240 | with an increased density of triangles, by setting |
---|
| 1241 | \code{max_triangle_area}. The |
---|
| 1242 | region boundary is described by the input \code{polygon}. Additionally, the |
---|
| 1243 | user specifies a list of boundary tags, one for each edge of the |
---|
| 1244 | bounding polygon. |
---|
| 1245 | |
---|
| 1246 | \end{methoddesc} |
---|
| 1247 | |
---|
| 1248 | |
---|
| 1249 | |
---|
| 1250 | |
---|
| 1251 | |
---|
| 1252 | \begin{methoddesc} {add\_vertices}{point_data} |
---|
[3441] | 1253 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1254 | Add user vertices. The point_data can be a list of (x,y) values, a numeric |
---|
| 1255 | array or a geospatial_data instance. |
---|
| 1256 | \end{methoddesc} |
---|
[3275] | 1257 | |
---|
[3441] | 1258 | \begin{methoddesc} {auto\_segment}{raw_boundary=raw_boundary, |
---|
| 1259 | remove_holes=remove_holes, |
---|
| 1260 | smooth_indents=smooth_indents, |
---|
| 1261 | expand_pinch=expand_pinch} |
---|
| 1262 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1263 | Add segments between the user vertices to give the vertices an |
---|
| 1264 | outline. The outline is an alpha shape. This method is |
---|
| 1265 | useful since a set of user vertices need to be outlined by segments |
---|
| 1266 | before generate_mesh is called. |
---|
[3275] | 1267 | |
---|
| 1268 | \end{methoddesc} |
---|
| 1269 | |
---|
| 1270 | \begin{methoddesc} {export\_mesh_file}{self,ofile} |
---|
| 1271 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1272 | |
---|
| 1273 | This method is used to save the mesh to a file. \code{ofile} is the |
---|
| 1274 | name of the mesh file to be written, including the extension. Use |
---|
| 1275 | the extension \code{.msh} for the file to be in NetCDF format and |
---|
| 1276 | \code{.tsh} for the file to be ASCII format. |
---|
| 1277 | \end{methoddesc} |
---|
| 1278 | |
---|
| 1279 | \begin{methoddesc} {generate\_mesh}{self, |
---|
| 1280 | maximum_triangle_area=None, |
---|
| 1281 | minimum_triangle_angle=28.0, |
---|
| 1282 | verbose=False} |
---|
| 1283 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1284 | |
---|
| 1285 | This method is used to generate the triangular mesh. The maximal |
---|
| 1286 | area of any triangle in the mesh can be specified, which is used to |
---|
| 1287 | control the triangle density, along with the |
---|
| 1288 | minimum angle in any triangle. |
---|
| 1289 | \end{methoddesc} |
---|
| 1290 | |
---|
| 1291 | |
---|
| 1292 | |
---|
| 1293 | \begin{methoddesc} {import_ungenerate_file}{self,ofile, tag=None} |
---|
| 1294 | Module: \module{pmesh.mesh}, Class: \class{Mesh} |
---|
| 1295 | |
---|
| 1296 | This method is used to import a polygon file in the ungenerate |
---|
| 1297 | format, which is used by arcGIS. The polygons from the file are converted to |
---|
| 1298 | vertices and segments. \code{ofile} is the name of the polygon file. |
---|
| 1299 | \code{tag} is the tag given to all the polygon's segments. |
---|
| 1300 | |
---|
| 1301 | This function can be used to import building footprints. |
---|
| 1302 | \end{methoddesc} |
---|
| 1303 | |
---|
| 1304 | %%%%%% |
---|
| 1305 | \section{Initialising the Domain} |
---|
| 1306 | |
---|
| 1307 | %Include description of the class Domain and the module domain. |
---|
| 1308 | |
---|
| 1309 | %FIXME (Ole): This is also defined in a later chapter |
---|
| 1310 | %\declaremodule{standard}{pyvolution.domain} |
---|
| 1311 | |
---|
| 1312 | \begin{classdesc} {Domain} {source=None, |
---|
| 1313 | triangles=None, |
---|
| 1314 | boundary=None, |
---|
| 1315 | conserved_quantities=None, |
---|
| 1316 | other_quantities=None, |
---|
| 1317 | tagged_elements=None, |
---|
| 1318 | geo_reference=None, |
---|
| 1319 | use_inscribed_circle=False, |
---|
| 1320 | mesh_filename=None, |
---|
| 1321 | use_cache=False, |
---|
| 1322 | verbose=False, |
---|
| 1323 | full_send_dict=None, |
---|
| 1324 | ghost_recv_dict=None, |
---|
| 1325 | processor=0, |
---|
| 1326 | numproc=1} |
---|
| 1327 | Module: \refmodule{pyvolution.domain} |
---|
| 1328 | |
---|
| 1329 | This class is used to create an instance of a data structure used to |
---|
| 1330 | store and manipulate data associated with a mesh. The mesh is |
---|
| 1331 | specified either by assigning the name of a mesh file to |
---|
| 1332 | \code{source} or by |
---|
| 1333 | \end{classdesc} |
---|
| 1334 | |
---|
| 1335 | \begin{funcdesc} {pmesh\_to\_domain\_instance}{file_name, DomainClass, use_cache = False, verbose = False} |
---|
| 1336 | Module: \module{pyvolution.pmesh2domain} |
---|
| 1337 | |
---|
| 1338 | Once the initial mesh file has been created, this function is |
---|
| 1339 | applied to convert it to a domain object---that is, to a member of |
---|
| 1340 | the special Python class \class{Domain} (or a subclass of |
---|
| 1341 | \class{Domain}), which provides access to properties and methods |
---|
| 1342 | that allow quantities to be set and other operations to be carried |
---|
| 1343 | out. |
---|
| 1344 | |
---|
| 1345 | \code{file\_name} is the name of the mesh file to be converted, |
---|
| 1346 | including the extension. \code{DomainClass} is the class to be |
---|
| 1347 | returned, which must be a subclass of \class{Domain} having the same |
---|
| 1348 | interface as \class{Domain}---in practice, it can usually be set |
---|
| 1349 | simply to \class{Domain}. |
---|
| 1350 | |
---|
| 1351 | This is now superseded by Domain(mesh_filename). |
---|
| 1352 | \end{funcdesc} |
---|
| 1353 | |
---|
| 1354 | |
---|
| 1355 | \subsection{Key Methods of Domain} |
---|
| 1356 | |
---|
| 1357 | \begin{methoddesc} {set\_name}{name} |
---|
| 1358 | Module: \refmodule{pyvolution.domain}, page \pageref{mod:pyvolution.domain} %\code{pyvolution.domain} |
---|
| 1359 | |
---|
| 1360 | Assigns the name \code{name} to the domain. |
---|
| 1361 | \end{methoddesc} |
---|
| 1362 | |
---|
| 1363 | \begin{methoddesc} {get\_name}{} |
---|
| 1364 | Module: \module{pyvolution.domain} |
---|
| 1365 | |
---|
| 1366 | Returns the name assigned to the domain by \code{set\_name}. If no name has been |
---|
| 1367 | assigned, returns \code{`domain'}. |
---|
| 1368 | \end{methoddesc} |
---|
| 1369 | |
---|
| 1370 | \begin{methoddesc} {set\_datadir}{name} |
---|
| 1371 | Module: \module{pyvolution.domain} |
---|
| 1372 | |
---|
| 1373 | Specifies the directory used for SWW files, assigning it to the pathname \code{name}. The default value, before |
---|
| 1374 | \code{set\_datadir} has been run, is the value \code{default\_datadir} |
---|
| 1375 | specified in \code{config.py}. |
---|
| 1376 | |
---|
| 1377 | Since different operating systems use different formats for specifying pathnames, |
---|
| 1378 | it is necessary to specify path separators using the Python code \code{os.sep}, rather than |
---|
| 1379 | the operating-specific ones such as `$\slash$' or `$\backslash$'. |
---|
| 1380 | For this to work you will need to include the statement \code{import os} |
---|
| 1381 | in your code, before the first appearance of \code{set\_datadir}. |
---|
| 1382 | |
---|
| 1383 | For example, to set the data directory to a subdirectory |
---|
| 1384 | \code{data} of the directory \code{project}, you could use |
---|
| 1385 | the statements: |
---|
| 1386 | |
---|
| 1387 | {\small \begin{verbatim} |
---|
| 1388 | import os |
---|
| 1389 | domain.set_datadir{'project' + os.sep + 'data'} |
---|
| 1390 | \end{verbatim}} |
---|
| 1391 | \end{methoddesc} |
---|
| 1392 | |
---|
| 1393 | \begin{methoddesc} {get\_datadir}{} |
---|
| 1394 | Module: \module{pyvolution.domain} |
---|
| 1395 | |
---|
| 1396 | Returns the data directory set by \code{set\_datadir} or, |
---|
| 1397 | if \code{set\_datadir} has not |
---|
| 1398 | been run, returns the value \code{default\_datadir} specified in |
---|
| 1399 | \code{config.py}. |
---|
| 1400 | \end{methoddesc} |
---|
| 1401 | |
---|
[3533] | 1402 | \begin{methoddesc} {set\_minimum_sww_depth}{time=0.0} |
---|
| 1403 | Module: \module{pyvolution.domain} |
---|
| 1404 | |
---|
| 1405 | Sets the minimum depth that will be recognised when writing |
---|
| 1406 | to an sww file. This is useful for removing thin water layers |
---|
| 1407 | that seems to be caused by friction creep. |
---|
| 1408 | \end{methoddesc} |
---|
| 1409 | |
---|
[3275] | 1410 | \begin{methoddesc} {set\_time}{time=0.0} |
---|
| 1411 | Module: \module{pyvolution.domain} |
---|
| 1412 | |
---|
| 1413 | Sets the initial time, in seconds, for the simulation. The |
---|
| 1414 | default is 0.0. |
---|
| 1415 | \end{methoddesc} |
---|
| 1416 | |
---|
| 1417 | \begin{methoddesc} {set\_default\_order}{n} |
---|
| 1418 | Sets the default (spatial) order to the value specified by |
---|
| 1419 | \code{n}, which must be either 1 or 2. (Assigning any other value |
---|
| 1420 | to \code{n} will cause an error.) |
---|
| 1421 | \end{methoddesc} |
---|
| 1422 | |
---|
| 1423 | |
---|
| 1424 | %%%%%% |
---|
| 1425 | \section{Initial Conditions} |
---|
| 1426 | \label{sec:Initial Conditions} |
---|
| 1427 | In standard usage of partial differential equations, initial conditions |
---|
| 1428 | refers to the values associated to the system variables (the conserved |
---|
| 1429 | quantities here) for \code{time = 0}. In setting up a scenario script |
---|
| 1430 | as described in Sections \ref{sec:simpleexample} and \ref{sec:realdataexample}, |
---|
| 1431 | \code{set_quantity} is used to define the initial conditions of variables |
---|
| 1432 | other than the conserved quantities, such as friction. Here, we use the terminology |
---|
| 1433 | of initial conditions to refer to initial values for variables which need |
---|
| 1434 | prescription to solve the shallow water wave equation. Further, it must be noted |
---|
| 1435 | that \code{set_quantity} does not necessarily have to be used in the initial |
---|
| 1436 | condition setting; it can be used at any time throughout the simulation. |
---|
| 1437 | |
---|
| 1438 | \begin{methoddesc}{set\_quantity}{name, |
---|
| 1439 | numeric = None, |
---|
| 1440 | quantity = None, |
---|
| 1441 | function = None, |
---|
| 1442 | geospatial_data = None, |
---|
| 1443 | filename = None, |
---|
| 1444 | attribute_name = None, |
---|
| 1445 | alpha = None, |
---|
| 1446 | location = 'vertices', |
---|
| 1447 | indices = None, |
---|
| 1448 | verbose = False, |
---|
| 1449 | use_cache = False} |
---|
| 1450 | Module: \module{pyvolution.domain} |
---|
| 1451 | (see also \module{pyvolution.quantity.set\_values}) |
---|
| 1452 | |
---|
| 1453 | This function is used to assign values to individual quantities for a |
---|
| 1454 | domain. It is very flexible and can be used with many data types: a |
---|
| 1455 | statement of the form \code{domain.set\_quantity(name, x)} can be used |
---|
| 1456 | to define a quantity having the name \code{name}, where the other |
---|
| 1457 | argument \code{x} can be any of the following: |
---|
| 1458 | |
---|
| 1459 | \begin{itemize} |
---|
| 1460 | \item a number, in which case all vertices in the mesh gets that for |
---|
| 1461 | the quantity in question. |
---|
| 1462 | \item a list of numbers or a Numeric array ordered the same way as the mesh vertices. |
---|
| 1463 | \item a function (e.g.\ see the samples introduced in Chapter 2) |
---|
| 1464 | \item an expression composed of other quantities and numbers, arrays, lists (for |
---|
| 1465 | example, a linear combination of quantities, such as |
---|
| 1466 | \code{domain.set\_quantity('stage','elevation'+x))} |
---|
| 1467 | \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. |
---|
| 1468 | \item a geospatial dataset (See ?????). Optional argument attribute\_name applies here as with files. |
---|
| 1469 | \end{itemize} |
---|
| 1470 | |
---|
| 1471 | |
---|
| 1472 | Exactly one of the arguments |
---|
| 1473 | numeric, quantity, function, points, filename |
---|
| 1474 | must be present. |
---|
| 1475 | |
---|
| 1476 | |
---|
| 1477 | Set quantity will look at the type of the second argument (\code{numeric}) and |
---|
| 1478 | determine what action to take. |
---|
| 1479 | |
---|
| 1480 | Values can also be set using the appropriate keyword arguments. |
---|
| 1481 | 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)} |
---|
| 1482 | are all equivalent. |
---|
| 1483 | |
---|
| 1484 | |
---|
| 1485 | Other optional arguments are |
---|
| 1486 | \begin{itemize} |
---|
| 1487 | \item \code{indices} which is a list of ids of triangles to which set\_quantity should apply its assignment of values. |
---|
[3449] | 1488 | \item \code{location} determines which part of the triangles to assign |
---|
| 1489 | to. Options are 'vertices' (default), 'edges', 'unique vertices', and 'centroids'. |
---|
[3275] | 1490 | \end{itemize} |
---|
| 1491 | |
---|
[3449] | 1492 | %%% |
---|
| 1493 | \anuga provides a number of predefined initial conditions to be used |
---|
| 1494 | with \code{set\_quantity}. |
---|
[3275] | 1495 | |
---|
| 1496 | \end{methoddesc} |
---|
| 1497 | |
---|
| 1498 | |
---|
| 1499 | |
---|
| 1500 | |
---|
[3449] | 1501 | \begin{funcdesc}{set_region}{tag, quantity, X, location='vertices'} |
---|
| 1502 | Module: \module{pyvolution.domain} |
---|
[3450] | 1503 | |
---|
[3449] | 1504 | (see also \module{pyvolution.quantity.set\_values}) |
---|
| 1505 | |
---|
| 1506 | This function is used to assign values to individual quantities given |
---|
[3450] | 1507 | a regional tag. It is similar to \code{set\_quantity}. |
---|
[3449] | 1508 | For example, if in pmesh a regional tag of 'ditch' was |
---|
| 1509 | used, set\_region can be used to set elevation of this region to |
---|
| 1510 | -10m. X is the constant or function to be applied to the quantity, |
---|
| 1511 | over the tagged region. Location describes how the values will be |
---|
| 1512 | applied. Options are 'vertices' (default), 'edges', 'unique |
---|
| 1513 | vertices', and 'centroids'. |
---|
[3275] | 1514 | |
---|
[3449] | 1515 | This method can also be called with a list of region objects. This is |
---|
| 1516 | useful for adding quantities in regions, and having one quantity |
---|
| 1517 | value based on another quantity. See \module{pyvolution.region} for |
---|
| 1518 | more details. |
---|
| 1519 | \end{funcdesc} |
---|
[3275] | 1520 | |
---|
| 1521 | |
---|
| 1522 | |
---|
[3449] | 1523 | |
---|
[3275] | 1524 | \begin{funcdesc}{slump_tsunami}{length, depth, slope, width=None, thickness=None, |
---|
| 1525 | x0=0.0, y0=0.0, alpha=0.0, |
---|
| 1526 | gravity=9.8, gamma=1.85, |
---|
| 1527 | massco=1, dragco=1, frictionco=0, psi=0, |
---|
| 1528 | dx=None, kappa=3.0, kappad=0.8, zsmall=0.01, |
---|
| 1529 | domain=None, |
---|
| 1530 | verbose=False} |
---|
| 1531 | Module: \module{pyvolution.smf} |
---|
| 1532 | |
---|
| 1533 | This function returns a callable object representing an initial water |
---|
| 1534 | displacement generated by a submarine sediment failure. These failures can take the form of |
---|
| 1535 | a submarine slump or slide. In the case of a slide, use \code{slide_tsunami} instead. |
---|
| 1536 | |
---|
| 1537 | The arguments include as a minimum, the slump or slide length, the water depth to the centre of sediment |
---|
| 1538 | mass, and the bathymetric slope. Other slump or slide parameters can be included if they are known. |
---|
| 1539 | \end{funcdesc} |
---|
| 1540 | |
---|
| 1541 | |
---|
| 1542 | %%% |
---|
| 1543 | \begin{funcdesc}{file\_function}{filename, |
---|
| 1544 | domain = None, |
---|
| 1545 | quantities = None, |
---|
| 1546 | interpolation_points = None, |
---|
| 1547 | verbose = False, |
---|
| 1548 | use_cache = False} |
---|
| 1549 | Module: \module{pyvolution.util} |
---|
| 1550 | |
---|
| 1551 | Reads the time history of spatial data for |
---|
| 1552 | specified interpolation points from a NetCDF file (\code{filename}) |
---|
| 1553 | and returns |
---|
| 1554 | a callable object. \code{filename} could be a \code{sww} file. |
---|
| 1555 | Returns interpolated values based on the input |
---|
| 1556 | file using the underlying \code{interpolation\_function}. |
---|
| 1557 | |
---|
| 1558 | \code{quantities} is either the name of a single quantity to be |
---|
| 1559 | interpolated or a list of such quantity names. In the second case, the resulting |
---|
| 1560 | function will return a tuple of values---one for each quantity. |
---|
| 1561 | |
---|
| 1562 | \code{interpolation\_points} is a list of absolute UTM coordinates |
---|
| 1563 | for points at which values are sought. |
---|
| 1564 | |
---|
| 1565 | The model time stored within the file function can be accessed using |
---|
| 1566 | the method \code{f.get\_time()} |
---|
| 1567 | \end{funcdesc} |
---|
| 1568 | |
---|
| 1569 | %%% |
---|
| 1570 | \begin{classdesc}{Interpolation\_function}{self, |
---|
| 1571 | time, |
---|
| 1572 | quantities, |
---|
| 1573 | quantity_names = None, |
---|
| 1574 | vertex_coordinates = None, |
---|
| 1575 | triangles = None, |
---|
| 1576 | interpolation_points = None, |
---|
| 1577 | verbose = False} |
---|
| 1578 | Module: \module{pyvolution.least\_squares} |
---|
| 1579 | |
---|
| 1580 | Given a time series (i.e. a series of values associated with |
---|
| 1581 | different times), whose values are either just numbers or a set of |
---|
| 1582 | numbers defined at the vertices of a triangular mesh (such as those |
---|
| 1583 | stored in SWW files), \code{Interpolation\_function} is used to |
---|
| 1584 | create a callable object that interpolates a value for an arbitrary |
---|
| 1585 | time \code{t} within the model limits and possibly a point \code{(x, |
---|
| 1586 | y)} within a mesh region. |
---|
| 1587 | |
---|
| 1588 | The actual time series at which data is available is specified by |
---|
| 1589 | means of an array \code{time} of monotonically increasing times. The |
---|
| 1590 | quantities containing the values to be interpolated are specified in |
---|
| 1591 | an array---or dictionary of arrays (used in conjunction with the |
---|
| 1592 | optional argument \code{quantity\_names}) --- called |
---|
| 1593 | \code{quantities}. The optional arguments \code{vertex\_coordinates} |
---|
| 1594 | and \code{triangles} represent the spatial mesh associated with the |
---|
| 1595 | quantity arrays. If omitted the function created by |
---|
| 1596 | \code{Interpolation\_function} will be a function of \code{t} only. |
---|
| 1597 | |
---|
| 1598 | Since, in practice, values need to be computed at specified points, |
---|
| 1599 | the syntax allows the user to specify, once and for all, a list |
---|
| 1600 | \code{interpolation\_points} of points at which values are required. |
---|
| 1601 | In this case, the function may be called using the form \code{f(t, |
---|
| 1602 | id)}, where \code{id} is an index for the list |
---|
| 1603 | \code{interpolation\_points}. |
---|
| 1604 | |
---|
| 1605 | \end{classdesc} |
---|
| 1606 | |
---|
| 1607 | %%% |
---|
| 1608 | %\begin{funcdesc}{set\_region}{functions} |
---|
| 1609 | %[Low priority. Will be merged into set\_quantity] |
---|
| 1610 | |
---|
| 1611 | %Module:\module{pyvolution.domain} |
---|
| 1612 | %\end{funcdesc} |
---|
| 1613 | |
---|
| 1614 | |
---|
| 1615 | |
---|
| 1616 | %%%%%% |
---|
| 1617 | \section{Boundary Conditions}\index{boundary conditions} |
---|
| 1618 | |
---|
| 1619 | \anuga provides a large number of predefined boundary conditions, |
---|
| 1620 | represented by objects such as \code{Reflective\_boundary(domain)} and |
---|
| 1621 | \code{Dirichlet\_boundary([0.2, 0.0, 0.0])}, described in the examples |
---|
| 1622 | in Chapter 2. Alternatively, you may prefer to ``roll your own'', |
---|
| 1623 | following the method explained in Section \ref{sec:roll your own}. |
---|
| 1624 | |
---|
| 1625 | These boundary objects may be used with the function \code{set\_boundary} described below |
---|
| 1626 | to assign boundary conditions according to the tags used to label boundary segments. |
---|
| 1627 | |
---|
| 1628 | \begin{methoddesc}{set\_boundary}{boundary_map} |
---|
| 1629 | Module: \module{pyvolution.domain} |
---|
| 1630 | |
---|
| 1631 | This function allows you to assign a boundary object (corresponding to a |
---|
| 1632 | pre-defined or user-specified boundary condition) to every boundary segment that |
---|
| 1633 | has been assigned a particular tag. |
---|
| 1634 | |
---|
| 1635 | This is done by specifying a dictionary \code{boundary\_map}, whose values are the boundary objects |
---|
| 1636 | and whose keys are the symbolic tags. |
---|
| 1637 | |
---|
| 1638 | \end{methoddesc} |
---|
| 1639 | |
---|
| 1640 | \begin{methoddesc} {get\_boundary\_tags}{} |
---|
| 1641 | Module: \module{pyvolution.mesh} |
---|
| 1642 | |
---|
| 1643 | Returns a list of the available boundary tags. |
---|
| 1644 | \end{methoddesc} |
---|
| 1645 | |
---|
| 1646 | %%% |
---|
| 1647 | \subsection{Predefined boundary conditions} |
---|
| 1648 | |
---|
| 1649 | \begin{classdesc}{Reflective\_boundary}{Boundary} |
---|
| 1650 | Module: \module{pyvolution.shallow\_water} |
---|
| 1651 | |
---|
| 1652 | Reflective boundary returns same conserved quantities as those present in |
---|
| 1653 | the neighbouring volume but reflected. |
---|
| 1654 | |
---|
| 1655 | This class is specific to the shallow water equation as it works with the |
---|
| 1656 | momentum quantities assumed to be the second and third conserved quantities. |
---|
| 1657 | \end{classdesc} |
---|
| 1658 | |
---|
| 1659 | %%% |
---|
| 1660 | \begin{classdesc}{Transmissive\_boundary}{domain = None} |
---|
| 1661 | Module: \module{pyvolution.generic\_boundary\_conditions} |
---|
| 1662 | |
---|
| 1663 | A transmissive boundary returns the same conserved quantities as |
---|
| 1664 | those present in the neighbouring volume. |
---|
| 1665 | |
---|
| 1666 | The underlying domain must be specified when the boundary is instantiated. |
---|
| 1667 | \end{classdesc} |
---|
| 1668 | |
---|
| 1669 | %%% |
---|
| 1670 | \begin{classdesc}{Dirichlet\_boundary}{conserved_quantities=None} |
---|
| 1671 | Module: \module{pyvolution.generic\_boundary\_conditions} |
---|
| 1672 | |
---|
| 1673 | A Dirichlet boundary returns constant values for each of conserved |
---|
| 1674 | quantities. In the example of \code{Dirichlet\_boundary([0.2, 0.0, 0.0])}, |
---|
| 1675 | the \code{stage} value at the boundary is 0.2 and the \code{xmomentum} and |
---|
| 1676 | \code{ymomentum} at the boundary are set to 0.0. The list must contain |
---|
| 1677 | a value for each conserved quantity. |
---|
| 1678 | \end{classdesc} |
---|
| 1679 | |
---|
| 1680 | %%% |
---|
| 1681 | \begin{classdesc}{Time\_boundary}{domain = None, f = None} |
---|
| 1682 | Module: \module{pyvolution.generic\_boundary\_conditions} |
---|
| 1683 | |
---|
| 1684 | A time-dependent boundary returns values for the conserved |
---|
| 1685 | quantities as a function \code{f(t)} of time. The user must specify |
---|
| 1686 | the domain to get access to the model time. |
---|
| 1687 | \end{classdesc} |
---|
| 1688 | |
---|
| 1689 | %%% |
---|
| 1690 | \begin{classdesc}{File\_boundary}{Boundary} |
---|
| 1691 | Module: \module{pyvolution.generic\_boundary\_conditions} |
---|
| 1692 | |
---|
| 1693 | This method may be used if the user wishes to apply a SWW file or |
---|
| 1694 | a time series file to a boundary segment or segments. |
---|
| 1695 | The boundary values are obtained from a file and interpolated to the |
---|
| 1696 | appropriate segments for each conserved quantity. |
---|
| 1697 | \end{classdesc} |
---|
| 1698 | |
---|
| 1699 | |
---|
| 1700 | |
---|
| 1701 | %%% |
---|
| 1702 | \begin{classdesc}{Transmissive\_Momentum\_Set\_Stage\_boundary}{Boundary} |
---|
| 1703 | Module: \module{pyvolution.shallow\_water} |
---|
| 1704 | |
---|
| 1705 | This boundary returns same momentum conserved quantities as |
---|
| 1706 | those present in its neighbour volume but sets stage as in a Time\_boundary. |
---|
| 1707 | The underlying domain must be specified when boundary is instantiated |
---|
| 1708 | |
---|
| 1709 | This type of boundary is useful when stage is known at the boundary as a |
---|
| 1710 | function of time, but momenta (or speeds) aren't. |
---|
| 1711 | |
---|
| 1712 | This class is specific to the shallow water equation as it works with the |
---|
| 1713 | momentum quantities assumed to be the second and third conserved quantities. |
---|
| 1714 | \end{classdesc} |
---|
| 1715 | |
---|
| 1716 | |
---|
| 1717 | |
---|
| 1718 | \subsection{User-defined boundary conditions} |
---|
| 1719 | \label{sec:roll your own} |
---|
| 1720 | [How to roll your own] TBA |
---|
| 1721 | |
---|
| 1722 | |
---|
| 1723 | |
---|
| 1724 | |
---|
| 1725 | |
---|
| 1726 | \section{Forcing Functions} |
---|
| 1727 | |
---|
| 1728 | \anuga provides a number of predefined forcing functions to be used with ..... |
---|
| 1729 | |
---|
| 1730 | %\begin{itemize} |
---|
| 1731 | |
---|
| 1732 | |
---|
| 1733 | % \item \indexedcode{} |
---|
| 1734 | % [function, arguments] |
---|
| 1735 | |
---|
| 1736 | % \item \indexedcode{} |
---|
| 1737 | |
---|
| 1738 | %\end{itemize} |
---|
| 1739 | |
---|
| 1740 | |
---|
| 1741 | |
---|
| 1742 | \section{Evolution}\index{evolution} |
---|
| 1743 | |
---|
| 1744 | \begin{methoddesc}{evolve}{yieldstep = None, finaltime = None, duration = None, skip_initial_step = False} |
---|
| 1745 | |
---|
| 1746 | Module: \module{pyvolution.domain} |
---|
| 1747 | |
---|
| 1748 | This function (a method of \class{domain}) is invoked once all the |
---|
| 1749 | preliminaries have been completed, and causes the model to progress |
---|
| 1750 | through successive steps in its evolution, storing results and |
---|
| 1751 | outputting statistics whenever a user-specified period |
---|
| 1752 | \code{yieldstep} is completed (generally during this period the |
---|
| 1753 | model will evolve through several steps internally |
---|
| 1754 | as the method forces the water speed to be calculated |
---|
| 1755 | on successive new cells). The user |
---|
| 1756 | specifies the total time period over which the evolution is to take |
---|
| 1757 | place, by specifying values (in seconds) for either \code{duration} |
---|
| 1758 | or \code{finaltime}, as well as the interval in seconds after which |
---|
| 1759 | results are to be stored and statistics output. |
---|
| 1760 | |
---|
| 1761 | You can include \method{evolve} in a statement of the type: |
---|
| 1762 | |
---|
| 1763 | {\small \begin{verbatim} |
---|
| 1764 | for t in domain.evolve(yieldstep, finaltime): |
---|
| 1765 | <Do something with domain and t> |
---|
| 1766 | \end{verbatim}} |
---|
| 1767 | |
---|
| 1768 | \end{methoddesc} |
---|
| 1769 | |
---|
| 1770 | |
---|
| 1771 | |
---|
| 1772 | \subsection{Diagnostics} |
---|
| 1773 | |
---|
| 1774 | |
---|
| 1775 | \begin{funcdesc}{statistics}{} |
---|
| 1776 | Module: \module{pyvolution.domain} |
---|
| 1777 | |
---|
| 1778 | \end{funcdesc} |
---|
| 1779 | |
---|
| 1780 | \begin{funcdesc}{timestepping\_statistics}{} |
---|
| 1781 | Module: \module{pyvolution.domain} |
---|
| 1782 | |
---|
| 1783 | Returns a string of the following type for each |
---|
| 1784 | timestep: |
---|
| 1785 | |
---|
| 1786 | \code{Time = 0.9000, delta t in [0.00598964, 0.01177388], steps=12 |
---|
| 1787 | (12)} |
---|
| 1788 | |
---|
| 1789 | Here the numbers in \code{steps=12 (12)} indicate the number of steps taken and |
---|
| 1790 | the number of first-order steps, respectively. |
---|
| 1791 | \end{funcdesc} |
---|
| 1792 | |
---|
| 1793 | |
---|
| 1794 | \begin{funcdesc}{boundary\_statistics}{quantities = None, tags = None} |
---|
| 1795 | Module: \module{pyvolution.domain} |
---|
| 1796 | |
---|
| 1797 | Returns a string of the following type when \code{quantities = 'stage'} and \code{tags = ['top', 'bottom']}: |
---|
| 1798 | |
---|
| 1799 | {\small \begin{verbatim} |
---|
| 1800 | Boundary values at time 0.5000: |
---|
| 1801 | top: |
---|
| 1802 | stage in [ -0.25821218, -0.02499998] |
---|
| 1803 | bottom: |
---|
| 1804 | stage in [ -0.27098821, -0.02499974] |
---|
| 1805 | \end{verbatim}} |
---|
| 1806 | |
---|
| 1807 | \end{funcdesc} |
---|
| 1808 | |
---|
| 1809 | |
---|
| 1810 | \begin{funcdesc}{get\_quantity}{name, location='vertices', indices = None} |
---|
| 1811 | Module: \module{pyvolution.domain} |
---|
| 1812 | Allow access to individual quantities and their methods |
---|
| 1813 | |
---|
| 1814 | \end{funcdesc} |
---|
| 1815 | |
---|
| 1816 | |
---|
| 1817 | \begin{funcdesc}{get\_values}{location='vertices', indices = None} |
---|
| 1818 | Module: \module{pyvolution.quantity} |
---|
| 1819 | |
---|
| 1820 | Extract values for quantity as an array |
---|
| 1821 | |
---|
| 1822 | \end{funcdesc} |
---|
| 1823 | |
---|
| 1824 | |
---|
| 1825 | \begin{funcdesc}{get\_integral}{} |
---|
| 1826 | Module: \module{pyvolution.quantity} |
---|
| 1827 | |
---|
| 1828 | Return computed integral over entire domain for this quantity |
---|
| 1829 | |
---|
| 1830 | \end{funcdesc} |
---|
| 1831 | |
---|
| 1832 | |
---|
| 1833 | \section{Other} |
---|
| 1834 | |
---|
| 1835 | \begin{funcdesc}{domain.create\_quantity\_from\_expression}{???} |
---|
| 1836 | |
---|
| 1837 | Handy for creating derived quantities on-the-fly. |
---|
| 1838 | See \file{Analytical\_solution\_circular\_hydraulic\_jump.py} for an example of use. |
---|
| 1839 | \end{funcdesc} |
---|
| 1840 | |
---|
| 1841 | |
---|
| 1842 | |
---|
| 1843 | |
---|
| 1844 | |
---|
| 1845 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 1846 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 1847 | |
---|
| 1848 | \chapter{\anuga System Architecture} |
---|
| 1849 | |
---|
| 1850 | From pyvolution/documentation |
---|
| 1851 | |
---|
| 1852 | \section{File Formats} |
---|
| 1853 | \label{sec:file formats} |
---|
| 1854 | |
---|
| 1855 | \anuga makes use of a number of different file formats. The |
---|
| 1856 | following table lists all these formats, which are described in more |
---|
| 1857 | detail in the paragraphs below. |
---|
| 1858 | |
---|
| 1859 | \bigskip |
---|
| 1860 | |
---|
| 1861 | \begin{center} |
---|
| 1862 | |
---|
| 1863 | \begin{tabular}{|ll|} \hline |
---|
| 1864 | |
---|
| 1865 | \textbf{Extension} & \textbf{Description} \\ |
---|
| 1866 | \hline\hline |
---|
| 1867 | |
---|
| 1868 | \code{.sww} & NetCDF format for storing model output |
---|
| 1869 | \code{f(t,x,y)}\\ |
---|
| 1870 | |
---|
| 1871 | \code{.tms} & NetCDF format for storing time series \code{f(t)}\\ |
---|
| 1872 | |
---|
| 1873 | \code{.xya} & ASCII format for storing arbitrary points and |
---|
| 1874 | associated attributes\\ |
---|
| 1875 | |
---|
| 1876 | \code{.pts} & NetCDF format for storing arbitrary points and |
---|
| 1877 | associated attributes\\ |
---|
| 1878 | |
---|
| 1879 | \code{.asc} & ASCII format of regular DEMs as output from ArcView\\ |
---|
| 1880 | |
---|
| 1881 | \code{.prj} & Associated ArcView file giving more metadata for |
---|
| 1882 | \code{.asc} format\\ |
---|
| 1883 | |
---|
| 1884 | \code{.ers} & ERMapper header format of regular DEMs for ArcView\\ |
---|
| 1885 | |
---|
| 1886 | \code{.dem} & NetCDF representation of regular DEM data\\ |
---|
| 1887 | |
---|
| 1888 | \code{.tsh} & ASCII format for storing meshes and associated |
---|
| 1889 | boundary and region info\\ |
---|
| 1890 | |
---|
| 1891 | \code{.msh} & NetCDF format for storing meshes and associated |
---|
| 1892 | boundary and region info\\ |
---|
| 1893 | |
---|
| 1894 | \code{.nc} & Native ferret NetCDF format\\ |
---|
| 1895 | |
---|
| 1896 | \code{.geo} & Houdinis ASCII geometry format (?) \\ \par \hline |
---|
| 1897 | %\caption{File formats used by \anuga} |
---|
| 1898 | \end{tabular} |
---|
| 1899 | |
---|
| 1900 | |
---|
| 1901 | \end{center} |
---|
| 1902 | |
---|
| 1903 | The above table shows the file extensions used to identify the |
---|
| 1904 | formats of files. However, typically, in referring to a format we |
---|
| 1905 | capitalise the extension and omit the initial full stop---thus, we |
---|
| 1906 | refer, for example, to `SWW files' or `PRJ files'. |
---|
| 1907 | |
---|
| 1908 | \bigskip |
---|
| 1909 | |
---|
| 1910 | A typical dataflow can be described as follows: |
---|
| 1911 | |
---|
| 1912 | \subsection{Manually Created Files} |
---|
| 1913 | |
---|
| 1914 | \begin{tabular}{ll} |
---|
| 1915 | ASC, PRJ & Digital elevation models (gridded)\\ |
---|
| 1916 | NC & Model outputs for use as boundary conditions (e.g. from MOST) |
---|
| 1917 | \end{tabular} |
---|
| 1918 | |
---|
| 1919 | \subsection{Automatically Created Files} |
---|
| 1920 | |
---|
| 1921 | \begin{tabular}{ll} |
---|
| 1922 | ASC, PRJ $\rightarrow$ DEM $\rightarrow$ PTS & Convert |
---|
| 1923 | DEMs to native \code{.pts} file\\ |
---|
| 1924 | |
---|
| 1925 | NC $\rightarrow$ SWW & Convert MOST boundary files to |
---|
| 1926 | boundary \code{.sww}\\ |
---|
| 1927 | |
---|
| 1928 | PTS + TSH $\rightarrow$ TSH with elevation & Least squares fit\\ |
---|
| 1929 | |
---|
| 1930 | TSH $\rightarrow$ SWW & Convert TSH to \code{.sww}-viewable using |
---|
| 1931 | Swollen\\ |
---|
| 1932 | |
---|
| 1933 | TSH + Boundary SWW $\rightarrow$ SWW & Simulation using |
---|
| 1934 | \code{pyvolution}\\ |
---|
| 1935 | |
---|
| 1936 | Polygonal mesh outline $\rightarrow$ & TSH or MSH |
---|
| 1937 | \end{tabular} |
---|
| 1938 | |
---|
| 1939 | |
---|
| 1940 | |
---|
| 1941 | |
---|
| 1942 | \bigskip |
---|
| 1943 | |
---|
| 1944 | \subsection{SWW and TMS Formats} |
---|
| 1945 | |
---|
| 1946 | The SWW and TMS formats are both NetCDF formats, and are of key |
---|
| 1947 | importance for \anuga. |
---|
| 1948 | |
---|
| 1949 | An SWW file is used for storing \anuga output and therefore pertains |
---|
| 1950 | to a set of points and a set of times at which a model is evaluated. |
---|
| 1951 | It contains, in addition to dimension information, the following |
---|
| 1952 | variables: |
---|
| 1953 | |
---|
| 1954 | \begin{itemize} |
---|
| 1955 | \item \code{x} and \code{y}: coordinates of the points, represented as Numeric arrays |
---|
| 1956 | \item \code{elevation}, a Numeric array storing bed-elevations |
---|
| 1957 | \item \code{volumes}, a list specifying the points at the vertices of each of the |
---|
| 1958 | triangles |
---|
| 1959 | % Refer here to the example to be provided in describing the simple example |
---|
| 1960 | \item \code{time}, a Numeric array containing times for model |
---|
| 1961 | evaluation |
---|
| 1962 | \end{itemize} |
---|
| 1963 | |
---|
| 1964 | |
---|
| 1965 | The contents of an SWW file may be viewed using the visualisation |
---|
| 1966 | tool \code{swollen}, which creates an on-screen geometric |
---|
| 1967 | representation. See section \ref{sec:swollen} (page |
---|
| 1968 | \pageref{sec:swollen}) in Appendix \ref{ch:supportingtools} for more |
---|
| 1969 | on \code{swollen}. |
---|
| 1970 | |
---|
| 1971 | Alternatively, there are tools, such as \code{ncdump}, that allow |
---|
| 1972 | you to convert an NetCDF file into a readable format such as the |
---|
| 1973 | Class Definition Language (CDL). The following is an excerpt from a |
---|
| 1974 | CDL representation of the output file \file{bedslope.sww} generated |
---|
| 1975 | from running the simple example \file{runup.py} of |
---|
| 1976 | Chapter \ref{ch:getstarted}: |
---|
| 1977 | |
---|
| 1978 | \verbatiminput{examples/bedslopeexcerpt.cdl} |
---|
| 1979 | |
---|
| 1980 | The SWW format is used not only for output but also serves as input |
---|
| 1981 | for functions such as \function{file\_boundary} and |
---|
| 1982 | \function{file\_function}, described in Chapter \ref{ch:interface}. |
---|
| 1983 | |
---|
| 1984 | A TMS file is used to store time series data that is independent of |
---|
| 1985 | position. |
---|
| 1986 | |
---|
| 1987 | |
---|
| 1988 | \subsection{Mesh File Formats} |
---|
| 1989 | |
---|
| 1990 | A mesh file is a file that has a specific format suited to |
---|
| 1991 | triangular meshes and their outlines. A mesh file can have one of |
---|
| 1992 | two formats: it can be either a TSH file, which is an ASCII file, or |
---|
| 1993 | an MSH file, which is a NetCDF file. A mesh file can be generated |
---|
| 1994 | from the function \function{create\_mesh\_from\_regions} (see |
---|
| 1995 | Section \ref{sec:meshgeneration}) and used to initialise a domain. |
---|
| 1996 | |
---|
| 1997 | A mesh file can define the outline of the mesh---the vertices and |
---|
| 1998 | line segments that enclose the region in which the mesh is |
---|
| 1999 | created---and the triangular mesh itself, which is specified by |
---|
| 2000 | listing the triangles and their vertices, and the segments, which |
---|
| 2001 | are those sides of the triangles that are associated with boundary |
---|
| 2002 | conditions. |
---|
| 2003 | |
---|
| 2004 | In addition, a mesh file may contain `holes' and/or `regions'. A |
---|
| 2005 | hole represents an area where no mesh is to be created, while a |
---|
| 2006 | region is a labelled area used for defining properties of a mesh, |
---|
| 2007 | such as friction values. A hole or region is specified by a point |
---|
| 2008 | and bounded by a number of segments that enclose that point. |
---|
| 2009 | |
---|
| 2010 | A mesh file can also contain a georeference, which describes an |
---|
| 2011 | offset to be applied to $x$ and $y$ values---eg to the vertices. |
---|
| 2012 | |
---|
| 2013 | |
---|
| 2014 | \subsection{Formats for Storing Arbitrary Points and Attributes} |
---|
| 2015 | |
---|
| 2016 | An XYA file is used to store data representing arbitrary numerical |
---|
| 2017 | attributes associated with a set of points. |
---|
| 2018 | |
---|
| 2019 | The format for an XYA file is:\\ |
---|
| 2020 | %\begin{verbatim} |
---|
| 2021 | |
---|
| 2022 | first line: \code{[attribute names]}\\ |
---|
| 2023 | other lines: \code{x y [attributes]}\\ |
---|
| 2024 | |
---|
| 2025 | for example:\\ |
---|
| 2026 | \code{elevation, friction}\\ |
---|
| 2027 | \code{0.6, 0.7, 4.9, 0.3}\\ |
---|
| 2028 | \code{1.9, 2.8, 5, 0.3}\\ |
---|
| 2029 | \code{2.7, 2.4, 5.2, 0.3} |
---|
| 2030 | |
---|
| 2031 | The first two columns are always implicitly assumed to be $x$, $y$ coordinates. |
---|
| 2032 | Use the same delimiter for the attribute names and the data. |
---|
| 2033 | |
---|
| 2034 | An XYA file can optionally end with a description of the georeference: |
---|
| 2035 | |
---|
| 2036 | \code{\#geo reference}\\ |
---|
| 2037 | \code{56}\\ |
---|
| 2038 | \code{466600.0}\\ |
---|
| 2039 | \code{8644444.0} |
---|
| 2040 | |
---|
| 2041 | Here the first number specifies the UTM zone (in this case zone 56) and other numbers specify the |
---|
| 2042 | easting and northing |
---|
| 2043 | coordinates (in this case (466600.0, 8644444.0)) of the lower left corner. |
---|
| 2044 | |
---|
| 2045 | A PTS file is a NetCDF representation of the data held in an XYA |
---|
| 2046 | file. If the data is associated with a set of $N$ points, then the |
---|
| 2047 | data is stored using an $N \times 2$ Numeric array of float |
---|
| 2048 | variables for the points and an $N \times 1$ Numeric array for each |
---|
| 2049 | attribute. |
---|
| 2050 | |
---|
| 2051 | %\end{verbatim} |
---|
| 2052 | |
---|
| 2053 | \subsection{ArcView Formats} |
---|
| 2054 | |
---|
| 2055 | Files of the three formats ASC, PRJ and ERS are all associated with |
---|
| 2056 | data from ArcView. |
---|
| 2057 | |
---|
| 2058 | An ASC file is an ASCII representation of DEM output from ArcView. |
---|
| 2059 | It contains a header with the following format: |
---|
| 2060 | |
---|
| 2061 | \begin{tabular}{l l} |
---|
| 2062 | \code{ncols} & \code{753}\\ |
---|
| 2063 | \code{nrows} & \code{766}\\ |
---|
| 2064 | \code{xllcorner} & \code{314036.58727982}\\ |
---|
| 2065 | \code{yllcorner} & \code{6224951.2960092}\\ |
---|
| 2066 | \code{cellsize} & \code{100}\\ |
---|
| 2067 | \code{NODATA_value} & \code{-9999} |
---|
| 2068 | \end{tabular} |
---|
| 2069 | |
---|
| 2070 | The remainder of the file contains the elevation data for each grid point |
---|
| 2071 | in the grid defined by the above information. |
---|
| 2072 | |
---|
| 2073 | A PRJ file is an ArcView file used in conjunction with an ASC file |
---|
| 2074 | to represent metadata for a DEM. |
---|
| 2075 | |
---|
| 2076 | |
---|
| 2077 | \subsection{DEM Format} |
---|
| 2078 | |
---|
| 2079 | A DEM file is a NetCDF representation of regular DEM data. |
---|
| 2080 | |
---|
| 2081 | |
---|
| 2082 | \subsection{Other Formats} |
---|
| 2083 | |
---|
| 2084 | |
---|
| 2085 | |
---|
| 2086 | |
---|
| 2087 | \subsection{Basic File Conversions} |
---|
| 2088 | |
---|
| 2089 | \begin{funcdesc}{sww2dem}{basename_in, basename_out = None, |
---|
| 2090 | quantity = None, |
---|
| 2091 | timestep = None, |
---|
| 2092 | reduction = None, |
---|
| 2093 | cellsize = 10, |
---|
| 2094 | NODATA_value = -9999, |
---|
| 2095 | easting_min = None, |
---|
| 2096 | easting_max = None, |
---|
| 2097 | northing_min = None, |
---|
| 2098 | northing_max = None, |
---|
| 2099 | expand_search = False, |
---|
| 2100 | verbose = False, |
---|
| 2101 | origin = None, |
---|
| 2102 | datum = 'WGS84', |
---|
| 2103 | format = 'ers'} |
---|
| 2104 | Module: \module{pyvolution.data\_manager} |
---|
| 2105 | |
---|
| 2106 | Takes data from an SWW file \code{basename_in} and converts it to DEM format (ASC or |
---|
| 2107 | ERS) of a desired grid size \code{cellsize} in metres. |
---|
| 2108 | The easting and northing values are used if the user wished to clip the output |
---|
| 2109 | file to a specified rectangular area. The \code{reduction} input refers to a function |
---|
| 2110 | to reduce the quantities over all time step of the SWW file, example, maximum. |
---|
| 2111 | \end{funcdesc} |
---|
| 2112 | |
---|
| 2113 | |
---|
| 2114 | \begin{funcdesc}{dem2pts}{basename_in, basename_out=None, |
---|
| 2115 | easting_min=None, easting_max=None, |
---|
| 2116 | northing_min=None, northing_max=None, |
---|
| 2117 | use_cache=False, verbose=False} |
---|
| 2118 | Module: \module{pyvolution.data\_manager} |
---|
| 2119 | |
---|
| 2120 | Takes DEM data (a NetCDF file representation of data from a regular Digital |
---|
| 2121 | Elevation Model) and converts it to PTS format. |
---|
| 2122 | \end{funcdesc} |
---|
| 2123 | |
---|
| 2124 | |
---|
| 2125 | |
---|
| 2126 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 2127 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 2128 | |
---|
| 2129 | \chapter{Basic \anuga Assumptions} |
---|
| 2130 | |
---|
| 2131 | (From pyvolution/documentation) |
---|
| 2132 | |
---|
| 2133 | |
---|
| 2134 | Physical model time cannot be earlier than 1 Jan 1970 00:00:00. |
---|
| 2135 | If one wished to recreate scenarios prior to that date it must be done |
---|
| 2136 | using some relative time (e.g. 0). |
---|
| 2137 | |
---|
| 2138 | |
---|
| 2139 | All spatial data relates to the WGS84 datum (or GDA94) and has been |
---|
| 2140 | projected into UTM with false easting of 500000 and false northing of |
---|
| 2141 | 1000000 on the southern hemisphere (0 on the northern). |
---|
| 2142 | |
---|
| 2143 | It is assumed that all computations take place within one UTM zone. |
---|
| 2144 | |
---|
| 2145 | DEMs, meshes and boundary conditions can have different origins within |
---|
| 2146 | one UTM zone. However, the computation will use that of the mesh for |
---|
| 2147 | numerical stability. |
---|
| 2148 | |
---|
[3439] | 2149 | When generating a mesh it is assumed that polygons do not cross. |
---|
| 2150 | Having polygons tht cross can cause the mesh generation to fail or bad |
---|
| 2151 | meshes being produced. |
---|
[3275] | 2152 | |
---|
[3439] | 2153 | |
---|
[3275] | 2154 | %OLD |
---|
| 2155 | %The dataflow is: (See data_manager.py and from scenarios) |
---|
| 2156 | % |
---|
| 2157 | % |
---|
| 2158 | %Simulation scenarios |
---|
| 2159 | %--------------------% |
---|
| 2160 | %% |
---|
| 2161 | % |
---|
| 2162 | %Sub directories contain scrips and derived files for each simulation. |
---|
| 2163 | %The directory ../source_data contains large source files such as |
---|
| 2164 | %DEMs provided externally as well as MOST tsunami simulations to be used |
---|
| 2165 | %as boundary conditions. |
---|
| 2166 | % |
---|
| 2167 | %Manual steps are: |
---|
| 2168 | % Creation of DEMs from argcview (.asc + .prj) |
---|
| 2169 | % Creation of mesh from pmesh (.tsh) |
---|
| 2170 | % Creation of tsunami simulations from MOST (.nc) |
---|
| 2171 | %% |
---|
| 2172 | % |
---|
| 2173 | %Typical scripted steps are% |
---|
| 2174 | % |
---|
| 2175 | % prepare_dem.py: Convert asc and prj files supplied by arcview to |
---|
| 2176 | % native dem and pts formats% |
---|
| 2177 | % |
---|
| 2178 | % prepare_pts.py: Convert netcdf output from MOST to an sww file suitable |
---|
| 2179 | % as boundary condition% |
---|
| 2180 | % |
---|
| 2181 | % prepare_mesh.py: Merge DEM (pts) and mesh (tsh) using least squares |
---|
| 2182 | % smoothing. The outputs are tsh files with elevation data.% |
---|
| 2183 | % |
---|
| 2184 | % run_simulation.py: Use the above together with various parameters to |
---|
| 2185 | % run inundation simulation. |
---|
| 2186 | |
---|
| 2187 | |
---|
| 2188 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 2189 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 2190 | |
---|
| 2191 | \appendix |
---|
| 2192 | |
---|
| 2193 | \chapter{Supporting Tools} |
---|
| 2194 | \label{ch:supportingtools} |
---|
| 2195 | |
---|
| 2196 | This section describes a number of supporting tools, supplied with \anuga, that offer a |
---|
| 2197 | variety of types of functionality and enhance the basic capabilities of \anuga. |
---|
| 2198 | |
---|
| 2199 | \section{caching} |
---|
| 2200 | \label{sec:caching} |
---|
| 2201 | |
---|
| 2202 | The \code{cache} function is used to provide supervised caching of function |
---|
| 2203 | results. A Python function call of the form |
---|
| 2204 | |
---|
| 2205 | {\small \begin{verbatim} |
---|
| 2206 | result = func(arg1,...,argn) |
---|
| 2207 | \end{verbatim}} |
---|
| 2208 | |
---|
| 2209 | can be replaced by |
---|
| 2210 | |
---|
| 2211 | {\small \begin{verbatim} |
---|
| 2212 | from caching import cache |
---|
| 2213 | result = cache(func,(arg1,...,argn)) |
---|
| 2214 | \end{verbatim}} |
---|
| 2215 | |
---|
| 2216 | which returns the same output but reuses cached |
---|
| 2217 | results if the function has been computed previously in the same context. |
---|
| 2218 | \code{result} and the arguments can be simple types, tuples, list, dictionaries or |
---|
| 2219 | objects, but not unhashable types such as functions or open file objects. |
---|
| 2220 | The function \code{func} may be a member function of an object or a module. |
---|
| 2221 | |
---|
| 2222 | This type of caching is particularly useful for computationally intensive |
---|
| 2223 | functions with few frequently used combinations of input arguments. Note that |
---|
| 2224 | if the inputs or output are very large caching may not save time because |
---|
| 2225 | disc access may dominate the execution time. |
---|
| 2226 | |
---|
| 2227 | If the function definition changes after a result has been cached, this will be |
---|
| 2228 | detected by examining the functions \code{bytecode (co\_code, co\_consts, |
---|
| 2229 | func\_defaults, co\_argcount)} and the function will be recomputed. |
---|
| 2230 | However, caching will not detect changes in modules used by \code{func}. |
---|
| 2231 | In this case cache must be cleared manually. |
---|
| 2232 | |
---|
| 2233 | Options are set by means of the function \code{set\_option(key, value)}, |
---|
| 2234 | where \code{key} is a key associated with a |
---|
| 2235 | Python dictionary \code{options}. This dictionary stores settings such as the name of |
---|
| 2236 | the directory used, the maximum |
---|
| 2237 | number of cached files allowed, and so on. |
---|
| 2238 | |
---|
| 2239 | The \code{cache} function allows the user also to specify a list of dependent files. If any of these |
---|
| 2240 | have been changed, the function is recomputed and the results stored again. |
---|
| 2241 | |
---|
| 2242 | %Other features include support for compression and a capability to \ldots |
---|
| 2243 | |
---|
| 2244 | |
---|
| 2245 | \textbf{USAGE:} \nopagebreak |
---|
| 2246 | |
---|
| 2247 | {\small \begin{verbatim} |
---|
| 2248 | result = cache(func, args, kwargs, dependencies, cachedir, verbose, |
---|
| 2249 | compression, evaluate, test, return_filename) |
---|
| 2250 | \end{verbatim}} |
---|
| 2251 | |
---|
| 2252 | |
---|
| 2253 | \section{swollen} |
---|
| 2254 | \label{sec:swollen} |
---|
| 2255 | The output generated by \anuga may be viewed by |
---|
| 2256 | means of the visualisation tool \code{swollen}, which takes the |
---|
| 2257 | \code{SWW} file output by \anuga and creates a visual representation |
---|
| 2258 | of the data. Examples may be seen in Figures \ref{fig:runupstart} |
---|
| 2259 | and \ref{fig:bedslope2}. To view an \code{SWW} file with |
---|
| 2260 | \code{swollen} in the Windows environment, you can simply drag the |
---|
| 2261 | icon representing the file over an icon on the desktop for the |
---|
| 2262 | \code{swollen} executable file (or a shortcut to it), or set up a |
---|
| 2263 | file association to make files with the extension \code{.sww} open |
---|
| 2264 | with \code{swollen}. Alternatively, you can operate \code{swollen} |
---|
| 2265 | from the command line, in both Windows and Linux environments. |
---|
| 2266 | |
---|
| 2267 | On successful operation, you will see an interactive moving-picture |
---|
| 2268 | display. You can use keys and the mouse to slow down, speed up or |
---|
| 2269 | stop the display, change the viewing position or carry out a number |
---|
| 2270 | of other simple operations. Help is also displayed when you press |
---|
| 2271 | the \code{h} key. |
---|
| 2272 | |
---|
| 2273 | The main keys operating the interactive screen are:\\ |
---|
| 2274 | |
---|
| 2275 | \begin{center} |
---|
| 2276 | \begin{tabular}{|ll|} \hline |
---|
| 2277 | |
---|
| 2278 | \code{w} & toggle wireframe \\ |
---|
| 2279 | |
---|
| 2280 | space bar & start/stop\\ |
---|
| 2281 | |
---|
| 2282 | up/down arrows & increase/decrease speed\\ |
---|
| 2283 | |
---|
| 2284 | left/right arrows & direction in time \emph{(when running)}\\ |
---|
| 2285 | & step through simulation \emph{(when stopped)}\\ |
---|
| 2286 | |
---|
| 2287 | left mouse button & rotate\\ |
---|
| 2288 | |
---|
| 2289 | middle mouse button & pan\\ |
---|
| 2290 | |
---|
| 2291 | right mouse button & zoom\\ \hline |
---|
| 2292 | |
---|
| 2293 | \end{tabular} |
---|
| 2294 | \end{center} |
---|
| 2295 | |
---|
| 2296 | \vfill |
---|
| 2297 | |
---|
| 2298 | The following table describes how to operate swollen from the command line: |
---|
| 2299 | |
---|
| 2300 | Usage: \code{swollen [options] swwfile \ldots}\\ \nopagebreak |
---|
| 2301 | Options:\\ \nopagebreak |
---|
| 2302 | \begin{tabular}{ll} |
---|
| 2303 | \code{--display <type>} & \code{MONITOR | POWERWALL | REALITY\_CENTER |}\\ |
---|
| 2304 | & \code{HEAD\_MOUNTED\_DISPLAY}\\ |
---|
| 2305 | \code{--rgba} & Request a RGBA colour buffer visual\\ |
---|
| 2306 | \code{--stencil} & Request a stencil buffer visual\\ |
---|
| 2307 | \code{--stereo} & Use default stereo mode which is \code{ANAGLYPHIC} if not \\ |
---|
| 2308 | & overridden by environmental variable\\ |
---|
| 2309 | \code{--stereo <mode>} & \code{ANAGLYPHIC | QUAD\_BUFFER | HORIZONTAL\_SPLIT |}\\ |
---|
| 2310 | & \code{VERTICAL\_SPLIT | LEFT\_EYE | RIGHT\_EYE |}\\ |
---|
| 2311 | & \code{ON | OFF} \\ |
---|
| 2312 | \code{-alphamax <float 0-1>} & Maximum transparency clamp value\\ |
---|
| 2313 | \code{-alphamin <float 0-1>} & Transparency value at \code{hmin}\\ |
---|
| 2314 | \end{tabular} |
---|
| 2315 | |
---|
| 2316 | \begin{tabular}{ll} |
---|
| 2317 | \code{-cullangle <float angle 0-90>} & Cull triangles steeper than this value\\ |
---|
| 2318 | \code{-help} & Display this information\\ |
---|
| 2319 | \code{-hmax <float>} & Height above which transparency is set to |
---|
| 2320 | \code{alphamax}\\ |
---|
| 2321 | \end{tabular} |
---|
| 2322 | |
---|
| 2323 | \begin{tabular}{ll} |
---|
| 2324 | |
---|
| 2325 | \code{-hmin <float>} & Height below which transparency is set to |
---|
| 2326 | zero\\ |
---|
| 2327 | \end{tabular} |
---|
| 2328 | |
---|
| 2329 | \begin{tabular}{ll} |
---|
| 2330 | \code{-lightpos <float>,<float>,<float>} & $x,y,z$ of bedslope directional light ($z$ is |
---|
| 2331 | up, default is overhead)\\ |
---|
| 2332 | \end{tabular} |
---|
| 2333 | |
---|
| 2334 | \begin{tabular}{ll} |
---|
| 2335 | \code{-loop} & Repeated (looped) playback of \code{.swm} files\\ |
---|
| 2336 | |
---|
| 2337 | \end{tabular} |
---|
| 2338 | |
---|
| 2339 | \begin{tabular}{ll} |
---|
| 2340 | \code{-movie <dirname>} & Save numbered images to named directory and |
---|
| 2341 | quit\\ |
---|
| 2342 | |
---|
| 2343 | \code{-nosky} & Omit background sky\\ |
---|
| 2344 | |
---|
| 2345 | |
---|
| 2346 | \code{-scale <float>} & Vertical scale factor\\ |
---|
| 2347 | \code{-texture <file>} & Image to use for bedslope topography\\ |
---|
| 2348 | \code{-tps <rate>} & Timesteps per second\\ |
---|
| 2349 | \code{-version} & Revision number and creation (not compile) |
---|
| 2350 | date\\ |
---|
| 2351 | \end{tabular} |
---|
| 2352 | |
---|
| 2353 | \section{utilities/polygons} |
---|
| 2354 | |
---|
| 2355 | \declaremodule{standard}{utilities.polygon} |
---|
| 2356 | \refmodindex{utilities.polygon} |
---|
| 2357 | |
---|
| 2358 | \begin{classdesc}{Polygon\_function}{regions, default = 0.0, geo_reference = None} |
---|
| 2359 | Module: \code{utilities.polygon} |
---|
| 2360 | |
---|
| 2361 | Creates a callable object that returns one of a specified list of values when |
---|
| 2362 | evaluated at a point \code{x, y}, depending on which polygon, from a specified list of polygons, the |
---|
| 2363 | point belongs to. The parameter \code{regions} is a list of pairs |
---|
| 2364 | \code{(P, v)}, where each \code{P} is a polygon and each \code{v} |
---|
| 2365 | is either a constant value or a function of coordinates \code{x} |
---|
| 2366 | and \code{y}, specifying the return value for a point inside \code{P}. The |
---|
| 2367 | optional parameter \code{default} may be used to specify a value |
---|
| 2368 | for a point not lying inside any of the specified polygons. When a |
---|
| 2369 | point lies in more than one polygon, the return value is taken to |
---|
| 2370 | be the value for whichever of these polygon appears later in the |
---|
| 2371 | list. |
---|
| 2372 | %FIXME (Howard): CAN x, y BE VECTORS? |
---|
| 2373 | |
---|
| 2374 | \end{classdesc} |
---|
| 2375 | |
---|
| 2376 | \begin{funcdesc}{read\_polygon}{filename} |
---|
| 2377 | Module: \code{utilities.polygon} |
---|
| 2378 | |
---|
| 2379 | Reads the specified file and returns a polygon. Each |
---|
| 2380 | line of the file must contain exactly two numbers, separated by a comma, which are interpreted |
---|
| 2381 | as coordinates of one vertex of the polygon. |
---|
| 2382 | \end{funcdesc} |
---|
| 2383 | |
---|
| 2384 | \begin{funcdesc}{populate\_polygon}{polygon, number_of_points, seed = None, exclude = None} |
---|
| 2385 | Module: \code{utilities.polygon} |
---|
| 2386 | |
---|
| 2387 | Populates the interior of the specified polygon with the specified number of points, |
---|
| 2388 | selected by means of a uniform distribution function. |
---|
| 2389 | \end{funcdesc} |
---|
| 2390 | |
---|
| 2391 | \begin{funcdesc}{point\_in\_polygon}{polygon, delta=1e-8} |
---|
| 2392 | Module: \code{utilities.polygon} |
---|
| 2393 | |
---|
| 2394 | Returns a point inside the specified polygon and close to the edge. The distance between |
---|
| 2395 | the returned point and the nearest point of the polygon is less than $\sqrt{2}$ times the |
---|
| 2396 | second argument \code{delta}, which is taken as $10^{-8}$ by default. |
---|
| 2397 | \end{funcdesc} |
---|
| 2398 | |
---|
| 2399 | \begin{funcdesc}{inside\_polygon}{points, polygon, closed = True, verbose = False} |
---|
| 2400 | Module: \code{utilities.polygon} |
---|
| 2401 | |
---|
| 2402 | Used to test whether the members of a list of points |
---|
| 2403 | are inside the specified polygon. Returns a Numeric |
---|
| 2404 | array comprising the indices of the points in the list that lie inside the polygon. |
---|
| 2405 | (If none of the points are inside, returns \code{zeros((0,), 'l')}.) |
---|
| 2406 | Points on the edges of the polygon are regarded as inside if |
---|
| 2407 | \code{closed} is set to \code{True} or omitted; otherwise they are regarded as outside. |
---|
| 2408 | \end{funcdesc} |
---|
| 2409 | |
---|
| 2410 | \begin{funcdesc}{outside\_polygon}{points, polygon, closed = True, verbose = False} |
---|
| 2411 | Module: \code{utilities.polygon} |
---|
| 2412 | |
---|
| 2413 | Exactly like \code{inside\_polygon}, but with the words `inside' and `outside' interchanged. |
---|
| 2414 | \end{funcdesc} |
---|
| 2415 | |
---|
| 2416 | \begin{funcdesc}{is\_inside\_polygon}{point, polygon, closed=True, verbose=False} |
---|
| 2417 | Module: \code{utilities.polygon} |
---|
| 2418 | |
---|
| 2419 | Returns \code{True} if \code{point} is inside \code{polygon} or |
---|
| 2420 | \code{False} otherwise. Points on the edges of the polygon are regarded as inside if |
---|
| 2421 | \code{closed} is set to \code{True} or omitted; otherwise they are regarded as outside. |
---|
| 2422 | \end{funcdesc} |
---|
| 2423 | |
---|
| 2424 | \begin{funcdesc}{is\_outside\_polygon}{point, polygon, closed=True, verbose=False} |
---|
| 2425 | Module: \code{utilities.polygon} |
---|
| 2426 | |
---|
| 2427 | Exactly like \code{is\_outside\_polygon}, but with the words `inside' and `outside' interchanged. |
---|
| 2428 | \end{funcdesc} |
---|
| 2429 | |
---|
| 2430 | \begin{funcdesc}{point\_on\_line}{x, y, x0, y0, x1, y1} |
---|
| 2431 | Module: \code{utilities.polygon} |
---|
| 2432 | |
---|
| 2433 | Returns \code{True} or \code{False}, depending on whether the point with coordinates |
---|
| 2434 | \code{x, y} is on the line passing through the points with coordinates \code{x0, y0} |
---|
| 2435 | and \code{x1, y1} (extended if necessary at either end). |
---|
| 2436 | \end{funcdesc} |
---|
| 2437 | |
---|
| 2438 | \begin{funcdesc}{separate\_points\_by\_polygon}{points, polygon, closed = True, verbose = False} |
---|
| 2439 | \indexedcode{separate\_points\_by\_polygon} |
---|
| 2440 | Module: \code{utilities.polygon} |
---|
| 2441 | |
---|
| 2442 | \end{funcdesc} |
---|
| 2443 | |
---|
| 2444 | \begin{funcdesc}{polygon\_area}{polygon} |
---|
| 2445 | Module: \code{utilities.polygon} |
---|
| 2446 | |
---|
| 2447 | Returns area of arbitrary polygon (reference http://mathworld.wolfram.com/PolygonArea.html) |
---|
| 2448 | \end{funcdesc} |
---|
| 2449 | |
---|
| 2450 | \begin{funcdesc}{plot\_polygons}{polygons, figname, verbose = False} |
---|
| 2451 | Module: \code{utilities.polygon} |
---|
| 2452 | |
---|
| 2453 | Plots each polygon contained in input polygon list, e.g. |
---|
| 2454 | \code{polygons = [poly1, poly2, poly3]} where \code{poly1 = [[x11,y11],[x12,y12],[x13,y13]]} |
---|
| 2455 | etc. Each polygon is closed for plotting purposes and subsequent plot saved to \code{figname}. |
---|
| 2456 | Returns list containing the minimum and maximum of \code{x} and \code{y}, |
---|
| 2457 | i.e. \code{[x_{min}, x_{max}, y_{min}, y_{max}]}. |
---|
| 2458 | \end{funcdesc} |
---|
| 2459 | |
---|
| 2460 | \section{coordinate\_transforms} |
---|
| 2461 | |
---|
| 2462 | \section{geospatial\_data} |
---|
| 2463 | |
---|
| 2464 | This describes a class that represents arbitrary point data in UTM |
---|
| 2465 | coordinates along with named attribute values. |
---|
| 2466 | |
---|
| 2467 | %FIXME (Ole): This gives a LaTeX error |
---|
| 2468 | %\declaremodule{standard}{geospatial_data} |
---|
| 2469 | %\refmodindex{geospatial_data} |
---|
| 2470 | |
---|
| 2471 | |
---|
| 2472 | |
---|
| 2473 | \begin{classdesc}{Geospatial\_data} |
---|
| 2474 | {data_points = None, |
---|
| 2475 | attributes = None, |
---|
| 2476 | geo_reference = None, |
---|
| 2477 | default_attribute_name = None, |
---|
| 2478 | file_name = None} |
---|
| 2479 | Module: \code{geospatial\_data} |
---|
| 2480 | |
---|
| 2481 | This class is used to store a set of data points and associated |
---|
| 2482 | attributes, allowing these to be manipulated by methods defined for |
---|
| 2483 | the class. |
---|
| 2484 | |
---|
| 2485 | The data points are specified either by reading them from a NetCDF |
---|
| 2486 | or XYA file, identified through the parameter \code{file\_name}, or |
---|
| 2487 | by providing their \code{x}- and \code{y}-coordinates in metres, |
---|
| 2488 | either as a sequence of 2-tuples of floats or as an $M \times 2$ |
---|
| 2489 | Numeric array of floats, where $M$ is the number of points. |
---|
| 2490 | Coordinates are interpreted relative to the origin specified by the |
---|
| 2491 | object \code{geo\_reference}, which contains data indicating the UTM |
---|
| 2492 | zone, easting and northing. If \code{geo\_reference} is not |
---|
| 2493 | specified, a default is used. |
---|
| 2494 | |
---|
| 2495 | Attributes are specified through the parameter \code{attributes}, |
---|
| 2496 | set either to a list or array of length $M$ or to a dictionary whose |
---|
| 2497 | keys are the attribute names and whose values are lists or arrays of |
---|
| 2498 | length $M$. One of the attributes may be specified as the default |
---|
| 2499 | attribute, by assigning its name to \code{default\_attribute\_name}. |
---|
| 2500 | If no value is specified, the default attribute is taken to be the |
---|
| 2501 | first one. |
---|
| 2502 | \end{classdesc} |
---|
| 2503 | |
---|
| 2504 | |
---|
| 2505 | \begin{methoddesc}{import\_points\_file}{delimiter = None, verbose = False} |
---|
| 2506 | |
---|
| 2507 | \end{methoddesc} |
---|
| 2508 | |
---|
| 2509 | |
---|
| 2510 | \begin{methoddesc}{export\_points\_file}{ofile, absolute=False} |
---|
| 2511 | |
---|
| 2512 | \end{methoddesc} |
---|
| 2513 | |
---|
| 2514 | |
---|
| 2515 | \begin{methoddesc}{get\_data\_points}{absolute = True} |
---|
| 2516 | |
---|
| 2517 | \end{methoddesc} |
---|
| 2518 | |
---|
| 2519 | |
---|
| 2520 | \begin{methoddesc}{set\_attributes}{attributes} |
---|
| 2521 | |
---|
| 2522 | \end{methoddesc} |
---|
| 2523 | |
---|
| 2524 | |
---|
| 2525 | \begin{methoddesc}{get\_attributes}{attribute_name = None} |
---|
| 2526 | |
---|
| 2527 | \end{methoddesc} |
---|
| 2528 | |
---|
| 2529 | |
---|
| 2530 | \begin{methoddesc}{get\_all\_attributes}{} |
---|
| 2531 | |
---|
| 2532 | \end{methoddesc} |
---|
| 2533 | |
---|
| 2534 | |
---|
| 2535 | \begin{methoddesc}{set\_default\_attribute\_name}{default_attribute_name} |
---|
| 2536 | |
---|
| 2537 | \end{methoddesc} |
---|
| 2538 | |
---|
| 2539 | |
---|
| 2540 | \begin{methoddesc}{set\_geo\_reference}{geo_reference} |
---|
| 2541 | |
---|
| 2542 | \end{methoddesc} |
---|
| 2543 | |
---|
| 2544 | |
---|
| 2545 | \begin{methoddesc}{add}{} |
---|
| 2546 | |
---|
| 2547 | \end{methoddesc} |
---|
| 2548 | |
---|
| 2549 | |
---|
| 2550 | \section{pmesh GUI} |
---|
[3499] | 2551 | \emph{Pmesh} |
---|
| 2552 | allows the user to set up the mesh of the problem interactively. |
---|
| 2553 | It can be used to build the outline of a mesh or to visualise a mesh |
---|
| 2554 | automatically generated. |
---|
[3275] | 2555 | |
---|
[3499] | 2556 | Pmesh will let the user select various modes. The current allowable |
---|
| 2557 | modes are vertex, segment, hole or region. The mode describes what |
---|
| 2558 | sort of object is added or selected in response to mouse clicks. When |
---|
| 2559 | changing modes any prior selected objects become deselected. |
---|
| 2560 | |
---|
| 2561 | In general the left mouse button will add an object and the right |
---|
| 2562 | mouse button will select an object. A selected object can de deleted |
---|
| 2563 | by pressing the the middle mouse button (scroll bar). |
---|
| 2564 | |
---|
[3275] | 2565 | \section{alpha\_shape} |
---|
| 2566 | \emph{Alpha shapes} are used to generate close-fitting boundaries |
---|
| 2567 | around sets of points. The alpha shape algorithm produces a shape |
---|
| 2568 | that approximates to the `shape formed by the points'---or the shape |
---|
| 2569 | that would be seen by viewing the points from a coarse enough |
---|
| 2570 | resolution. For the simplest types of point sets, the alpha shape |
---|
| 2571 | reduces to the more precise notion of the convex hull. However, for |
---|
| 2572 | many sets of points the convex hull does not provide a close fit and |
---|
| 2573 | the alpha shape usually fits more closely to the original point set, |
---|
| 2574 | offering a better approximation to the shape being sought. |
---|
| 2575 | |
---|
| 2576 | In \anuga, an alpha shape is used to generate a polygonal boundary |
---|
| 2577 | around a set of points before mesh generation. The algorithm uses a |
---|
| 2578 | parameter $\alpha$ that can be adjusted to make the resultant shape |
---|
| 2579 | resemble the shape suggested by intuition more closely. An alpha |
---|
| 2580 | shape can serve as an initial boundary approximation that the user |
---|
| 2581 | can adjust as needed. |
---|
| 2582 | |
---|
| 2583 | The following paragraphs describe the class used to model an alpha |
---|
| 2584 | shape and some of the important methods and attributes associated |
---|
| 2585 | with instances of this class. |
---|
| 2586 | |
---|
| 2587 | \begin{classdesc}{Alpha\_Shape}{points, alpha = None} |
---|
| 2588 | Module: \code{alpha\_shape} |
---|
| 2589 | |
---|
| 2590 | To instantiate this class the user supplies the points from which |
---|
| 2591 | the alpha shape is to be created (in the form of a list of 2-tuples |
---|
| 2592 | \code{[[x1, y1],[x2, y2]}\ldots\code{]}, assigned to the parameter |
---|
| 2593 | \code{points}) and, optionally, a value for the parameter |
---|
| 2594 | \code{alpha}. The alpha shape is then computed and the user can then |
---|
| 2595 | retrieve details of the boundary through the attributes defined for |
---|
| 2596 | the class. |
---|
| 2597 | \end{classdesc} |
---|
| 2598 | |
---|
| 2599 | |
---|
| 2600 | \begin{funcdesc}{alpha\_shape\_via\_files}{point_file, boundary_file, alpha= None} |
---|
| 2601 | Module: \code{alpha\_shape} |
---|
| 2602 | |
---|
| 2603 | This function reads points from the specified point file |
---|
| 2604 | \code{point\_file}, computes the associated alpha shape (either |
---|
| 2605 | using the specified value for \code{alpha} or, if no value is |
---|
| 2606 | specified, automatically setting it to an optimal value) and outputs |
---|
| 2607 | the boundary to a file named \code{boundary\_file}. This output file |
---|
| 2608 | lists the coordinates \code{x, y} of each point in the boundary, |
---|
| 2609 | using one line per point. |
---|
| 2610 | \end{funcdesc} |
---|
| 2611 | |
---|
| 2612 | |
---|
| 2613 | \begin{methoddesc}{set\_boundary\_type}{self,raw_boundary=True, |
---|
| 2614 | remove_holes=False, |
---|
| 2615 | smooth_indents=False, |
---|
| 2616 | expand_pinch=False, |
---|
| 2617 | boundary_points_fraction=0.2} |
---|
| 2618 | Module: \code{alpha\_shape}, Class: \class{Alpha\_Shape} |
---|
| 2619 | |
---|
| 2620 | This function sets flags that govern the operation of the algorithm |
---|
| 2621 | that computes the boundary, as follows: |
---|
| 2622 | |
---|
| 2623 | \code{raw\_boundary = True} returns raw boundary, i.e. the regular edges of the |
---|
| 2624 | alpha shape.\\ |
---|
| 2625 | \code{remove\_holes = True} removes small holes (`small' is defined by |
---|
| 2626 | \code{boundary\_points\_fraction})\\ |
---|
| 2627 | \code{smooth\_indents = True} removes sharp triangular indents in |
---|
| 2628 | boundary\\ |
---|
| 2629 | \code{expand\_pinch = True} tests for pinch-off and |
---|
| 2630 | corrects---preventing a boundary vertex from having more than two edges. |
---|
| 2631 | \end{methoddesc} |
---|
| 2632 | |
---|
| 2633 | |
---|
| 2634 | \begin{methoddesc}{get\_boundary}{} |
---|
| 2635 | Module: \code{alpha\_shape}, Class: \class{Alpha\_Shape} |
---|
| 2636 | |
---|
| 2637 | Returns a list of tuples representing the boundary of the alpha |
---|
| 2638 | shape. Each tuple represents a segment in the boundary by providing |
---|
| 2639 | the indices of its two endpoints. |
---|
| 2640 | \end{methoddesc} |
---|
| 2641 | |
---|
| 2642 | |
---|
| 2643 | \begin{methoddesc}{write\_boundary}{file_name} |
---|
| 2644 | Module: \code{alpha\_shape}, Class: \class{Alpha\_Shape} |
---|
| 2645 | |
---|
| 2646 | Writes the list of 2-tuples returned by \code{get\_boundary} to the |
---|
| 2647 | file \code{file\_name}, using one line per tuple. |
---|
| 2648 | \end{methoddesc} |
---|
| 2649 | |
---|
| 2650 | \section{Numerical Tools} |
---|
| 2651 | |
---|
| 2652 | The following table describes some useful numerical functions that |
---|
| 2653 | may be found in the module \module{utilities.numerical\_tools}: |
---|
| 2654 | |
---|
| 2655 | \begin{tabular}{|p{8cm} p{8cm}|} \hline |
---|
| 2656 | \code{angle(v1, v2=None)} & Angle between two-dimensional vectors |
---|
| 2657 | \code{v1} and \code{v2}, or between \code{v1} and the $x$-axis if |
---|
| 2658 | \code{v2} is \code{None}. Value is in range $0$ to $2\pi$. \\ |
---|
| 2659 | |
---|
| 2660 | \code{normal\_vector(v)} & Normal vector to \code{v}.\\ |
---|
| 2661 | |
---|
| 2662 | \code{mean(x)} & Mean value of a vector \code{x}.\\ |
---|
| 2663 | |
---|
| 2664 | \code{cov(x, y=None)} & Covariance of vectors \code{x} and \code{y}. |
---|
| 2665 | If \code{y} is \code{None}, returns \code{cov(x, x)}.\\ |
---|
| 2666 | |
---|
| 2667 | \code{err(x, y=0, n=2, relative=True)} & Relative error of |
---|
| 2668 | $\parallel$\code{x}$-$\code{y}$\parallel$ to |
---|
| 2669 | $\parallel$\code{y}$\parallel$ (2-norm if \code{n} = 2 or Max norm |
---|
| 2670 | if \code{n} = \code{None}). If denominator evaluates to zero or if |
---|
| 2671 | \code{y} |
---|
| 2672 | is omitted or if \code{relative = False}, absolute error is returned.\\ |
---|
| 2673 | |
---|
| 2674 | \code{norm(x)} & 2-norm of \code{x}.\\ |
---|
| 2675 | |
---|
| 2676 | \code{corr(x, y=None)} & Correlation of \code{x} and \code{y}. If |
---|
| 2677 | \code{y} is \code{None} returns autocorrelation of \code{x}.\\ |
---|
| 2678 | |
---|
| 2679 | \code{ensure\_numeric(A, typecode = None)} & Returns a Numeric array |
---|
| 2680 | for any sequence \code{A}. If \code{A} is already a Numeric array it |
---|
| 2681 | will be returned unaltered. Otherwise, an attempt is made to convert |
---|
| 2682 | it to a Numeric array. (Needed because \code{array(A)} can |
---|
| 2683 | cause memory overflow.)\\ |
---|
| 2684 | |
---|
| 2685 | \code{histogram(a, bins, relative=False)} & Standard histogram. If |
---|
| 2686 | \code{relative} is \code{True}, values will be normalised against |
---|
| 2687 | the total and thus represent frequencies rather than counts.\\ |
---|
| 2688 | |
---|
| 2689 | \code{create\_bins(data, number\_of\_bins = None)} & Safely create |
---|
| 2690 | bins for use with histogram. If \code{data} contains only one point |
---|
| 2691 | or is constant, one bin will be created. If \code{number\_of\_bins} |
---|
| 2692 | is omitted, 10 bins will be created.\\ \hline |
---|
| 2693 | |
---|
| 2694 | \end{tabular} |
---|
| 2695 | |
---|
| 2696 | |
---|
| 2697 | \chapter{Modules available in \anuga} |
---|
| 2698 | |
---|
| 2699 | |
---|
| 2700 | \section{\module{pyvolution.general\_mesh} } |
---|
| 2701 | \declaremodule[pyvolution.generalmesh]{}{pyvolution.general\_mesh} |
---|
| 2702 | \label{mod:pyvolution.generalmesh} |
---|
| 2703 | |
---|
| 2704 | \section{\module{pyvolution.neighbour\_mesh} } |
---|
| 2705 | \declaremodule[pyvolution.neighbourmesh]{}{pyvolution.neighbour\_mesh} |
---|
| 2706 | \label{mod:pyvolution.neighbourmesh} |
---|
| 2707 | |
---|
| 2708 | \section{\module{pyvolution.domain} --- Generic module for 2D triangular domains for finite-volume computations of conservation laws} |
---|
| 2709 | \declaremodule{}{pyvolution.domain} |
---|
| 2710 | \label{mod:pyvolution.domain} |
---|
| 2711 | |
---|
| 2712 | |
---|
| 2713 | \section{\module{pyvolution.quantity}} |
---|
| 2714 | \declaremodule{}{pyvolution.quantity} |
---|
| 2715 | \label{mod:pyvolution.quantity} |
---|
| 2716 | |
---|
| 2717 | |
---|
| 2718 | Class Quantity - Implements values at each triangular element |
---|
| 2719 | |
---|
| 2720 | To create: |
---|
| 2721 | |
---|
| 2722 | Quantity(domain, vertex_values) |
---|
| 2723 | |
---|
| 2724 | domain: Associated domain structure. Required. |
---|
| 2725 | |
---|
| 2726 | vertex_values: N x 3 array of values at each vertex for each element. |
---|
| 2727 | Default None |
---|
| 2728 | |
---|
| 2729 | If vertex_values are None Create array of zeros compatible with domain. |
---|
| 2730 | Otherwise check that it is compatible with dimenions of domain. |
---|
| 2731 | Otherwise raise an exception |
---|
| 2732 | |
---|
| 2733 | |
---|
| 2734 | |
---|
| 2735 | \section{\module{pyvolution.shallow\_water} --- 2D triangular domains for finite-volume |
---|
| 2736 | computations of the shallow water wave equation. This module contains a specialisation |
---|
| 2737 | of class Domain from module domain.py consisting of methods specific to the Shallow Water |
---|
| 2738 | Wave Equation |
---|
| 2739 | } |
---|
| 2740 | \declaremodule[pyvolution.shallowwater]{}{pyvolution.shallow\_water} |
---|
| 2741 | \label{mod:pyvolution.shallowwater} |
---|
| 2742 | |
---|
| 2743 | |
---|
| 2744 | |
---|
| 2745 | |
---|
| 2746 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
| 2747 | |
---|
| 2748 | \chapter{Frequently Asked Questions} |
---|
| 2749 | |
---|
| 2750 | |
---|
| 2751 | \section{General Questions} |
---|
| 2752 | |
---|
| 2753 | \subsubsection{What is \anuga?} |
---|
| 2754 | |
---|
| 2755 | \subsubsection{Why is it called \anuga?} |
---|
| 2756 | |
---|
| 2757 | \subsubsection{How do I obtain a copy of \anuga?} |
---|
| 2758 | |
---|
| 2759 | \subsubsection{What developments are expected for \anuga in the future?} |
---|
| 2760 | |
---|
| 2761 | \subsubsection{Are there any published articles about \anuga that I can reference?} |
---|
| 2762 | |
---|
| 2763 | \section{Modelling Questions} |
---|
| 2764 | |
---|
| 2765 | \subsubsection{Which type of problems are \anuga good for?} |
---|
| 2766 | |
---|
| 2767 | \subsubsection{Which type of problems are beyond the scope of \anuga?} |
---|
| 2768 | |
---|
| 2769 | \subsubsection{Can I start the simulation at an arbitrary time?} |
---|
| 2770 | Yes, using \code{domain.set\_time()} you can specify an arbitrary |
---|
| 2771 | starting time. This is for example useful in conjunction with a |
---|
| 2772 | file\_boundary, which may start hours before anything hits the model |
---|
| 2773 | boundary. By assigning a later time for the model to start, |
---|
| 2774 | computational resources aren't wasted. |
---|
| 2775 | |
---|
| 2776 | \subsubsection{Can I change values for any quantity during the simulation?} |
---|
| 2777 | Yes, using \code{domain.set\_quantity()} inside the domain.evolve |
---|
| 2778 | loop you can change values of any quantity. This is for example |
---|
| 2779 | useful if you wish to let the system settle for a while before |
---|
| 2780 | assigning an initial condition. Another example would be changing |
---|
| 2781 | the values for elevation to model e.g. erosion. |
---|
| 2782 | |
---|
| 2783 | \subsubsection{Can I change boundary conditions during the simulation?} |
---|
| 2784 | Not sure, but it would be nice :-) |
---|
| 2785 | |
---|
| 2786 | \subsubsection{Why does a file\_function return a list of numbers when evaluated?} |
---|
| 2787 | Currently, file\_function works by returning values for the conserved |
---|
| 2788 | quantities \code{stage}, \code{xmomentum} and \code{ymomentum} at a given point in time |
---|
| 2789 | and space as a triplet. To access e.g.\ \code{stage} one must specify element 0 of the |
---|
| 2790 | triplet returned by file\_function. |
---|
| 2791 | |
---|
| 2792 | \subsubsection{Which diagnostics are available to troubleshoot a simulation?} |
---|
| 2793 | |
---|
| 2794 | \subsubsection{How do I use a DEM in my simulation?} |
---|
| 2795 | You use \code{dem2pts} to convert your DEM to the required .pts format. This .pts file is then called |
---|
| 2796 | when setting the elevation data to the mesh in \code{domain.set_quantity} |
---|
| 2797 | |
---|
| 2798 | \subsubsection{What sort of DEM resolution should I use?} |
---|
| 2799 | Try and work with the \emph{best} you have available. Onshore DEMs |
---|
| 2800 | are typically available in 25m, 100m and 250m grids. Note, offshore |
---|
| 2801 | data is often sparse, or non-existent. |
---|
| 2802 | |
---|
| 2803 | \subsubsection{What sort of mesh resolution should I use?} |
---|
| 2804 | 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, |
---|
| 2805 | 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, |
---|
| 2806 | you need a fine mesh over regions where the DEM changes rapidly, and other areas of significant interest, such as the coast. |
---|
| 2807 | |
---|
| 2808 | |
---|
| 2809 | \subsubsection{How do I tag interior polygons?} |
---|
| 2810 | At the moment create_mesh_from_regions does not allow interior |
---|
| 2811 | polygons with symbolic tags. If tags are needed, the interior |
---|
| 2812 | polygons must be created subsequently. For example, given a filename |
---|
| 2813 | of polygons representing solid walls (in Arc Ungenerate format) can |
---|
| 2814 | be tagged as such using the code snippet: |
---|
| 2815 | \begin{verbatim} |
---|
| 2816 | # Create mesh outline with tags |
---|
| 2817 | mesh = create_mesh_from_regions(bounding_polygon, |
---|
| 2818 | boundary_tags=boundary_tags) |
---|
| 2819 | # Add buildings outlines with tags set to 'wall'. This would typically |
---|
| 2820 | # bind to a Reflective boundary |
---|
| 2821 | mesh.import_ungenerate_file(buildings_filename, tag='wall') |
---|
| 2822 | |
---|
| 2823 | # Generate and write mesh to file |
---|
| 2824 | mesh.generate_mesh(maximum_triangle_area=max_area) |
---|
| 2825 | mesh.export_mesh_file(mesh_filename) |
---|
| 2826 | \end{verbatim} |
---|
| 2827 | |
---|
| 2828 | Note that a mesh object is returned from \code{create_mesh_from_regions} |
---|
| 2829 | when file name is omitted. |
---|
| 2830 | |
---|
| 2831 | \subsubsection{How often should I store the output?} |
---|
| 2832 | 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 |
---|
| 2833 | to look in detail at the evolution, then you will need to balance your storage requirements and the duration of the simulation. |
---|
| 2834 | 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 |
---|
| 2835 | quantities on a mesh with approximately 300000 triangles on a 2 min interval for 5 hours will result in approximately 350Mb SWW file |
---|
| 2836 | (as for the \file{run\_sydney\_smf.py} example). |
---|
| 2837 | |
---|
| 2838 | \subsection{Boundary Conditions} |
---|
| 2839 | |
---|
| 2840 | \subsubsection{How do I create a Dirichlet boundary condition?} |
---|
| 2841 | |
---|
| 2842 | A Dirichlet boundary condition sets a constant value for the |
---|
| 2843 | conserved quantities at the boundaries. A list containing |
---|
| 2844 | the constant values for stage, xmomentum and ymomentum is constructed |
---|
| 2845 | and used in the function call, e.g. \code{Dirichlet_boundary([0.2,0.,0.])} |
---|
| 2846 | |
---|
| 2847 | \subsubsection{How do I know which boundary tags are available?} |
---|
| 2848 | The method \code{domain.get\_boundary\_tags()} will return a list of |
---|
| 2849 | available tags for use with |
---|
| 2850 | \code{domain.set\_boundary\_condition()}. |
---|
| 2851 | |
---|
| 2852 | |
---|
| 2853 | |
---|
| 2854 | |
---|
| 2855 | |
---|
| 2856 | \chapter{Glossary} |
---|
| 2857 | |
---|
| 2858 | \begin{tabular}{|lp{10cm}|c|} \hline |
---|
| 2859 | %\begin{tabular}{|llll|} \hline |
---|
| 2860 | \emph{Term} & \emph{Definition} & \emph{Page}\\ \hline |
---|
| 2861 | |
---|
| 2862 | \indexedbold{\anuga} & Name of software (joint development between ANU and |
---|
| 2863 | GA) & \pageref{def:anuga}\\ |
---|
| 2864 | |
---|
| 2865 | \indexedbold{bathymetry} & offshore elevation &\\ |
---|
| 2866 | |
---|
| 2867 | \indexedbold{conserved quantity} & conserved (stage, x and y |
---|
| 2868 | momentum) & \\ |
---|
| 2869 | |
---|
| 2870 | % \indexedbold{domain} & The domain of a function is the set of all input values to the |
---|
| 2871 | % function.&\\ |
---|
| 2872 | |
---|
| 2873 | \indexedbold{Digital Elevation Model (DEM)} & DEMs are digital files consisting of points of elevations, |
---|
| 2874 | sampled systematically at equally spaced intervals.& \\ |
---|
| 2875 | |
---|
| 2876 | \indexedbold{Dirichlet boundary} & A boundary condition imposed on a differential equation |
---|
| 2877 | that specifies the values the solution is to take on the boundary of the |
---|
| 2878 | domain. & \pageref{def:dirichlet boundary}\\ |
---|
| 2879 | |
---|
| 2880 | \indexedbold{edge} & A triangular cell within the computational mesh can be depicted |
---|
| 2881 | as a set of vertices joined by lines (the edges). & \\ |
---|
| 2882 | |
---|
| 2883 | \indexedbold{elevation} & refers to bathymetry and topography &\\ |
---|
| 2884 | |
---|
| 2885 | \indexedbold{evolution} & integration of the shallow water wave equations |
---|
| 2886 | over time &\\ |
---|
| 2887 | |
---|
| 2888 | \indexedbold{finite volume method} & The method evaluates the terms in the shallow water |
---|
| 2889 | wave equation as fluxes at the surfaces of each finite volume. Because the |
---|
| 2890 | flux entering a given volume is identical to that leaving the adjacent volume, |
---|
| 2891 | these methods are conservative. Another advantage of the finite volume method is |
---|
| 2892 | that it is easily formulated to allow for unstructured meshes. The method is used |
---|
| 2893 | in many computational fluid dynamics packages. & \\ |
---|
| 2894 | |
---|
| 2895 | \indexedbold{forcing term} & &\\ |
---|
| 2896 | |
---|
| 2897 | \indexedbold{flux} & the amount of flow through the volume per unit |
---|
| 2898 | time & \\ |
---|
| 2899 | |
---|
| 2900 | \indexedbold{grid} & Evenly spaced mesh & \\ |
---|
| 2901 | |
---|
| 2902 | \indexedbold{latitude} & The angular distance on a mericlear north and south of the |
---|
| 2903 | equator, expressed in degrees and minutes. & \\ |
---|
| 2904 | |
---|
| 2905 | \indexedbold{longitude} & The angular distance east or west, between the meridian |
---|
| 2906 | of a particular place on Earth and that of the Prime Meridian (located in Greenwich, |
---|
| 2907 | England) expressed in degrees or time.& \\ |
---|
| 2908 | |
---|
| 2909 | \indexedbold{Manning friction coefficient} & &\\ |
---|
| 2910 | |
---|
| 2911 | \indexedbold{mesh} & Triangulation of domain &\\ |
---|
| 2912 | |
---|
| 2913 | \indexedbold{mesh file} & A TSH or MSH file & \pageref{def:mesh file}\\ |
---|
| 2914 | |
---|
| 2915 | \indexedbold{NetCDF} & &\\ |
---|
| 2916 | |
---|
| 2917 | \indexedbold{northing} & A rectangular (x,y) coordinate measurement of distance |
---|
| 2918 | north from a north-south reference line, usually a meridian used as the axis of |
---|
| 2919 | origin within a map zone or projection. Northing is a UTM (Universal Transverse |
---|
| 2920 | Mercator) coordinate. & \\ |
---|
| 2921 | |
---|
| 2922 | \indexedbold{points file} & A PTS or XYA file & \\ \hline |
---|
| 2923 | |
---|
| 2924 | \end{tabular} |
---|
| 2925 | |
---|
| 2926 | \begin{tabular}{|lp{10cm}|c|} \hline |
---|
| 2927 | |
---|
| 2928 | \indexedbold{polygon} & A sequence of points in the plane. \anuga represents a polygon |
---|
| 2929 | either as a list consisting of Python tuples or lists of length 2 or as an $N \times 2$ |
---|
| 2930 | Numeric array, where $N$ is the number of points. |
---|
| 2931 | |
---|
| 2932 | The unit square, for example, would be represented either as |
---|
| 2933 | \code{[ [0,0], [1,0], [1,1], [0,1] ]} or as \code{array( [0,0], [1,0], [1,1], |
---|
| 2934 | [0,1] )}. |
---|
| 2935 | |
---|
| 2936 | NOTE: For details refer to the module \module{utilities/polygon.py}. & |
---|
| 2937 | \\ \indexedbold{resolution} & The maximal area of a triangular cell in a |
---|
| 2938 | mesh & \\ |
---|
| 2939 | |
---|
| 2940 | |
---|
| 2941 | \indexedbold{reflective boundary} & Models a solid wall. Returns same conserved |
---|
| 2942 | quantities as those present in the neighbouring volume but reflected. Specific to the |
---|
| 2943 | shallow water equation as it works with the momentum quantities assumed to be the |
---|
| 2944 | second and third conserved quantities. & \pageref{def:reflective boundary}\\ |
---|
| 2945 | |
---|
| 2946 | \indexedbold{stage} & &\\ |
---|
| 2947 | |
---|
| 2948 | % \indexedbold{try this} |
---|
| 2949 | |
---|
| 2950 | \indexedbold{swollen} & visualisation tool used with \anuga & \pageref{sec:swollen}\\ |
---|
| 2951 | |
---|
| 2952 | \indexedbold{time boundary} & Returns values for the conserved |
---|
| 2953 | quantities as a function of time. The user must specify |
---|
| 2954 | the domain to get access to the model time. & \pageref{def:time boundary}\\ |
---|
| 2955 | |
---|
| 2956 | \indexedbold{topography} & onshore elevation &\\ |
---|
| 2957 | |
---|
| 2958 | \indexedbold{transmissive boundary} & & \pageref{def:transmissive boundary}\\ |
---|
| 2959 | |
---|
| 2960 | \indexedbold{vertex} & A point at which edges meet. & \\ |
---|
| 2961 | |
---|
| 2962 | \indexedbold{xmomentum} & conserved quantity (note, two-dimensional SWW equations say |
---|
| 2963 | only \code{x} and \code{y} and NOT \code{z}) &\\ |
---|
| 2964 | |
---|
| 2965 | \indexedbold{ymomentum} & conserved quantity & \\ \hline |
---|
| 2966 | |
---|
| 2967 | \end{tabular} |
---|
| 2968 | |
---|
| 2969 | |
---|
| 2970 | %The \code{\e appendix} markup need not be repeated for additional |
---|
| 2971 | %appendices. |
---|
| 2972 | |
---|
| 2973 | |
---|
| 2974 | % |
---|
| 2975 | % The ugly "%begin{latexonly}" pseudo-environments are really just to |
---|
| 2976 | % keep LaTeX2HTML quiet during the \renewcommand{} macros; they're |
---|
| 2977 | % not really valuable. |
---|
| 2978 | % |
---|
| 2979 | % If you don't want the Module Index, you can remove all of this up |
---|
| 2980 | % until the second \input line. |
---|
| 2981 | % |
---|
| 2982 | |
---|
| 2983 | %begin{latexonly} |
---|
| 2984 | %\renewcommand{\indexname}{Module Index} |
---|
| 2985 | %end{latexonly} |
---|
| 2986 | \input{mod\jobname.ind} % Module Index |
---|
| 2987 | % |
---|
| 2988 | %begin{latexonly} |
---|
| 2989 | %\renewcommand{\indexname}{Index} |
---|
| 2990 | %end{latexonly} |
---|
| 2991 | \input{\jobname.ind} % Index |
---|
| 2992 | |
---|
| 2993 | |
---|
| 2994 | |
---|
| 2995 | \begin{thebibliography}{99} |
---|
| 2996 | \bibitem[nielsen2005]{nielsen2005} |
---|
| 2997 | {\it Hydrodynamic modelling of coastal inundation}. |
---|
| 2998 | Nielsen, O., S. Roberts, D. Gray, A. McPherson and A. Hitchman. |
---|
| 2999 | In Zerger, A. and Argent, R.M. (eds) MODSIM 2005 International Congress on |
---|
| 3000 | Modelling and Simulation. Modelling and Simulation Society of Australia and |
---|
| 3001 | New Zealand, December 2005, pp. 518-523. ISBN: 0-9758400-2-9.\\ |
---|
| 3002 | http://www.mssanz.org.au/modsim05/papers/nielsen.pdf |
---|
| 3003 | |
---|
| 3004 | |
---|
| 3005 | |
---|
| 3006 | |
---|
| 3007 | \end{thebibliography}{99} |
---|
| 3008 | |
---|
| 3009 | \end{document} |
---|