October 2018 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] plex test 26 failing for complex
by Matthew Knepley 24 Oct '18

24 Oct '18

On Wed, Oct 24, 2018 at 9:54 AM Hapla Vaclav <vaclav.hapla(a)erdw.ethz.ch> wrote: > Tests dm_impls_plex_tests-ex26% fail for exodusii+complex build. > > E.g. > not ok dm_impls_plex_tests-ex26_15 > # [0]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > # [0]PETSC ERROR: Petsc has generated inconsistent data > # [0]PETSC ERROR: UAlpha ||Vin - Vout|| = 1000.56 > # > # [0]PETSC ERROR: See > http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting. > # [0]PETSC ERROR: Petsc Development GIT revision: > v3.10.1-219-g632bab2 GIT Date: 2018-10-24 12:51:19 +0200 > # [0]PETSC ERROR: ../ex26 on a arch-linux-gcc-complex-single-64idx > named swp-group-pc by vhapla Wed Oct 24 15:43:20 2018 > # [0]PETSC ERROR: Configure options --download-c2html > --download-f2cblaslapack --download-exodusii --download-hdf5 > --download-metis --download-netcdf --download-pnetcdf --download-parmetis > --download-ptscotch --download-ctetgen --with-64-bit-indices > --download-zlib --with-cc=mpicc --with-cxx=mpicxx --with-fc=mpifort > --with-precision=single --with-python=1 --with-scalar-type=complex > --with-shared-libraries=1 --with-valgrind-dir=/home/vhapla > PETSC_ARCH=arch-linux-gcc-complex-single-64idx > # [0]PETSC ERROR: #1 main() line 387 in > /home/vhapla/petsc-1/src/dm/impls/plex/examples/tests/ex26.c > > > Should this be fixed or "requires: !complex" added? > Yes. This is Blaise's test, and I do not know if it was intended to work with complex. Thanks, Matt > Is this configuration not covered by nightly tests? > > Vaclav -- 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/ <http://www.cse.buffalo.edu/~knepley/>

1 0

plex test 26 failing for complex
by Hapla Vaclav 24 Oct '18

24 Oct '18

Tests dm_impls_plex_tests-ex26% fail for exodusii+complex build. E.g. not ok dm_impls_plex_tests-ex26_15 # [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- # [0]PETSC ERROR: Petsc has generated inconsistent data # [0]PETSC ERROR: UAlpha ||Vin - Vout|| = 1000.56 # # [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting. # [0]PETSC ERROR: Petsc Development GIT revision: v3.10.1-219-g632bab2 GIT Date: 2018-10-24 12:51:19 +0200 # [0]PETSC ERROR: ../ex26 on a arch-linux-gcc-complex-single-64idx named swp-group-pc by vhapla Wed Oct 24 15:43:20 2018 # [0]PETSC ERROR: Configure options --download-c2html --download-f2cblaslapack --download-exodusii --download-hdf5 --download-metis --download-netcdf --download-pnetcdf --download-parmetis --download-ptscotch --download-ctetgen --with-64-bit-indices --download-zlib --with-cc=mpicc --with-cxx=mpicxx --with-fc=mpifort --with-precision=single --with-python=1 --with-scalar-type=complex --with-shared-libraries=1 --with-valgrind-dir=/home/vhapla PETSC_ARCH=arch-linux-gcc-complex-single-64idx # [0]PETSC ERROR: #1 main() line 387 in /home/vhapla/petsc-1/src/dm/impls/plex/examples/tests/ex26.c Should this be fixed or "requires: !complex" added? Is this configuration not covered by nightly tests? Vaclav

1 0

Assistant Professorship in Computational Earth-Surface Process Modeling at CU Boulder
by Jed Brown 23 Oct '18

23 Oct '18

The Institute of Arctic and Alpine Research (INSTAAR) and Community Surface Dynamics Modeling System (CSDMS) at the University of Colorado invite applications for a tenure-track assistant professor position in Computational Earth-Surface Process Modeling, with an August 2019 start. CSDMS is an NSF-sponsored facility that supports modeling and prediction of erosion, transport, and deposition of sediment in landscapes and sedimentary basins over a broad range of environments and time and space scales. The candidate will join a team at INSTAAR at the University of Colorado, Boulder, responsible for promoting the growth of CSDMS by developing multidisciplinary and international collaboration in support of earth surface processes modeling. We seek a scientist who takes advantage of new opportunities in computing and remote sensing to advance understanding of landscape, coastal, and/or seascape geomorphology and sediment dynamics. Disciplinary areas of particular interest include, but are not limited to: modeling of terrestrial, coastal, cryospheric, and/or marine processes; use of high-resolution topographic data to test process models; earth surface interactions with the climate system; modeling human impacts; high-performance computing; and community scientific software development. CSDMS is hosted at INSTAAR. The new assistant professor would be rostered in the Research & Innovation Office (RIO) and also become a tenure-track professor in one of INSTAAR’s affiliated academic departments and programs that best suits their training and interests (Geological Sciences; Civil, Environmental, and Architectural Engineering; Atmospheric and Ocean Sciences; Computer Science). A strong commitment to teaching, and mentorship at the undergraduate and graduate levels, and to outreach activities, is expected. The candidate is expected to engage in development of coursework in his or her area of research expertise, and to teach at the undergraduate and graduate level in the home department. Incorporation of computing skills in undergraduate and graduate curricula is desirable. Applicants should have a Ph.D. in geosciences, engineering, or related field at the time of appointment. We seek a strong team player with excellent communication and networking skills, who is focused on achieving multidisciplinary research goals. We welcome candidates who will bring diverse intellectual, geographical, gender, and ethnic perspectives to CSDMS and the University of Colorado campus community. For further information and to apply: https://jobs.colorado.edu/jobs/JobDetail/?jobId=13976

1 0

Re: [petsc-dev] PETSC_WITH_EXTERNAL_LIB is not including the correct gcc directories
by Hector E Barrios Molano 23 Oct '18

23 Oct '18

Satish, My problem is that my application links with PETSc and another library (Iphreeqc) that uses libstdc++. I compiled this other library with a newer gcc (6.1). Then, during the configuration of my application (with CMake) it looks into petscvariables to get the additional libraries required and there it gets the old gcc path. When I am linking my application the linker gets libstdc++ from the old path instead of the new path and it breaks. This is not a problem if I use the default gcc (but for the system I am working now it is quite old) or if I do not link another library which requirements can conflict. Best regards, Hector On 10/23/18 4:34 PM, Balay, Satish wrote: > BTW: You have not stated what problem you are encountering due to this reference to old gcc libraries from ifort. > > Satish > > On Tue, 23 Oct 2018, Balay, Satish wrote: > >> You can check 'ifort -v test.F' - to see how its using gcc internally. >> >> configure.log will have the details on where the path is coming from. [you can send us this log] >> >> PETSc configure attempts to determine the compiler libraries - and this part could show >> up with some paths that are not needed. >> >> Workaround is to manually specify these paths to petsc configure - so that it doesn't >> try to determine from 'ifort -v' - and pick up unneed stuff. >> >> ./configure LIBS=/path_to/libifcore.a >> >> [but then ifort changes this from libifcore.a to libifcoremt.a - if openmp is enabled] >> >> Satish >> >> >> On Tue, 23 Oct 2018, Hector E Barrios Molano wrote: >> >>> Thank you Satish for your response, >>> >>> Yes I am intended to use ifort with gcc. >>> >>> I changed ifort versions to one that does not include tbb. >>> >>> However, PETSc is still including -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 in >>> petscvariables, attached you will find an updated petscvariables file. >>> >>> ifort is not including any gcc, neither there is reference to this directory >>> in $PATH or $LD_LIBRARY_PATH, why is PETSc still including it? >>> >>> Thanks for your help, >>> >>> Hector >>> >>> >>> On 10/18/18 5:28 PM, Balay, Satish wrote: >>>>> -L/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1 >>>>> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 >>>> Its likely the gcc-4.1 stuff is coming from ifort. >>>> >>>> Did you intend to use ifort with gcc? [instead of gfortran?] >>>> >>>> Satish >>>> >>>> On Thu, 18 Oct 2018, Hector E Barrios Molano wrote: >>>> >>>>> Hi PETSc Experts! >>>>> >>>>> I am building PETSc from the git repository and it is strange that once >>>>> PETSc >>>>> is installed the petscvariables (PETSC_WITH_EXTERNAL_LIB) file shows a >>>>> different gcc library path that the one from the compiler used and the one >>>>> defined in LD_LIBRARY_PATH. This is causing me troubles when using PETSc >>>>> with >>>>> other library that requires libstdc++ >>>>> >>>>> Here is the command used to build PETSc: >>>>> ./configure --prefix=$DEV_lib_dir/petsc_git-debug >>>>> --PETSC_DIR=/home/hector/dwnld_prog/petsc --PETSC_ARCH=linux-intel-debug >>>>> --CC=mpicc --FC=mpifort --CXX=mpicxx --with-openmp=1 --with-valgrind=1 >>>>> --with-valgri >>>>> nd-dir=/home/hector/installed --with-parmetis-dir=$DEV_lib_dir/parmetis/ >>>>> --with-metis-dir=$DEV_lib_dir/parmetis/ >>>>> --with-zoltan-dir=$DEV_lib_dir/zoltan/ >>>>> --with-hypre-dir=$DEV_lib_dir/hypre --download-ptscotch >>>>> --with-blas-lapack-lib=\[${MKLR >>>>> OOT}/lib/intel64/libmkl_intel_lp64.a,${MKLROOT}/lib/intel64/libmkl_core.a,${MKLROOT}/lib/intel64/libmkl_intel_thread.a\] >>>>> --with-scalapack-include=${MKLROOT}/include >>>>> --with-scalapack-lib=\[${MKLROOT}/lib/intel64/libmkl_scalapack_lp64.a,${MK >>>>> LROOT}/lib/intel64/libmkl_blacs_intelmpi_lp64.a\] --with-shared-libraries=0 >>>>> --FC_LINKER_FLAGS="-qopenmp -qopenmp-link static" --FFLAGS="-qopenmp >>>>> -qopenmp-link static" --LIBS="-Wl,--start-group >>>>> ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a ${M >>>>> KLROOT}/lib/intel64/libmkl_core.a >>>>> ${MKLROOT}/lib/intel64/libmkl_intel_thread.a >>>>> -Wl,--end-group -liomp5 -ldl -lpthread -lm" >>>>> >>>>> Here is LD_LIBRARY_PATH: >>>>> echo $LD_LIBRARY_PATH >>>>> /home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/libraries_intel/openmpi/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/mic/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/ipp/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1:/share/apps/intel3/debugger_2016/libipt/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../tbb >>>>> /li >>>>> b/intel64_lin/gcc4.4:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../compiler/lib/intel64_lin:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/opt/gridengine/lib/lx26-amd64:/opt/openmpi/lib >>>>> >>>>> >>>>> Attached you will find the resulting petscvariables file. There in the >>>>> definition of PETSC_WITH_EXTERNAL_LIB it is not included the gcc-6.1 >>>>> directory >>>>> and instead gcc4.1 directory is included. >>>>> >>>>> >>>>> What could be the problem? Thank you for your help. >>>>> >>>>> Best regards, >>>>> >>>>> Hector >>>>> >>>>> >>>

1 0

Re: [petsc-dev] PETSC_WITH_EXTERNAL_LIB is not including the correct gcc directories
by Balay, Satish 23 Oct '18

23 Oct '18

BTW: You have not stated what problem you are encountering due to this reference to old gcc libraries from ifort. Satish On Tue, 23 Oct 2018, Balay, Satish wrote: > You can check 'ifort -v test.F' - to see how its using gcc internally. > > configure.log will have the details on where the path is coming from. [you can send us this log] > > PETSc configure attempts to determine the compiler libraries - and this part could show > up with some paths that are not needed. > > Workaround is to manually specify these paths to petsc configure - so that it doesn't > try to determine from 'ifort -v' - and pick up unneed stuff. > > ./configure LIBS=/path_to/libifcore.a > > [but then ifort changes this from libifcore.a to libifcoremt.a - if openmp is enabled] > > Satish > > > On Tue, 23 Oct 2018, Hector E Barrios Molano wrote: > > > Thank you Satish for your response, > > > > Yes I am intended to use ifort with gcc. > > > > I changed ifort versions to one that does not include tbb. > > > > However, PETSc is still including -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 in > > petscvariables, attached you will find an updated petscvariables file. > > > > ifort is not including any gcc, neither there is reference to this directory > > in $PATH or $LD_LIBRARY_PATH, why is PETSc still including it? > > > > Thanks for your help, > > > > Hector > > > > > > On 10/18/18 5:28 PM, Balay, Satish wrote: > > >> -L/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1 > > >> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 > > > Its likely the gcc-4.1 stuff is coming from ifort. > > > > > > Did you intend to use ifort with gcc? [instead of gfortran?] > > > > > > Satish > > > > > > On Thu, 18 Oct 2018, Hector E Barrios Molano wrote: > > > > > >> Hi PETSc Experts! > > >> > > >> I am building PETSc from the git repository and it is strange that once > > >> PETSc > > >> is installed the petscvariables (PETSC_WITH_EXTERNAL_LIB) file shows a > > >> different gcc library path that the one from the compiler used and the one > > >> defined in LD_LIBRARY_PATH. This is causing me troubles when using PETSc > > >> with > > >> other library that requires libstdc++ > > >> > > >> Here is the command used to build PETSc: > > >> ./configure --prefix=$DEV_lib_dir/petsc_git-debug > > >> --PETSC_DIR=/home/hector/dwnld_prog/petsc --PETSC_ARCH=linux-intel-debug > > >> --CC=mpicc --FC=mpifort --CXX=mpicxx --with-openmp=1 --with-valgrind=1 > > >> --with-valgri > > >> nd-dir=/home/hector/installed --with-parmetis-dir=$DEV_lib_dir/parmetis/ > > >> --with-metis-dir=$DEV_lib_dir/parmetis/ > > >> --with-zoltan-dir=$DEV_lib_dir/zoltan/ > > >> --with-hypre-dir=$DEV_lib_dir/hypre --download-ptscotch > > >> --with-blas-lapack-lib=\[${MKLR > > >> OOT}/lib/intel64/libmkl_intel_lp64.a,${MKLROOT}/lib/intel64/libmkl_core.a,${MKLROOT}/lib/intel64/libmkl_intel_thread.a\] > > >> --with-scalapack-include=${MKLROOT}/include > > >> --with-scalapack-lib=\[${MKLROOT}/lib/intel64/libmkl_scalapack_lp64.a,${MK > > >> LROOT}/lib/intel64/libmkl_blacs_intelmpi_lp64.a\] --with-shared-libraries=0 > > >> --FC_LINKER_FLAGS="-qopenmp -qopenmp-link static" --FFLAGS="-qopenmp > > >> -qopenmp-link static" --LIBS="-Wl,--start-group > > >> ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a ${M > > >> KLROOT}/lib/intel64/libmkl_core.a > > >> ${MKLROOT}/lib/intel64/libmkl_intel_thread.a > > >> -Wl,--end-group -liomp5 -ldl -lpthread -lm" > > >> > > >> Here is LD_LIBRARY_PATH: > > >> echo $LD_LIBRARY_PATH > > >> /home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/libraries_intel/openmpi/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/mic/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/ipp/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1:/share/apps/intel3/debugger_2016/libipt/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../tbb > > >> /li > > >> b/intel64_lin/gcc4.4:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../compiler/lib/intel64_lin:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/opt/gridengine/lib/lx26-amd64:/opt/openmpi/lib > > >> > > >> > > >> Attached you will find the resulting petscvariables file. There in the > > >> definition of PETSC_WITH_EXTERNAL_LIB it is not included the gcc-6.1 > > >> directory > > >> and instead gcc4.1 directory is included. > > >> > > >> > > >> What could be the problem? Thank you for your help. > > >> > > >> Best regards, > > >> > > >> Hector > > >> > > >> > > > > >

1 0

Re: [petsc-dev] PETSC_WITH_EXTERNAL_LIB is not including the correct gcc directories
by Balay, Satish 23 Oct '18

23 Oct '18

You can check 'ifort -v test.F' - to see how its using gcc internally. configure.log will have the details on where the path is coming from. [you can send us this log] PETSc configure attempts to determine the compiler libraries - and this part could show up with some paths that are not needed. Workaround is to manually specify these paths to petsc configure - so that it doesn't try to determine from 'ifort -v' - and pick up unneed stuff. ./configure LIBS=/path_to/libifcore.a [but then ifort changes this from libifcore.a to libifcoremt.a - if openmp is enabled] Satish On Tue, 23 Oct 2018, Hector E Barrios Molano wrote: > Thank you Satish for your response, > > Yes I am intended to use ifort with gcc. > > I changed ifort versions to one that does not include tbb. > > However, PETSc is still including -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 in > petscvariables, attached you will find an updated petscvariables file. > > ifort is not including any gcc, neither there is reference to this directory > in $PATH or $LD_LIBRARY_PATH, why is PETSc still including it? > > Thanks for your help, > > Hector > > > On 10/18/18 5:28 PM, Balay, Satish wrote: > >> -L/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1 > >> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 > > Its likely the gcc-4.1 stuff is coming from ifort. > > > > Did you intend to use ifort with gcc? [instead of gfortran?] > > > > Satish > > > > On Thu, 18 Oct 2018, Hector E Barrios Molano wrote: > > > >> Hi PETSc Experts! > >> > >> I am building PETSc from the git repository and it is strange that once > >> PETSc > >> is installed the petscvariables (PETSC_WITH_EXTERNAL_LIB) file shows a > >> different gcc library path that the one from the compiler used and the one > >> defined in LD_LIBRARY_PATH. This is causing me troubles when using PETSc > >> with > >> other library that requires libstdc++ > >> > >> Here is the command used to build PETSc: > >> ./configure --prefix=$DEV_lib_dir/petsc_git-debug > >> --PETSC_DIR=/home/hector/dwnld_prog/petsc --PETSC_ARCH=linux-intel-debug > >> --CC=mpicc --FC=mpifort --CXX=mpicxx --with-openmp=1 --with-valgrind=1 > >> --with-valgri > >> nd-dir=/home/hector/installed --with-parmetis-dir=$DEV_lib_dir/parmetis/ > >> --with-metis-dir=$DEV_lib_dir/parmetis/ > >> --with-zoltan-dir=$DEV_lib_dir/zoltan/ > >> --with-hypre-dir=$DEV_lib_dir/hypre --download-ptscotch > >> --with-blas-lapack-lib=\[${MKLR > >> OOT}/lib/intel64/libmkl_intel_lp64.a,${MKLROOT}/lib/intel64/libmkl_core.a,${MKLROOT}/lib/intel64/libmkl_intel_thread.a\] > >> --with-scalapack-include=${MKLROOT}/include > >> --with-scalapack-lib=\[${MKLROOT}/lib/intel64/libmkl_scalapack_lp64.a,${MK > >> LROOT}/lib/intel64/libmkl_blacs_intelmpi_lp64.a\] --with-shared-libraries=0 > >> --FC_LINKER_FLAGS="-qopenmp -qopenmp-link static" --FFLAGS="-qopenmp > >> -qopenmp-link static" --LIBS="-Wl,--start-group > >> ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a ${M > >> KLROOT}/lib/intel64/libmkl_core.a > >> ${MKLROOT}/lib/intel64/libmkl_intel_thread.a > >> -Wl,--end-group -liomp5 -ldl -lpthread -lm" > >> > >> Here is LD_LIBRARY_PATH: > >> echo $LD_LIBRARY_PATH > >> /home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/libraries_intel/openmpi/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/mic/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/ipp/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1:/share/apps/intel3/debugger_2016/libipt/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../tbb > >> /li > >> b/intel64_lin/gcc4.4:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../compiler/lib/intel64_lin:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/opt/gridengine/lib/lx26-amd64:/opt/openmpi/lib > >> > >> > >> Attached you will find the resulting petscvariables file. There in the > >> definition of PETSC_WITH_EXTERNAL_LIB it is not included the gcc-6.1 > >> directory > >> and instead gcc4.1 directory is included. > >> > >> > >> What could be the problem? Thank you for your help. > >> > >> Best regards, > >> > >> Hector > >> > >> > >

1 0

Re: [petsc-dev] PETSC_WITH_EXTERNAL_LIB is not including the correct gcc directories
by Hector E Barrios Molano 23 Oct '18

23 Oct '18

Thank you Satish for your response, Yes I am intended to use ifort with gcc. I changed ifort versions to one that does not include tbb. However, PETSc is still including -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 in petscvariables, attached you will find an updated petscvariables file. ifort is not including any gcc, neither there is reference to this directory in $PATH or $LD_LIBRARY_PATH, why is PETSc still including it? Thanks for your help, Hector On 10/18/18 5:28 PM, Balay, Satish wrote: >> -L/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1 >> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 > Its likely the gcc-4.1 stuff is coming from ifort. > > Did you intend to use ifort with gcc? [instead of gfortran?] > > Satish > > On Thu, 18 Oct 2018, Hector E Barrios Molano wrote: > >> Hi PETSc Experts! >> >> I am building PETSc from the git repository and it is strange that once PETSc >> is installed the petscvariables (PETSC_WITH_EXTERNAL_LIB) file shows a >> different gcc library path that the one from the compiler used and the one >> defined in LD_LIBRARY_PATH. This is causing me troubles when using PETSc with >> other library that requires libstdc++ >> >> Here is the command used to build PETSc: >> ./configure --prefix=$DEV_lib_dir/petsc_git-debug >> --PETSC_DIR=/home/hector/dwnld_prog/petsc --PETSC_ARCH=linux-intel-debug >> --CC=mpicc --FC=mpifort --CXX=mpicxx --with-openmp=1 --with-valgrind=1 >> --with-valgri >> nd-dir=/home/hector/installed --with-parmetis-dir=$DEV_lib_dir/parmetis/ >> --with-metis-dir=$DEV_lib_dir/parmetis/ --with-zoltan-dir=$DEV_lib_dir/zoltan/ >> --with-hypre-dir=$DEV_lib_dir/hypre --download-ptscotch >> --with-blas-lapack-lib=\[${MKLR >> OOT}/lib/intel64/libmkl_intel_lp64.a,${MKLROOT}/lib/intel64/libmkl_core.a,${MKLROOT}/lib/intel64/libmkl_intel_thread.a\] >> --with-scalapack-include=${MKLROOT}/include >> --with-scalapack-lib=\[${MKLROOT}/lib/intel64/libmkl_scalapack_lp64.a,${MK >> LROOT}/lib/intel64/libmkl_blacs_intelmpi_lp64.a\] --with-shared-libraries=0 >> --FC_LINKER_FLAGS="-qopenmp -qopenmp-link static" --FFLAGS="-qopenmp >> -qopenmp-link static" --LIBS="-Wl,--start-group >> ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a ${M >> KLROOT}/lib/intel64/libmkl_core.a ${MKLROOT}/lib/intel64/libmkl_intel_thread.a >> -Wl,--end-group -liomp5 -ldl -lpthread -lm" >> >> Here is LD_LIBRARY_PATH: >> echo $LD_LIBRARY_PATH >> /home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/libraries_intel/openmpi/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/mic/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/ipp/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1:/share/apps/intel3/debugger_2016/libipt/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../tbb/li >> b/intel64_lin/gcc4.4:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../compiler/lib/intel64_lin:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/opt/gridengine/lib/lx26-amd64:/opt/openmpi/lib >> >> >> Attached you will find the resulting petscvariables file. There in the >> definition of PETSC_WITH_EXTERNAL_LIB it is not included the gcc-6.1 directory >> and instead gcc4.1 directory is included. >> >> >> What could be the problem? Thank you for your help. >> >> Best regards, >> >> Hector >> >>

1 0

Re: [petsc-dev] Testing for deprecated MKL functions?
by Jed Brown 23 Oct '18

23 Oct '18

Yeah, I don't think there is anything wrong with checking INTEL_MKL_VERSION for this purpose. "Balay, Satish" <balay(a)mcs.anl.gov> writes: > On Tue, 23 Oct 2018, Mills, Richard Tran wrote: > >> On 10/23/18 2:31 PM, Matthew Knepley wrote: >> On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran <rtmills(a)anl.gov<mailto:[email protected]>> wrote: >> Barry, Satish, and others, >> >> In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces were deprecated in favor of the newer, inspector-executor versions. To keep lots of warnings from being generated, I put in some preprocessor code to avoid using these interfaces in AIJMKL, and the hack-y way I did this was simply based on whether PETSC_HAVE_MKL_SPARSE_SP2M is defined, since mkl_sparse_sp2m() was introduced in this same update and I needed a configure test for the presence of this function anyway. >> >> I now want to change the mkl_sparse_sp2m.py test to not define PETSC_HAVE_MKL_SPARSE_SP2M for versions of MKL prior to 2019, because I determined that the way I am using mkl_sparse_sp2m() is unsafe prior to this version. Since this will break my current logic for determining which MKL routines are deprecated, this seems like a good time to handle the deprecation in a better way. > > Check HAVE_MPI_WIN_CREATE_FEATURE code. Its probably messy - but the idea is - 'PETSC_HAVE_MKL_SPARSE_SP2M' should not be overloaded with this additional constranits. > > however 'PETSC_HAVE_MKL_SPARSE_SP2M_FEATURE' - can be used [flag set only when additional constraints are satisfied]. > >> >> I did some cursory grepping through the BuildSystem packages files, and it looks (?) like we don't have some examples to follow on how to handle deprecated library functions. What I'd like to do is compile a test that calls one of the deprecated functions and then checks for warning messages from the compiler, but I don't know the variants of all of the warning messages that compilers might emit, and I think some compilers won't give any. If there isn't a good way to do such a test, I could >> >> * Rely on the version information in mkl_version.h, OR >> * (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This was introduced when the old sparse BLAS interfaces were deprecated.) > > Assuming the feature works with this version check across all MKL impls [linux, mac, win] - I migh just do the version check. Processing warnings is fragile. > [note there is a version check for HAVE_MPI_WIN_CREATE_FEATURE] > > Satish >> >> I do not understand this one. You check for a #define, which happens to coincide with the change? >> Yes, MKL_DEPRECATED is a macro that is defined in MKL and used to tag the prototypes of the deprecated functions. This appears to be the first time that this macro has been used, so it coincides with the change. >> >> Is there a "best practice" for how we should handle such things in PETSc? >> >> Relying on compiler warnings seems bad unless its something that compilers are guaranteed to emit. >> Yeah. The motivation is to eliminate compiler warnings, but I don't know exactly what the warnings will be or whether a given compiler will even emit anything... >> >> --Richard >> >> Matt >> >> --Richard >> >> >> -- >> 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/<http://www.cse.buffalo.edu/%7Eknepley/> >> >>

1 0

Re: [petsc-dev] Testing for deprecated MKL functions?
by Balay, Satish 23 Oct '18

23 Oct '18

On Tue, 23 Oct 2018, Mills, Richard Tran wrote: > On 10/23/18 2:31 PM, Matthew Knepley wrote: > On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran <rtmills(a)anl.gov<mailto:[email protected]>> wrote: > Barry, Satish, and others, > > In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces were deprecated in favor of the newer, inspector-executor versions. To keep lots of warnings from being generated, I put in some preprocessor code to avoid using these interfaces in AIJMKL, and the hack-y way I did this was simply based on whether PETSC_HAVE_MKL_SPARSE_SP2M is defined, since mkl_sparse_sp2m() was introduced in this same update and I needed a configure test for the presence of this function anyway. > > I now want to change the mkl_sparse_sp2m.py test to not define PETSC_HAVE_MKL_SPARSE_SP2M for versions of MKL prior to 2019, because I determined that the way I am using mkl_sparse_sp2m() is unsafe prior to this version. Since this will break my current logic for determining which MKL routines are deprecated, this seems like a good time to handle the deprecation in a better way. Check HAVE_MPI_WIN_CREATE_FEATURE code. Its probably messy - but the idea is - 'PETSC_HAVE_MKL_SPARSE_SP2M' should not be overloaded with this additional constranits. however 'PETSC_HAVE_MKL_SPARSE_SP2M_FEATURE' - can be used [flag set only when additional constraints are satisfied]. > > I did some cursory grepping through the BuildSystem packages files, and it looks (?) like we don't have some examples to follow on how to handle deprecated library functions. What I'd like to do is compile a test that calls one of the deprecated functions and then checks for warning messages from the compiler, but I don't know the variants of all of the warning messages that compilers might emit, and I think some compilers won't give any. If there isn't a good way to do such a test, I could > > * Rely on the version information in mkl_version.h, OR > * (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This was introduced when the old sparse BLAS interfaces were deprecated.) Assuming the feature works with this version check across all MKL impls [linux, mac, win] - I migh just do the version check. Processing warnings is fragile. [note there is a version check for HAVE_MPI_WIN_CREATE_FEATURE] Satish > > I do not understand this one. You check for a #define, which happens to coincide with the change? > Yes, MKL_DEPRECATED is a macro that is defined in MKL and used to tag the prototypes of the deprecated functions. This appears to be the first time that this macro has been used, so it coincides with the change. > > Is there a "best practice" for how we should handle such things in PETSc? > > Relying on compiler warnings seems bad unless its something that compilers are guaranteed to emit. > Yeah. The motivation is to eliminate compiler warnings, but I don't know exactly what the warnings will be or whether a given compiler will even emit anything... > > --Richard > > Matt > > --Richard > > > -- > 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/<http://www.cse.buffalo.edu/%7Eknepley/> > >

1 0

Re: [petsc-dev] Testing for deprecated MKL functions?
by Mills, Richard Tran 23 Oct '18

23 Oct '18

On 10/23/18 2:31 PM, Matthew Knepley wrote: On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran <rtmills(a)anl.gov<mailto:[email protected]>> wrote: Barry, Satish, and others, In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces were deprecated in favor of the newer, inspector-executor versions. To keep lots of warnings from being generated, I put in some preprocessor code to avoid using these interfaces in AIJMKL, and the hack-y way I did this was simply based on whether PETSC_HAVE_MKL_SPARSE_SP2M is defined, since mkl_sparse_sp2m() was introduced in this same update and I needed a configure test for the presence of this function anyway. I now want to change the mkl_sparse_sp2m.py test to not define PETSC_HAVE_MKL_SPARSE_SP2M for versions of MKL prior to 2019, because I determined that the way I am using mkl_sparse_sp2m() is unsafe prior to this version. Since this will break my current logic for determining which MKL routines are deprecated, this seems like a good time to handle the deprecation in a better way. I did some cursory grepping through the BuildSystem packages files, and it looks (?) like we don't have some examples to follow on how to handle deprecated library functions. What I'd like to do is compile a test that calls one of the deprecated functions and then checks for warning messages from the compiler, but I don't know the variants of all of the warning messages that compilers might emit, and I think some compilers won't give any. If there isn't a good way to do such a test, I could * Rely on the version information in mkl_version.h, OR * (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This was introduced when the old sparse BLAS interfaces were deprecated.) I do not understand this one. You check for a #define, which happens to coincide with the change? Yes, MKL_DEPRECATED is a macro that is defined in MKL and used to tag the prototypes of the deprecated functions. This appears to be the first time that this macro has been used, so it coincides with the change. Is there a "best practice" for how we should handle such things in PETSc? Relying on compiler warnings seems bad unless its something that compilers are guaranteed to emit. Yeah. The motivation is to eliminate compiler warnings, but I don't know exactly what the warnings will be or whether a given compiler will even emit anything... --Richard Matt --Richard -- 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/<http://www.cse.buffalo.edu/%7Eknepley/>

1 0