From: Martin Kronbichler Date: Fri, 1 May 2020 10:41:32 +0000 (+0200) Subject: Comment on the use of thread-safe BLAS/LAPACK X-Git-Tag: v9.2.0-rc1~147^2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=561f473bfc45df4316edae46e581f9d184d67c4e;p=dealii.git Comment on the use of thread-safe BLAS/LAPACK --- 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) {