-
Notifications
You must be signed in to change notification settings - Fork 63
/
2DO
165 lines (126 loc) · 5.93 KB
/
2DO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
2DO list from Mar 7, 2012.
* Wrap scipy.integrate.odeint (LSODA).
Status: Done (but first_step parameter doesn't work, probably ok as is).
* Rewrite tutorial with a better sequence of examples in the beginning,
e.e., logistic equation.
Status: done.
* Motivating example with F77/LSODE, Matlab ode45 and (now) scipy with
vode (beginning of doc/src/odespy/odespy.do.txt): set adams 10-th
order method (to demonstrate setting parameters) for Fortran and Python.
How is this done in pure Fortran?
Status: much in progress.
* Split class RungeKutta in two: one for 1-level methods, derived from
Solver, and one for 2-level methods, derived from Adaptive.
Status: done.
* Refactor the advance method in class RungeKutta so that it clearly
illustrates the logical steps for students.
Status: done (can still be improved).
* Implement RK34.
Status: done, but buggy. Maybe drop it?
* Clean up odepack.py: Consider the feasibility of doing all points
below. If not done, move the package to sandbox and make no
claims that odespy wraps ODEPACK.
* 2DO list for odepack.py:
* Get method description (what kind of numerical method is used)
into the doc string and preferably in the quick_description too.
Status: not done.
* Move complicated methods in solver.py not used elsewhere to odepack.
Status: done.
* Doc strings have ugly formatting both in pydoc and sphinx.
Use either one-line strings or multi-line strings in help,
and don't wrap the multi-line strings. Reformat all code examples
in doc strings (subroutine signatures) to proper multi-line format.
Remove fixed_width in the doc string formatting as this skrews
up the formatting in pydoc and breaks lines at strange points.
Get rid of everything with fixed_width and work with one or multi
line strings, where whitespace is exactly preserved in the latter.
Status: done.
* Introduce a blank line before and after Fortran subroutine signatures.
Status: done.
* Move _parameters items from solver.py that are specific to
ODEPACK to odepack.py. Change general names like iter_method to
more specific like correction_iter_method.
Status: done.
* "there are often memory errors" and similar things in doc strings,
and all real problems, must be seriously dealt with. Better to
have a separate line at the end of the doc string with a WARNING
about potential problems, maybe also a print statement in
one of the functions that are always called.
Very important point!
Status: not done.
* Use sphinx/rst list syntax in doc stings and help strings.
Status: some corrections.
* Variables in ODEPACK are referred to with both upper and lower
case variables. Must be consistent!
Status: not done.
* Get test cases (from tests?) into the doc strings of functions.
It is hard to use odepack.py because of all the parameters and
there is almost no documentation.
Status: not done.
* Why is not class Odepack derived from Adaptive?
It adds all the adaptive prms rtol, atol, etc.
Status:
* Why are lrw and liw user-given parameters? Isn't this something
the Python code can compute and set?
What does the doc strings in expand_*work really mean?
Not easy to understand.
Status:
* The return objects from Python functions (res, jac_lsoibt and others)
have a strange syntax (vector * float * ...). Use std Python syntax.
Status: not done.
* Typeset all variables in help and doc strings with double `` to
make them formatted verbatim in syntax.
Status: not done.
* Go through all English in all help and doc strings.
A lot of the info is incomplete, inconsistent, does not make sense, has
grammer mistakes, etc.
Status: not done.
* INSTALL.txt: require Py 2.7, numpy, scipy, sympy,
python-scitools, explain this in tutorial too, together with git clone.
sundials, odelib.
Status: not done.
* Examples: shooting method for e*u''=u' (or 1D boundary value problems
in general; planet orbit (illustrate large ellipse and adaptivity);
series of SIS, SIR, SIRV models; 1D diffusion equation (use it in rkc
too);
Status: will by done by hpl.
* Link to all source code files in tutorial.
Status: not done.
* More tutorial examples: pure_diffusion, reaction_diffusion.
Status: note done:
* Unit tests.
Make a class Problem with f, jac, stiff, complex_, a la scipy.integrate,
but lett stiff etc be self.stiff such that parameters can vary and
determine if the problem is stiff.
Status: partially done.
* Get description of rkf45.f and rkc.f into doc strings.
Status: not done.
* Consider wrapping more methods like radau5, or are these methods in
fact available through other software (maybe already in odespy)?
Status: not done.
setup.py:
Think of an extension module as a set of .f files that are first
compiled to a library. This is specified by add_library.
Then an interface .c or .pyf is compiled
and linked with the library to form an extension module. This is
specified with add_extension. See scipy.integrate.
#!/usr/bin/env python
def configuration(parent_package='',top_path=None):
from numpy.distutils.misc_util import Configuration
config = Configuration('mymodule',parent_package,top_path)
config.add_extension('fastcalc', ['src/fastcalc.f90'])
return config
if __name__ == "__main__":
from numpy.distutils.core import setup
setup(configuration=configuration)
More examples are in
numpy/distutils/tests/
setup.py numpy style is to only build extension modules while
__init__.py imports all the python modules and makes then
available, either from import or just import
mixture of Cython, Python, C, F77: maybe these with separate setup.py
in separate dirs? Can numpy distutils call up a Cython setup.py?
Yes, one first runs manually Cython on the .pyx file and creates the
.c file, then this file is simply added as extension, see
scipy/io/matlab/setup.py. The setup.py script can run Cython, see
if that's "official".