Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 1345:c2012db881cb refactor/grids

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Clean notes.md
author Jonatan Werpers <jonatan@werpers.com>
date Mon, 15 May 2023 22:54:32 +0200
parents c0c1189c5f2e
children 08f06bfacd5c
comparison
equal deleted inserted replaced
1344:760a4a1ec4b7 1345:c2012db881cb
139 - [ ] Check how the native julia doc generator works 139 - [ ] Check how the native julia doc generator works
140 - [ ] Check if Vidars design docs fit in there 140 - [ ] Check if Vidars design docs fit in there
141 - [ ] Create a macro @lazy which replaces a binary op (+,-) by its lazy equivalent? Would be a neat way to indicate which evaluations are lazy without cluttering/confusing with special characters. 141 - [ ] Create a macro @lazy which replaces a binary op (+,-) by its lazy equivalent? Would be a neat way to indicate which evaluations are lazy without cluttering/confusing with special characters.
142 - [ ] Dispatch on Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ??? 142 - [ ] Dispatch on Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ???
143 Seems better unless there is some specific reason to use the type instead of the value. 143 Seems better unless there is some specific reason to use the type instead of the value.
144 - [ ] How do we handle mixes of periodic and non-periodic grids? Seems it should be supported on the grid level and on the 1d operator level. Between there it should be transparent.
145 - [ ] Can we have a trait to tell if a LazyTensor is transposable? 144 - [ ] Can we have a trait to tell if a LazyTensor is transposable?
146 - [ ] Is it ok to have "Constructors" for abstract types which create subtypes? For example a Grids() functions that gives different kind of grids based on input? 145 - [ ] Is it ok to have "Constructors" for abstract types which create subtypes? For example a Grids() functions that gives different kind of grids based on input?
147 - [ ] Figure out how to treat the borrowing parameters of operators. Include in into the struct? Expose via function dispatched on the operator type and grid? 146 - [ ] Figure out how to treat the borrowing parameters of operators. Include in into the struct? Expose via function dispatched on the operator type and grid?
148 147
149 ## Identifiers for regions 148 ## Identifiers for regions
150 The identifiers (`Upper`, `Lower`, `Interior`) used for region indecies should probabily be included in the grid module. This allows new grid types to come with their own regions. 149 The identifiers (`Upper`, `Lower`, `Interior`) used for region indecies should probably be included in the grid module. This allows new grid types to come with their own regions.
151 We implement this by refactoring RegionIndices to be agnostic to the region types and then moving the actual types to Grids. 150 We implement this by refactoring RegionIndices to be agnostic to the region types and then moving the actual types to Grids.
152 151
153 ## Regions and tensormappings 152 ## Regions and tensormappings
154 - [ ] Use a trait to indicate if a LazyTensor uses indices with regions. 153 - [ ] Use a trait to indicate if a LazyTensor uses indices with regions.
155 The default should be that they do NOT. 154 The default should be that they do NOT.
312 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. 311 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.
313 312
314 ### Komponenter som gridfunktioner 313 ### Komponenter som gridfunktioner
315 En viktig operation för vektorfält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy. 314 En viktig operation för vektorfält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy.
316 Det finns ett par olika lösningar: 315 Det finns ett par olika lösningar:
316 * Använda map eller en lazy map (se diskussion om eval_on)
317 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl? 317 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl?
318 * Använda en LazyTensor 318 * Använda en LazyTensor
319 * Någon typ av lazy-broadcast 319 * Någon typ av lazy-broadcast
320 * En lazy array som applicerar en funktion för varje element. 320 * En lazy array som applicerar en funktion för varje element.
321 321
322 Skulle vara en fördel om det är hyffsat generiskt så att en eventuell användare kan utöka det enkelt om de har någon egen exotisk typ. Eller ska man vila helt på
323
324 Syntax:
325 ```
326 gf = eval(...)
327 component(gf,2) # Andra komponenten av en vektor
328 component(gf,2,3) # (2,3) elementet av en matris
329 component(gf,:,2) # Andra kolumnen av en matris
330 @ourview gf[:,:][2]
331 ```
332 322
333 ### Prestanda-aspekter 323 ### Prestanda-aspekter
334 [Vidar, Discord, 2023-03-03] 324 [Vidar, Discord, 2023-03-03]
335 Typiskt sett finns det två sätt att representera vektorvärda gridfunktioner AbstractArray{T,Dim} där T är en vektor över komponenterna. Man skulle alltså i 1D ha 325 Typiskt sett finns det två sätt att representera vektorvärda gridfunktioner AbstractArray{T,Dim} där T är en vektor över komponenterna. Man skulle alltså i 1D ha
336 u = [ [u1[x1], u2[x1]] , [u1[x2], u2[x2]], ... [u1[xN], u2[xN]]]. Detta brukar kallas array of structs (AoS). Alternativet är struct of arrays (SoA), där man har alla gridpunkter för en given komponent u = [[u1[x1], u1[x2]],... u1[xN]], [u2[x1], u2[x2], ... u2[xN]]]. 326 u = [ [u1[x1], u2[x1]] , [u1[x2], u2[x2]], ... [u1[xN], u2[xN]]]. Detta brukar kallas array of structs (AoS). Alternativet är struct of arrays (SoA), där man har alla gridpunkter för en given komponent u = [[u1[x1], u1[x2]],... u1[xN]], [u2[x1], u2[x2], ... u2[xN]]].