September 2015 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Satish Balay 22 Sep '15

22 Sep '15

On Tue, 22 Sep 2015, Jed Brown wrote: > Satish Balay <balay(a)mcs.anl.gov> writes: > > [Jed suggested we should 'always use FC as linker' and not do any such > > detection. But then we still have to worry about C++. Previously we > > had machines where we had to use C++ linker - but perhaps such > > machines don't exist anymore] > > We might only need to distinguish -lstdc++ and -lc++. It's certainly > simpler and more consistent than finding Fortran run-time libraries. And then the MPI c++ libraries.. Satish

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Jed Brown 22 Sep '15

22 Sep '15

Satish Balay <balay(a)mcs.anl.gov> writes: > [Jed suggested we should 'always use FC as linker' and not do any such > detection. But then we still have to worry about C++. Previously we > had machines where we had to use C++ linker - but perhaps such > machines don't exist anymore] We might only need to distinguish -lstdc++ and -lc++. It's certainly simpler and more consistent than finding Fortran run-time libraries.

1 0

Re: [petsc-dev] including PETSc4py (and Tao4py) inside PETSc repository
by Matthew Knepley 22 Sep '15

22 Sep '15

On Tue, Sep 22, 2015 at 3:39 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Lisandro, > > Now that everyone is using git and knows branches well can we move > PETSc4py inside the PETSc repository as was done a couple of years ago with > BuildSystem. Now when changes/additions are made to PETSc there is a slow > inefficient, often forgotten manual process of bringing them over to > petsc4py. If we put them all in one repository the updates happen quickly > and far more efficiently, as would testing. We'll also get the ability to > do bi-section. > > I realize you want a PETSc4py release to be compatible with previous > versions of PETSc; this property could still remain and we could easily > have a tool that "pulls out" the petsc4py release material from the petsc > repository. > > I think once we make this change we'll wonder why we didn't do it log > ago; just as when we changed BuildSystem. Thoughts? > I agree with this. The biggest thing to work on (for me) is to make it easier and less complex to add things, like classes, to petsc4py. Right now we need to change 7 different places to add a class. Matt > Thanks > > Barry > > -- 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

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Satish Balay 22 Sep '15

22 Sep '15

I'm not sure what to suggest. Blaise gets a successful build with: --with-cxx=0 --with-clib-autodetect=0 --with-fortranlib-autodetect=0 LIBS="/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a" The next thing Blaise could try is: --with-cxx=0 --with-clib-autodetect=0 --with-fortranlib-autodetect=0 LIBS=-lifcore [and if this fails - see which ifcore the binary is using - via 'otool -l petscbinary |grep ifore'] If not - what I would do - is try compiling an example with a petsc makefile. [with the broken build] And then copy/paste the link line - removing stuff - until the binary created by that link line works. [and identify the linker option is making the difference]. Again - this would be for Blaise to try. Intel compilers (esp on Mac) had workarrounds to system issues encoded in the link command. [I remember the first generation of intel compilers on Mac had such issues]. And the way PETSc configure, and checkFortranLibraries() process/use this 'ifort -v' info can break these encoded workarrounds.. [Its a hacky piece of code - and not easy to get right] Ideally compilers should provide equivalent of 'mpicc -show' - so that configure tools can grab and use this info for language interoperable linking. [Jed suggested we should 'always use FC as linker' and not do any such detection. But then we still have to worry about C++. Previously we had machines where we had to use C++ linker - but perhaps such machines don't exist anymore] Satish On Tue, 22 Sep 2015, Richard Mills wrote: > Blaise and Satish, > > I'm a bit slow to pick up on this thread as I was busy traveling, but since > I use a Mac and work for Intel, I thought I should see if I could reproduce > the problems that Blaise is seeing. I installed the 16.0 compilers and > built a simple configuration ('--with-debugging=1 COPTFLAGS="-g -O0" > FOPTFLAGS="-g -O0" CXXOPTFLAGS="-g -O0" > --with-blas-lapack-dir=/opt/intel/compilers_and_libraries_2016/mac/mkl > --with-mpi-dir=/Users/rtmills/packages/mpich-3.1.4-intel') using a very > recent revision of 'master' (09b4d96fa5749f82a0af9a914729f77a4ef2b2fd, Sun > Sep 20 22:51:31 2015 -0500). When I try running SNES ex5f and passing > various command-line options, everything appears to work fine. Any > suggestions for digging deeping into this to try to determine the > difference between what Blaise and I are seeing? > > Best regards, > Richard > > On Mon, Sep 21, 2015 at 10:21 AM, Blaise A Bourdin <bourdin(a)lsu.edu> wrote: > > > > > > On Sep 20, 2015, at 9:04 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > > > Hm - I would suggest doing a minimal build build with: > > > > > > --with-cxx=0 > > > --with-clib-autodetect=0 --with-fortranlib-autodetect=0 > > LIBS="/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a" > > > > > > And see if that makes a difference. > > Satish, > > > > It does help. > > Turning off auto detect leads to a functional build, turning it back on > > leads to a non-functioning one. > > > > The configure.log without auto detect is here: > > > > https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/61967j4XaVp > > The one with auto detect there: > > https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/691pPOSRU > > > > The petscconf.h are attached > > > > >

1 0

including PETSc4py (and Tao4py) inside PETSc repository
by Barry Smith 22 Sep '15

22 Sep '15

Lisandro, Now that everyone is using git and knows branches well can we move PETSc4py inside the PETSc repository as was done a couple of years ago with BuildSystem. Now when changes/additions are made to PETSc there is a slow inefficient, often forgotten manual process of bringing them over to petsc4py. If we put them all in one repository the updates happen quickly and far more efficiently, as would testing. We'll also get the ability to do bi-section. I realize you want a PETSc4py release to be compatible with previous versions of PETSc; this property could still remain and we could easily have a tool that "pulls out" the petsc4py release material from the petsc repository. I think once we make this change we'll wonder why we didn't do it log ago; just as when we changed BuildSystem. Thoughts? Thanks Barry

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Richard Mills 22 Sep '15

22 Sep '15

Blaise and Satish, I'm a bit slow to pick up on this thread as I was busy traveling, but since I use a Mac and work for Intel, I thought I should see if I could reproduce the problems that Blaise is seeing. I installed the 16.0 compilers and built a simple configuration ('--with-debugging=1 COPTFLAGS="-g -O0" FOPTFLAGS="-g -O0" CXXOPTFLAGS="-g -O0" --with-blas-lapack-dir=/opt/intel/compilers_and_libraries_2016/mac/mkl --with-mpi-dir=/Users/rtmills/packages/mpich-3.1.4-intel') using a very recent revision of 'master' (09b4d96fa5749f82a0af9a914729f77a4ef2b2fd, Sun Sep 20 22:51:31 2015 -0500). When I try running SNES ex5f and passing various command-line options, everything appears to work fine. Any suggestions for digging deeping into this to try to determine the difference between what Blaise and I are seeing? Best regards, Richard On Mon, Sep 21, 2015 at 10:21 AM, Blaise A Bourdin <bourdin(a)lsu.edu> wrote: > > > On Sep 20, 2015, at 9:04 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > Hm - I would suggest doing a minimal build build with: > > > > --with-cxx=0 > > --with-clib-autodetect=0 --with-fortranlib-autodetect=0 > LIBS="/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a" > > > > And see if that makes a difference. > Satish, > > It does help. > Turning off auto detect leads to a functional build, turning it back on > leads to a non-functioning one. > > The configure.log without auto detect is here: > > https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/61967j4XaVp > The one with auto detect there: > https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/691pPOSRU > > The petscconf.h are attached > >

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Blaise A Bourdin 21 Sep '15

21 Sep '15

> On Sep 20, 2015, at 9:04 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > Hm - I would suggest doing a minimal build build with: > > --with-cxx=0 > --with-clib-autodetect=0 --with-fortranlib-autodetect=0 LIBS="/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a" > > And see if that makes a difference. Satish, It does help. Turning off auto detect leads to a functional build, turning it back on leads to a non-functioning one. The configure.log without auto detect is here: https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/61967j4XaVp The one with auto detect there: https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/691pPOSRU The petscconf.h are attached

1 0

Re: [petsc-dev] Fwd: [petsc-maint] Petsc configure Error on Edison on NERSC
by Patrick Sanan 21 Sep '15

21 Sep '15

One place where those options are currently documented is in config/examples/arch-cray-*, but I'm not sure if all users find those. Some simple changes to http://www.mcs.anl.gov/petsc/documentation/installation.html might help, for instance, under "Encounter Problems?" an entry could be added which says "Examine config/examples/*.py for settings which might be relevant to your system". The settings I use to build PETSc on the cray XC30 and XC40 are similar to those in the xt5 and xt6 examples, at least as far as the big gotchas are concerned. Out of curiosity, are these still relevant on current cray machines? '--COPTFLAGS=-fast -mp', '--CXXOPTFLAGS=-fast -mp', '--FOPTFLAGS=-fast -mp', On Sun, Sep 20, 2015 at 03:51:03PM -0500, Barry Smith wrote: > > Satish, > > We get too many mails like this, it wastes our time and their time. In config/configure.py please add checks if the machine is a cray > that the user did not provide an MPI dir, and that the user did pass in > > '--with-clib-autodetect=0', > '--with-cxxlib-autodetect=0', > '--with-fortranlib-autodetect=0', > > and any other mandatory things and error out with a very useful error message telling them what options to use and not to use. > > Barry > > It is absurd to think that somehow Cray users will magically know to use the auto detect = 0 flag and not provide an MPI dir etc. > > > > > > Begin forwarded message: > > > > From: Phani Motamarri <phanim(a)umich.edu> > > Subject: [petsc-maint] Petsc configure Error on Edison on NERSC > > Date: September 20, 2015 at 3:39:22 PM CDT > > To: petsc-maint <petsc-maint(a)mcs.anl.gov> > > > > Hi, > > > > I am trying to compile PETSc on Edison one of the NERSC clusters. However I get the following > > configure error > > "C libraries cannot directly be used from Fortran". > > > > I am wondering if I am missing anything. I attaching configure.log with this email. > > > > Regards > > Phani >

1 0

Re: [petsc-dev] DMSetUseNatural() and DMPlexConstructGhostCells()
by Adrian Croucher 21 Sep '15

21 Sep '15

On 20/07/15 22:51, Matthew Knepley wrote: > > > It looks a bit like DMPlexConstructGhostCells() might be messing > with the DM's sfNatural property? or does this not work the way I > think it should? > > > Thats a bug. CreateGhostCells() makes an entirely new DM, and the > SetNatural is a piece of state which did not get carried over. I will > fix it. > Was there a fix for this? I'm just starting to look at this stuff again, and it still seems to be having the same problem. Cheers, Adrian -- Dr Adrian Croucher Senior Research Fellow Department of Engineering Science University of Auckland, New Zealand email: a.croucher(a)auckland.ac.nz tel: +64 (0)9 923 84611

1 0

Fwd: [petsc-maint] Petsc configure Error on Edison on NERSC
by Barry Smith 20 Sep '15

20 Sep '15

Satish, We get too many mails like this, it wastes our time and their time. In config/configure.py please add checks if the machine is a cray that the user did not provide an MPI dir, and that the user did pass in '--with-clib-autodetect=0', '--with-cxxlib-autodetect=0', '--with-fortranlib-autodetect=0', and any other mandatory things and error out with a very useful error message telling them what options to use and not to use. Barry It is absurd to think that somehow Cray users will magically know to use the auto detect = 0 flag and not provide an MPI dir etc. > Begin forwarded message: > > From: Phani Motamarri <phanim(a)umich.edu> > Subject: [petsc-maint] Petsc configure Error on Edison on NERSC > Date: September 20, 2015 at 3:39:22 PM CDT > To: petsc-maint <petsc-maint(a)mcs.anl.gov> > > Hi, > > I am trying to compile PETSc on Edison one of the NERSC clusters. However I get the following > configure error > "C libraries cannot directly be used from Fortran". > > I am wondering if I am missing anything. I attaching configure.log with this email. > > Regards > Phani

1 0