Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 1594:d68d02dd882f feature/boundary_conditions

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Merge with default
author Vidar Stiernström <vidar.stiernstrom@gmail.com>
date Sat, 25 May 2024 16:07:10 -0700
parents 4550beef9694 8b9cdadb845a
children 8ebcac8edd9d
comparison
equal deleted inserted replaced
1591:615eeb6e662e 1594:d68d02dd882f
202 lmap(f, I) = LazyIndexableMap(f,I) 202 lmap(f, I) = LazyIndexableMap(f,I)
203 ``` 203 ```
204 204
205 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. 205 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.
206 206
207
208 ### 2024-04
209 MappedArrays.jl provides a simple array type and function like the description
210 of LazyMapping above. One option is to remove `eval_on` completely and rely on
211 destructuring arguments if handling the function input as a vector is
212 undesirable.
213
214 If we can let multi-block grids be iterators over grid points we could even
215 handle those by specialized implementation of `map` and `mappedarray`.
216
207 ## Multiblock implementation 217 ## Multiblock implementation
208 We want multiblock things to work very similarly to regular one block things. 218 We want multiblock things to work very similarly to regular one block things.
209 219
210 ### Grid functions 220 ### Grid functions
211 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]`. 221 Should probably support a nested indexing so that we first have an index for
212 222 subgrid and then an index for nodes on that grid. E.g `g[1,2][2,3]` or
213 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. 223 `g[3][43,21]`.
214 224
215 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. 225 We could also possibly provide a combined indexing style `g[1,2,3,4]` where
226 the first group of indices are for the subgrid and the remaining are for the
227 nodes.
228
229 We should make sure the underlying buffer for grid functions are continuously
230 stored and are easy to convert to, so that interaction with for example
231 DifferentialEquations is simple and without much boilerplate.
216 232
217 #### `map` and `collect` and nested indexing 233 #### `map` and `collect` and nested indexing
218 We need to make sure `collect`, `map` and a potential lazy map work correctly through the nested indexing. 234 We need to make sure `collect`, `map` and a potential lazy map work correctly
235 through the nested indexing. Also see notes on `eval_on` above.
236
237 Possibly this can be achieved by providing special nested indexing but not
238 adhering to an array interface at the top level, instead being implemented as
239 an iterator over the grid points. A custom trait can let map and other methods
240 know the shape (or structure) of the nesting so that they can efficiently
241 allocate result arrays.
219 242
220 ### Tensor applications 243 ### Tensor applications
221 Should behave as grid functions 244 Should behave as grid functions
222 245
223 ### LazyTensors 246 ### LazyTensors
341 ``` 364 ```
342 365
343 * This would impact how tensor grid works. 366 * This would impact how tensor grid works.
344 * To make things homogenous maybe these index collections should be used for the more simple grids too. 367 * To make things homogenous maybe these index collections should be used for the more simple grids too.
345 * The function `to_indices` from Base could be useful to implement for `IndexCollection` 368 * The function `to_indices` from Base could be useful to implement for `IndexCollection`
369
370
371 ## Stencil application pipeline
372 We should make sure that `@inbounds` and `Base.@propagate_inbounds` are
373 applied correctly throughout the stack. When testing the performance of
374 stencil application on the bugfix/sbp_operators/stencil_return_type branch
375 there seemed to be some strange results where such errors could be the
376 culprit.