Mercurial > repos > public > sbplib_julia
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? |