Hi Ernesto, I hope you are doing well. I agree with Satish. It would be best to resolve the issues with the pure MKL approach. Any "hack" that got the libraries to work mixing fblaslapack and MKL would be fragile and untrustworthy.
Feel free to email to petsc-ma...@mcs.anl.gov <mailto:petsc-ma...@mcs.anl.gov> the configure.log make.log and failure information in the pure MKL approach so we can take a look at it. Since you doing this in a controlled environment presumably we can even reproduce the problem with enough information on your build process and track down the underlying cause. Barry > On Mar 16, 2022, at 1:03 AM, Ernesto Prudencio via petsc-users > <petsc-users@mcs.anl.gov> 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: > 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). > 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)? > > Question 2) In the case PETSc, is there any problem if run “make” and “make > install” without specifying PETSC_ARCH? > > Thank you in advance, > > Ernesto. > > Schlumberger-Private
