Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 1531:9da4ab4fb85e bugfix/sbp_operators/stencil_return_type

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Merge default
author Jonatan Werpers <jonatan@werpers.com>
date Thu, 11 Apr 2024 22:50:42 +0200
parents d641798539c2
children 8b9cdadb845a
comparison
equal deleted inserted replaced
1456:f13857f37b8f 1531:9da4ab4fb85e
184 lmap(f, I) = LazyIndexableMap(f,I) 184 lmap(f, I) = LazyIndexableMap(f,I)
185 ``` 185 ```
186 186
187 The interaction of the map methods with the probable design of multiblock functions involving nested indecies complicate the picture slightly. It's clear at the time of writing how this would work with `Base.map`. Perhaps we want to implement our own versions of both eager and lazy map. 187 The interaction of the map methods with the probable design of multiblock functions involving nested indecies complicate the picture slightly. It's clear at the time of writing how this would work with `Base.map`. Perhaps we want to implement our own versions of both eager and lazy map.
188 188
189
190 ### 2024-04
191 MappedArrays.jl provides a simple array type and function like the description
192 of LazyMapping above. One option is to remove `eval_on` completely and rely on
193 destructuring arguments if handling the function input as a vector is
194 undesirable.
195
196 If we can let multi-block grids be iterators over grid points we could even
197 handle those by specialized implementation of `map` and `mappedarray`.
198
189 ## Multiblock implementation 199 ## Multiblock implementation
190 We want multiblock things to work very similarly to regular one block things. 200 We want multiblock things to work very similarly to regular one block things.
191 201
192 ### Grid functions 202 ### Grid functions
193 Should probably support a nested indexing so that we first have an index for subgrid and then an index for nodes on that grid. E.g `g[1,2][2,3]` or `g[3][43,21]`. 203 Should probably support a nested indexing so that we first have an index for
194 204 subgrid and then an index for nodes on that grid. E.g `g[1,2][2,3]` or
195 We could also possibly provide a combined indexing style `g[1,2,3,4]` where the first group of indices are for the subgrid and the remaining are for the nodes. 205 `g[3][43,21]`.
196 206
197 We should make sure the underlying buffer for gridfunctions are continuously stored and are easy to convert to, so that interaction with for example DifferentialEquations is simple and without much boilerplate. 207 We could also possibly provide a combined indexing style `g[1,2,3,4]` where
208 the first group of indices are for the subgrid and the remaining are for the
209 nodes.
210
211 We should make sure the underlying buffer for grid functions are continuously
212 stored and are easy to convert to, so that interaction with for example
213 DifferentialEquations is simple and without much boilerplate.
198 214
199 #### `map` and `collect` and nested indexing 215 #### `map` and `collect` and nested indexing
200 We need to make sure `collect`, `map` and a potential lazy map work correctly through the nested indexing. 216 We need to make sure `collect`, `map` and a potential lazy map work correctly
217 through the nested indexing. Also see notes on `eval_on` above.
218
219 Possibly this can be achieved by providing special nested indexing but not
220 adhering to an array interface at the top level, instead being implemented as
221 an iterator over the grid points. A custom trait can let map and other methods
222 know the shape (or structure) of the nesting so that they can efficiently
223 allocate result arrays.
201 224
202 ### Tensor applications 225 ### Tensor applications
203 Should behave as grid functions 226 Should behave as grid functions
204 227
205 ### LazyTensors 228 ### LazyTensors
311 334
312 ## Implementation of LazyOuterProduct 335 ## Implementation of LazyOuterProduct
313 Could the implementation of LazyOuterProduct be simplified by making it a 336 Could the implementation of LazyOuterProduct be simplified by making it a
314 struct containing two or more LazyTensors? (using split_tuple in a similar way 337 struct containing two or more LazyTensors? (using split_tuple in a similar way
315 as TensorGrid) 338 as TensorGrid)
339
340 ## Implementation of boundary_indices for more complex grids
341 To represent boundaries of for example tet-elements we can use a type `IndexCollection` to index a grid function directly.
342
343 ```julia
344 I = IndexCollection(...)
345 v[I]
346 ```
347
348 * This would impact how tensor grid works.
349 * To make things homogenous maybe these index collections should be used for the more simple grids too.
350 * The function `to_indices` from Base could be useful to implement for `IndexCollection`