You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Slab transport is evaluating the contribution to the transport term coming from derivatives along a single direction. Considering a slab of data in the $j$-orientation, we want to compute
Implementation of slab transport can then split into three steps:
Add a new cuda_diffengine_t derived type providing a diff bound procedure executing a cuda kernel performing the differentiation (Implement differentiation on the GPU #3).
Compute and combine derivatives into a transport_dir bound procedure on the cuda slab.
Implement the top level transport bound procedure on the cuda slab type.
Although the GPU implementation might eventually differ from the CPU implementation for performance reasons (e.g. computation of all derivatives and their sum within a single CUDA kernel), I suggest that the first working version follows the CPU implementation closely.
Just like the diffengine_t type is responsible for instanciating a tridiagonal solver from the bulk and boundary differentiation schemes, the cuda_diffengine_t could hold device arrays and stencil instances for the thomas solver coefficeints and stencil, respectively. These device objects could be initialised from host code before calling the differentatiation kernel.
The text was updated successfully, but these errors were encountered:
Slab transport is evaluating the contribution to the transport term coming from derivatives along a single direction. Considering a slab of data in the$j$ -orientation, we want to compute
Implementation of slab transport can then split into three steps:
cuda_diffengine_t
derived type providing adiff
bound procedure executing a cuda kernel performing the differentiation (Implement differentiation on the GPU #3).transport_dir
bound procedure on the cuda slab.Although the GPU implementation might eventually differ from the CPU implementation for performance reasons (e.g. computation of all derivatives and their sum within a single CUDA kernel), I suggest that the first working version follows the CPU implementation closely.
Just like the
diffengine_t
type is responsible for instanciating a tridiagonal solver from the bulk and boundary differentiation schemes, thecuda_diffengine_t
could holddevice
arrays andstencil
instances for the thomas solver coefficeints and stencil, respectively. These device objects could be initialised from host code before calling the differentatiation kernel.The text was updated successfully, but these errors were encountered: