diff grid_refactor.md @ 1277:79647b60a73b refactor/grids

Add and delete notes
author Jonatan Werpers <jonatan@werpers.com>
date Sun, 26 Feb 2023 17:09:51 +0100
parents dcd8654ca33b
children 1157f889bf50
line wrap: on
line diff
--- 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.