[petsc-users] [Ext] Re: Two simple questions on building

[Satish Balay]

On Wed, 16 Mar 2022, Matthew Knepley wrote:

> On Wed, Mar 16, 2022 at 9:30 AM Ernesto Prudencio via petsc-users <
> petsc-users at mcs.anl.gov> 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 <knepley at gmail.com>
> > *Sent:* Wednesday, March 16, 2022 5:45 AM
> > *To:* Ernesto Prudencio <EPrudencio at slb.com>
> > *Cc:* PETSc users list <petsc-users at mcs.anl.gov>
> > *Subject:* [Ext] Re: [petsc-users] Two simple questions on building
> >
> >
> >
> > On Wed, Mar 16, 2022 at 1:04 AM Ernesto Prudencio via petsc-users <
> > petsc-users at 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:
> >
> >    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
> >
> 
> 
>