Thanks, yes, I figured out the OMP_NUM_THREADS=1 way while triaging it, and the --download-fblaslapack way occurred to me.
I was hoping for something that "just worked" (refuse to build in this case) but I don't know if it's programmatically possible for petsc to tell whether or not it's linking to a threaded BLAS? On Wed, Dec 7, 2022 at 4:35 PM Satish Balay <[email protected]> wrote: > If you don't specify a blas to use - petsc configure will guess and use > what it can find. > > So only way to force it use a particular blas is to specify one [one way > is --download-fblaslapack] > > Wrt multi-thread openblas - you can force it run single threaded [by one > of these 2 env variables] > > # Use single thread openblas > export OPENBLAS_NUM_THREADS=1 > export OMP_NUM_THREADS=1 > > Satish > > > On Wed, 7 Dec 2022, Mark Lohry wrote: > > > I ran into an unexpected issue -- on an NP-core machine, each MPI rank of > > my application was launching NP threads, such that when running with > > multiple ranks the machine was quickly oversubscribed and performance > > tanked. > > > > The root cause of this was petsc linking against the system-provided > > library (libopenblas0-pthread in this case) set by the > update-alternatives > > in ubuntu. At some point this machine got updated to using the threaded > > blas implementation instead of serial; not sure how, and I wouldn't have > > noticed if I weren't running interactively. > > > > Is there any mechanism in petsc or its build system to prevent linking > > against an inappropriate BLAS, or do I need to be diligent about manually > > setting the BLAS library in the configuration stage? > > > > Thanks, > > Mark > > > >
