Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 654:d26231227b89

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Add a bunch of notes on reading and storing operators and how to implement variable second derivatives
author Jonatan Werpers <jonatan@werpers.com>
date Sun, 24 Jan 2021 21:54:42 +0100
parents 8f9b3eac128a
children f1803ab08740 841ca12f3359
comparison
equal deleted inserted replaced
653:2a0b17adaf9e 654:d26231227b89
1 # Notes 1 # Notes
2
3 ## Reading operators
4
5 Jonatan's suggestion is to add methods to `Laplace`, `SecondDerivative` and
6 similar functions that take in a filename from which to read stencils. These
7 methods encode how to use the structure in a file to build the particular
8 operator. The filename should be a keyword argument and could have a default
9 value.
10
11 * This allows easy creation of operators without the user having to handle stencils.
12 * The user can easily switch between sets of operators by changing the file stecils are read from.
13
14 Grids for optimized operators could be created by reading from a .toml file in
15 a similar fashion as for the operators. The grid can then be used in a
16 `Laplace` method which dispatches on the grid type and knows how to read the
17 optimized operators. The method would also make sure the operators match the
18 grid.
19
20 Idea: Make the current upper case methods lower case. Add types with the upper
21 case names. These types are tensor mappings for the operator but also contain
22 the associated operators as fields. For example:
23
24 ```julia
25 L = Laplace(grid)
26 L.H
27 L.Hi
28 L.e
29 L.d
30 L.M
31
32 wave = L - L.Hi∘L.e'∘L.d
33 ```
34
35 These types could also contain things like borrowing and such.
36
37 ## Storage of operators
38 We need to change the toml format so that it is easier to store several
39 operator with different kinds of differentiations. For example there could be
40 several operators of the same order but with different number of boundary
41 points or different choice of boundary stencils.
42
43 Properties that differentiate operators should for this reason be stored in
44 variables and not be section or table names.
45
46 Operators/sets of stencils should be stored in an [array of tables](https://toml.io/en/v1.0.0-rc.3#array-of-tables).
47
48 We should formalize the format and write simple and general access methods for
49 getting operators/sets of stencils from the file. They should support a simple
50 way to filter based on values of variables. There filters could possibly be
51 implemented through keyword arguments that are sent through all the layers of
52 operator creation.
53
54 * Remove order as a table name and put it as a variable.
55
56
57 ## Variable second derivative
58
59 2020-12-08 after discussion with Vidar:
60 We will have to handle the variable second derivative in a new variant of
61 VolumeOperator, "SecondDerivativeVariable?". Somehow it needs to know about
62 the coefficients. They should be provided as an AbstractVector. Where they are
63 provided is another question. It could be that you provide a reference to the
64 array to the constructor of SecondDerivativeVariable. If that array is mutable
65 you are free to change it whenever and the changes should propagate
66 accordingly. Another option is that the counter part to "Laplace" for this
67 variable second derivate returns a function or acts like a functions that
68 takes an Abstract array and returns a SecondDerivativeVariable with the
69 appropriate array. This would allow syntax like `D2(a)*v`. Can this be made
70 performant?
71
72 For the 1d case we can have a constructor
73 `SecondDerivativeVariable(D2::SecondDerivativeVariable, a)` that just creates
74 a copy with a different `a`.
75
76 Apart from just the second derivative in 1D we need operators for higher
77 dimensions. What happens if a=a(x,y)? Maybe this can be solved orthogonally to
78 the `D2(a)*v` issue, meaning that if a constant nD version of
79 SecondDerivativeVariable is available then maybe it can be wrapped to support
80 function like syntax. We might have to implement `SecondDerivativeVariable`
81 for N dimensions which takes a N dimensional a. If this could be easily
82 closured to allow D(a) syntax we would have come a long way.
83
84 For `Laplace` which might use a variable D2 if it is on a curvilinear grid we
85 might want to choose how to calculate the metric coefficients. They could be
86 known on closed form, they could be calculated from the grid coordinates or
87 they could be provided as a vector. Which way you want to do it might change
88 depending on for example if you are memory bound or compute bound. This choice
89 cannot be done on the grid since the grid shouldn't care about the computer
90 architecture. The most sensible option seems to be to have an argument to the
91 `Laplace` function which controls how the coefficients are gotten from the
92 grid. The argument could for example be a function which is to be applied to
93 the grid.
94
95 What happens if the grid or the varible coefficient is dependent on time?
96 Maybe it becomes important to support `D(a)` or even `D(t,a)` syntax in a more
97 general way.
98
99 ```
100 g = TimeDependentGrid()
101 L = Laplace(g)
102 function Laplace(g::TimeDependentGrid)
103 g_logical = logical(g) # g_logical is time independent
104 ... Build a L(a) assuming we can do that ...
105 a(t) = metric_coeffs(g,t)
106 return t->L(a(t))
107 end
108 ```
2 109
3 ## Known size of range and domain? 110 ## Known size of range and domain?
4 Is there any reason to use a trait to differentiate between fixed size and unknown size? 111 Is there any reason to use a trait to differentiate between fixed size and unknown size?
5 112
6 When do we need to know the size of the range and domain? 113 When do we need to know the size of the range and domain?