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

Tao unusable from complex??
by Stefano Zampini 12 Dec '18

12 Dec '18

If I compile PETSc with complex support, all of the TAO methods are not registered. Fare enough? not really, I can imagine at least three valid reasons to use those 1) I want to check that my code works for complex builds, even if I have pure real function evaluations. I may need complex support in other parts or the code (not when using TAO), or I just want to be a diligent PETSc developer 2) I want to test REAL gradients or Hessians using built-in capability, instead of writing my own 3) I want to use the complex differentiation trick to compute REAL gradients Last time I checked, at least option 2) was available; However, from commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are registered when PETSC_USE_COMPLEX is defined, and code like the one below fail at runtime: TaoCreate() TaoSetFromOption() TaoSetObjectiveRoutine() TaoTestGradient() [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing package: http://www.mcs.anl.gov/petsc/documentation/installation.html#external [0]PETSC ERROR: Unable to find requested Tao type lmvm -- Stefano

1 0

Re: [petsc-dev] Unneeded check in TSSetUp?
by Lisandro Dalcin 11 Dec '18

11 Dec '18

On Tue, 11 Dec 2018 at 07:47, Stefano Zampini via petsc-dev < petsc-dev(a)mcs.anl.gov> wrote: > Yes, I have also noticed it. > IMHO, we should enforce the TSGetDM + DMCreateGlobalVector pattern > instead of duplicating ts->vec_sol in all the implementations. > I'll open a bitbucket issue if you agree > > As long as you do not break third party code that do not set a DM on TS, I would not object. Otherwise, I'll replace the sugar in your desk with salt, so you can have a really tasty afternoon coffee. -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0

Re: [petsc-dev] Unneeded check in TSSetUp?
by Smith, Barry F. 11 Dec '18

11 Dec '18

I guess > On Dec 11, 2018, at 4:45 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: > > Yes, I have also noticed it. > IMHO, we should enforce the TSGetDM + DMCreateGlobalVector pattern instead of duplicating ts->vec_sol in all the implementations. > I'll open a bitbucket issue if you agree > > Il giorno lun 10 dic 2018 alle ore 22:49 Smith, Barry F. <bsmith(a)mcs.anl.gov> ha scritto: > > No, it cannot be simply removed. If I remove it and run src/ts/examples/tutorials/ex1.c (after removing the TSSetSolution() and x argument to the TSSolve() I get the bad error > > $ ./ex1 > [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- > [0]PETSC ERROR: Null argument, when expecting valid pointer > [0]PETSC ERROR: Null Object: Parameter # 1 > [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.2-975-g84761bfe160 GIT Date: 2018-12-08 17:24:25 -0700 > [0]PETSC ERROR: ./ex1 on a arch-master named anlextwls003-196.wl.anl-external.org by barrysmith Mon Dec 10 13:40:15 2018 > [0]PETSC ERROR: Configure options > [0]PETSC ERROR: #1 VecDuplicate() line 376 in /Users/barrysmith/Src/petsc/src/vec/vec/interface/vector.c > [0]PETSC ERROR: #2 TSSetUp_Pseudo() line 300 in /Users/barrysmith/Src/petsc/src/ts/impls/pseudo/posindep.c > > > which is not useful to users. > > But I think it can be moved to TSSolve() after the call to TSSetUp(). > > Barry > > > > > On Dec 10, 2018, at 6:35 AM, Stefano Zampini via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > > > In TSSetUp, current master has > > > > if (!ts->vec_sol) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_ARG_WRONGSTATE,"Must call TSSetSolution() first"); > > > > but the function apparently does not make use of it. Would it be safe to remove the check? > > > > -- > > Stefano > > > > -- > Stefano

1 0

Re: [petsc-dev] default MPI in debian/ubuntu: openmpi vs mpich
by Drew Parsons 11 Dec '18

11 Dec '18

Thanks Jed, I'll pass that on to the debian thread. Normalising the MPI ABI sounds like a useful goal. Drew On 2018-12-08 13:15, Jed Brown wrote: > The Open MPI API is better for developers due to better type safety > (all > handles in MPICH are typedef'd to int). Most major commercial vendors > are organized around variants of MPICH (where there is collective ABI > standardization). Open MPI is more modular so most vendor stuff goes > into their plugins (for those vendors working with OMPI). > > I think a good solution for Linux distros (and many others) would be to > make a library that is ABI compatible with OMPI, but dispatches through > to MPICH. There exists a (messy) open source demonstration. > > https://github.com/cea-hpc/wi4mpi/ > > > Drew Parsons via petsc-dev <petsc-dev(a)mcs.anl.gov> writes: > >> Hi PETSc developers, >> >> Debian (and therefore Ubuntu) currently uses openmpi as the default >> MPI >> implementation. Some developers have encouraged us to switch to mpich, >> partly on experience of less bugs with mpich, partly around openmpi >> development policies. >> >> We're amenable to the idea but don't want to rush. The next Debian >> stable release is coming soon (around February) and we'd anticipate a >> lot of transition bugs (for instance scalapack currently builds for >> both >> openmpi and mpich, build tests pass openmpi but fail mpich). >> >> Equally importantly, pmix is in an uncertain state for mpich (and >> we've >> just finished closing outstanding pmix bugs with openmpi3. openmpi3 is >> stable now). Alastair McKinstry, the lead Debian MPI developer, >> thinks >> pmix support should be in order before going ahead with a transition >> to >> mpich, especially for container support (singularity). >> >> There's a discussion thread on Debian-Science at [1] (cc: to >> debian-release [2]). I'm writing to invite you to add your own >> experience to these discussions. >> >> Best regards, >> Drew Parsons >> Debian Developer / Debian Science member >> >> [1] https://lists.debian.org/debian-science/2018/12/msg00017.html >> [2] https://lists.debian.org/debian-release/2018/12/msg00162.html

1 0

Re: [petsc-dev] Unneeded check in TSSetUp?
by Stefano Zampini 11 Dec '18

11 Dec '18

Yes, I have also noticed it. IMHO, we should enforce the TSGetDM + DMCreateGlobalVector pattern instead of duplicating ts->vec_sol in all the implementations. I'll open a bitbucket issue if you agree Il giorno lun 10 dic 2018 alle ore 22:49 Smith, Barry F. <bsmith(a)mcs.anl.gov> ha scritto: > > No, it cannot be simply removed. If I remove it and run > src/ts/examples/tutorials/ex1.c (after removing the TSSetSolution() and x > argument to the TSSolve() I get the bad error > > $ ./ex1 > [0]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > [0]PETSC ERROR: Null argument, when expecting valid pointer > [0]PETSC ERROR: Null Object: Parameter # 1 > [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.2-975-g84761bfe160 > GIT Date: 2018-12-08 17:24:25 -0700 > [0]PETSC ERROR: ./ex1 on a arch-master named > anlextwls003-196.wl.anl-external.org by barrysmith Mon Dec 10 13:40:15 > 2018 > [0]PETSC ERROR: Configure options > [0]PETSC ERROR: #1 VecDuplicate() line 376 in > /Users/barrysmith/Src/petsc/src/vec/vec/interface/vector.c > [0]PETSC ERROR: #2 TSSetUp_Pseudo() line 300 in > /Users/barrysmith/Src/petsc/src/ts/impls/pseudo/posindep.c > > > which is not useful to users. > > But I think it can be moved to TSSolve() after the call to TSSetUp(). > > Barry > > > > > On Dec 10, 2018, at 6:35 AM, Stefano Zampini via petsc-dev < > petsc-dev(a)mcs.anl.gov> wrote: > > > > In TSSetUp, current master has > > > > if (!ts->vec_sol) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_ARG_WRONGSTATE,"Must > call TSSetSolution() first"); > > > > but the function apparently does not make use of it. Would it be safe to > remove the check? > > > > -- > > Stefano > > -- Stefano

1 0

Re: [petsc-dev] Unneeded check in TSSetUp?
by Smith, Barry F. 10 Dec '18

10 Dec '18

No, it cannot be simply removed. If I remove it and run src/ts/examples/tutorials/ex1.c (after removing the TSSetSolution() and x argument to the TSSolve() I get the bad error $ ./ex1 [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: Null argument, when expecting valid pointer [0]PETSC ERROR: Null Object: Parameter # 1 [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.2-975-g84761bfe160 GIT Date: 2018-12-08 17:24:25 -0700 [0]PETSC ERROR: ./ex1 on a arch-master named anlextwls003-196.wl.anl-external.org by barrysmith Mon Dec 10 13:40:15 2018 [0]PETSC ERROR: Configure options [0]PETSC ERROR: #1 VecDuplicate() line 376 in /Users/barrysmith/Src/petsc/src/vec/vec/interface/vector.c [0]PETSC ERROR: #2 TSSetUp_Pseudo() line 300 in /Users/barrysmith/Src/petsc/src/ts/impls/pseudo/posindep.c which is not useful to users. But I think it can be moved to TSSolve() after the call to TSSetUp(). Barry > On Dec 10, 2018, at 6:35 AM, Stefano Zampini via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > In TSSetUp, current master has > > if (!ts->vec_sol) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_ARG_WRONGSTATE,"Must call TSSetSolution() first"); > > but the function apparently does not make use of it. Would it be safe to remove the check? > > -- > Stefano

1 0

Unneeded check in TSSetUp?
by Stefano Zampini 10 Dec '18

10 Dec '18

In TSSetUp, current master has if (!ts->vec_sol) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_ARG_WRONGSTATE,"Must call TSSetSolution() first"); but the function apparently does not make use of it. Would it be safe to remove the check? -- Stefano

1 0

Docker images and NERSC's Shifter
by Jed Brown 09 Dec '18

09 Dec '18

The PETSc and FEniCS Dockerfiles and linked images here might be of interest to anyone running at an HPC facility that supports NERSC's Shifter. https://github.com/jedbrown/jedbrown-dockerfiles IMO, Shifter is far superior to any other HPC deployment mechanism and really should be supported everywhere. Using SLURM, it boils down to running (once) shifterimg pull docker:jedbrown/petsc:latest then sbatch --image docker:jedbrown/petsc:latest ... with srun -n 64 shifter ./your-petsc-app No need to futz with HPC build environments, modules, etc. You can build in the Shifter environment on a login node (see README). If you must use Python or other shared libraries, performance at scale is better (https://docs.nersc.gov/development/shifter/overview/) than any other low-hassle Python deployment technique. Comments welcome. I think we should consider automating the publishing of nightly updates for 'maint' and 'master', perhaps with a few common build configurations (int64, etc.). You'll notice that the Dockerfiles have some manual repairs for overzealous RPATH. We should have a configure option to avoid RPATH, and perhaps default to not using RPATH for any paths that don't need it (i.e., those that are already managed by the system ldconfig).

1 0

Re: [petsc-dev] default MPI in debian/ubuntu: openmpi vs mpich
by Jed Brown 07 Dec '18

07 Dec '18

The Open MPI API is better for developers due to better type safety (all handles in MPICH are typedef'd to int). Most major commercial vendors are organized around variants of MPICH (where there is collective ABI standardization). Open MPI is more modular so most vendor stuff goes into their plugins (for those vendors working with OMPI). I think a good solution for Linux distros (and many others) would be to make a library that is ABI compatible with OMPI, but dispatches through to MPICH. There exists a (messy) open source demonstration. https://github.com/cea-hpc/wi4mpi/ Drew Parsons via petsc-dev <petsc-dev(a)mcs.anl.gov> writes: > Hi PETSc developers, > > Debian (and therefore Ubuntu) currently uses openmpi as the default MPI > implementation. Some developers have encouraged us to switch to mpich, > partly on experience of less bugs with mpich, partly around openmpi > development policies. > > We're amenable to the idea but don't want to rush. The next Debian > stable release is coming soon (around February) and we'd anticipate a > lot of transition bugs (for instance scalapack currently builds for both > openmpi and mpich, build tests pass openmpi but fail mpich). > > Equally importantly, pmix is in an uncertain state for mpich (and we've > just finished closing outstanding pmix bugs with openmpi3. openmpi3 is > stable now). Alastair McKinstry, the lead Debian MPI developer, thinks > pmix support should be in order before going ahead with a transition to > mpich, especially for container support (singularity). > > There's a discussion thread on Debian-Science at [1] (cc: to > debian-release [2]). I'm writing to invite you to add your own > experience to these discussions. > > Best regards, > Drew Parsons > Debian Developer / Debian Science member > > [1] https://lists.debian.org/debian-science/2018/12/msg00017.html > [2] https://lists.debian.org/debian-release/2018/12/msg00162.html

1 0

default MPI in debian/ubuntu: openmpi vs mpich
by Drew Parsons 07 Dec '18

07 Dec '18

Hi PETSc developers, Debian (and therefore Ubuntu) currently uses openmpi as the default MPI implementation. Some developers have encouraged us to switch to mpich, partly on experience of less bugs with mpich, partly around openmpi development policies. We're amenable to the idea but don't want to rush. The next Debian stable release is coming soon (around February) and we'd anticipate a lot of transition bugs (for instance scalapack currently builds for both openmpi and mpich, build tests pass openmpi but fail mpich). Equally importantly, pmix is in an uncertain state for mpich (and we've just finished closing outstanding pmix bugs with openmpi3. openmpi3 is stable now). Alastair McKinstry, the lead Debian MPI developer, thinks pmix support should be in order before going ahead with a transition to mpich, especially for container support (singularity). There's a discussion thread on Debian-Science at [1] (cc: to debian-release [2]). I'm writing to invite you to add your own experience to these discussions. Best regards, Drew Parsons Debian Developer / Debian Science member [1] https://lists.debian.org/debian-science/2018/12/msg00017.html [2] https://lists.debian.org/debian-release/2018/12/msg00162.html

1 0