source: inundation/wiki/future_directions.txt @ 1841

Last change on this file since 1841 was 1841, checked in by ole, 19 years ago

Comments

File size: 8.3 KB
Line 
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: (Duncan)
24    Through graphical generator
25    Through scripts
26    Alternative triangulators (Strang, ?.)
27    alpha-shapes
28   
29
30   refactoring triangle interface
31   outputting a "triangle" readable file (from pmesh?)
32   
33   simple method in mesh factory that will convert regularly gridded data to mesh using
34   points as vertices
35
36Pmesh (Duncan)
37    - from pmesh issues file:
38        Main issues  (TBA) 
39     
40- Better API for handling (scripted) meshes:
41        *Error messages
42        *Refined regions should be specified easily
43        *Ways of handling different point sets (e.g. 10m, 100m, 250m)
44         and populate according to refinement of mesh
45         (wavelets or other adaptive method)
46         
47     
48Georeferencing
49  Code works in UTM coordinates. Zone boundaries cannot be crossed:
50  Introduce nonstandard central meridians if necessary
51 
52  Could code be cast in terms of lat/lons?
53  make sure that georeferencing is used consistently (domain, pmesh, sww files, ...) (Duncan) 
54  Test that least_squares (and elsewhere) correctly reconciles different georefs. (See Karratha)
55
56Least_squares, (Duncan)
57        use of quad-tree may not use all datapoints
58        (currently fixed by expand search, need algorithm for searching neighbouring treenodes) (TRAC)
59
60        Give feedback when
61                points outside mesh
62                mesh outside points boundary  !
63                if mesh is corrupted (see lwru2.py and create_mesh.py in debug dir)
64                if segments are repeated (maybe in mesh.check_integrity) (TRAC)   
65
66        use sparse matrix (CSR) format in "build_interpolation_matrix_A" (TRAC)
67       
68        simplify geo-referencing (make sure that coordinate changes 'change_points' are
69        used everywhere) (TRAC)
70       
71        memory issue: !  (TRAC)
72                If LS is used for fitting
73                    compute self.Atz and self AtA directly and avoid self.A.
74                    need alpha
75                If LS is to be used for interpolation
76                    compute self.A
77                    no alpha needed
78               
79               
80               
81refactor interpolate_sww in terms of Interpolation_function (Ole or Duncan)
82
83               
84Checkpointing (largely done but needs to be revisited)
85
86
87Ability to create additional quantities and initialise arbitrarily
88 
89FIXMEs (TBA)
90
91
92File management (msh, pts, dem, ..) - introduce the notion of a project
93
94Reduce # of methods that read/write sww files (Yes)
95
96 
97-----------------
98Efficiency issues
99
100Parallelisation (First cut is done)
101
102Edgefluxes are currently computed twice (f01 = -f10)
103(This has been fixed by Matt Hardy in June 2005)
104
105Increase Timesteps (Implicit techniques?)
106
107Optimise creation and importing of domains (C-code and caching)  (Ole)
108Caching needs optional arguments: bypass_args and bypass_kwargs.
109These should be passed onto the function when it is evaluated but not participate in the hashing.
110Rationale: Some arguments such as classes change their signature at every run and thus cause the functin to be evaluated every time, defeating the purpose of caching.
111
112
113
114------------
115Architecture
116
117Settle dataflows and formats (pts, dem, msh, sww, etc) (Ole)
118 
119finaltime to be renamed duration
120
121
122----
123API:
124
125Suggestion for set_quantity
126      set_quantity(name, X, location, region)
127      where
128      name: Name of quantity
129      X:
130              -Compatible list,
131                -compatible list or numeric array,
132                -constant
133                -list of points or array with attribute values (use LS) (How to distinguish this from a numeric array? - perhaps use keyword arguments for everything)
134                -callable object (f: x, y -> z) where x,y,z are arrays
135                        - inline
136                        - file functions
137                        - polygon functions
138                -another quantity Q or an expression of the form
139                   a*Q+b*R+c, where       
140                   a,b,c are scalars, arrays or quantities
141                   Q,R are quantities (or 1?)
142                - pts filename (use LS and caching) (how to select attribute?)
143                - general expression to be parsed   
144
145        location: Where values are to be stored.
146                Permissible options are: vertices, edges, centroid, unique_vertices
147        region: Identify subset of triangles. Permissible values are
148                  - tag name (refers to tagged region)
149                    - indices (refers to specific triangles)
150                    - polygon (identifies region)
151                (incorporate uniqueness/non-uniqueness)
152           
153
154        IDEA for set_quantity:
155              Use keywords and call underlying specific method, e.g.
156             
157              if filename is not None:
158                 vertex_values = caching( fitfunc, filename, dependencies = ...)
159                 set_quantity(..., ..., vertex_values)
160              elif:
161             
162        Largely done.
163        Should create class Point_set representing points and attribute(s)
164        Include filename too? Yep (and selected attributes)
165        This could also facilitate use of multiple point sources
166        (e.g. at different resolutions)
167       
168        (IN TRAC now)
169       
170             
171           
172Making methods private, using _private
173Or write the API in a separate module.
174
175
176Introduce create_quantity in domain.py: (Ole)
177  It will make a new named instance and populate it by calling set_quantity
178  if desired.
179  Create_quantity would be called automatically by shallow_water.         
180 
181
182Make stage appear as any other quantity:
183Either
184   1: Make stage a subclass of quantity having knowledge of elevation and a special 
185       limiter (or more limiters)
186Or
187   2: Equip each quantity with a limiter class
188      (Con: A limiter for stage should never be applied to any other quantity)
189
190
191Also, investigate if Quantity and Conserved_quantity should be one class (Steve).
192
193Finally, reconcile the optimised gradient limiter of Matt's with the more general framework
194
195
196
197
198Boundary (Dirichlet): Think about specifying values by quantity name (and having defaults)
199     Dirichlet(stage = 1.0, ymomentum = 0.2)
200     
201Finish MOST2SWW with bathymetry(Trevor)     
202
203Make Steve's new boundary spatially dependent (Ole)
204
205Look at matplotlib's verbosity object.
206
207
208------
209Other:
210
211Should we remove Python code superseded by C-extensions?
212  Pros:   Leaner code and no risk
213  Cons:  Less readable algorithms
214
215Move 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.
216
217Generally separate file_format stuff from functionality (and work with a small number of formats)
218
219
220Have a .tms format for straight timeseries, use sww for f(t,x,y).
221Modify Interpolation function and file_function accordingly. (Use lwru2.py as test bed) (Ole)
222
223
224-------------
225Visualisation
226
227Swollen:
228        Export to movie
229        Use maps
230        Colourcoding
231        z-scale
232
233Matplotlib:
234        Realtime and 'post mortem' generation of colour coded maps with         contourlines.
235        Also useful for graphs
236
237Visual Python:
238        Steves new and improved tool
239
240
241       
242-----------
243Installation and setup
244
245- Assume that root dir for AnuGA is on Pythonpath. That way the same code can work with
246  sandpits and final installation
247- need installers for all modules       
248- pmesh needs a compile.py that will compile triangle whan used from a sandpit.
249  Currently it seems one needs a full setup to use pmesh
250
251 
252-----------
253Development
254
255Restructuring and moving svn repository (Ole)
256
257Flatten directory structure (Ole or DUncan)
258
259Apply buildbot
260
261Use real bugtracking/project management tool
262(see http://www.generalconcepts.com/resources/tracking, plone, basecamp,?
263Try out TRAC which integrates into subversion (Ole and Kat 27/7/5) - Done
264
265Zeus?
266
267Install Matplotlib on nautilus
268
269
270
271--------------
272Documentation
273
274Hire technical writer to produce
275- Getting started
276- User guide
277- Reference manual - semi automated
278
279Mathematical model description  (Steve & Chris)
280
281
282-----------------
283Validation and QA
284
285Merimbula (Steve & Chris)
286PNG Landslide study or watertank data (Adrian?)
287BOM
288SMEC (Lex)
289CSIRO (Kathy)
290Watertank study (Okushiri) (Ole) Done
291Macca...
292
293
294--------
295Naming
296
297The collection as well as individual modules may benefit from better names.
298
299
300--------
301Release
302
303Search for appropriate procedure for OSS release (Ole is onto that with AGIMO)
304
305
306
Note: See TracBrowser for help on using the repository browser.