Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 1277:79647b60a73b refactor/grids

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Add and delete notes
author Jonatan Werpers <jonatan@werpers.com>
date Sun, 26 Feb 2023 17:09:51 +0100
parents a8fa8c1137cc
children 23f3b62388ba
comparison
equal deleted inserted replaced
1276:75a65db29be1 1277:79647b60a73b
198 This would mean no bounds checking in applys, however any indexing that they do would be boundschecked. The only loss would be readability of errors. But users aren't really supposed to call apply directly anyway. 198 This would mean no bounds checking in applys, however any indexing that they do would be boundschecked. The only loss would be readability of errors. But users aren't really supposed to call apply directly anyway.
199 199
200 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. 200 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.
201 201
202 ## Vector valued grid functions 202 ## Vector valued grid functions
203 Från slack konversation:
204
205 Jonatan Werpers:
206 Med vektorvärda gridfunktioner vill vi ju fortfarande att grid funktionen ska vara till exempel AbstractArray{LitenVektor,2}
207 Och att man ska kunna göra allt man vill med LitenVektor
208 typ addera, jämföra osv
209 Och då borde points returnera AbstractArray{LitenVektor{Float,2},2} för ett 2d nät
210 Men det kanske bara ska vara Static arrays?
211
212 Vidar Stiernström:
213 Ja, jag vet inte riktigt vad som är en rimlig representation
214 Du menar en vektor av static arrays då?
215
216 Jonatan Werpers:
217 Ja, att LitenVektor är en StaticArray
218
219 Vidar Stiernström:
220 Tuplar känns typ rätt inuitivt för att representera värdet i en punkt
221 men
222 det suger att man inte har + och - för dem
223
224 Jonatan Werpers:
225 Ja precis
226
227 Vidar Stiernström:
228 så kanske är bra med static arrays i detta fall
229
230 Jonatan Werpers:
231 Man vill ju kunna köra en Operator rakt på och vara klar eller?
232
233 Vidar Stiernström:
234 Har inte alls tänkt på hur det vi gör funkar mot vektorvärda funktioner
235 men känns som staticarrays är hur man vill göra det
236 tuplar är ju immutable också
237 blir jobbigt om man bara agerar på en komponent då
238
239 Jonatan Werpers:
240 Hm…
241 Tål att tänkas på
242 Men det lär ju bli mer indirektion med mutables eller?
243 Hur fungerar det?
244 Det finns ju hur som helst både SVector och MVector i StaticArrays
245
246 Vidar Stiernström:
247 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
248 så man lagrar grejer enl: w = [u1, v1, u2, v2, …] i 1D.
249 Men alltså har ingen aning hur julia hanterar detta
250
251 Jonatan Werpers:
252 Det vi är ute efter kanske är att en grid funcktion är en AbstractArray{T,2} where T<:NågotSomViKanRäknaMed
253 Och så får den typen var lite vad som helst.
254
255 Vidar Stiernström:
256 Tror det kan vara farligt att ha nåt som är AbstractArray{LitenArray{NDof},Dim}
257 Jag gissar att det kompilatorn vill ha är en stor array med doubles
258
259 Jonatan Werpers:
260 Och sen är det upp till den som använder grejerna att vara smart
261 Vill man vara trixig kan man väl då imlementera SuperHaxxorGridFunction <: AbstractArray{Array{…},2} som lagrar allt linjärt eller något sånt
262 Det kommer väl lösa sig när man börjar implementera vektorvärda saker
263 Euler nästa!
264 New
265 Vidar Stiernström:
266 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
267
268 Jonatan Werpers:
269 https://github.com/JuliaArrays/ArraysOfArrays.jl
270 https://github.com/jw3126/Setfield.jl
271 203
272 ### Test-applikationer 204 ### Test-applikationer
273 div och grad operationer 205 div och grad operationer
274 206
275 Enligt Wikipedia verkar det som att `∇⋅` agerar på första dimensionen av ett tensor fält och `div()` på sista. 207 Enligt Wikipedia verkar det som att `∇⋅` agerar på första dimensionen av ett tensor fält och `div()` på sista.
307 (Man skulle eventuellt också kunna låta den agera på `StaticMatrix{N,T,D} where N` och returnera `StaticMatrix{M,T,D+1}`. Frågan är om man vinner något på det...) 239 (Man skulle eventuellt också kunna låta den agera på `StaticMatrix{N,T,D} where N` och returnera `StaticMatrix{M,T,D+1}`. Frågan är om man vinner något på det...)
308 240
309 Skulle kunna ha en funktion `range_type(::LazyTensor, ::Type{domain_type})` 241 Skulle kunna ha en funktion `range_type(::LazyTensor, ::Type{domain_type})`
310 242
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. 243 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.
312
313 ### Ratade alternativ:
314
315
316 #### 2.AbstractArray{T,2+1} where T (NOPE!)
317 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.
318
319 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.
320
321 Syntax:
322 ```
323 gf = eval_on_grid(g,f)
324 gf[:,2,3] # Hela vektorn för en gridpunkt
325 gf[2,2,3] # Andra komponenten av vektor fältet i en punkt.
326 gf[2,:,:] #
327 ```
328
329 ### Evaluering av funktioner på nät
330 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?
331
332 ```
333 f(x,y) = [x^2, y^2]
334 f(x̄) = [x̄[1]^2, x̄[2]^2]
335 ```
336
337 Påverkas detta av hur vi förväntar oss kunna skapa lata gridfunktioner?
338 244
339 ### Komponenter som gridfunktioner 245 ### Komponenter som gridfunktioner
340 En viktig operation för vektor fält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy. 246 En viktig operation för vektor fält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy.
341 Det finns ett par olika lösningar: 247 Det finns ett par olika lösningar:
342 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl? 248 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl?
353 component(gf,2,3) # (2,3) elementet av en matris 259 component(gf,2,3) # (2,3) elementet av en matris
354 component(gf,:,2) # Andra kolumnen av en matris 260 component(gf,:,2) # Andra kolumnen av en matris
355 @ourview gf[:,:][2] 261 @ourview gf[:,:][2]
356 ``` 262 ```
357 263
358 ## Grids embedded in higher dimensions
359
360 For grids generated by asking for boundary grids for a regular grid, it would
361 make sense if these grids knew they were embedded in a higher dimension. They
362 would return coordinates in the full room. This would make sense when
363 drawing points for example, or when evaluating functions on the boundary.
364
365 Implementation of this is an issue that requires some thought. Adding an extra
366 "Embedded" type for each grid would make it easy to understand each type but
367 contribute to "type bloat". On the other hand adapting existing types to
368 handle embeddedness would complicate the now very simple grid types. Are there
369 other ways of doing the implentation?
370
371 ## Performance measuring 264 ## Performance measuring
372 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance? 265 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance?
373 266
374 We should make these test simple to run for any solver. 267 We should make these test simple to run for any solver.
375 268