April 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] pip cannot currently automatically download and install petsc on OS X
by Matthew Knepley 18 Apr '12

18 Apr '12

On Wed, Apr 18, 2012 at 8:18 AM, Aron Ahmadia <aron.ahmadia(a)kaust.edu.sa>wrote: > Lisandro has fixed the first issue, but another has sprung up in its place: > > pip seems to be installing the packages out of order and insists on > building petsc4py before petsc. We still have the issue with petsc wanting > mpif90 available on OS X... > Where are the configure arguments stored so I can look at them? Matt > A > > > On Wed, Apr 18, 2012 at 2:57 PM, Aron Ahmadia <aron(a)ahmadia.net> wrote: > >> This is on an OS X.6 box running Python 2.7 and pip 1.0.2 >> >> # at command line: >> pip install -vvv petsc4py >> >> # relevant bits: >> Downloading/unpacking petsc>=3.2,<3.3 (from petsc4py) >> Getting page http://pypi.python.org/simple/petsc >> URLs to search for versions for petsc>=3.2,<3.3 (from petsc4py): >> * http://pypi.python.org/simple/petsc/ >> Getting page http://www.mcs.anl.gov/petsc/ >> ... >> Skipping page >> http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-lite-3.2-p6.tar.gz… >> http://pypi.python.org/simple/petsc/) because of Content-Type: >> application/x-gzip >> ... >> >> Found link >> http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-lite-3.2-p6.tar.gz… >> http://pypi.python.org/simple/petsc/) version: lite-3.2-p6 >> >> The "lite-" prefix is being interpreted as part of the version, which pip >> doesn't quite know what to do with. It would probably just be easiest to >> host lite versions in a separate directory >> ../release-snapshots/lite/petsc-3.2-p6.tar.gz that petsc4py/PyPI can point >> to. Lisandro can also point to the non-lite versions until a solution is >> implemented. >> >> This is going to be an additional problem: >> >> >> ******************************************************************************* >> >> UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for >> details): >> >> >> ------------------------------------------------------------------------------- >> >> Fortran compiler you provided with --with-fc=/usr/bin/mpif90 does not work >> >> ******************************************************************************* >> >> Obviously the Mac doesn't come with /usr/bin/mpif90, so a clean system >> won't have this either... I think you guys know your options for how to >> fix this, but let me know if you want my 2 cents :) >> >> =AA= >> > > -- 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] pip cannot currently automatically download and install petsc on OS X
by Aron Ahmadia 18 Apr '12

18 Apr '12

Lisandro has fixed the first issue, but another has sprung up in its place: pip seems to be installing the packages out of order and insists on building petsc4py before petsc. We still have the issue with petsc wanting mpif90 available on OS X... A On Wed, Apr 18, 2012 at 2:57 PM, Aron Ahmadia <aron(a)ahmadia.net> wrote: > This is on an OS X.6 box running Python 2.7 and pip 1.0.2 > > # at command line: > pip install -vvv petsc4py > > # relevant bits: > Downloading/unpacking petsc>=3.2,<3.3 (from petsc4py) > Getting page http://pypi.python.org/simple/petsc > URLs to search for versions for petsc>=3.2,<3.3 (from petsc4py): > * http://pypi.python.org/simple/petsc/ > Getting page http://www.mcs.anl.gov/petsc/ > ... > Skipping page > http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-lite-3.2-p6.tar.gz… > http://pypi.python.org/simple/petsc/) because of Content-Type: > application/x-gzip > ... > > Found link > http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-lite-3.2-p6.tar.gz… > http://pypi.python.org/simple/petsc/) version: lite-3.2-p6 > > The "lite-" prefix is being interpreted as part of the version, which pip > doesn't quite know what to do with. It would probably just be easiest to > host lite versions in a separate directory > ../release-snapshots/lite/petsc-3.2-p6.tar.gz that petsc4py/PyPI can point > to. Lisandro can also point to the non-lite versions until a solution is > implemented. > > This is going to be an additional problem: > > > ******************************************************************************* > > UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for > details): > > > ------------------------------------------------------------------------------- > > Fortran compiler you provided with --with-fc=/usr/bin/mpif90 does not work > > > ******************************************************************************* > > Obviously the Mac doesn't come with /usr/bin/mpif90, so a clean system > won't have this either... I think you guys know your options for how to > fix this, but let me know if you want my 2 cents :) > > =AA= >

1 0

pip cannot currently automatically download and install petsc on OS X
by Aron Ahmadia 18 Apr '12

18 Apr '12

This is on an OS X.6 box running Python 2.7 and pip 1.0.2 # at command line: pip install -vvv petsc4py # relevant bits: Downloading/unpacking petsc>=3.2,<3.3 (from petsc4py) Getting page http://pypi.python.org/simple/petsc URLs to search for versions for petsc>=3.2,<3.3 (from petsc4py): * http://pypi.python.org/simple/petsc/ Getting page http://www.mcs.anl.gov/petsc/ ... Skipping page http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-lite-3.2-p6.tar.gz… http://pypi.python.org/simple/petsc/) because of Content-Type: application/x-gzip ... Found link http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-lite-3.2-p6.tar.gz… http://pypi.python.org/simple/petsc/) version: lite-3.2-p6 The "lite-" prefix is being interpreted as part of the version, which pip doesn't quite know what to do with. It would probably just be easiest to host lite versions in a separate directory ../release-snapshots/lite/petsc-3.2-p6.tar.gz that petsc4py/PyPI can point to. Lisandro can also point to the non-lite versions until a solution is implemented. This is going to be an additional problem: ******************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- Fortran compiler you provided with --with-fc=/usr/bin/mpif90 does not work ******************************************************************************* Obviously the Mac doesn't come with /usr/bin/mpif90, so a clean system won't have this either... I think you guys know your options for how to fix this, but let me know if you want my 2 cents :) =AA=

1 0

Re: [petsc-dev] PCApplyTranspose in BiCG
by Alexander Grayver 18 Apr '12

18 Apr '12

Jed, Thank you. TFQMR works well now, however TCQMR doesn't. Although latter was working before I updated petsc-dev. Might be same issue? On 18.04.2012 07:30, Jed Brown wrote: > Thanks for the details, we should have identified the issue earlier. > When VecDot changed from using custom code to BLAS xDOT, the > conjugation definition was accidentally changed. If you pull after > this patch, TFQMR will work for your problem again. > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/8f37c498b7b4 > > On Wed, Apr 11, 2012 at 00:38, Alexander Grayver > <agrayver(a)gfz-potsdam.de <mailto:[email protected]>> wrote: > > On 10.04.2012 14:19, Jed Brown wrote: >> >> There is no space allocated at (44,44); note that counting is >> 0-based. This consistency check has been in PETSc for many years, >> so I don't know why you didn't trip it in earlier runs. Do you >> have some options in PETSC_OPTIONS or .petscrc? > > Jed, > > This is not possible: > > >> A = PetscBinaryRead('A.dat','complex',true); > >> find(diag(A)==0) > ans = > Empty matrix: 0-by-1 > > >> A(45,45) > ans = (1,1) 7.999999999999997e+002 +6.316546778308559e-009i > > Sorry, I forgot to mention that this is double complex matrix and > vector. Have you read it as real double? > > >> >> If it is of any help files are here: >> http://dl.dropbox.com/u/60982984/A.dat >> http://dl.dropbox.com/u/60982984/RHS.dat >> >> Is this possible to look up changes in one file only? >> >> >> $ hg log src/ksp/ksp/impls/tfqmr/ >> >> But the problem was clearly not in that file. > > > -- > Regards, > Alexander > > -- Regards, Alexander

1 0

Re: [petsc-dev] PCApplyTranspose in BiCG
by Jed Brown 18 Apr '12

18 Apr '12

Thanks for the details, we should have identified the issue earlier. When VecDot changed from using custom code to BLAS xDOT, the conjugation definition was accidentally changed. If you pull after this patch, TFQMR will work for your problem again. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/8f37c498b7b4 On Wed, Apr 11, 2012 at 00:38, Alexander Grayver <agrayver(a)gfz-potsdam.de>wrote: > ** > On 10.04.2012 14:19, Jed Brown wrote: > > > There is no space allocated at (44,44); note that counting is 0-based. > This consistency check has been in PETSc for many years, so I don't know > why you didn't trip it in earlier runs. Do you have some options in > PETSC_OPTIONS or .petscrc? > > > Jed, > > This is not possible: > > >> A = PetscBinaryRead('A.dat','complex',true); > >> find(diag(A)==0) > ans = > Empty matrix: 0-by-1 > > >> A(45,45) > ans = (1,1) 7.999999999999997e+002 +6.316546778308559e-009i > > Sorry, I forgot to mention that this is double complex matrix and vector. > Have you read it as real double? > > > > >> >> If it is of any help files are here: >> http://dl.dropbox.com/u/60982984/A.dat >> http://dl.dropbox.com/u/60982984/RHS.dat >> >> Is this possible to look up changes in one file only? > > > $ hg log src/ksp/ksp/impls/tfqmr/ > > But the problem was clearly not in that file. > > > > -- > Regards, > Alexander > >

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Jed Brown 18 Apr '12

18 Apr '12

On Tue, Apr 17, 2012 at 20:17, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > The truth is likely that except for CG most of the methods were coded > without regard to complex and are likely wrong but not necessarily wrong in > a consistent way or even self-consistently wrong. This fixes Alexander Grayver's reported problem with TFQMR. I still don't know if CG is correct, but it should be easy to check.

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Barry Smith 17 Apr '12

17 Apr '12

On Apr 17, 2012, at 9:57 PM, Jed Brown wrote: > Where is the update to every KSP (at least the CGs, but I think all of them) to change the order? The assumption is that all the KSPs were coded assuming the complex conjugation of the second argument. If they were actually coded using the complex conjugate of the first argument then they have been WRONG for many years because PETSc has always implemented the inner products complex conjugating the second argument. (PETSc never used the zdotc() routine in BLAS because of the returning a complex double business so PETSc always had handcoded dot() within a #if def(complex) using the complex conjugate of the second argument. Since I do not know if they have always been coded wrong (and am assuming they are coded correctly, at least cg) changing them all by brute force now would make them all wrong now. Certainly if some are wrong now (which means they have always been wrong) they should be fixed, but that needs to be done by inspection/testing to determine which ones are wrong. The truth is likely that except for CG most of the methods were coded without regard to complex and are likely wrong but not necessarily wrong in a consistent way or even self-consistently wrong. Barry > I don't see it in the repository. Note that this notation is different from that used by most textbook and paper descriptions of the methods. > > On Apr 17, 2012 7:09 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > >> > >> > >> Since PETSc was written and always implemented with mathematician style* inner products, I have decided to keep it that way and call the BLASdot_() with the arguments reversed. Note that until Matt added the support for zdotc() we never called the BLAS for complex inner products and thus never used the engineers style inner products. > >> > >> Please report any problems, > >> > >> Barry > >> > >> * please do not be upset by my joking reference to mathematician and engineering style inner products. > >> > >> > >> On Apr 15, 2012, at 1:09 PM, Jed Brown wrote: > >> > >> > On Sun, Apr 15, 2012 at 12:55, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> > Real mathematicians conjugate the second one :-) > >> > > >> > I never unrderstood that choice. I like vectors to be column vectors, one forms to be row vectors, and operations to have standard fixity. How some mathematicians ended up with infix operators and postfix inner products is beyond me. > >> > > >> > > >> > The code to check is PETSc's conjugate gradient, there the conjugate does mater :-). > >> > > >> > Looks right to me. > >> > > >> > ierr = KSP_MatMult(ksp,Amat,P,W);CHKERRQ(ierr); /* w <- Ap */ > >> > ierr = VecXDot(P,W,&dpi);CHKERRQ(ierr); /* dpi <- p'w */ > >> > > >>

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Jed Brown 17 Apr '12

17 Apr '12

Where is the update to every KSP (at least the CGs, but I think all of them) to change the order? I don't see it in the repository. Note that this notation is different from that used by most textbook and paper descriptions of the methods. On Apr 17, 2012 7:09 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: >> >> >> Since PETSc was written and always implemented with mathematician style* inner products, I have decided to keep it that way and call the BLASdot_() with the arguments reversed. Note that until Matt added the support for zdotc() we never called the BLAS for complex inner products and thus never used the engineers style inner products. >> >> Please report any problems, >> >> Barry >> >> * please do not be upset by my joking reference to mathematician and engineering style inner products. >> >> >> On Apr 15, 2012, at 1:09 PM, Jed Brown wrote: >> >> > On Sun, Apr 15, 2012 at 12:55, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> > Real mathematicians conjugate the second one :-) >> > >> > I never unrderstood that choice. I like vectors to be column vectors, one forms to be row vectors, and operations to have standard fixity. How some mathematicians ended up with infix operators and postfix inner products is beyond me. >> > >> > >> > The code to check is PETSc's conjugate gradient, there the conjugate does mater :-). >> > >> > Looks right to me. >> > >> > ierr = KSP_MatMult(ksp,Amat,P,W);CHKERRQ(ierr); /* w <- Ap */ >> > ierr = VecXDot(P,W,&dpi);CHKERRQ(ierr); /* dpi <- p'w */ >> > >>

1 0

Re: [petsc-dev] various dot products messed up for complex numbers?
by Barry Smith 17 Apr '12

17 Apr '12

Since PETSc was written and always implemented with mathematician style* inner products, I have decided to keep it that way and call the BLASdot_() with the arguments reversed. Note that until Matt added the support for zdotc() we never called the BLAS for complex inner products and thus never used the engineers style inner products. Please report any problems, Barry * please do not be upset by my joking reference to mathematician and engineering style inner products. On Apr 15, 2012, at 1:09 PM, Jed Brown wrote: > On Sun, Apr 15, 2012 at 12:55, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Real mathematicians conjugate the second one :-) > > I never unrderstood that choice. I like vectors to be column vectors, one forms to be row vectors, and operations to have standard fixity. How some mathematicians ended up with infix operators and postfix inner products is beyond me. > > > The code to check is PETSc's conjugate gradient, there the conjugate does mater :-). > > Looks right to me. > > ierr = KSP_MatMult(ksp,Amat,P,W);CHKERRQ(ierr); /* w <- Ap */ > ierr = VecXDot(P,W,&dpi);CHKERRQ(ierr); /* dpi <- p'w */ >

1 0

Re: [petsc-dev] buildsystem: cusp location
by Sean Farley 16 Apr '12

16 Apr '12

> > Given our --with-package-dir model of checking all kinds of possibilities > I don't see why that extra include would be required part? Isn't it just > one possibility? > > What is the argument about, just have cusp.py check more possibilities. What's the status on this? I haven't seen a changeset that fixes this yet.

1 0