[petsc-users] help needed for -snes_mf_operator

> ? Do not pass -snes_mf or -snes_mf_operator with the -snes_type test ? option Sorry, I am lost. I provide an analytical Jacobian to a polynomial function. Sure I can make mistakes even in such trivial derivations, but how would I get the results I expect from a book without the option? Dominik

[petsc-users] help needed for -snes_mf_operator

> My guess is that your "exact" Jacobian ?is wrong I am happy to be guilty if I know how I can improve: why do I get the right results without this option, for several cases? > Run with -snes_type test and see what it reports. The moment I specify this option I get: [0]PETSC ERROR: Invalid argu

[petsc-users] help needed for -snes_mf_operator

>> Should this be the case, how would I get correct results for several >> benchmarks without using the option? > > > This is not what I said. Look closely at the above. I said the > preconditioner you give > back when using -snes_mf_operator is not right. This has nothing to do with > normal > ope

[petsc-users] ex52_integrateElement.cu

>>>>>>>>>>>>>> declared but never referenced >>>>>>>>>>>>>> >>>>>>>>>>>>>> ex52_gpu_inline.h(21): warning: variable "Basis_0" was >>&

[petsc-users] Question about MatDestroy...

Wiener -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/c16879d5/attachment-0001.htm>

[petsc-users] help needed for -snes_mf_operator

> Notice that there is no increase in the residual as is required. Notice also > that > there is no decrease. This must mean that the preconditioner is rank > deficient, > and I think it probably means that it is 0 since I find it hard to believe > that P x > produces no component in the b directio

[petsc-users] help needed for -snes_mf_operator

> Start by comparing residuals, with an without. Is SNES 0 the same? Is KSP 0 > the same? KSP 1? BCGS, with the option: 0 SNES Function norm 1.747536282885e+01 0 KSP unpreconditioned resid norm 1.747536282885e+01 true resid norm 1.747536282885e+01 ||r(i)||/||b|| 1.e+00 1 KSP unp

[petsc-users] help needed for -snes_mf_operator

>> Now I want to reproduce the same results without providing the >> Jacobian, preparing for future real life cases where it will not be >> known. I am under the impression that Petsc can approximate the >> Jacobian itself using some sort of secant method. How exactly am I >> supposed to use it? If

[petsc-users] Question about MatDestroy...

Hello, Lately I experienced very weird behavior in PETSC. While solving small size problem (25k) on my laptop, it MatDestroy clean the objects. Another test (40k unknowns) problem use most of my memory and left around 500 MB free while solving the problem. Then when I call MatDestroy, PETSC r

[petsc-users] help needed for -snes_mf_operator

Dominik, The -snes_type test optioncompares the full Jacobian you provide with one that PETSc computes to try to determine if your Jacobian is correct. Please run with this option and see what happens and send us result. It should print a few numbers and a statement of whether the

[petsc-users] help needed for -snes_mf_operator

Do not pass -snes_mf or -snes_mf_operator with the -snes_type test option Barry On Apr 25, 2012, at 4:16 PM, Jed Brown wrote: > On Wed, Apr 25, 2012 at 16:06, Dominik Szczerba > wrote: > I am happy to be guilty if I know how I can improve: why do I get the > right results without this

[petsc-users] help needed for -snes_mf_operator

ther (a) set different matrices for the operator and preconditioning matrix or (b) passed -snes_mf. Just pass one matrix. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/19a14a00/attachment.htm>

[petsc-users] help needed for -snes_mf_operator

part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/4fc6bf4d/attachment.htm>

[petsc-users] error in petsc-dev

FromOptions() picks it and set the > type accordingly. SetPreallocation() > will be called after the type is set. > > Hong > >> >> Mohammd >> > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/d8747353/attachment.htm>

[petsc-users] ex52_integrateElement.cu

gt;> >>>>>>>>>>>>> ex52_gpu_inline.h(21): warning: variable "Basis_0" was >>>>>>>>>>>>> declared but never refe

[petsc-users] help needed for -snes_mf_operator

The true residual decreases nicely without matrix free operator, otherwise it does not decrease. This likely means the preconditioner is no good for the matrix free, but is good for the matrix based. This means that the matrix based multiply is not the same as the matrix free multiply. Thes

[petsc-users] help needed for -snes_mf_operator

han any results to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/46cbfb13/attachment.htm>

[petsc-users] ex52_integrateElement.cu

>>>>>>>>>>>> /usr/bin/mpicxx -O0 -g -o ex52 ex52.o ex52_integrateElement.o >>>>>>>>>>>> >>>>>>>>>>>> -Wl,-rpath,/opt/apps/PETSC/petsc-dev/gcc-4.4.3-mpich2-1.2-epd-sm_20-dbg/lib >>>>>>>>>>>> -L/opt/apps/PETSC/petsc-dev/gcc-4.4.3-mpich2-1.2-epd-sm_20-dbg/lib >>>>>>>>>>>> -lpetsc >>>>>>>>>>>> -Wl,-rpath,/opt/apps/PETSC/petsc-dev/gcc-4.4.3-mpich2-1.2-epd-sm_20-dbg/lib >>>>>>>>>>>> -ltriangle -lX11 -lpthread -lsuperlu_dist_3.0 -lcmumps -ldmumps >>>>>>>>>>>> -lsmumps >>>>>>>>>>>> -lzmumps -lmumps_common -lpord -lparmetis -lmetis -lscalapack >>>>>>>>>>>> -lblacs >>>>>>>>>>>> -Wl,-rpath,/opt/apps/cuda/4.1/cuda/lib64 >>>>>>>>>>>> -L/opt/apps/cuda/4.1/cuda/lib64 >>>>>>>>>>>> -lcufft -lcublas -lcudart -lcusparse >>>>>>>>>>>> -Wl,-rpath,/opt/MATLAB/R2011a/sys/os/glnxa64:/opt/MATLAB/R2011a/bin/glnxa64:/opt/MATLAB/R2011a/extern/lib/glnxa64 >>>>>>>>>>>> -L/opt/MATLAB/R2011a/bin/glnxa64 >>>>>>>>>>>> -L/opt/MATLAB/R2011a/extern/lib/glnxa64 >>>>>>>>>>>> -leng -lmex -lmx -lmat -lut -licudata -licui18n -licuuc >>>>>>>>>>>> -Wl,-rpath,/opt/epd-7.1-2-rh5-x86_64/lib >>>>>>>>>>>> -L/opt/epd-7.1-2-rh5-x86_64/lib >>>>>>>>>>>> -lmkl_rt -lmkl_intel_thread -lmkl_core -liomp5 -lexoIIv2for >>>>>>>>>>>> -lexodus >>>>>>>>>>>> -lnetcdf_c++ -lnetcdf >>>>>>>>>>>> -Wl,-rpath,/usr/lib/gcc/x86_64-linux-gnu/4.4.3 >>>>>>>>>>>> -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -ldl -lmpich -lopa -lpthread >>>>>>>>>>>> -lrt >>>>>>>>>>>> -lgcc_s -lmpichf90 -lgfortran -lm -lm -lmpichcxx -lstdc++ >>>>>>>>>>>> -lmpichcxx >>>>>>>>>>>> -lstdc++ -ldl -lmpich -lopa -lpthread -lrt -lgcc_s -ldl >>>>>>>>>>>> /bin/rm -f ex52.o ex52_integrateElement.o >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> SCRGP2$ ./ex52 -dim 2 -compute_function -show_residual -batch >>>>>>>>>>>> Residual: >>>>>>>>>>>> Vector Object: 1 MPI processes >>>>>>>>>>>> type: seq >>>>>>>>>>>> -0.25 >>>>>>>>>>>> -0.5 >>>>>>>>>>>> 0.25 >>>>>>>>>>>> -0.5 >>>>>>>>>>>> -1 >>>>>>>>>>>> 0.5 >>>>>>>>>>>> 0.25 >>>>>>>>>>>> 0.5 >>>>>>>>>>>> 0.75 >>>>>>>>>>>> SCRGP2$ ./ex52 -dim 2 -compute_function -show_residual -batch >>>>>>>>>>>> -gpu >>>>>>>>>>>> [0]PETSC ERROR: IntegrateElementBatchGPU() line 323 in >>>>>>>>>>>> src/snes/examples/tutorials/ex52_integrateElement.cu >>>>>>>>>>>> [0]PETSC ERROR: FormFunctionLocalBatch() line 679 in >>>>>>>>>>>> src/snes/examples/tutorials/ex52.c >>>>>>>>>>>> [0]PETSC ERROR: SNESDMComplexComputeFunction() line 431 in >>>>>>>>>>>> src/snes/utils/damgsnes.c >>>>>>>>>>>> [0]PETSC ERROR: main() line 1021 in >>>>>>>>>>>> src/snes/examples/tutorials/ex52.c >>>>>>>>>>>> application called MPI_Abort(MPI_COMM_WORLD, 35) - process 0 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is failing on cudaMalloc(), which means your card is not >>>>>>>>>>> available for running. Are you trying to run on your laptop? >>>>>>>>>>> If so, applications like Preview can lock up the GPU. I know of >>>>>>>>>>> no way to test this in CUDA while running. I just close >>>>>>>>>>> apps until it runs. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 27, 2012 at 8:37 PM, Matthew Knepley < >>>>>>>>>>>> knepley at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 27, 2012 at 2:10 PM, Blaise Bourdin < >>>>>>>>>>>>> bourdin at lsu.edu> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 27, 2012, at 1:23 PM, Matthew Knepley wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Mar 27, 2012 at 12:58 PM, David Fuentes < >>>>>>>>>>>>>> fuentesdt at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I had a question about the status of example 52. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://petsc.cs.iit.edu/petsc/petsc-dev/file/a8e2f2c19319/src/snes/examples/tutorials/ex52.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://petsc.cs.iit.edu/petsc/petsc-dev/file/a8e2f2c19319/src/snes/examples/tutorials/ex52_integrateElement.cu >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can this example be used with a DM object created from an >>>>>>>>>>>>>>> unstructured exodusII mesh, DMMeshCreateExodus, And the FEM >>>>>>>>>>>>>>> assembly done >>>>>>>>>>>>>>> on GPU ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) I have pushed many more tests for it now. They can be run >>>>>>>>>>>>>> using the Python build system >>>>>>>>>>>>>> >>>>>>>>>>>>>> ./config/builder2.py check >>>>>>>>>>>>>> src/snes/examples/tutorials/ex52.c >>>>>>>>>>>>>> >>>>>>>>>>>>>> in fact, you can build any set of files this way. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) The Exodus creation has to be converted to DMComplex from >>>>>>>>>>>>>> DMMesh. That should not take me very long. Blaise maintains that >>>>>>>>>>>>>> so maybe there will be help :) You will just replace >>>>>>>>>>>>>> DMComplexCreateBoxMesh() with DMComplexCreateExodus(). If you >>>>>>>>>>>>>> request >>>>>>>>>>>>>> it, I will bump it up the list. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> DMMeshCreateExodusNG is much more flexible >>>>>>>>>>>>>> than DMMeshCreateExodus in that it can read meshes with multiple >>>>>>>>>>>>>> element >>>>>>>>>>>>>> types and should have a much lower memory footprint. The code >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> fairly easy to read. you can email me directly if you have >>>>>>>>>>>>>> specific >>>>>>>>>>>>>> questions. I had looked at creating a DMComplex and it did not >>>>>>>>>>>>>> look too >>>>>>>>>>>>>> difficult, as long as interpolation is not needed. I have plans >>>>>>>>>>>>>> to >>>>>>>>>>>>>> write DMComplexCreateExodus, but haven't had time too so far. >>>>>>>>>>>>>> Updating the >>>>>>>>>>>>>> Vec viewers and readers may be a bit more involved. In perfect >>>>>>>>>>>>>> world, one >>>>>>>>>>>>>> would write an EXODUS viewer following the lines of the VTK and >>>>>>>>>>>>>> HDF5 ones. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David and Blaise, I have converted this function, now >>>>>>>>>>>>> DMComplexCreateExodus(). Its not tested, but I think >>>>>>>>>>>>> Blaise has some stuff we can use to test it. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Matt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Blaise >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Let me know if you can run the tests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Matt >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Department of Mathematics and Center for Computation & >>>>>>>>>>>>>> Technology >>>>>>>>>>>>>> Louisiana State University, Baton Rouge, LA 70803, USA >>>>>>>>>>>>>> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 >>>>>>>>>>>>>> http://www.math.lsu.edu/~bourdin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >>> >> >> > > > -- > 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 > -- 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/5fa4456a/attachment-0001.htm>

[petsc-users] error in petsc-dev

ts to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/ca811ab2/attachment.htm>

[petsc-users] Problem with fortran version of ex29 in ksp

ETSC_NULL_INTEGER,ierr) >> >> Hx = 1.d0 / (mx-1) >> >> Hy = 1.d0 / (my-1) >> >> HxdHy = Hx/Hy >> >> HydHx = Hy/Hx >> >> call >> >> DMDAGetCorners(da,xs,ys,PETSC_NULL_INTEGER,xm,ym,PETSC_NULL_INTEGER,ierr) >> >> >> do j=ys,ys+ym-1 >> >> do i=xs,xs+xm-1 >> >> row(MatStencil_i) = i >> >> row(MatStencil_j) = j >> >> call ComputeRho(i,j,mx,my,centerRho,rho) >> >> if (i.eq.0 .or. j.eq.0 .or. i.eq.mx-1 .or. j.eq.my-1) >> then >> >> v(1) = 2.0*rho*(HxdHy + HydHx) >> >> call >> MatSetValuesStencil(jac,i1,row,i1,row,v,INSERT_VALUES,ierr) >> >> else >> >> v(1) = -rho*HxdHy >> >> col(MatStencil_i,1) = i >> >> col(MatStencil_j,2) = j-1 >> >> >> Cut and paste error above. >> >> Matt >> >> v(2) = -rho*HydHx >> >> col(MatStencil_i,2) = i-1 >> >> col(MatStencil_j,2) = j >> >> v(3) = 2.0*rho*(HxdHy + HydHx) >> >> col(MatStencil_i,3) = i >> >> col(MatStencil_j,3) = j >> >> v(4) = -rho*HydHx >> >> col(MatStencil_i,4) = i+1 >> >> col(MatStencil_j,4) = j >> >> v(5) = -rho*HxdHy >> >> col(MatStencil_i,5) = i >> >> col(MatStencil_j,5) = j+1 >> >> call >> MatSetValuesStencil(jac,i1,row,i5,col,v,INSERT_VALUES,ierr) >> >> end if >> >> end do >> >> end do >> >> call MatAssemblyBegin(jac,MAT_FINAL_ASSEMBLY,ierr) >> >> call MatAssemblyEnd(jac,MAT_FINAL_ASSEMBLY,ierr) >> >> !call >> >> MatNullSpaceCreate(PETSC_COMM_WORLD,PETSC_TRUE,PETSC_NULL_INTEGER,PETSC_NULL_INTEGER,nullspace,ierr) >> >> !call MatSetNullSpace(jac,nullspace,ierr) >> >> !call MatNullSpaceDestroy(nullspace,ierr) >> >> end subroutine ComputeMatrix >> >> subroutine ComputeRho(i,j,mx,my,centerRho,rho) >> >> PetscInti,j,mx,my >> >> PetscScalar rho,centerRho >> >> if ((i > mx/3.0) .and. (i < 2.0*mx/3.0) .and. (j > my/3.0) >> .and. (j < 2.0*my/3.0)) then >> >> rho = centerRho >> >> else >> >> rho = 1.0 >> >> end if >> >> >> end subroutine ComputeRho >> >> -- >> Yours sincerely, >> >> TAY wee-beng >> >> >> >> >> -- >> 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 > > > > > -- > 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/49c3c2fd/attachment-0001.htm>

[petsc-users] ex52_integrateElement.cu

>>>>> -lzmumps -lmumps_common -lpord -lparmetis -lmetis -lscalapack >>>>>>>>>>> -lblacs >>>>>>>>>>> -Wl,-rpath,/opt/apps/cuda/4.1/cuda/lib64 >>>>>>>>>>> -L/opt/apps/cuda/4.1/cuda/lib64 >>>>>>>>>>> -lcufft -lcublas -lcudart -lcusparse >>>>>>>>>>> -Wl,-rpath,/opt/MATLAB/R2011a/sys/os/glnxa64:/opt/MATLAB/R2011a/bin/glnxa64:/opt/MATLAB/R2011a/extern/lib/glnxa64 >>>>>>>>>>> -L/opt/MATLAB/R2011a/bin/glnxa64 >>>>>>>>>>> -L/opt/MATLAB/R2011a/extern/lib/glnxa64 >>>>>>>>>>> -leng -lmex -lmx -lmat -lut -licudata -licui18n -licuuc >>>>>>>>>>> -Wl,-rpath,/opt/epd-7.1-2-rh5-x86_64/lib >>>>>>>>>>> -L/opt/epd-7.1-2-rh5-x86_64/lib >>>>>>>>>>> -lmkl_rt -lmkl_intel_thread -lmkl_core -liomp5 -lexoIIv2for -lexodus >>>>>>>>>>> -lnetcdf_c++ -lnetcdf -Wl,-rpath,/usr/lib/gcc/x86_64-linux-gnu/4.4.3 >>>>>>>>>>> -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -ldl -lmpich -lopa -lpthread >>>>>>>>>>> -lrt >>>>>>>>>>> -lgcc_s -lmpichf90 -lgfortran -lm -lm -lmpichcxx -lstdc++ -lmpichcxx >>>>>>>>>>> -lstdc++ -ldl -lmpich -lopa -lpthread -lrt -lgcc_s -ldl >>>>>>>>>>> /bin/rm -f ex52.o ex52_integrateElement.o >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> SCRGP2$ ./ex52 -dim 2 -compute_function -show_residual -batch >>>>>>>>>>> Residual: >>>>>>>>>>> Vector Object: 1 MPI processes >>>>>>>>>>> type: seq >>>>>>>>>>> -0.25 >>>>>>>>>>> -0.5 >>>>>>>>>>> 0.25 >>>>>>>>>>> -0.5 >>>>>>>>>>> -1 >>>>>>>>>>> 0.5 >>>>>>>>>>> 0.25 >>>>>>>>>>> 0.5 >>>>>>>>>>> 0.75 >>>>>>>>>>> SCRGP2$ ./ex52 -dim 2 -compute_function -show_residual -batch >>>>>>>>>>> -gpu >>>>>>>>>>> [0]PETSC ERROR: IntegrateElementBatchGPU() line 323 in >>>>>>>>>>> src/snes/examples/tutorials/ex52_integrateElement.cu >>>>>>>>>>> [0]PETSC ERROR: FormFunctionLocalBatch() line 679 in >>>>>>>>>>> src/snes/examples/tutorials/ex52.c >>>>>>>>>>> [0]PETSC ERROR: SNESDMComplexComputeFunction() line 431 in >>>>>>>>>>> src/snes/utils/damgsnes.c >>>>>>>>>>> [0]PETSC ERROR: main() line 1021 in >>>>>>>>>>> src/snes/examples/tutorials/ex52.c >>>>>>>>>>> application called MPI_Abort(MPI_COMM_WORLD, 35) - process 0 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is failing on cudaMalloc(), which means your card is not >>>>>>>>>> available for running. Are you trying to run on your laptop? >>>>>>>>>> If so, applications like Preview can lock up the GPU. I know of >>>>>>>>>> no way to test this in CUDA while running. I just close >>>>>>>>>> apps until it runs. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 27, 2012 at 8:37 PM, Matthew Knepley < >>>>>>>>>>> knepley at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 27, 2012 at 2:10 PM, Blaise Bourdin < >>>>>>>>>>>> bourdin at lsu.edu> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 27, 2012, at 1:23 PM, Matthew Knepley wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 27, 2012 at 12:58 PM, David Fuentes < >>>>>>>>>>>>> fuentesdt at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I had a question about the status of example 52. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://petsc.cs.iit.edu/petsc/petsc-dev/file/a8e2f2c19319/src/snes/examples/tutorials/ex52.c >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://petsc.cs.iit.edu/petsc/petsc-dev/file/a8e2f2c19319/src/snes/examples/tutorials/ex52_integrateElement.cu >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can this example be used with a DM object created from an >>>>>>>>>>>>>> unstructured exodusII mesh, DMMeshCreateExodus, And the FEM >>>>>>>>>>>>>> assembly done >>>>>>>>>>>>>> on GPU ? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1) I have pushed many more tests for it now. They can be run >>>>>>>>>>>>> using the Python build system >>>>>>>>>>>>> >>>>>>>>>>>>> ./config/builder2.py check src/snes/examples/tutorials/ex52.c >>>>>>>>>>>>> >>>>>>>>>>>>> in fact, you can build any set of files this way. >>>>>>>>>>>>> >>>>>>>>>>>>> 2) The Exodus creation has to be converted to DMComplex from >>>>>>>>>>>>> DMMesh. That should not take me very long. Blaise maintains that >>>>>>>>>>>>> so maybe there will be help :) You will just replace >>>>>>>>>>>>> DMComplexCreateBoxMesh() with DMComplexCreateExodus(). If you >>>>>>>>>>>>> request >>>>>>>>>>>>> it, I will bump it up the list. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> DMMeshCreateExodusNG is much more flexible >>>>>>>>>>>>> than DMMeshCreateExodus in that it can read meshes with multiple >>>>>>>>>>>>> element >>>>>>>>>>>>> types and should have a much lower memory footprint. The code >>>>>>>>>>>>> should be >>>>>>>>>>>>> fairly easy to read. you can email me directly if you have >>>>>>>>>>>>> specific >>>>>>>>>>>>> questions. I had looked at creating a DMComplex and it did not >>>>>>>>>>>>> look too >>>>>>>>>>>>> difficult, as long as interpolation is not needed. I have plans to >>>>>>>>>>>>> write DMComplexCreateExodus, but haven't had time too so far. >>>>>>>>>>>>> Updating the >>>>>>>>>>>>> Vec viewers and readers may be a bit more involved. In perfect >>>>>>>>>>>>> world, one >>>>>>>>>>>>> would write an EXODUS viewer following the lines of the VTK and >>>>>>>>>>>>> HDF5 ones. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David and Blaise, I have converted this function, now >>>>>>>>>>>> DMComplexCreateExodus(). Its not tested, but I think >>>>>>>>>>>> Blaise has some stuff we can use to test it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Blaise >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Let me know if you can run the tests. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Matt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Department of Mathematics and Center for Computation & >>>>>>>>>>>>> Technology >>>>>>>>>>>>> Louisiana State University, Baton Rouge, LA 70803, USA >>>>>>>>>>>>> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 >>>>>>>>>>>>> http://www.math.lsu.edu/~bourdin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> -- >> 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 >> > > -- 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/a67ec439/attachment-0001.htm>

[petsc-users] help needed for -snes_mf_operator

sid norm > 6.122286294218e-01 ||r(i)||/||b|| 3.503381505824e-02 > > Dominik > -- 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 -- next part

[petsc-users] MatCreateMPIAIJ with zero size on some ranks

chnical troubles in PETSc. The share of nodes participating in the coarse space may vary. Thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/4a5fd0e5/attachment.htm>

[petsc-users] error in petsc-dev

An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/8e9fc0b5/attachment.htm>

[petsc-users] help needed for -snes_mf_operator

t; expected results in the expected time. > > Dominik > -- 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/cba71eef/attachment.htm>

[petsc-users] On pure boundary conditions with SNES

Dear All, I am solving a problem with pure boundary conditions with SNES with PETSc. I got the correct result with the following code, and it seems that Petsc detected the singularity and managed to solve that ( by adding another constraint like \sigma p_i=0?). However, it was much slower compared

[petsc-users] ex52_integrateElement.cu

1a/extern/lib/glnxa64 >>>>>>>>>> -leng -lmex -lmx -lmat -lut -licudata -licui18n -licuuc >>>>>>>>>> -Wl,-rpath,/opt/epd-7.1-2-rh5-x86_64/lib >>>>>>>>>> -L/opt/epd-7.1-2-rh5-x86_64/lib >>>>>>>>>> -lmkl_rt -lmkl_intel_thread -lmkl_core -liomp5 -lexoIIv2for -lexodus >>>>>>>>>> -lnetcdf_c++ -lnetcdf -Wl,-rpath,/usr/lib/gcc/x86_64-linux-gnu/4.4.3 >>>>>>>>>> -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 -ldl -lmpich -lopa -lpthread >>>>>>>>>> -lrt >>>>>>>>>> -lgcc_s -lmpichf90 -lgfortran -lm -lm -lmpichcxx -lstdc++ -lmpichcxx >>>>>>>>>> -lstdc++ -ldl -lmpich -lopa -lpthread -lrt -lgcc_s -ldl >>>>>>>>>> /bin/rm -f ex52.o ex52_integrateElement.o >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> SCRGP2$ ./ex52 -dim 2 -compute_function -show_residual -batch >>>>>>>>>> Residual: >>>>>>>>>> Vector Object: 1 MPI processes >>>>>>>>>> type: seq >>>>>>>>>> -0.25 >>>>>>>>>> -0.5 >>>>>>>>>> 0.25 >>>>>>>>>> -0.5 >>>>>>>>>> -1 >>>>>>>>>> 0.5 >>>>>>>>>> 0.25 >>>>>>>>>> 0.5 >>>>>>>>>> 0.75 >>>>>>>>>> SCRGP2$ ./ex52 -dim 2 -compute_function -show_residual -batch -gpu >>>>>>>>>> [0]PETSC ERROR: IntegrateElementBatchGPU() line 323 in >>>>>>>>>> src/snes/examples/tutorials/ex52_integrateElement.cu >>>>>>>>>> [0]PETSC ERROR: FormFunctionLocalBatch() line 679 in >>>>>>>>>> src/snes/examples/tutorials/ex52.c >>>>>>>>>> [0]PETSC ERROR: SNESDMComplexComputeFunction() line 431 in >>>>>>>>>> src/snes/utils/damgsnes.c >>>>>>>>>> [0]PETSC ERROR: main() line 1021 in >>>>>>>>>> src/snes/examples/tutorials/ex52.c >>>>>>>>>> application called MPI_Abort(MPI_COMM_WORLD, 35) - process 0 >>>>>>>>>> >>>>>>>>> >>>>>>>>> This is failing on cudaMalloc(), which means your card is not >>>>>>>>> available for running. Are you trying to run on your laptop? >>>>>>>>> If so, applications like Preview can lock up the GPU. I know of no >>>>>>>>> way to test this in CUDA while running. I just close >>>>>>>>> apps until it runs. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 27, 2012 at 8:37 PM, Matthew Knepley < >>>>>>>>>> knepley at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> On Tue, Mar 27, 2012 at 2:10 PM, Blaise Bourdin >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mar 27, 2012, at 1:23 PM, Matthew Knepley wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 27, 2012 at 12:58 PM, David Fuentes < >>>>>>>>>>>> fuentesdt at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I had a question about the status of example 52. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://petsc.cs.iit.edu/petsc/petsc-dev/file/a8e2f2c19319/src/snes/examples/tutorials/ex52.c >>>>>>>>>>>>> >>>>>>>>>>>>> http://petsc.cs.iit.edu/petsc/petsc-dev/file/a8e2f2c19319/src/snes/examples/tutorials/ex52_integrateElement.cu >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Can this example be used with a DM object created from an >>>>>>>>>>>>> unstructured exodusII mesh, DMMeshCreateExodus, And the FEM >>>>>>>>>>>>> assembly done >>>>>>>>>>>>> on GPU ? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1) I have pushed many more tests for it now. They can be run >>>>>>>>>>>> using the Python build system >>>>>>>>>>>> >>>>>>>>>>>> ./config/builder2.py check src/snes/examples/tutorials/ex52.c >>>>>>>>>>>> >>>>>>>>>>>> in fact, you can build any set of files this way. >>>>>>>>>>>> >>>>>>>>>>>> 2) The Exodus creation has to be converted to DMComplex from >>>>>>>>>>>> DMMesh. That should not take me very long. Blaise maintains that >>>>>>>>>>>> so maybe there will be help :) You will just replace >>>>>>>>>>>> DMComplexCreateBoxMesh() with DMComplexCreateExodus(). If you >>>>>>>>>>>> request >>>>>>>>>>>> it, I will bump it up the list. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> DMMeshCreateExodusNG is much more flexible >>>>>>>>>>>> than DMMeshCreateExodus in that it can read meshes with multiple >>>>>>>>>>>> element >>>>>>>>>>>> types and should have a much lower memory footprint. The code >>>>>>>>>>>> should be >>>>>>>>>>>> fairly easy to read. you can email me directly if you have specific >>>>>>>>>>>> questions. I had looked at creating a DMComplex and it did not >>>>>>>>>>>> look too >>>>>>>>>>>> difficult, as long as interpolation is not needed. I have plans to >>>>>>>>>>>> write DMComplexCreateExodus, but haven't had time too so far. >>>>>>>>>>>> Updating the >>>>>>>>>>>> Vec viewers and readers may be a bit more involved. In perfect >>>>>>>>>>>> world, one >>>>>>>>>>>> would write an EXODUS viewer following the lines of the VTK and >>>>>>>>>>>> HDF5 ones. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David and Blaise, I have converted this function, now >>>>>>>>>>> DMComplexCreateExodus(). Its not tested, but I think >>>>>>>>>>> Blaise has some stuff we can use to test it. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Blaise >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Let me know if you can run the tests. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Department of Mathematics and Center for Computation & >>>>>>>>>>>> Technology >>>>>>>>>>>> Louisiana State University, Baton Rouge, LA 70803, USA >>>>>>>>>>>> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 >>>>>>>>>>>> http://www.math.lsu.edu/~bourdin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> >> >> >> -- >> 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 >> > > > > -- > 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 > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/3614b519/attachment-0001.htm>

[petsc-users] help needed for -snes_mf_operator

I am successfully solving a couple (unstructured FEM) benchmark problems with SNES, providing both FormFunction and FormJacobian. I am using a simple (polynomial) form for the nonlinear part so I am fairly sure I compute the Jacobian correctly and exactly. I am also getting the expected results. N

[petsc-users] error in petsc-dev

etFromOptions and 2) I do not call MatSeqAIJSetPreallocation which I think I do not need anyway. Is there something I'm doing wrong? Mohammd -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/0ccae1d1/attachment-0001.htm>

[petsc-users] error in petsc-dev

otta check. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/d393ef7b/attachment.htm>

[petsc-users] error in petsc-dev

es(m, 10, 10, PETSC_DECIDE, PETSC_DECIDE); >>>>>> >>>>>> MatSetFromOptions(m); >>>>>> >>>>>> MatAssemblyBegin(m, MAT_FINAL_ASSEMBLY); >>>>>> >>>>>> MatAssemblyEnd(m, MAT_FINAL_ASSEMBLY); >>>>>> >>>>>> MatView(m, PETSC_VIEWER_STDOUT_WORLD); >>>>>> >>>>>> MatDestroy(&m); >>>>>> >>>>>> >>>>>> PetscFinalize(); >>>>>> >>>>>> return 0; >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> This runs without any problem under 3.2-p6 but fails with petsc-dev: >>>>>> >>>>>> [0]PETSC ERROR: - Error Message >>>>>> >>>>>> [0]PETSC ERROR: Object is in wrong state! >>>>>> [0]PETSC ERROR: Must call MatXXXSetPreallocation() or MatSetUp() on >>>>>> argument 1 "mat" before MatAssemblyBegin()! >>>>>> [0]PETSC ERROR: >>>>>> >>>>>> >>>>>> Eventually I could fix this by adding MatSetUp(m) after setting the >>>>>> options. Why do I need this in petsc-dev? Does this somehow preallocate >>>>>> the >>>>>> matrix? >>>>>> >>>>> Yes. >>>>> >>>>> Hong >>>>> >>>>>> >>>>>> Thanks, >>>>>> Mohammad >>>>>> >>>>> >>>>> >>>> >>> >> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/ba5ddf9c/attachment.htm>

[petsc-users] MatCreateMPIAIJ with zero size on some ranks

Is it possible to create a parallel matrix (MPIAIJ) with empty size on some ranks? Even if this should work, does it make sense (with respect to runtime and efficiency) to collect all ranks having a nonempty contribution the the global matrix in an mpi group and to use this communicator for mat

[petsc-users] MatCreateMPIAIJ with zero size on some ranks

d before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/ef392618/attachment.htm>

[petsc-users] MatCreateMPIAIJ with zero size on some ranks

attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/6ee0760f/attachment-0001.htm>

[petsc-users] MatCreateMPIAIJ with zero size on some ranks

ality (independent of whether you also contract the communicator) is more useful for MatMult, but you have to weight the benefits relative to the cost of moving the data, and it may not pay off. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/p

[petsc-users] help needed for -snes_mf_operator

tachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/b22494f1/attachment-0001.htm>

[petsc-users] error in petsc-dev

atrix()) before calling MatSetValues(), MatSetValuesBlocked() etc. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/cf557b1e/attachment-0001.htm>

[petsc-users] On pure boundary conditions with SNES

directly, use SNESGetKSP, then KSPSetNullSpace; with petsc-dev, you can just call MatSetNullSpace() on the operator (and preconditioning matrix, if applicable). -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/671eeebe/attachment.htm>

[petsc-users] help needed for -snes_mf_operator

your approximate Jacobian? Are you still calling MatAssemblyBegin/End on the first argument, as in the examples? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/72983ed2/attachment.htm>

[petsc-users] MatCreateMPIAIJ with zero size on some ranks

--- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120425/187cb266/attachment.htm>