--- a/Notes.md	Wed Jul 14 23:40:10 2021 +0200
+++ b/Notes.md	Thu Jul 15 00:06:16 2021 +0200
@@ -298,3 +298,35 @@
 component(gf,:,2) # Andra kolumnen av en matris
 @ourview gf[:,:][2]
 ```
+
+## Grids embedded in higher dimensions
+
+For grids generated by asking for boundary grids for a regular grid, it would
+make sense if these grids knew they were embedded in a higher dimension. They
+would return coordinates in the full room. This would make sense when
+drawing points for example, or when evaluating functions on the boundary.
+
+Implementation of this is an issue that requires some thought. Adding an extra
+"Embedded" type for each grid would make it easy to understand each type but
+contribute to "type bloat". On the other hand adapting existing types to
+handle embeddedness would complicate the now very simple grid types. Are there
+other ways of doing the implentation?
+
+## Performance measuring
+We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance?
+
+We should make these test simple to run for any solver.
+
+See [this talk](https://www.youtube.com/watch?v=vPsfZUqI4_0) for some simple ideas for defining effecive memory usage and some comparison with peak performance.
+
+
+## Adjoint as a trait on the sbp_operator level?
+
+It would be nice to have a way of refering to adjoints with resepct to the sbp-inner-product.
+If it was possible you could reduce the number of times you have to deal with the inner product matrix.
+
+Since the LazyOperators package is sort of implementing matrix-free matrices there is no concept of inner products there at the moment. It seems to complicate large parts of the package if this was included there.
+
+A different approach would be to include it as a trait for operators so that you can specify what the adjoint for that operator is.
+
+