Mercurial > repos > public > sbplib_julia
comparison Notes.md @ 1557:9113f437431d feature/grids/curvilinear
Merge default
| author | Jonatan Werpers <jonatan@werpers.com> |
|---|---|
| date | Sat, 13 Apr 2024 23:52:40 +0200 |
| parents | 8b9cdadb845a |
| children | d68d02dd882f bb4c119e91fa |
comparison
equal
deleted
inserted
replaced
| 1527:69790e9d1652 | 1557:9113f437431d |
|---|---|
| 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 |
| 323 ``` | 346 ``` |
| 324 | 347 |
| 325 * This would impact how tensor grid works. | 348 * This would impact how tensor grid works. |
| 326 * To make things homogenous maybe these index collections should be used for the more simple grids too. | 349 * To make things homogenous maybe these index collections should be used for the more simple grids too. |
| 327 * The function `to_indices` from Base could be useful to implement for `IndexCollection` | 350 * The function `to_indices` from Base could be useful to implement for `IndexCollection` |
| 351 | |
| 352 | |
| 353 ## Stencil application pipeline | |
| 354 We should make sure that `@inbounds` and `Base.@propagate_inbounds` are | |
| 355 applied correctly throughout the stack. When testing the performance of | |
| 356 stencil application on the bugfix/sbp_operators/stencil_return_type branch | |
| 357 there seemed to be some strange results where such errors could be the | |
| 358 culprit. |