Changeset 3225


Ignore:
Timestamp:
Jun 26, 2006, 9:42:35 AM (18 years ago)
Author:
duncan
Message:

adding damage requirements

File:
1 edited

Legend:

Unmodified
Added
Removed
  • documentation/requirements/anuga_API_requirements.tex

    r3060 r3225  
    4848\chapter{Public API}           
    4949\section{General principles}   
    50  The ANUGA API must be simple to use.
    51 Operations that are conceptually simple should be easy to do. An example would be setting up a small test problem on a unit square without any geographic orientation.
    52 Complex operations should be manageable and not require the user to enter information that isn't strictly part of the problem description. Examples are entering UTM coordinates (or geographic coordinates) as read from a map should not require any reference to a particular origin.
    53 Nor should the same information have to be entered more than once per scenario.
     50
     51 The ANUGA API must be simple to use.  Operations that are
     52conceptually simple should be easy to do. An example would be setting
     53up a small test problem on a unit square without any geographic
     54orientation.  Complex operations should be manageable and not require
     55the user to enter information that isn't strictly part of the problem
     56description. Examples are entering UTM coordinates (or geographic
     57coordinates) as read from a map should not require any reference to a
     58particular origin.  Nor should the same information have to be entered
     59more than once per scenario.
    5460
    5561
     
    5864
    5965Currently ANUGA is limited to UTM coordinates assumed to belong to one zone.
    60 ANUGA shall throw an exeption if this assumption is violated.
     66ANUGA shall throw an exception if this assumption is violated.
    6167
    6268It must be possible in general to enter data points as
     
    7783    not exist geographically.
    7884
    79   \item Any component that needs coordinates to be relative to a particular point shall be responsible for deriving that origin. Examples are meshes where absolute coordinates may cause numerical problems. An example of a derived origin would be using the South-West most point on the boundary.
     85  \item Any component that needs coordinates to be relative to a
     86  particular point shall be responsible for deriving that
     87  origin. Examples are meshes where absolute coordinates may cause
     88  numerical problems. An example of a derived origin would be using
     89  the South-West most point on the boundary.
    8090
    8191  \item Coordinates must be passed around as either geospatial objects
     
    8696  it is currently done, it doesn't have to be
    8797  changed as a matter of priority, but don't document this 'feature'
    88   in the user manual.  If you are refactoring this API, then plase
     98  in the user manual.  If you are refactoring this API, then please
    8999  remove geo_reference as a keyword.
    90100 
     
    94104 
    95105\chapter{Internal API}
     106
     107\section{Damage Model - Requirements}
     108Generally, damage model determines a percentage damage to a set of
     109structures and their content.
     110The dollar loss for each structure and its contents due to this damage
     111is then determined.
     112
     113The damage model used in ANUGA is expected to change. The requirements
     114for this damage model is based on three algorithms.
     115
     116 
     117\begin{itemize}
     118  \item Probability of structural collapse.  Given the distance from
     119  the coast and the inundation height above ground floor, the
     120  percentage probability of collapse is calculated.  The distance from
     121  the coast is
     122  'binned' into one of 4 distance ranges.  The height in binned into
     123  one of 5 ranges.  The percentage result is therefore represented by
     124  a 4 by 5 array.
     125  \item Structural damage curve.  Given the type of building (X or Y)
     126  and the inundation height above ground floor, the
     127  percentage damage loss to the structure is determined.  The curve is
     128  based on a set of [height, percentage damage] points. 
     129  \item Content damage curve.  Given the inundation height above
     130  ground floor, the
     131  percentage damage loss to the content of each structure is
     132  determined.  The curve is based on a set of [height, percentage
     133  damage] points. 
     134\end{itemize} 
     135Interpolate between points when using the damage curves.
     136
     137
     138The national building exposure database (NBED) gives the following relevant
     139information for each structure;
     140\begin{itemize}
     141  \item Location, Latitude and Longitude.
     142  \item The total cost of the structure.
     143  \item The total cost of the structures contents.
     144  \item The building type  (Have to check how this is given).
     145\end{itemize} 
     146This information is given in a csv file. Each row is a structure.
     147 
     148So how will these dry algorithms (look-up tables) be used? 
     149Given NBED, an sww and an assumed ground floor height the percent
     150structure and content loss and probability of collapse can be determined.
     151 
     152The probability of collapse will be used in a way to have each
     153structure either collapsed, or not not collapsed.  There will not be
     154any 20\% probablity of collapse structures when calculating the damage
     155loss.
     156
     157This is we will get either collapsed, or not not collapsed from a
     158probability of collapse;
     159\begin{itemize}
     160  \item Count the number of houses (sample size) with each unique
     161 probability of collapse (excluding 0).
     162  \item probability of collapse * sample size = Number of collapsed
     163  buildings (NCB).
     164  \item Round the number of collapsed buildings.
     165  \item Randomly 'collapse' NCB buildings, from the sample structures.
     166  This is done by setting the \% damage loss to structures and content
     167  to 100.  This overrides losses calculated from the curves.   
     168\end{itemize} 
     169 
     170What is the final output?
     171Add these columns to the NBED file.
     172\begin{itemize}
     173  \item \% content damage
     174  \item \% structure damage
     175  \item damage cost to content
     176  \item damage cost to structure
     177\end{itemize}   
     178
     179How will the ground floor height be given?
     180Have it passed as a keyword argument, defaulting to .3.
     181
     182\section{Damage Model - Design}
     183It has to be modular.  In the future the three algorithms will be
     184combined to give a cumulative probability distribution, so this part
     185doesn't have to be designed to be too flexible.
     186
    96187
    97188
     
    109200  \item a function for re-assembling model output should be made available
    110201  \item scoping of methodologies for automatic domain decomposition
    111   \item implementation of automatic domain decomposition
    112     (using C extensions for maximal sequential performance in order to minimise
     202  \item implementation of automatic domain decomposition (using C
     203    extensions for maximal sequential performance in order to minimise
    113204    performance penalties due to Amdahl's law)
    114   \item in depth testing and tuning of parallel performane. This may require
     205  \item in depth testing and tuning of parallel performance. This may require
    115206    adding wrappers for non-blocking MPI communication to pypar if needed.   
    116207  \item ability to read in precomputed sub-domains. Perhaps using caching.py 
Note: See TracChangeset for help on using the changeset viewer.