1 | Project Plan |
---|
2 | |
---|
3 | By Duncan Gray |
---|
4 | |
---|
5 | INTRODUCTION |
---|
6 | |
---|
7 | Software, called least squares, has been developed to implement a |
---|
8 | penalised least-squares fit and associated interpolations. It is in |
---|
9 | least_squares.py. It is currently not meeting user requirements with |
---|
10 | regards to speed and memory use. Additional functionality is also needed. |
---|
11 | |
---|
12 | SCOPE |
---|
13 | This is looking at refactoring the Class Interpolation |
---|
14 | |
---|
15 | LIFE-CYCLE |
---|
16 | |
---|
17 | Use a staged delivery life-cycle (see rapid development), with the |
---|
18 | proviso that additional functionality to supporting objects, such as |
---|
19 | build_quadtree in quad.py can be worked on after requirements have |
---|
20 | been determined. Also, the current least squares may be tinkered with |
---|
21 | to check the feasibility of concepts. |
---|
22 | |
---|
23 | At this stage how the design will be coded, eg built from the ground |
---|
24 | up, cut and past into a new file or changing the current code, has not |
---|
25 | been determined. |
---|
26 | |
---|
27 | |
---|
28 | |
---|
29 | ______________________________________________________________________ |
---|
30 | Least Squares Refactoring Software Requirements Specification |
---|
31 | |
---|
32 | By Duncan Gray |
---|
33 | |
---|
34 | |
---|
35 | INTRODUCTION |
---|
36 | |
---|
37 | This document specifies the requirements to implement when these |
---|
38 | modules are refactored. |
---|
39 | |
---|
40 | |
---|
41 | OVERALL DESCRIPTION |
---|
42 | |
---|
43 | Steven Roberts outlined the least squares algorithm used. |
---|
44 | |
---|
45 | |
---|
46 | DEFINITIONS |
---|
47 | |
---|
48 | The least squares algorithm will not be changed. |
---|
49 | |
---|
50 | |
---|
51 | REQUIREMENT SECTION |
---|
52 | |
---|
53 | Introduction |
---|
54 | |
---|
55 | Assume that all the requirements of the current least squares code will |
---|
56 | stay the same, unless stated. Note implementation and names used are |
---|
57 | not regarded as requirements. |
---|
58 | |
---|
59 | |
---|
60 | Requirements |
---|
61 | Warn the user when interpolating if points are outside the mesh. |
---|
62 | Let the user set the default value that is returned for these points. |
---|
63 | |
---|
64 | Warn the user when fitting to mesh if the mesh is outside the points boundary. |
---|
65 | (Note: by using alpha least squares can alway return a result in this |
---|
66 | situation) |
---|
67 | |
---|
68 | X number of points will not cause a memory error. (Problem is setting |
---|
69 | how many) |
---|
70 | Reduce the memory use of least_squares. (This requirement isn't |
---|
71 | really testable) |
---|
72 | |
---|
73 | Reduce the time spent building matrix A. (ditto) |
---|
74 | |
---|
75 | by using blocking and improving |
---|
76 | the architecture. and is implementation focused.) |
---|
77 | |
---|
78 | |
---|
79 | |
---|
80 | Requirement Notes |
---|
81 | How should we handle points outside of the mesh when interpolating? |
---|
82 | Currently the interpolated values are set to 0.0. |
---|
83 | Other options are, set to a given value. |
---|
84 | Raise an error. |
---|
85 | Return/set a flag and set to a given value/0.0. (I like this one) |
---|
86 | |
---|
87 | |
---|
88 | How should interpolate_sww respond? |
---|
89 | warning/error/exit/replace with given value. |
---|
90 | |
---|
91 | General Error Handling Guidelines |
---|
92 | |
---|
93 | Assume 4 ways of using the code |
---|
94 | 1) command line interface |
---|
95 | 2) API function - these have parameters of input data file names, |
---|
96 | output file names, and carry out a process. |
---|
97 | 3) External methods - These are the calls that the api function uses |
---|
98 | 4) Internal methods. |
---|
99 | |
---|
100 | Ways 1 and 2 are used by general users, so they should not return |
---|
101 | something that looks like a code crash from bad input. |
---|
102 | Another option for way 2 is to raise an error, which the user handles. |
---|
103 | Discus with Ole |
---|
104 | |
---|
105 | |
---|
106 | ___________________________________________________________________________ |
---|
107 | Least Squares System Design Specification |
---|
108 | |
---|
109 | By Duncan Gray |
---|
110 | |
---|
111 | |
---|
112 | INTRODUCTION |
---|
113 | |
---|
114 | This specifies design choices for the least squares code. |
---|
115 | |
---|
116 | OVERALL ARCHITECTURAL CHANGES |
---|
117 | |
---|
118 | DESIGN IDEAS, to meet requirements |
---|
119 | *To save memory; |
---|
120 | When interpolating, don't build AtA, B and D. (This has been implemented) |
---|
121 | When fitting, don't build A. |
---|
122 | |
---|
123 | |
---|
124 | |
---|
125 | |
---|
126 | * To save memory |
---|
127 | Use blocking when interpolating a large number of points (how large? |
---|
128 | Can the program check the available memory and work out a good block |
---|
129 | size?) |
---|
130 | |
---|
131 | *To reduce the time spent building matrix A. |
---|
132 | Change the expansion algorithm, when determining what triangle a point |
---|
133 | is in. It should look in the cell of the point and then all adjacent |
---|
134 | cells. If it isn't there then ... we have problems. My feeling is it |
---|
135 | has to be there. |
---|
136 | |
---|
137 | |
---|
138 | DESIGN IDEAS, refactoring |
---|
139 | |
---|
140 | Remove georeferencing from build_interpolation_matrix_A. Change the |
---|
141 | point co-ords to conform to the mesh co-ords early in the code. |
---|
142 | |
---|
143 | |
---|