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 <balay@mcs.anl.gov> 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
>