Mercurial > repos > public > sbplib_julia
comparison Notes.md @ 769:0158c3fd521c operator_storage_array_of_table
Merge in default
| author | Jonatan Werpers <jonatan@werpers.com> |
|---|---|
| date | Thu, 15 Jul 2021 00:06:16 +0200 |
| parents | d7d030f8f708 |
| children | 1d166e7a9deb |
comparison
equal
deleted
inserted
replaced
| 768:7c87a33963c5 | 769:0158c3fd521c |
|---|---|
| 296 component(gf,2) # Andra komponenten av en vektor | 296 component(gf,2) # Andra komponenten av en vektor |
| 297 component(gf,2,3) # (2,3) elementet av en matris | 297 component(gf,2,3) # (2,3) elementet av en matris |
| 298 component(gf,:,2) # Andra kolumnen av en matris | 298 component(gf,:,2) # Andra kolumnen av en matris |
| 299 @ourview gf[:,:][2] | 299 @ourview gf[:,:][2] |
| 300 ``` | 300 ``` |
| 301 | |
| 302 ## Grids embedded in higher dimensions | |
| 303 | |
| 304 For grids generated by asking for boundary grids for a regular grid, it would | |
| 305 make sense if these grids knew they were embedded in a higher dimension. They | |
| 306 would return coordinates in the full room. This would make sense when | |
| 307 drawing points for example, or when evaluating functions on the boundary. | |
| 308 | |
| 309 Implementation of this is an issue that requires some thought. Adding an extra | |
| 310 "Embedded" type for each grid would make it easy to understand each type but | |
| 311 contribute to "type bloat". On the other hand adapting existing types to | |
| 312 handle embeddedness would complicate the now very simple grid types. Are there | |
| 313 other ways of doing the implentation? | |
| 314 | |
| 315 ## Performance measuring | |
| 316 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance? | |
| 317 | |
| 318 We should make these test simple to run for any solver. | |
| 319 | |
| 320 See [this talk](https://www.youtube.com/watch?v=vPsfZUqI4_0) for some simple ideas for defining effecive memory usage and some comparison with peak performance. | |
| 321 | |
| 322 | |
| 323 ## Adjoint as a trait on the sbp_operator level? | |
| 324 | |
| 325 It would be nice to have a way of refering to adjoints with resepct to the sbp-inner-product. | |
| 326 If it was possible you could reduce the number of times you have to deal with the inner product matrix. | |
| 327 | |
| 328 Since the LazyOperators package is sort of implementing matrix-free matrices there is no concept of inner products there at the moment. It seems to complicate large parts of the package if this was included there. | |
| 329 | |
| 330 A different approach would be to include it as a trait for operators so that you can specify what the adjoint for that operator is. | |
| 331 | |
| 332 |