--- a/Notes.md	Sun Feb 26 17:09:35 2023 +0100
+++ b/Notes.md	Sun Feb 26 17:09:51 2023 +0100
@@ -200,74 +200,6 @@
 Preferably dimensions and sizes should be checked when lazy objects are created, for example TensorApplication, TensorComposition and so on. If dimension checks decreases performance we can make them skippable later.
 
 ## Vector valued grid functions
-Från slack konversation:
-
-Jonatan Werpers:
-Med vektorvärda gridfunktioner vill vi ju fortfarande att grid funktionen ska vara till exempel AbstractArray{LitenVektor,2}
-Och att man ska kunna göra allt man vill med LitenVektor
-typ addera, jämföra osv
-Och då borde points returnera AbstractArray{LitenVektor{Float,2},2} för ett 2d nät
-Men det kanske bara ska vara Static arrays?
-
-Vidar Stiernström:
-Ja, jag vet inte riktigt vad som är en rimlig representation
-Du menar en vektor av static arrays då?
-
-Jonatan Werpers:
-Ja, att LitenVektor är en StaticArray
-
-Vidar Stiernström:
-Tuplar känns typ rätt inuitivt för att representera värdet i en punkt
-men
-det suger att man inte har + och - för dem
-
-Jonatan Werpers:
-Ja precis
-
-Vidar Stiernström:
-så kanske är bra med static arrays i detta fall
-
-Jonatan Werpers:
-Man vill ju kunna köra en Operator rakt på och vara klar eller?
-
-Vidar Stiernström:
-Har inte alls tänkt på hur det vi gör funkar mot vektorvärda funktioner
-men känns som staticarrays är hur man vill göra det
-tuplar är ju immutable också
-blir jobbigt om man bara agerar på en komponent då
-
-Jonatan Werpers:
-Hm…
-Tål att tänkas på
-Men det lär ju bli mer indirektion med mutables eller?
-Hur fungerar det?
-Det finns ju hur som helst både SVector och MVector i StaticArrays
-
-Vidar Stiernström:
-När vi jobbat i c/c++ och kollat runt lite hur man brukar göra så lagrar man i princip alla sina obekanta i en lång vektor och så får man specificera i funktioerna vilken komponent man agerar på och till vilken man skriver
-så man lagrar grejer enl: w = [u1, v1, u2, v2, …] i 1D.
-Men alltså har ingen aning hur julia hanterar detta
-
-Jonatan Werpers:
-Det vi är ute efter kanske är att en grid funcktion är en AbstractArray{T,2} where T<:NågotSomViKanRäknaMed
-Och så får den typen var lite vad som helst.
-
-Vidar Stiernström:
-Tror det kan vara farligt att ha nåt som är AbstractArray{LitenArray{NDof},Dim}
-Jag gissar att det kompilatorn vill ha är en stor array med doubles
-
-Jonatan Werpers:
-Och sen är det upp till den som använder grejerna att vara smart
-Vill man vara trixig kan man väl då imlementera SuperHaxxorGridFunction <: AbstractArray{Array{…},2} som lagrar allt linjärt eller något sånt
-Det kommer väl lösa sig när man börjar implementera vektorvärda saker
-Euler nästa!
-New
-Vidar Stiernström:
-Det vore skönt att inte behöva skriva såhär varje gång man testar mot en tupel :smile: @test [gp[i]...] ≈ [p[i]...] atol=5e-13
-
-Jonatan Werpers:
-https://github.com/JuliaArrays/ArraysOfArrays.jl
-https://github.com/jw3126/Setfield.jl
 
 ### Test-applikationer
 div och grad operationer
@@ -310,32 +242,6 @@
 
 Kanske kan man implementera `⋅(tm::LazyTensor{R,D}, v::AbstractArray{T,D})` där T är en AbstractArray, tm på något sätt har komponenter, lika många som T har element.
 
-### Ratade alternativ:
-
-
-#### 2.AbstractArray{T,2+1} where T (NOPE!)
-Blir inte den här. Bryter mot alla tankar om hur grid funktioner ska fungera. Om de tillåts ha en annan dimension än nätet blir allt hemskt.
-
-Man låter helt enkelt arrayen ha en extra dimension. En fördel är att man har en väldigt "native" typ. En nackdel kan vara att det eventuellt blir rörigt vilken dimension olika operatorer ska agera på. I värsta fall behöver vi "kroneckra in" de tillagda dimensionerna. Vektorfältets index kommer också att bli det första eftersom vi vill att de ska lagras kontinuerligt i minnet pga chachen. (Går kanske att lösa med en custom typ men då krånglar man till det för sig). En fördel skulle vara att man enkelt får ut olika komponenter.
-
-Syntax:
-```
-gf = eval_on_grid(g,f)
-gf[:,2,3] # Hela vektorn för en gridpunkt
-gf[2,2,3] # Andra komponenten av vektor fältet i en punkt.
-gf[2,:,:] #
-```
-
-### Evaluering av funktioner på nät
-Hur ska man skriva funktioner som evalueras på nätet? `f(x,y) = ...` eller `f(x̄) = ...`? Eller båda? Kan eval_on_grid se skillnad eller får användaren specificera?
-
-```
-f(x,y) = [x^2, y^2]
-f(x̄) = [x̄[1]^2, x̄[2]^2]
-```
-
-Påverkas detta av hur vi förväntar oss kunna skapa lata gridfunktioner?
-
 ### Komponenter som gridfunktioner
 En viktig operation för vektor fält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy.
 Det finns ett par olika lösningar:
@@ -355,19 +261,6 @@
 @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?
 

--- a/grid_refactor.md	Sun Feb 26 17:09:35 2023 +0100
+++ b/grid_refactor.md	Sun Feb 26 17:09:51 2023 +0100
@@ -1,15 +1,34 @@
 # Grids refactor
 
-## Mål
-  * Embedded grids
-  * Vektorvärda grid funktioner, speciellt koordinat-funktionen
-  * Olika griddar i olika riktningar?
-      * Tex periodiskt i en riktning och intervall i en.
-      * Tex ostrukturerat i ett par och strukturerat i en.
-  * Enkelt att evaluera på 0d-grid
+## Goals before merging
+* A somewhat clear path towards multi-block grids and their grid functions.
+* A somewhat clear path towards implementations of div() and rot() or the elastic operator (See Notes.md)
+
+## Change summary
+* `EquidistantGrid` is now only a 1D thing.
+* Higher dimensions are supported through `TensorGrid`.
+* The old behavior of `EquidistantGrid` has been moved to the function `equidistant_grid`.
+* Grids embedded in higher dimensions are now supported through tensor products with `ZeroDimGrid`s.
+* Vector valued grid functions are now supported and the default element type is `SVector`.
+* Grids are now expected to support Julia's indexing and iteration interface.
+
+
+## TODO
+* Document the expected behavior of grid functions
+* Write down the thinking around Grid being an AbstractArray. Why it doesn't work
+
+* Clean out Notes.md of any solved issues
+* Delete this document, move remaining notes to Notes.md
+
+## Remaining work for feature branches
+* Multi-block grids
+* Periodic grids
+* Grids with modified boundary nodes
+* Unstructured grids?
 
 ## Frågor
 
+### Should we move utility functions to their own file?
 
 ### Ska `Grid` vara en AbstractArray?
 Efter som alla nät ska agera som en gridfunktion för koordinaterna måste man
@@ -22,7 +41,6 @@
   - Non-simply connected?
   - CG/DG-nät
 
-
 Om alla nät är någon slags AbstractArray så kan tillexempel ett multiblock nät vara en AbstractArray{<:Grid, 1} och motsvarande gridfunktioner AbstractArray{<:AbstractArray,1}.
 Där man alltså först indexerar för vilket när man vill åt och sedan indexerar nätet. Tex `mg[2][32,12]`.
 
@@ -69,35 +87,7 @@
  * Om vi har nod-indexerade ostrukturerade nät borde de fungera med TensorGrid.
  * Griddar ska uppfylla Indexing och Iteration interfacen
 
-### Kan vi introducera 1d griddar och tensorgriddar?
-  * Vanligt intervallgrid
-  * Periodiskt grid
-  * 0-dimensionellt grid
-
-Det skulle kunna lösa frågan med embedded-griddar
-och frågan om mixade grids.
-
-En svårighet kan vara att implemetera indexeringen för tensorgridden. Är det
-lätt att göra den transparent för kompilatorn?
-
-Läs i notes.md om: Grids embedded in higher dimensions
-
-Periodiska gridfunktioner? Eller ska vi bara skita i det och låta användaren
-hantera det själv? Blir det krångligt i högre dimensioner?
-
-
-### Hur ska vi hantera gridfunktioner med flera komponenter?
-Tex koordinat-funktionen på nätet?
-
-Funkar det att ha StaticArray som element type?
-    Kan man köra rakt på med en operator då?
-
-Vi skulle också kunna använda ArraysOfArrays. Skillnaden blir att den elementtypen är Array{T,N}. Vilket betyder att den är by reference?
-    Frågan är om kompilatorn kommer att bry sig... Jag skulle luta mot StaticArrays for safety
-
-Läs i notes.md om: Vector valued grid functions
-
-## Should Grid have function for the target manifold dimension?
+### Should Grid have function for the target manifold dimension?
 Where would it be used?
     In the constructor for TensorGrid
     In eval on if we want to allow multiargument functions
@@ -105,7 +95,7 @@
 
 An alternative is to analyze T in Grid{T,D} to find the answer. (See combined_coordinate_vector_type in tensor_grid.jl)
 
-## Lazy version of map for our needs?
+### Lazy version of map for our needs?
 Could be used to
  * evaulate functions on grids
  * pick out components of grid functions
@@ -121,20 +111,14 @@
 
 Could allow us to remove eval_on.
 
-## Do we need functions like `getcomponent`?
+### Do we need functions like `getcomponent`?
 Perhaps this can be more cleanly solved using map or a lazy version of map?
 That approach would be more flexible and more general requiring few specialized functions.
 
 (see "Lazy version of map for our needs?" above)
 
-## Notes from pluto notebook
-- Är det dåligt att använda ndims om antalet index inte matchar?
-   - Tex ostrukturerat grid
-   - Baserat på hur Array fungerar och ndims docs borde den nog returnera
-     antalet index och inte griddens dimension
-   - Å andra sidan kanske man inte behöver veta viken dimension det är? Fast det känns konstigt...
-- Should we keep the `points` function?
-   - Maybe it's better to support `collect` on the grid?
-- How to handle boundary identifiers and boundary grids on `TensorGrid`?
+### Would it help to introduce a type for grid functions?
+Seems easier to avoid this but it might be worth investigating.
 
+Can it be done with some kind of trait? We can give AbstractArray the appropriate trait and keep them for the simplest grid functions.