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

Re: [petsc-dev] VI vs. SNESLineSearchPostCheck and projecting to bounds
by Matthew Knepley 27 Apr '12

27 Apr '12

On Fri, Apr 27, 2012 at 3:57 PM, Peter Brune <prbrune(a)gmail.com> wrote: > Seems to me we have at least two ways of enforcing physicality or other > constraints on the solution; SNESLineSearchPostCheck and the VI machinery. > I'm trying to solve PFLOTRAN examples that make extensive use of > SNESLineSearchPostCheck and am having to put postchecks at strategic places > in SNESNGMRES and other solvers that don't just use the line searches > directly make sure the solution becomes physical. > > Jed, you've already complained about post-check checking the step after > taking it being nonsensical, and I agree on this point as well. Should we > move towards an interface so that there's a general "SNESProjectToBounds" > or whatever, with VI doing what it needs to do through this as well? This > way we have the ability to solve the constrained problems with all the > solvers. We already have hooks for this kind of thing in the DM. > I am cool with that. Its at least good enough for projected gradient. Matt > Thanks, > > - Peter > > > -- 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

VI vs. SNESLineSearchPostCheck and projecting to bounds
by Peter Brune 27 Apr '12

27 Apr '12

Seems to me we have at least two ways of enforcing physicality or other constraints on the solution; SNESLineSearchPostCheck and the VI machinery. I'm trying to solve PFLOTRAN examples that make extensive use of SNESLineSearchPostCheck and am having to put postchecks at strategic places in SNESNGMRES and other solvers that don't just use the line searches directly make sure the solution becomes physical. Jed, you've already complained about post-check checking the step after taking it being nonsensical, and I agree on this point as well. Should we move towards an interface so that there's a general "SNESProjectToBounds" or whatever, with VI doing what it needs to do through this as well? This way we have the ability to solve the constrained problems with all the solvers. We already have hooks for this kind of thing in the DM. Thanks, - Peter

1 0

Re: [petsc-dev] 4.2 and PETSc
by Matthew Knepley 27 Apr '12

27 Apr '12

On Fri, Apr 27, 2012 at 11:53 AM, Daniel Lowell <redratio1(a)gmail.com> wrote: > Even with the new build system I still had to go through and eliminate the > -g3 in petscvariables > > CC_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing > -Wno-unknown-pragmas -g3 -fno-inline -O0 > PCC_LINKER_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing > -Wno-unknown-pragmas -g3 -fno-inline -O0 > PCC_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing > -Wno-unknown-pragmas -g3 -fno-inline -O0 > I just ran this last night. There were no more -g3's. As Satish said, send logs. Matt > On Mon, Apr 23, 2012 at 4:43 PM, Daniel Lowell <redratio1(a)gmail.com>wrote: > >> Sending the make.log to petsc-maint now. >> >> >> On Mon, Apr 23, 2012 at 4:38 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: >> >>> but you missed copy/pasting the actual compile command. So incomplete >>> info here.. >>> >>> satish >>> >>> On Mon, 23 Apr 2012, Daniel Lowell wrote: >>> >>> > I added -v in the local folder's makefile to produce verbose output. >>> > >>> > On Mon, Apr 23, 2012 at 4:33 PM, Satish Balay <balay(a)mcs.anl.gov> >>> wrote: >>> > >>> > > Hm - we've seen these errors with -g3 but not with -g. Are you sure >>> > > there is no '-g3' somewhere on the compile command? >>> > > >>> > > With latest petsc-dev/buildsystem one should not see -g3 [set by >>> configure] >>> > > >>> > > Also - why is there 'cicc' in a petsc build? >>> > > >>> > > Satish >>> > > >>> > > On Mon, 23 Apr 2012, Daniel Lowell wrote: >>> > > >>> > > > Hi all, >>> > > > >>> > > > >>> > > > Has anyone run into any problems with NVCC 4.1 or .42 on PETSc with >>> > > > arch=sm_20? >>> > > > I have having real issues with it. I keep getting this: >>> > > > >>> > > > #$ cicc -arch compute_20 -m64 -ftz=0 -prec_div=1 -prec_sqrt=1 >>> -fmad=1 -g >>> > > > -O0 "/tmp/tmpxft_00000b8b_00000000-10_vecgpu" >>> > > > "/tmp/tmpxft_00000b8b_00000000-7_vecgpu.cpp3.i" -o >>> > > > "/tmp/tmpxft_00000b8b_00000000-2_vecgpu.ptx" >>> > > > <built-in>(2): error: "__STDC_HOSTED__" is predefined; attempted >>> > > > redefinition ignored >>> > > > >>> > > > <built-in>(8): error: "__WCHAR_TYPE__" is predefined; attempted >>> > > > redefinition ignored >>> > > > >>> > > > <built-in>(115): error: "__x86_64" is predefined; attempted >>> redefinition >>> > > > ignored >>> > > > >>> > > > <built-in>(116): error: "__x86_64__" is predefined; attempted >>> > > redefinition >>> > > > ignored >>> > > > >>> > > > <built-in>(126): error: "__linux__" is predefined; attempted >>> redefinition >>> > > > ignored >>> > > > >>> > > > <built-in>(128): error: "__unix__" is predefined; attempted >>> redefinition >>> > > > ignored >>> > > > >>> > > > 6 errors detected in the compilation of >>> > > > "/tmp/tmpxft_00000b8b_00000000-7_vecgpu.cpp3.i". >>> > > > # --error 0x1 -- >>> > > > >>> > > > >>> > > > 4.0 works fine, no issues. >>> > > > 4.0 version uses the older nvopencc, in 4.1 and 4.2 they use >>> something >>> > > > called cicc, for target architecture sm_2x. Of course it does no >>> mention >>> > > > cicc in the updated nvcc documentation at all. >>> > > > >>> > > > Tried 4.2 with GCC 4.3 and 4.4 without any difference in behavior. >>> > > > >>> > > > >>> > > > PETSc configuration script: >>> > > > >>> > > > MPI_DIR="--with-mpi-dir=$MPICH2_HOME" >>> > > > LAD="--download-f-blas-lapack=yes" >>> > > > CUD="--with-cuda-dir=/soft/cuda-4.2/cuda" >>> > > > ./config/configure.py $MPI_DIR $LAD $CUD \ >>> > > > --with-debugging=1 \ >>> > > > --with-cudac="nvcc -m64 -g -G" \ >>> > > > --with-precision=double \ >>> > > > --with-clanguage=c \ >>> > > > --with-cuda-arch=sm_20 >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > >>> > >>> > >>> >>> >> >> >> -- >> Daniel Lowell >> >> > > > -- > Daniel Lowell > > -- 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] 4.2 and PETSc
by Satish Balay 27 Apr '12

27 Apr '12

send build logs to petsc-maint. satish On Fri, 27 Apr 2012, Daniel Lowell wrote: > Even with the new build system I still had to go through and eliminate the > -g3 in petscvariables > > CC_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas > -g3 -fno-inline -O0 > PCC_LINKER_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing > -Wno-unknown-pragmas -g3 -fno-inline -O0 > PCC_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing > -Wno-unknown-pragmas -g3 -fno-inline -O0 > > > On Mon, Apr 23, 2012 at 4:43 PM, Daniel Lowell <redratio1(a)gmail.com> wrote: > > > Sending the make.log to petsc-maint now. > > > > > > On Mon, Apr 23, 2012 at 4:38 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > >> but you missed copy/pasting the actual compile command. So incomplete > >> info here.. > >> > >> satish > >> > >> On Mon, 23 Apr 2012, Daniel Lowell wrote: > >> > >> > I added -v in the local folder's makefile to produce verbose output. > >> > > >> > On Mon, Apr 23, 2012 at 4:33 PM, Satish Balay <balay(a)mcs.anl.gov> > >> wrote: > >> > > >> > > Hm - we've seen these errors with -g3 but not with -g. Are you sure > >> > > there is no '-g3' somewhere on the compile command? > >> > > > >> > > With latest petsc-dev/buildsystem one should not see -g3 [set by > >> configure] > >> > > > >> > > Also - why is there 'cicc' in a petsc build? > >> > > > >> > > Satish > >> > > > >> > > On Mon, 23 Apr 2012, Daniel Lowell wrote: > >> > > > >> > > > Hi all, > >> > > > > >> > > > > >> > > > Has anyone run into any problems with NVCC 4.1 or .42 on PETSc with > >> > > > arch=sm_20? > >> > > > I have having real issues with it. I keep getting this: > >> > > > > >> > > > #$ cicc -arch compute_20 -m64 -ftz=0 -prec_div=1 -prec_sqrt=1 > >> -fmad=1 -g > >> > > > -O0 "/tmp/tmpxft_00000b8b_00000000-10_vecgpu" > >> > > > "/tmp/tmpxft_00000b8b_00000000-7_vecgpu.cpp3.i" -o > >> > > > "/tmp/tmpxft_00000b8b_00000000-2_vecgpu.ptx" > >> > > > <built-in>(2): error: "__STDC_HOSTED__" is predefined; attempted > >> > > > redefinition ignored > >> > > > > >> > > > <built-in>(8): error: "__WCHAR_TYPE__" is predefined; attempted > >> > > > redefinition ignored > >> > > > > >> > > > <built-in>(115): error: "__x86_64" is predefined; attempted > >> redefinition > >> > > > ignored > >> > > > > >> > > > <built-in>(116): error: "__x86_64__" is predefined; attempted > >> > > redefinition > >> > > > ignored > >> > > > > >> > > > <built-in>(126): error: "__linux__" is predefined; attempted > >> redefinition > >> > > > ignored > >> > > > > >> > > > <built-in>(128): error: "__unix__" is predefined; attempted > >> redefinition > >> > > > ignored > >> > > > > >> > > > 6 errors detected in the compilation of > >> > > > "/tmp/tmpxft_00000b8b_00000000-7_vecgpu.cpp3.i". > >> > > > # --error 0x1 -- > >> > > > > >> > > > > >> > > > 4.0 works fine, no issues. > >> > > > 4.0 version uses the older nvopencc, in 4.1 and 4.2 they use > >> something > >> > > > called cicc, for target architecture sm_2x. Of course it does no > >> mention > >> > > > cicc in the updated nvcc documentation at all. > >> > > > > >> > > > Tried 4.2 with GCC 4.3 and 4.4 without any difference in behavior. > >> > > > > >> > > > > >> > > > PETSc configuration script: > >> > > > > >> > > > MPI_DIR="--with-mpi-dir=$MPICH2_HOME" > >> > > > LAD="--download-f-blas-lapack=yes" > >> > > > CUD="--with-cuda-dir=/soft/cuda-4.2/cuda" > >> > > > ./config/configure.py $MPI_DIR $LAD $CUD \ > >> > > > --with-debugging=1 \ > >> > > > --with-cudac="nvcc -m64 -g -G" \ > >> > > > --with-precision=double \ > >> > > > --with-clanguage=c \ > >> > > > --with-cuda-arch=sm_20 > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > > >> > >> > > > > > > -- > > Daniel Lowell > > > > > > >

1 0

Re: [petsc-dev] 4.2 and PETSc
by Daniel Lowell 27 Apr '12

27 Apr '12

Even with the new build system I still had to go through and eliminate the -g3 in petscvariables CC_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 PCC_LINKER_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 PCC_FLAGS = -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 On Mon, Apr 23, 2012 at 4:43 PM, Daniel Lowell <redratio1(a)gmail.com> wrote: > Sending the make.log to petsc-maint now. > > > On Mon, Apr 23, 2012 at 4:38 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > >> but you missed copy/pasting the actual compile command. So incomplete >> info here.. >> >> satish >> >> On Mon, 23 Apr 2012, Daniel Lowell wrote: >> >> > I added -v in the local folder's makefile to produce verbose output. >> > >> > On Mon, Apr 23, 2012 at 4:33 PM, Satish Balay <balay(a)mcs.anl.gov> >> wrote: >> > >> > > Hm - we've seen these errors with -g3 but not with -g. Are you sure >> > > there is no '-g3' somewhere on the compile command? >> > > >> > > With latest petsc-dev/buildsystem one should not see -g3 [set by >> configure] >> > > >> > > Also - why is there 'cicc' in a petsc build? >> > > >> > > Satish >> > > >> > > On Mon, 23 Apr 2012, Daniel Lowell wrote: >> > > >> > > > Hi all, >> > > > >> > > > >> > > > Has anyone run into any problems with NVCC 4.1 or .42 on PETSc with >> > > > arch=sm_20? >> > > > I have having real issues with it. I keep getting this: >> > > > >> > > > #$ cicc -arch compute_20 -m64 -ftz=0 -prec_div=1 -prec_sqrt=1 >> -fmad=1 -g >> > > > -O0 "/tmp/tmpxft_00000b8b_00000000-10_vecgpu" >> > > > "/tmp/tmpxft_00000b8b_00000000-7_vecgpu.cpp3.i" -o >> > > > "/tmp/tmpxft_00000b8b_00000000-2_vecgpu.ptx" >> > > > <built-in>(2): error: "__STDC_HOSTED__" is predefined; attempted >> > > > redefinition ignored >> > > > >> > > > <built-in>(8): error: "__WCHAR_TYPE__" is predefined; attempted >> > > > redefinition ignored >> > > > >> > > > <built-in>(115): error: "__x86_64" is predefined; attempted >> redefinition >> > > > ignored >> > > > >> > > > <built-in>(116): error: "__x86_64__" is predefined; attempted >> > > redefinition >> > > > ignored >> > > > >> > > > <built-in>(126): error: "__linux__" is predefined; attempted >> redefinition >> > > > ignored >> > > > >> > > > <built-in>(128): error: "__unix__" is predefined; attempted >> redefinition >> > > > ignored >> > > > >> > > > 6 errors detected in the compilation of >> > > > "/tmp/tmpxft_00000b8b_00000000-7_vecgpu.cpp3.i". >> > > > # --error 0x1 -- >> > > > >> > > > >> > > > 4.0 works fine, no issues. >> > > > 4.0 version uses the older nvopencc, in 4.1 and 4.2 they use >> something >> > > > called cicc, for target architecture sm_2x. Of course it does no >> mention >> > > > cicc in the updated nvcc documentation at all. >> > > > >> > > > Tried 4.2 with GCC 4.3 and 4.4 without any difference in behavior. >> > > > >> > > > >> > > > PETSc configuration script: >> > > > >> > > > MPI_DIR="--with-mpi-dir=$MPICH2_HOME" >> > > > LAD="--download-f-blas-lapack=yes" >> > > > CUD="--with-cuda-dir=/soft/cuda-4.2/cuda" >> > > > ./config/configure.py $MPI_DIR $LAD $CUD \ >> > > > --with-debugging=1 \ >> > > > --with-cudac="nvcc -m64 -g -G" \ >> > > > --with-precision=double \ >> > > > --with-clanguage=c \ >> > > > --with-cuda-arch=sm_20 >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > >> > >> > >> >> > > > -- > Daniel Lowell > > -- Daniel Lowell

1 0

Re: [petsc-dev] [petsc-users] writing native PETSc binaries in python
by Ataollah Mesgarnejad 27 Apr '12

27 Apr '12

Thanks for the replies: Just a bug report with petsc4py: petsc4py which downloads with --download-petsc4py=1 is the older v1.1.1 which doesn't compile with petsc-dev? Thanks, Ata On Fri, Apr 27, 2012 at 8:25 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Fri, Apr 27, 2012 at 9:19 AM, Ataollah Mesgarnejad < > amesga1(a)tigers.lsu.edu> wrote: > >> Dear all, >> >> I was wondering if there is way to write numpy arrays as native PETSc >> binaries in python so I can open them inside my program with VecView? >> > > I think what you want is to create a Vec using that array in petsc4py. > > Matt > > >> Thanks, >> Ata >> > > > > -- > 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 > -- A. Mesgarnejad PhD Student, Research Assistant Mechanical Engineering Department Louisiana State University 2203 Patrick F. Taylor Hall Baton Rouge, La 70803

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Jed Brown 25 Apr '12

25 Apr '12

On Wed, Apr 25, 2012 at 19:46, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > I think we shouldn't try to encode the near-null space being sparse. For > elasticity, we would only reduce the 18 matrix entries to 12, which is only > about break-even on storage since the dense null space can use fewer column > indices (this is ignoring the dense case also being more efficient). > > > Its worse than that in aggregation MG, I think, because P is not the null > space but Q in a QR decomposition of the rigid body modes ... that might > still have some sparsity, not sure. > Well, the translational modes are position-independent, so they should retain sparsity with a standard implementation of QR (in the sense that the zeros will remain very close to 0 so that you could discard them, though I don't think it's even worth trying to do that).

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Mark F. Adams 25 Apr '12

25 Apr '12

On Apr 25, 2012, at 7:15 PM, Jed Brown wrote: > On Wed, Apr 25, 2012 at 17:58, Mark F. Adams <mark.adams(a)columbia.edu> wrote: > The blocks are not always dense, so by what appears to be your definition of block size it is not (always) a 'column block size'. But I think that it is semantically a blocked matrix and hence it has a column block size. > > I think we shouldn't try to encode the near-null space being sparse. For elasticity, we would only reduce the 18 matrix entries to 12, which is only about break-even on storage since the dense null space can use fewer column indices (this is ignoring the dense case also being more efficient). Its worse than that in aggregation MG, I think, because P is not the null space but Q in a QR decomposition of the rigid body modes ... that might still have some sparsity, not sure.

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Barry Smith 25 Apr '12

25 Apr '12

Ok, so add MatSetBlockSizes(). Reason we don't have implemented fully function different row and column block sizes or different block sizes in different parts of the matrix: with our current programming model (C+MPI) the code complexity would get higher increasing the time to write and maintain code hence it has not been done. Plus we have plenty of other high priority things to work on. Nothing is stopping anyone from writing a more general block implementation and putting it in PETSc. Barry On Apr 25, 2012, at 5:58 PM, Mark F. Adams wrote: > > On Apr 25, 2012, at 6:10 PM, Barry Smith wrote: > >> >> On Apr 25, 2012, at 4:58 PM, Jed Brown wrote: >> >>> On Wed, Apr 25, 2012 at 16:41, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear alternatives. >>> >>> What about having a separate row and column block size? The BAIJ and MAIJ formats can continue to store data using bs=gcd(rowbs,colbs), but those row and column block sizes indicate that redundancy exists in the data structure, so it can be utilized by appropriate operations. >> >> Mark told me in a earlier email that the "column block size" isn't really the column block size (except in some cases), since it is not really a column block size I don't want the matrix to list it as the column block size (hence my virtual column block size thing). > > The blocks are not always dense, so by what appears to be your definition of block size it is not (always) a 'column block size'. But I think that it is semantically a blocked matrix and hence it has a column block size. > >> >> If it is truly a column block size then great, P is given the column block size with MatSetColumnBlockSize() or MatSetBlockSizes(mat,col,row) and PtAP automatically uses that column block size for the resulting matrix block size. >> > > I think this solution is the best (eg, no 'virtual'). Column block size is a fundamental property of a blocked matrix. PETSc's current implementations do not exploit or accommodate this but since it is a fundamental property I do not mind cluttering up Mat with yet another parameter. You deal with rectangular matrices, and blocked matrices, why not rectangular blocks? You also have row block size on AIJ matrices that do not have dense blocks so why not column block size? > > Mark > >> So Mark I ask you again, in GAMG is it truly a column block size? >> >> Barry >> >> >> >

1 0

Re: [petsc-dev] MetSetBlockSize issue
by Jed Brown 25 Apr '12

25 Apr '12

On Wed, Apr 25, 2012 at 17:58, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > The blocks are not always dense, so by what appears to be your definition > of block size it is not (always) a 'column block size'. But I think that > it is semantically a blocked matrix and hence it has a column block size. I think we shouldn't try to encode the near-null space being sparse. For elasticity, we would only reduce the 18 matrix entries to 12, which is only about break-even on storage since the dense null space can use fewer column indices (this is ignoring the dense case also being more efficient).

1 0