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) |
||
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 | |
− | + | *** 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 |
Revision as of 13:48, 25 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
- 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: