On Wed, 16 Mar 2022, Matthew Knepley wrote: > On Wed, Mar 16, 2022 at 9:30 AM Ernesto Prudencio via petsc-users < > [email protected]> wrote: > > > Thanks, Matt. > > > > > > Regarding the blas/lapack used by PETSc via the –download-fblaslapack > > configuration option: are the libraries consumed as .a or as .so? > > > > Those are .a
However - note that petsc library build defaults to shared - so it links in with these blas .a files [so a copy gets into libpetsc.so]. Alternative is to build PETSc --with-shared-libraries=0 Another alternative is to just install system blas/lapack in the container - and use that instead of download-fblaslapack > > > > My question was related to the situation where they would be .so, with my > > LD_LIBRARY_PATH pointing first to the MKL path and then to the PETSc path. > > Would that cause PETSc to use the blas/lapack from MKL at run time, instead > > of the blas/lapack use at compilation time? I would think the first resolved symbol should get used. Also one can also use LD_PRELOAD to force loading MKL libraries first. > > > > It would, but since BLAS/LAPACK does not have a standard ABI there can > still be problems I think. > > > > Regarding your question on (a): at the end of the PETSc building process, > > a docker image has to be created, but then there are some soft links in the > > supplied MKL library which are not resolved. The problem boils down to > > details on where the MKL is actually located, and the overall compilation > > environment used for all software, where certain rules have to be enforced > > for all. > > > > Oh, yes for a container you would have to install MKL into the container > just as you would install it anywhere else. Then install PETSc in the > container. > I have done that for another project and got it to work. Yeah - its best to figure out the issue here - and build PETSc with MKL. Perhaps LD_PRELOAD will help here. I would think LD_LIBRARY_PATH should enable the resolution of the paths [should be verifiable with ldd] - or perhaps there is some other subtle issue here. Satish > > Thanks, > > Matt > > > > Cheers, > > > > > > > > Ernesto. > > > > > > > > *From:* Matthew Knepley <[email protected]> > > *Sent:* Wednesday, March 16, 2022 5:45 AM > > *To:* Ernesto Prudencio <[email protected]> > > *Cc:* PETSc users list <[email protected]> > > *Subject:* [Ext] Re: [petsc-users] Two simple questions on building > > > > > > > > On Wed, Mar 16, 2022 at 1:04 AM Ernesto Prudencio via petsc-users < > > [email protected]> wrote: > > > > Hi. > > > > > > > > I have an application that uses MKL for some convolution operations. Such > > MKL functionality uses, I suppose, BLAS/LAPACK underneath. > > > > > > > > This same application of mine also uses PETSc for other purposes. I can > > supply blas and lapack to PETSc in two ways: > > > > 1. Using the configuration > > option--with-blaslapack-lib="-L${MKL_DIR}/lib/intel64 -lfile1 -lfile2 … > > ". > > For reasons related to compilation environments + docker images + cloud, > > I > > am having issues with this option (a) _*after*_ PETSc builds > > successfully (both make and make install work fine). > > 2. Using the configuration option --download-fblaslapack=yes. This > > options works fine for the purpose of generating my application > > executable. > > > > > > > > If I use option (b), I understand that I will have two different > > blas/lapack codes available during the execution of my application: one > > from MKL, the other being the one that PETSc downloads during its > > configuration. > > > > > > > > Question 1) Do you foresee any potential run time issue with option (b)? > > > > > > > > All those BLAS/LAPACK functions have the same name. If MKL does something > > slightly different in one, you could have problems. The annoying thing is > > that it will probably work 99% of the time. > > > > > > > > What problem do you have with a)? > > > > > > > > Question 2) In the case PETSc, is there any problem if run “make” and > > “make install” without specifying PETSC_ARCH? > > > > > > > > It will choose an ARCH if you do not specify one. > > > > > > > > Thanks, > > > > > > > > Matt > > > > > > > > > > > > Thank you in advance, > > > > > > > > Ernesto. > > > > > > > > Schlumberger-Private > > > > > > > > > > -- > > > > What most experimenters take for granted before they begin their > > experiments is infinitely more interesting than any results to which their > > experiments lead. > > -- Norbert Wiener > > > > > > > > https://www.cse.buffalo.edu/~knepley/ > > <https://urldefense.com/v3/__http:/www.cse.buffalo.edu/*knepley/__;fg!!Kjv0uj3L4nM6H-I!1YIcv0EOPSK_loLVyLJiARQF8B0wUp96gOBWK4L-7PdpPbhDZIEQPSkoe3a2pw$> > > > > Schlumberger-Private > > > > >
