Difference between revisions of "Teleconference 2015-03-25"
Jump to navigation
Jump to search
Jsmeredith (talk | contribs) (Created page with "participants: Hank, Dave, Jeremy * Hank: discussion of writing, essentially a VTK-m textbook simultaneously with a grad class in the Fall * we will discuss more later * Jer...") |
Jsmeredith (talk | contribs) |
||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
* Hank: discussion of writing, essentially a VTK-m textbook simultaneously with a grad class in the Fall | * Hank: discussion of writing, essentially a VTK-m textbook simultaneously with a grad class in the Fall | ||
− | + | ** we will discuss more later | |
* Jeremy, Dave: quick progress updates, some discussion on these topics: | * Jeremy, Dave: quick progress updates, some discussion on these topics: | ||
− | + | ** grouped vs ungrouped connectivity: | |
− | + | *** no one has yet come up with a code that natively highly mixes cell types | |
− | + | *** hank suggest some algorithms (clipping, material interface, etc.) may generate highly mixed or grouped, though we're not sure that grouped performs better than mixed due to caching effects (i.e. if one clipped cell generates a tet and a wedge, those shapes will share nodes, and so the mixed algorithm will generally access the same nodes, or even nearby ones (spatial locality) with temporal locality). | |
− | + | *** there are potentially upsides and downsides to both: | |
− | + | **** memory usage favors grouped: minimal memory penalty in the worst case (e.g. alternating tris with quads) and moderate memory benefit in best case | |
− | + | **** grouped makes celltype-specific kernel launches trivially easy | |
− | + | **** but may be one extra indirection for grouped (must look up group index and connectivity index from cell index; either two separate cell-length arrays, or look up group index in cell-length array then look up connectivity startindex in group-length array) | |
− | + | *** as such, since it is pretty easy to implement both and convert between, we may simply do both | |
− | + | ** some brief discussion of allowing more than two topology types in a single worklet (e.g. node-and-face-and-cell to cell), decided to pass for now for lack of concrete examples; can always add later |
Latest revision as of 09:10, 30 March 2015
participants: Hank, Dave, Jeremy
- Hank: discussion of writing, essentially a VTK-m textbook simultaneously with a grad class in the Fall
- we will discuss more later
- Jeremy, Dave: quick progress updates, some discussion on these topics:
- grouped vs ungrouped connectivity:
- no one has yet come up with a code that natively highly mixes cell types
- hank suggest some algorithms (clipping, material interface, etc.) may generate highly mixed or grouped, though we're not sure that grouped performs better than mixed due to caching effects (i.e. if one clipped cell generates a tet and a wedge, those shapes will share nodes, and so the mixed algorithm will generally access the same nodes, or even nearby ones (spatial locality) with temporal locality).
- there are potentially upsides and downsides to both:
- memory usage favors grouped: minimal memory penalty in the worst case (e.g. alternating tris with quads) and moderate memory benefit in best case
- grouped makes celltype-specific kernel launches trivially easy
- but may be one extra indirection for grouped (must look up group index and connectivity index from cell index; either two separate cell-length arrays, or look up group index in cell-length array then look up connectivity startindex in group-length array)
- as such, since it is pretty easy to implement both and convert between, we may simply do both
- some brief discussion of allowing more than two topology types in a single worklet (e.g. node-and-face-and-cell to cell), decided to pass for now for lack of concrete examples; can always add later
- grouped vs ungrouped connectivity: