QA: Have SMEC (and the likes) try the software for one of their projects and ask them to comment on: quality performance (size and speed) ease of installation documentation NAME: How about naming the whole thing GANU or ANUGA ? PROJECTS: One way of implementing parallelism would be through domain decomposition (DD). Perhaps we can work with someone with experience in DD of PDEs and once that works, parallelise the code by having several sub-domains on each processor. Uncertainty modelling and MC simluations. Running a large simulation (Stress test): {Peter Row?) DONE (tsunamies) Momentum sink study. Scale, extent, map various copmpositions of structures to friction terms Stephen: Look at domain decomposition algorithms with a view of parallelising pyvolution Stephen: Timestepping to be controlled by error estimator. DESIGN PRINCIPLES (17/3/5) - as agreed to by Duncan and Ole Objects shared across project should not precompute structures upon initialisation unless they are used by all clients. Rather precompute on demand or split using inheritance. Pro: Good separation of concepts Con: It may be harder to find the right file Also, modules shared across project should not generally depend on other modules. Idea (ON 28/4/5): Allow set_quantity to take a .pts file as argument. That should use least_squares to populate the quantity. Furthermore use caching.py to assert whether this should be computed or read from cache. Use logger module as suggested by steve See also HUSK.txt in pyvolution Have the option of changing boundaries and forcing functions on the fly depnding on e.g. time or value of conserved quantities. PROJECT IDEAS (NOV 2005) GBR Effect on tsunami (Stephen may get student) Convection (Grad proposal 2005/2006, Ole) Momentum sink (Grad proposal 2005/2006, Duncan) Convergence study (Ole) VRML export (David Beard, Malcolm Nicoll) Proper installer Overcome 2GB NetCDF limit IO (data_manager) needs some TLC See also work program ideas 2005-2006