From 561f473bfc45df4316edae46e581f9d184d67c4e Mon Sep 17 00:00:00 2001 From: Martin Kronbichler Date: Fri, 1 May 2020 12:41:32 +0200 Subject: [PATCH] Comment on the use of thread-safe BLAS/LAPACK --- examples/step-51/step-51.cc | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/examples/step-51/step-51.cc b/examples/step-51/step-51.cc index f9ab7dcf33..084e576328 100644 --- a/examples/step-51/step-51.cc +++ b/examples/step-51/step-51.cc @@ -647,6 +647,15 @@ namespace Step51 // manner. The @p trace_reconstruct input parameter is used to decide // whether we are solving for the global skeleton solution (false) or the // local solution (true). + // + // One thing worth noting for the multi-threaded execution of assembly is + // the fact that the local computations in `assemble_system_one_cell()` call + // into BLAS and LAPACK functions if those are available in deal.II. Thus, + // the underlying BLAS/LAPACK library must support calls from multiple + // threads at the same time. Most implementations do support this, but some + // libraries need to be built in a specific way to avoid problems. For + // example, OpenBLAS compiled without multithreading inside the BLAS/LAPACK + // calls needs to built with a flag called `USE_LOCKING` set to true. template void HDG::assemble_system(const bool trace_reconstruct) { -- 2.39.5