|
| subroutine | gs_crystal_init (this, send_pe, recv_pe) |
| | Initialise crystal router based communication method See gs_comm.f90 for details.
|
| |
| subroutine | gs_crystal_init_vec (this) |
| | Allocate the fused vector working and send buffers, sized for GS_VEC_NC components. Deferred to the first fused exchange, see gs_comm_t. The routing plan is shared with the scalar exchange and is not rebuilt here, so this stays rank local.
|
| |
| subroutine | gs_crystal_free (this) |
| | Deallocate crystal router based communication method.
|
| |
| subroutine | gs_crystal_nbrecv (this, tag) |
| | Post the receives of the first routing stage.
|
| |
| subroutine | gs_crystal_nbsend (this, u, n, tag, deps, strm) |
| | Pack the shared vector and post the send of the first routing stage.
|
| |
| subroutine | gs_crystal_nbwait (this, u, n, op, strm) |
| | Drive the remaining routing stages and reduce what is delivered into the shared vector.
|
| |
| subroutine | gs_crystal_nbrecv_vec (this, tag, nc) |
| | Post the receives of the first routing stage, fused nc-component.
|
| |
| subroutine | gs_crystal_nbsend_vec (this, u, n, nc, tag, deps, strm) |
| | Pack the shared vector and post the send of the first routing stage, fused nc-component.
|
| |
| subroutine | gs_crystal_nbwait_vec (this, u, n, nc, op, strm) |
| | Drive the remaining routing stages and reduce what is delivered into the shared vector, fused nc-component.
|
| |
Runs the halo exchange as a crystal router rather than as a message to every peer: the routing plan worked out once by gs_crystal_plan says, for each stage, which words leave for a single partner, which stay, and how many arrive. One gs operation therefore costs at most one message per active stage instead of one per peer, at the price of forwarding the words that are not yet home – see gs_crystal_plan.f90 for when that trade pays.
Only the first stage overlaps the local gather-scatter: it is posted from nbsend and completed in nbwait, which then drives the remaining stages back to back. Stages are dependent, so there is nothing to hide the later ones behind.
All MPI is issued from the master thread, so the backend needs nothing beyond MPI_THREAD_FUNNELED; the packing, forwarding and reduction loops are shared out over the team.
1.9.8