comparison Notes.md @ 1672:3714a391545a refactor/grids/boundary_identifiers_1d

Make the boundary identifiers for EquidistantGrid subtype BoundaryIdentifer
author Vidar Stiernström <vidar.stiernstrom@gmail.com>
date Sun, 07 Jul 2024 15:15:12 -0700
parents e551fe1fff14
children 52c2e6dff228
comparison
equal deleted inserted replaced
1671:791d0f3f289a 1672:3714a391545a
127 - [ ] Can we have a trait to tell if a LazyTensor is transposable? 127 - [ ] Can we have a trait to tell if a LazyTensor is transposable?
128 - [ ] 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? 128 - [ ] 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?
129 - [ ] 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? 129 - [ ] 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?
130 130
131 ## Identifiers for regions 131 ## Identifiers for regions
132 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. 132 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. We implement this by refactoring RegionIndices to be agnostic to the region types and then moving the actual types to Grids.
133 We implement this by refactoring RegionIndices to be agnostic to the region types and then moving the actual types to Grids. 133
134 `Region`s denote the parts of an operator for which closures and interior stencils are applied respectively. Boundaries/interfaces are included in the closure regions but or are separate concepts. The currently used `Upper`, `Lower` should perhaps instead be subtypes of `BoundaryIdentifier`. Perhaps we should also change the name of `Region` to `StencilRegion`.
135
136 Dispatching on regions:
137 * Use region indices `Index{Region}` as presently. This is simply an integer parametrized on the region.
138 * Use tag dispatch in the apply functions, i.e. `apply(op,u,I,::Region)` where `I` now is a regular `CartesianIndex`. Drawback with this approch is that regular indexing (op*u)[I] won't be aware of regions.
139
140 The structure of the apply function may then either be (using the tag dispatch alternative)
141 ```julia
142 function apply(op,u,I,r::Region)
143 if r == Lower()
144 return apply_lower(op,u,I)
145 ...
146 end
147 end
148 ```
149 with specific implementations of `apply_lower`. Here we need to make sure that the top level apply function actually is removed by the compiler. This should be possible since `r` is known in compile time. Alternatively one directly specializes `apply(op,u,I,::Lower)` and then introduces a toplevel function `apply(op,u,I) = apply(op,u,I,get_region(op,I))`. The second alterative seems more Julian to me.
134 150
135 ## Regions and tensormappings 151 ## Regions and tensormappings
136 - [ ] Use a trait to indicate if a LazyTensor uses indices with regions. 152 - [ ] Use a trait to indicate if a LazyTensor uses indices with regions.
137 The default should be that they do NOT. 153 The default should be that they do NOT.
138 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle? 154 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle?