--- a/Notes.md	Thu Jun 08 15:33:44 2023 +0200
+++ b/Notes.md	Thu Jun 08 15:45:33 2023 +0200
@@ -71,59 +71,6 @@
 dictionary-structure containing stencils, tuples, scalars and other types
 ready for input to the methods creating the operators.
 
-## Variable second derivative
-
-2020-12-08 after discussion with Vidar:
-We will have to handle the variable second derivative in a new variant of
-VolumeOperator, "SecondDerivativeVariable?". Somehow it needs to know about
-the coefficients. They should be provided as an AbstractVector. Where they are
-provided is another question. It could be that you provide a reference to the
-array to the constructor of SecondDerivativeVariable. If that array is mutable
-you are free to change it whenever and the changes should propagate
-accordingly. Another option is that the counter part to "Laplace" for this
-variable second derivate returns a function or acts like a functions that
-takes an Abstract array and returns a SecondDerivativeVariable with the
-appropriate array. This would allow syntax like `D2(a)*v`. Can this be made
-performant?
-
-For the 1d case we can have a constructor
-`SecondDerivativeVariable(D2::SecondDerivativeVariable, a)` that just creates
-a copy with a different `a`.
-
-Apart from just the second derivative in 1D we need operators for higher
-dimensions. What happens if a=a(x,y)? Maybe this can be solved orthogonally to
-the `D2(a)*v` issue, meaning that if a constant nD version of
-SecondDerivativeVariable is available then maybe it can be wrapped to support
-function like syntax. We might have to implement `SecondDerivativeVariable`
-for N dimensions which takes a N dimensional a. If this could be easily
-closured to allow D(a) syntax we would have come a long way.
-
-For `Laplace` which might use a variable D2 if it is on a curvilinear grid we
-might want to choose how to calculate the metric coefficients. They could be
-known on closed form, they could be calculated from the grid coordinates or
-they could be provided as a vector. Which way you want to do it might change
-depending on for example if you are memory bound or compute bound. This choice
-cannot be done on the grid since the grid shouldn't care about the computer
-architecture. The most sensible option seems to be to have an argument to the
-`Laplace` function which controls how the coefficients are gotten from the
-grid. The argument could for example be a function which is to be applied to
-the grid.
-
-What happens if the grid or the varible coefficient is dependent on time?
-Maybe it becomes important to support `D(a)` or even `D(t,a)` syntax in a more
-general way.
-
-```
-g = TimeDependentGrid()
-L = Laplace(g)
-function Laplace(g::TimeDependentGrid)
-    g_logical = logical(g) # g_logical is time independent
-    ... Build a L(a) assuming we can do that ...
-    a(t) = metric_coeffs(g,t)
-    return t->L(a(t))
-end
-```
-
 ## Known size of range and domain?
 Is there any reason to use a trait to differentiate between fixed size and unknown size?
 

--- a/src/SbpOperators/volumeops/derivatives/second_derivative_variable.jl	Thu Jun 08 15:33:44 2023 +0200
+++ b/src/SbpOperators/volumeops/derivatives/second_derivative_variable.jl	Thu Jun 08 15:45:33 2023 +0200
@@ -40,7 +40,6 @@
 end
 
 
-# REVIEW: Fixa docs
 """
     SecondDerivativeVariable{Dir,T,D,...} <: LazyTensor{T,D,D}
 
@@ -130,13 +129,13 @@
         I = Base.setindex(I, Index(i, Upper), dir)
         return LazyTensors.apply(op, v, I...)
     else
-        error("Bounds error") # TODO: Make this more standard
+        error("Bounds error") # This should be `throw(BoundsError())` but the type inference is so fragile that it doesn't work. Needs investigation. / Jonatan 2023-06-08
     end
 end
 
 
-## 2D Specific implementations to avoid instability
-## TODO: Should really be solved by fixing the general methods instead
+# 2D Specific implementations to avoid type instability
+# TBD: Can this be solved by fixing the general methods instead?
 
 
 ## x-direction