source: inundation/wiki/requirements.txt @ 2113

Requirements for the Storm Surge Model:
-------------------------------------


(So far these are merely questions, that should crystallise into a
common view and a proper list of requirements).

GENERAL:

We are required to deliver a Single processor version of the Storm
Surge hazard model, integrating the Storm Surge model, animation,
pMesh, examples and a case study. This will be delivered on April 2005.

How do we want users to be able to interact with this model?  What are
the requirements of the user interface?  

We have a current interface the consists of pmesh and its graphical 
user interface as well as the pyvolution library (domain, 
shallow_water and pmesh.mesh) - with each scenario 
currently controlled by a short scripts.  
What additional functionality do we need/want/desire in the 
April deliverable?  Also, how do we want to change the current interfaces?

If we gather these requirements and prioritise them it will clarify
what should be implemented.


REQUIREMENT QUESTIONS (Storm Surge):
------------------------------------

Scenarios:
Please think up some scenarios a la
1  "The software shall allow the user to run a simulation using a coarse grid,
   then perform some local refinement of specific regions and then run again
   iteratively until a suitable mesh has been developed."

2  "The software shall then allow the user to increase the resolution
   of the adapted mesh by a common factor such that the ratio between 
   fine and course parts remains constant. 

   
How to set up a simulation:
    The following components are required:
        A triangular mesh (e.g. domain) detailing
          - location of vertices
        Bed elevation, friction, stage and x, y momentum at vertices
    or described by function inputting x and y.
        Specific boundary conditions applied to various segments
        Forcing terms
        Various control parameters such as order

   What else?
   And how do we want to manage these components?

   Should pmesh have the option of supplying the stage, bed
   elevation and/or friction values?  How user friendly should this
   be?  Currently there is a function which assumes the first
   attribute is bed elevation, 2nd is stage and third is friction.
   
   Should the parameters of a boundary condition be able to be set in
   pmesh?
   
   Should regional attributes from pmesh be able to change field
   conditions and conserved quantities? How user friendly should this
   be?
   
   Should pmesh show segment tag names to which a boundary object has
   been attached?  I.e. should pmesh load a dictionary of boundary
   objects indexed by tags, and show/let the user select the known
   tags?  The tags would be words, rather than integers.
   

Data flow
     How should data flow from initial datasets, 

     E.g. 
     Data -> cleaning -> preprocessing -> mesh generation -> 
     application of boundary, initial conditions and forcing terms ->
     Simulation (check pointing, parallelism) ->
     Actions at every yield (e.g. save data, apply building impacts, viz) ->
     
     Visualise and post-process model data.

     
Other:
     What is the need for casting boundary conditions and initial conditions 
     in terms of height (h) as well as stage (w=z+h) -
     stage being the conserved quantitity which can be set directly.

     What is the need for setting initial conditions and boundary conditions 
     as functions in terms of x and y?            

Specifics:
    
    Output statistics about #volumes, min/max area/edgelengts, specified 
    max_speed and derived minimal timestep.