source: inundation/ga/storm_surge/wiki/future_directions.txt @ 1574

Last change on this file since 1574 was 1574, checked in by ole, 20 years ago
File size: 4.7 KB
RevLine 
[1572]1ANUGA Future Directions (2005-2006)
2
3
4--------------------------------------------------
5Draft of known issues regarding the ANUGA software
6--------------------------------------------------
7
8
9----------------
10Numerical issues
11
12CFL condition (centroid-midpt distances versus inscribed circle ? or error estimator)
13Gradient limiters
14Forcing terms:
15    Friction of Mud
16    Viscosity
17
18
19
20--------------------
21Functionality issues
22
23Mesh generation:
24    Through graphical generator
25    Through scripts
26    Alternative triangulators (Strang, ?.)
27    alpha-shapes
28
29refactoring triangle interface
30outputting a ?triangle? readable file (from pmesh?)
31
32  from pmesh issues file:
33      Main issues  (TBA) 
34
35Georeferencing
36  Code works in UTM coordinates. Zone boundaries cannot be crossed
37  Could code be cast in terms of lat/lons?
38
39least_squares, use of quad-tree may not use all datapoints
40        (currently fixed by expand search, need algorithm for searching neighbouring    treenodes)
41
42        Give feedback when
43                points outside mesh
44                mesh outside points boundary
45
46        use sparse matrix (CSR) format in ?build_interpolation_matrix_A?
47        simplify geo-referencing
48
49Checkpointing (largely done but needs to be revisited)
50
51Ability to create additional quantities and initialise arbitrarily
52 
53FIXMEs (TBA)
54
55
56File management (msh, pts, dem, ..) ? introduce the notion of a project
57 - reduce # of methods that read/write sww files (Yes)
58
59 
60-----------------
61Efficiency issues
62
63Parallelisation
64
65Edgefluxes are currently computed twice (f01 = -f10)
66(This has been fixed by Matt Hardy)
67
68Increase Timesteps (Implicit techniques?)
69
70Optimise creation and importing of domains (C-code and caching)
71
72
73------------
74Architecture
75
76Settle dataflows and formats (pts, dem, msh, sww, etc)
77 
78?finaltime? to be renamed ?duration?
79
80
81----
82API:
83
84Suggestion for set_quantity
85      set_quantity(name, X, location, region)
86   where
87        name: Name of quantity
88      X:
89                -Compatible list,
90              -Numeric array,
91              -constant
92                -callable object (f: x, y -> z) where x,y,z are arrays
93                        - inline
94                        - file functions
95                        - polygon functions
96              -another quantity Q or an expression of the form
97    a*Q+b*R+c, where
98        a,b,c are scalars, arrays or quantities
99                        Q,R are quantities (or 1?)
100                - list of points with attribute values (use LS)
101                - pts filename (use LS and caching)           
102                - general expression to be parsed   
103
104        location: Where values are to be stored.
105Permissible options are: vertices, edges, centroid,    unique_vertices
106        region: Identify subset of triangles. Permissible values are
107                  - tag name (refers to tagged region)
108                    - indices (refers to specific triangles)
109                    - polygon (identifies region)
110                (incorporate uniqueness/non-uniqueness)
111           
112
113Making methods private, using _private
114Or write the API in a separate module.
115
116
117Make stage appear as any other quantity:
118Either
119   1: Make stage a subclass of quantity having knowledge of elevation and a special 
120       limiter (or more limiters)
121Or
122   2: Equip each quantity with a limiter class
123      (Con: A limiter for stage should never be applied to any other quantity)
124
125
126Also, investigate if Quantity and Conserved_quantity should be one class (Steve).
127
[1574]128Finally, reconcile the optimised gradient limiter of Matt's with the more general framework
[1572]129
[1574]130
131
[1572]132------
133Other:
134
135Should we remove Python code superseded by C-extensions?
136  Pros:   Leaner code and no risk
137  Cons:  Less readable algorithms
138
139Move py code into files such as quantity_ext.py and have python wrappers with doc strings for all functions. Name the code in extensions _ext and conditional import as usual.
140
141
142-------------
143Visualisation
144
145Swollen:
146        Export to movie
147        Use maps
148        Colourcoding
149        z-scale
150
151Matplotlib:
152        Realtime and ?post mortem? generation of colour coded maps with         contourlines.
153
154Visual Python:
155        Steves new and improved tool
156
157
158
159-----------
160Development
161
162Restructuring and moving svn repository
163
164Flatten directory structure
165
166Apply buildbot
167
168Use real bugtracking/project management tool
169(see http://www.generalconcepts.com/resources/tracking, plone, basecamp,?
170Try out TRAC which integrates into subversion
171
172Zeus?
173
174
175--------------
176Documentation
177
178Hire technical writer to produce
179- Getting started
180- User guide
181- Reference manual ? semi automated
182
183Mathematical model description  (Steve & Chris)
184
185
186-----------------
187Validation and QA
188
189Merimbula (Steve & Chris)
190PNG Landslide study or watertank data (Adrian?)
191BOM
192SMEC
193CSIRO
194
195
196--------
197Naming
198
199The collection as well as individual modules may benefit from better names.
200
201
202--------
203Release
204
205Search for appropriate procedure for OSS release (Ole is onto that with AGIMO)
206
207
208
Note: See TracBrowser for help on using the repository browser.