On Tue, May 21, 2019 at 12:16 AM Smith, Barry F. <[email protected]> wrote:
> > Yes, this is totally my fault. By removing the help message it made > configure treat the argument as a string hence '0' was true and you got the > error message. For fblaslapack one should use -known-64-bit-blas-indices=0 > just as you did, I have pushed a fix to master > > What kind of system is sunfire09.pppl.gov ? Surely a system that has a > batch system provides its own good BLAS/LAPACK. You should use the ones on > the machine, not fblaslapack. Using fblaslapack in this situation is like > going to a fancy sit-down dinner but bringing your dessert from McDonalds. > We just want stuff to work. This machine is not well supported and we are using MUMPS, so we just want PETSc to build and be correct. Thanks > > It may be possible to remove many (but not all) of the cases where > -known-64-bit-blas-indices is needed (for example when MKL, fblaslapack, > f2blaslapack or --download-openblas is used we we know if the library is 64 > bit indices and should set that without a need for a test or command line > option. I'll look at it. > > Barry > > > > On May 20, 2019, at 3:50 PM, Balay, Satish via petsc-users < > [email protected]> wrote: > > > > I'm not yet sure what the correct fix is - but the following change > should get this going.. > > > > diff --git a/config/BuildSystem/config/packages/BlasLapack.py > b/config/BuildSystem/config/packages/BlasLapack.py > > index e0310da4b0..7355f1a369 100644 > > --- a/config/BuildSystem/config/packages/BlasLapack.py > > +++ b/config/BuildSystem/config/packages/BlasLapack.py > > @@ -42,7 +42,7 @@ class Configure(config.package.Package): > > help.addArgument('BLAS/LAPACK', '-with-lapack-lib=<libraries: e.g. > [/Users/..../liblapack.a,...]>',nargs.ArgLibrary(None, None, 'Indicate the > library(s) containing LAPACK')) > > help.addArgument('BLAS/LAPACK', > '-with-blaslapack-suffix=<string>',nargs.ArgLibrary(None, None, 'Indicate a > suffix for BLAS/LAPACK subroutine names.')) > > help.addArgument('BLAS/LAPACK', '-with-64-bit-blas-indices', > nargs.ArgBool(None, 0, 'Try to use 64 bit integers for BLAS/LAPACK; will > error if not available')) > > -# help.addArgument('BLAS/LAPACK', > '-known-64-bit-blas-indices=<bool>', nargs.ArgBool(None, 0, 'Indicate if > using 64 bit integer BLAS')) > > + help.addArgument('BLAS/LAPACK', > '-known-64-bit-blas-indices=<bool>', nargs.ArgBool(None, 0, 'Indicate if > using 64 bit integer BLAS')) > > return > > > > def getPrefix(self): > > > > Satish > > > > On Mon, 20 May 2019, Mark Adams via petsc-users wrote: > > > >> On Mon, May 20, 2019 at 3:55 PM Balay, Satish <[email protected]> > wrote: > >> > >>> for ex: ilp version of mkl is --known-64-bit-blas-indices=1 while lp > mkl > >>> is --known-64-bit-blas-indices=0 > >>> > >>> Default blas we normally use is --known-64-bit-blas-indices=0 [they > don't > >>> use 64bit indices] > >>> > >> > >> Humm, that is what Dylan (in the log that I sent). He is downloading > blas > >> and has --known-64-bit-blas-indices=0. Should this be correct? > >> > >> > >>> > >>> Satish > >>> > >>> On Mon, 20 May 2019, Mark Adams via petsc-users wrote: > >>> > >>>> We are getting this failure. This a bit frustrating in that the first > >>> error > >>>> message "Must give a default value for known-mpi-shared-libraries.." > OK, > >>> I > >>>> google it and find that =0 is suggested. That seemed to work. Then we > >>> got a > >>>> similar error about -known-64-bit-blas-indices. It was clear from the > >>>> documentation what to use so we tried =0 and that failed (attached). > This > >>>> is little frustrating having to use try and error for each of these > >>> 'known" > >>>> things. > >>>> > >>>> Dylan is trying --known-64-bit-blas-indices=1 now. I trust that will > >>> work, > >>>> but I think the error are not very informative. All this known stuff > is > >>> new > >>>> to me. Perhaps put an FAQ for this and list all of the "known"s that > we > >>>> need to add in batch. > >>>> > >>>> Thanks, > >>>> Mark > >>>> > >>> > >>> > >> > > > >
