March 2011 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] missing include files
by Lisandro Dalcin 17 Mar '11

17 Mar '11

On 17 March 2011 18:46, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Hi, > > include/finclude/petsc.h references "finclude/petscdmadda.h", "finclude/petscdmcomposite.h", "finclude/petscdmsliced.h", none of which exists in my system. > > Is the header file wrong or are the header files really missing in the repository? > I think it is the second. However, I'm not sure if the ADDA, COMPOSITE and Sliced API's are fully supported in Fortran. [dalcinl@nikola dev]$ nm linux-gnu/lib/libpetsc.so | grep dmadda 0000000000599900 T dmaddagetcorners_ 00000000005998f0 T dmaddagetghostcorners_ 0000000000599930 T dmaddagetmatrixns_ 0000000000599910 T dmaddasetrefinement_ [dalcinl@nikola dev]$ nm linux-gnu/lib/libpetsc.so | grep dmcomposite 0000000000596ed0 T dmcompositeaddarray_ 0000000000596f00 T dmcompositeadddm_ 0000000000596f20 T dmcompositecreate_ 0000000000596ef0 T dmcompositedestroy_ 0000000000596eb0 T dmcompositegetaccess4_ 0000000000626970 T dmcompositegetaccessvpvp_ 0000000000596df0 T dmcompositegetcontext_ 0000000000596fb0 T dmcompositegetentries1_ 0000000000596f90 T dmcompositegetentries2_ 0000000000596f70 T dmcompositegetentries3_ 0000000000596f50 T dmcompositegetentries4_ 0000000000596f30 T dmcompositegetentries5_ 0000000000596e30 T dmcompositegetlocalvectors4_ 0000000000596e50 T dmcompositerestoreaccess4_ 0000000000626900 T dmcompositerestoreaccessvpvp_ 0000000000596e10 T dmcompositerestorelocalvectors4_ 0000000000596e80 T dmcompositescatter4_ 0000000000596e00 T dmcompositesetcontext_ [dalcinl@nikola dev]$ nm linux-gnu/lib/libpetsc.so | grep dmsliced > > The problem comes up when compiling a heavily patched version of TAO compatible with petsc-dev > Is this patched version publicly available somewhere? Are you planning to contribute it back to TAO? Do it still requires a C++ build of PETSc? -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

missing include files
by Blaise Bourdin 17 Mar '11

17 Mar '11

Hi, include/finclude/petsc.h references "finclude/petscdmadda.h", "finclude/petscdmcomposite.h", "finclude/petscdmsliced.h", none of which exists in my system. Is the header file wrong or are the header files really missing in the repository? The problem comes up when compiling a heavily patched version of TAO compatible with petsc-dev Blaise -- 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

1 0

Re: [petsc-dev] Using PCFieldSplitSetIS
by Barry Smith 17 Mar '11

17 Mar '11

Did you get a chance to run as I requested with "Please run with -ksp_view and send the output." We are eager to determine the problem. Barry On Mar 16, 2011, at 11:03 AM, Barry Smith wrote: > > On Mar 16, 2011, at 8:57 AM, Thomas Witkowski wrote: > > -pc_fieldsplit_type schur -fieldsplit_interior_ksp_type preonly -fieldsplit_interior_pc_type bjacobi -fieldsplit_interior_sub_pc_type lu -fieldsplit_boundary_ksp_monitor -ksp_monitor_true_residual > > >> Residual norms for fieldsplit_boundary_ solve. >> 0 KSP Residual norm 1.790059331071e-04 >> ..... >> 18 KSP Residual norm 1.593454221996e-09 >> 0 KSP preconditioned resid norm 5.745043818120e-01 true resid norm 1.584249437360e-01 ||r(i)||/||b|| 1.000000000000e+00 > This is the norms on the outer iteration variables >> Residual norms for fieldsplit_boundary_ solve. >> 0 KSP Residual norm 1.790059331000e-04 > This is the norms on the Schur complement iteration >> .... >> 18 KSP Residual norm 1.593449602302e-09 > > It is unclear to me why it starts up another solve here, starting basically where it left off. I think it should just kick out to print the norm of the residual of the outer iteration. > >> Residual norms for fieldsplit_boundary_ solve. >> 0 KSP Residual norm 1.593449603155e-09 >> ... >> 18 KSP Residual norm 1.335744434252e-14 >> 1 KSP preconditioned resid norm 2.608069232839e-13 true resid norm 1.449869994655e-13 ||r(i)||/||b|| 9.151778504469e-13 >> > > Are you running with petsc-dev? > > Please run with -ksp_view and send the output. > > When I run tutorials/multiphysics/mp.c with the options ./mp -couple -snes_monitor_short -pc_type fieldsplit -ksp_monitor -pc_fieldsplit_type schur -fieldsplit_ksp_monitor -fieldsplit_1_ksp_type fgmres -fieldsplit_0_ksp_type gmres -snes_view I do not see the "double" iteration business. > > Barry > > > >> >> So, are there now two or one outer iterations? >> >> Thomas >> >> >> >> >> Matthew Knepley wrote: >>> On Wed, Mar 16, 2011 at 8:27 AM, Thomas Witkowski <thomas.witkowski(a)tu-dresden.de <mailto:[email protected]>> wrote: >>> >>> Jed Brown wrote: >>> >>> On Wed, Mar 16, 2011 at 07:37, Thomas Witkowski >>> <thomas.witkowski(a)tu-dresden.de >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> wrote: >>> >>> Thanks for explanations! It works fine in my code. But I >>> have two >>> questions about it, maybe you can help me with them: >>> - To the first, is the LU factorization on block A_00 done >>> only once? >>> >>> >>> Yes, one way to confirm this is to run with -log_summary and >>> check MatLUFactor{Sym,Num}. >>> - I have run the code with -fieldsplit_1_ksp_monitor to get >>> some >>> more information about the internal solves. I expected to get >>> information about one iterative solver (for solving the Schur >>> complement system), but I got three, all of them need around 20 >>> iterations for my example. Could you explain to me what is >>> actually solved there? >>> >>> >>> I'm going to guess that you still have an outer KSP that (in >>> the global norm, rather than the partitioned norm used inside >>> of splits) has a tighter tolerance, therefore it takes a few >>> outer iterations. If you use loose inner tolerances then the >>> preconditioner becomes nonlinear and you'll need to use FGMRES >>> for the outer. When in doubt, run with -ksp_view and show us >>> the results if you don't understand. Additionally, monitoring >>> inner solves separately can be useful, e.g. >>> -fieldsplit_0_ksp_converged_reason -fieldsplit_1_ksp_monitor >>> -ksp_monitor_true_residual. >>> >>> Okay, I run my code with the options "-pc_fieldsplit_type schur >>> -fieldsplit_interior_ksp_type preonly -fieldsplit_interior_pc_type >>> bjacobi -fieldsplit_interior_sub_pc_type lu >>> -fieldsplit_boundary_ksp_monitor -ksp_monitor_true_residual >>> -fieldsplit_interior_ksp_converged_reason". The splits are named >>> "interior" and "boundary". The ksp output is as follows: >>> >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> Residual norms for fieldsplit_boundary_ solve. >>> 0 KSP Residual norm 1.790059331071e-04 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 1 KSP Residual norm 1.237356212928e-04 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 2 KSP Residual norm 7.952220245101e-05 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 3 KSP Residual norm 3.502858665398e-05 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 4 KSP Residual norm 1.601085190129e-05 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 5 KSP Residual norm 8.491161243057e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 6 KSP Residual norm 4.778227395989e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 7 KSP Residual norm 2.571919352633e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 8 KSP Residual norm 1.353979940120e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 9 KSP Residual norm 7.408377337496e-07 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 10 KSP Residual norm 3.810694345834e-07 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 11 KSP Residual norm 1.955889542056e-07 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 12 KSP Residual norm 9.938906113920e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 13 KSP Residual norm 4.893445675773e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 14 KSP Residual norm 2.395128458062e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 15 KSP Residual norm 1.2464425896 <tel:1.2464425896>57e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 16 KSP Residual norm 6.316454504022e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 17 KSP Residual norm 3.088668836241e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 18 KSP Residual norm 1.593454221996e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> [0] Petsc-Iteration 0: 0.574504 >>> 0 KSP preconditioned resid norm 5.745043818120e-01 true resid >>> norm 1.584249437360e-01 ||r(i)||/||b|| 1.000000000000e+00 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> Residual norms for fieldsplit_boundary_ solve. >>> 0 KSP Residual norm 1.790059331000e-04 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 1 KSP Residual norm 1.237356237744e-04 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 2 KSP Residual norm 7.952220078415e-05 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 3 KSP Residual norm 3.502859285561e-05 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 4 KSP Residual norm 1.601086485810e-05 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 5 KSP Residual norm 8.491169384185e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 6 KSP Residual norm 4.778229157872e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 7 KSP Residual norm 2.571917112191e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 8 KSP Residual norm 1.353977280183e-06 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 9 KSP Residual norm 7.408352317360e-07 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 10 KSP Residual norm 3.810710583336e-07 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 11 KSP Residual norm 1.955898169394e-07 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 12 KSP Residual norm 9.938892788465e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 13 KSP Residual norm 4.893428546840e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 14 KSP Residual norm 2.395120857135e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 15 KSP Residual norm 1.2464367927 <tel:1.2464367927>84e-08 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 16 KSP Residual norm 6.316409779118e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 17 KSP Residual norm 3.088649355374e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 18 KSP Residual norm 1.593449602302e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> Residual norms for fieldsplit_boundary_ solve. >>> 0 KSP Residual norm 1.593449603155e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 1 KSP Residual norm 1.011857676662e-09 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 2 KSP Residual norm 5.660892669788e-10 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 3 KSP Residual norm 3.046799343903e-10 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 4 KSP Residual norm 1.6004713993 <tel:1.6004713993>29e-10 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 5 KSP Residual norm 8.083216601016e-11 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 6 KSP Residual norm 4.308671648345e-11 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 7 KSP Residual norm 2.381959817139e-11 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 8 KSP Residual norm 1.264839790114e-11 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 9 KSP Residual norm 6.435098853282e-12 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 10 KSP Residual norm 3.184769579797e-12 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 11 KSP Residual norm 1.5022019430 <tel:1.5022019430>16e-12 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 12 KSP Residual norm 7.099486208425e-13 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 13 KSP Residual norm 3.443222176388e-13 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 14 KSP Residual norm 1.6478434989 <tel:1.6478434989>12e-13 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 15 KSP Residual norm 8.208508173926e-14 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 16 KSP Residual norm 4.376604355287e-14 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 17 KSP Residual norm 2.596069152755e-14 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 18 KSP Residual norm 1.335744434252e-14 >>> Linear solve converged due to CONVERGED_ITS iterations 1 >>> 1 KSP preconditioned resid norm 2.608069232839e-13 true resid >>> norm 1.449869994655e-13 ||r(i)||/||b|| 9.151778504469e-13 >>> >>> I have no idea how to interpret this output! Could you help me >>> with it? >>> >>> >>> Get rid of -fieldsplit_interior_ksp_converged_reason. It is confusing things. Then you will see >>> the outer iteration and the inner boundary iteration which is indented. >>> >>> Matt >>> >>> >>> Thomas >>> >>> >>> >>> >>> -- >>> 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] PCCreate_BFBt has no manual page
by Barry Smith 17 Mar '11

17 Mar '11

Remove it. Dead code is a sin. Barry On Mar 17, 2011, at 9:09 AM, Jed Brown wrote: > On Sun, Feb 27, 2011 at 18:15, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > This exact text could go into the manual page. The problem now is that this information is in only one location (your head) and no one else knows if > 1) BFBt is orthogonal to to lsc > 2) BFBt is the replacement to lsc > 3) BFBt is to be replaced with lsc. > without consulting you. > > Dave knows. :-) > > Indeed, he just did the real work here and put in the MatNest support so that the BFBt methods from his paper now run with LSC and produces identical results. This has been merged into petsc-dev. > > About this example, it's quite a hard problem and pretty small (32x32 Q1-P0 elements), but the matrices come from Underworld which we can't easily include in a test. I'm inclined to put the matrix into datafiles and add the test to the nightlies since it seems to be a discerning preconditioner benchmark. > > Now about whether to delete PCBFBT now or leave it around. I don't see a problem with adding a man page that puts it in the "developer" level and has a note that it is deprecated and LSC should be used instead, with a link to this example for details on converting code.

1 0

Re: [petsc-dev] MatSetDA -> MatSetDM
by Barry Smith 17 Mar '11

17 Mar '11

On Mar 17, 2011, at 7:19 AM, Lisandro Dalcin wrote: > On 16 March 2011 23:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> >> No. Then we need VecGetComm(), KSPGetComm(), MonkeyGetComm() and it never ends >> > > Yes, I know... > >> Perhaps >> >> PetscErrorCode PetscObjectGetComm_(PetscObject,MPI_Comm*); >> #define PetscObjectGetComm(A,B) PetscObjectGetComm_((PetscObject)A,B) >> >> to hide the uglyness? >> > > The problem with this is that you effectively loose type checking... > You can PetscObjectGetComm() with whatever crap, and you do not notice > until runtime. But doing the cast yourself also removes the type checking: PetscObjectGetComm((PetscObject)vec,&comm); I can pass anything in for vec (like a pointer to an integer) and the type is not checked. Not having the type checking in PetscObjectGetComm() doesn't really bother me since it is pretty obvious that a PetscObject must be passed in; plus there is the run time checking. Barry > >> In fact, XXXXSetOptionsPrefix() could be all wrapped up in PetscObjectSetOptionsPrefix(). Heck even XXXSetFromOptions() and XXXSetUp() could be wrapped in PetscObjectSetFromOptions(), PetscObjectSetUp() but that may be going too far :-) >> > > Well, you have a very valid point, but as I said, PetscObjectXXX() > calls are nasty to use and you loose type checking... What about > providing XXSetup(), XXXGetComm(), XXXSetFromOptions(), and any other > important enough as STATIC_INLINE functions being a thin wrapper to > the corresponding PetscObjectXXX() ? > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] PCCreate_BFBt has no manual page
by Jed Brown 17 Mar '11

17 Mar '11

On Sun, Feb 27, 2011 at 18:15, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > This exact text could go into the manual page. The problem now is that this > information is in only one location (your head) and no one else knows if > 1) BFBt is orthogonal to to lsc > 2) BFBt is the replacement to lsc > 3) BFBt is to be replaced with lsc. > without consulting you. > Dave knows. :-) Indeed, he just did the real work here and put in the MatNest support so that the BFBt methods from his paper now run with LSC and produces identical results. This has been merged into petsc-dev. About this example, it's quite a hard problem and pretty small (32x32 Q1-P0 elements), but the matrices come from Underworld which we can't easily include in a test. I'm inclined to put the matrix into datafiles and add the test to the nightlies since it seems to be a discerning preconditioner benchmark. Now about whether to delete PCBFBT now or leave it around. I don't see a problem with adding a man page that puts it in the "developer" level and has a note that it is deprecated and LSC should be used instead, with a link to this example for details on converting code.

1 0

Re: [petsc-dev] MatSetDA -> MatSetDM
by Jed Brown 17 Mar '11

17 Mar '11

On Thu, Mar 17, 2011 at 13:19, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Well, you have a very valid point, but as I said, PetscObjectXXX() > calls are nasty to use and you loose type checking... What about > providing XXSetup(), XXXGetComm(), XXXSetFromOptions(), and any other > important enough as STATIC_INLINE functions being a thin wrapper to > the corresponding PetscObjectXXX() ? > It's a documentation problem as much as anything, technically these wrappers are one-liners to create (caps because it's a compile-time definition). petscsys.h: #define PETSC_OBJECT_FORWARD_DEFINE1(type,method,arg1type) \ PETSC_STATIC_INLINE PetscErrorCode type ## method (type obj,arg1type arg1) { \ PetscErrorCode ierr; \ PetscFunctionBegin; \ PetscValidHeaderSpecific(obj,type ## _CLASSID,1); \ ierr = PetscObject ## method ((PetscObject)obj,arg1);CHKERRQ(ierr); \ PetscFunctionReturn(0); } petscdm.h: PETSC_OBJECT_FORWARD_DEFINE1(DM,GetComm,MPI_Comm*) I don't have a strong opinion about whether or not to have these wrappers.

1 0

Re: [petsc-dev] quad precision
by Aron Ahmadia 17 Mar '11

17 Mar '11

Cool! On Thu, Mar 17, 2011 at 1:00 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > On Feb 8, 2011, at 6:31 AM, Jed Brown wrote: > >> > GCC now ships with the LGPL-licensed libquadmath library, which provides for targets with a __float128 datatype quad-precision mathematical functions. __float128 is available for targets on 32-bit x86, x86-64 and Itanium architectures. The libquadmath library is automatically built on such targets when building the Fortran compiler. >> >> http://gcc.gnu.org/gcc-4.6/changes.html#libquadmath >> http://gcc.gnu.org/onlinedocs/libquadmath/ >> >> Looks like this is something that actually works. GCC-4.6 is probably about two months away from a release, but this should be functional now. Perhaps it should be supported by petsc-3.2? > > Done (use ./configure --with-precision=__float128 --download-qblaslapack > > barry-smiths-macbook-pro:tutorials barrysmith$ petscmpiexec -n 2 ./ex19 -snes_monitor -ksp_monitor -ksp_rtol 1.e-30 -snes_rtol 1.e-28 > lid velocity = Qe, prandtl # = Qe, grashof # = Qe > 0 SNES Function norm 1.461936698223e-01 > 0 KSP Residual norm 1.461936698223e-01 > 1 KSP Residual norm 1.831093524630e-02 > 2 KSP Residual norm 3.842156479462e-03 > 3 KSP Residual norm 1.288406516834e-04 > 4 KSP Residual norm 6.151749539864e-06 > 5 KSP Residual norm 5.304145544729e-07 > 6 KSP Residual norm 1.885113023052e-08 > 7 KSP Residual norm 7.029816194041e-10 > 8 KSP Residual norm 5.197815114974e-11 > 9 KSP Residual norm 1.551090319297e-12 > 10 KSP Residual norm 6.563825928589e-14 > 11 KSP Residual norm 4.237666605992e-15 > 12 KSP Residual norm 1.991927370291e-16 > 13 KSP Residual norm 2.039546156320e-17 > 14 KSP Residual norm 1.399229447695e-17 > 15 KSP Residual norm 1.137432635542e-17 > 16 KSP Residual norm 9.814665753619e-18 > 17 KSP Residual norm 8.761318174145e-18 > 18 KSP Residual norm 7.987316427844e-18 > 19 KSP Residual norm 7.387832309954e-18 > 20 KSP Residual norm 6.905793284234e-18 > 21 KSP Residual norm 6.507264709320e-18 > 22 KSP Residual norm 6.170620606220e-18 > 23 KSP Residual norm 5.881342212029e-18 > 24 KSP Residual norm 5.629271709982e-18 > 25 KSP Residual norm 5.407060816706e-18 > 26 KSP Residual norm 5.209244641147e-18 > 27 KSP Residual norm 5.031663281118e-18 > 28 KSP Residual norm 4.871086689542e-18 > 29 KSP Residual norm 4.724963445290e-18 > 30 KSP Residual norm 1.945800083119e-17 > 31 KSP Residual norm 3.878029318777e-18 > 32 KSP Residual norm 8.021501106718e-19 > 33 KSP Residual norm 3.209251006205e-20 > 34 KSP Residual norm 9.713771954068e-22 > 35 KSP Residual norm 7.628163240222e-23 > 36 KSP Residual norm 4.108476441305e-24 > 37 KSP Residual norm 1.743186899274e-25 > 38 KSP Residual norm 1.115126800943e-26 > 39 KSP Residual norm 6.198813188878e-28 > 40 KSP Residual norm 2.869837519115e-29 > 41 KSP Residual norm 1.515585472682e-30 > 42 KSP Residual norm 5.770691059470e-32 > 1 SNES Function norm 2.507018921541e-05 > 0 KSP Residual norm 2.507018921541e-05 > 1 KSP Residual norm 7.131114735363e-07 > 2 KSP Residual norm 6.965532093127e-08 > 3 KSP Residual norm 8.087355337901e-09 > 4 KSP Residual norm 2.749048294679e-10 > 5 KSP Residual norm 1.113870556134e-11 > 6 KSP Residual norm 4.684216963041e-13 > 7 KSP Residual norm 4.911624900830e-14 > 8 KSP Residual norm 2.475960732046e-15 > 9 KSP Residual norm 1.012965264508e-16 > 10 KSP Residual norm 5.199268899437e-18 > 11 KSP Residual norm 2.361382990671e-19 > 12 KSP Residual norm 1.624218498133e-20 > 13 KSP Residual norm 1.626389274652e-21 > 14 KSP Residual norm 1.086627523198e-21 > 15 KSP Residual norm 8.796270682258e-22 > 16 KSP Residual norm 7.562576022670e-22 > 17 KSP Residual norm 6.738068994025e-22 > 18 KSP Residual norm 6.134859714231e-22 > 19 KSP Residual norm 5.669225669612e-22 > 20 KSP Residual norm 5.295704884674e-22 > 21 KSP Residual norm 4.987454291392e-22 > 22 KSP Residual norm 4.727440148233e-22 > 23 KSP Residual norm 4.504266287687e-22 > 24 KSP Residual norm 4.309981502786e-22 > 25 KSP Residual norm 4.138846776251e-22 > 26 KSP Residual norm 3.986602059865e-22 > 27 KSP Residual norm 3.850009759823e-22 > 28 KSP Residual norm 3.726559420703e-22 > 29 KSP Residual norm 3.614270387400e-22 > 30 KSP Residual norm 1.485730798507e-21 > 31 KSP Residual norm 5.734533095762e-23 > 32 KSP Residual norm 2.917983740862e-24 > 33 KSP Residual norm 2.415955278478e-25 > 34 KSP Residual norm 2.754121553256e-26 > 35 KSP Residual norm 1.530546077890e-27 > 36 KSP Residual norm 1.236527954824e-28 > 37 KSP Residual norm 5.968984750158e-30 > 38 KSP Residual norm 2.679693674423e-31 > 39 KSP Residual norm 2.728339059485e-32 > 40 KSP Residual norm 8.956127952264e-34 > 41 KSP Residual norm 2.732653737468e-35 > 42 KSP Residual norm 1.278928596713e-36 > 2 SNES Function norm 5.123354965471e-13 > 0 KSP Residual norm 5.123354965471e-13 > 1 KSP Residual norm 1.922138659280e-14 > 2 KSP Residual norm 1.916027080380e-15 > 3 KSP Residual norm 1.173166951366e-16 > 4 KSP Residual norm 6.562671109080e-18 > 5 KSP Residual norm 1.982740889768e-19 > 6 KSP Residual norm 1.593609248118e-20 > 7 KSP Residual norm 5.849655936465e-22 > 8 KSP Residual norm 2.871644899437e-23 > 9 KSP Residual norm 8.762292108710e-25 > 10 KSP Residual norm 2.883597656362e-26 > 11 KSP Residual norm 1.508069830626e-27 > 12 KSP Residual norm 9.552654188779e-29 > 13 KSP Residual norm 5.964437523019e-29 > 14 KSP Residual norm 4.773742821457e-29 > 15 KSP Residual norm 4.073114192114e-29 > 16 KSP Residual norm 3.613955807224e-29 > 17 KSP Residual norm 3.281398363062e-29 > 18 KSP Residual norm 3.026482504508e-29 > 19 KSP Residual norm 2.823023108355e-29 > 20 KSP Residual norm 2.655755272176e-29 > 21 KSP Residual norm 2.515082243565e-29 > 22 KSP Residual norm 2.394629606506e-29 > 23 KSP Residual norm 2.289975422292e-29 > 24 KSP Residual norm 2.197943014798e-29 > 25 KSP Residual norm 2.116183578028e-29 > 26 KSP Residual norm 2.042917954989e-29 > 27 KSP Residual norm 1.976770491487e-29 > 28 KSP Residual norm 1.916658520825e-29 > 29 KSP Residual norm 1.861716726173e-29 > 30 KSP Residual norm 7.847792961992e-29 > 31 KSP Residual norm 3.265251638392e-30 > 32 KSP Residual norm 2.554035610120e-31 > 33 KSP Residual norm 1.708749092417e-32 > 34 KSP Residual norm 1.088457747082e-33 > 35 KSP Residual norm 4.004032418947e-35 > 36 KSP Residual norm 3.626864425969e-36 > 37 KSP Residual norm 1.998928979977e-37 > 38 KSP Residual norm 5.929794876014e-39 > 39 KSP Residual norm 3.867971851833e-40 > 40 KSP Residual norm 2.306219660368e-41 > 41 KSP Residual norm 1.109502994834e-42 > 42 KSP Residual norm 7.010253552905e-44 > 3 SNES Function norm 1.676590295787e-28 > >

1 0

Re: [petsc-dev] MatSetDA -> MatSetDM
by Lisandro Dalcin 17 Mar '11

17 Mar '11

On 16 March 2011 23:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > No. Then we need VecGetComm(), KSPGetComm(), MonkeyGetComm() and it never ends > Yes, I know... > Perhaps > > PetscErrorCode PetscObjectGetComm_(PetscObject,MPI_Comm*); > #define PetscObjectGetComm(A,B) PetscObjectGetComm_((PetscObject)A,B) > > to hide the uglyness? > The problem with this is that you effectively loose type checking... You can PetscObjectGetComm() with whatever crap, and you do not notice until runtime. > In fact, XXXXSetOptionsPrefix() could be all wrapped up in PetscObjectSetOptionsPrefix(). Heck even XXXSetFromOptions() and XXXSetUp() could be wrapped in PetscObjectSetFromOptions(), PetscObjectSetUp() but that may be going too far :-) > Well, you have a very valid point, but as I said, PetscObjectXXX() calls are nasty to use and you loose type checking... What about providing XXSetup(), XXXGetComm(), XXXSetFromOptions(), and any other important enough as STATIC_INLINE functions being a thin wrapper to the corresponding PetscObjectXXX() ? -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] MatSetDA -> MatSetDM
by Barry Smith 16 Mar '11

16 Mar '11

On Mar 16, 2011, at 9:13 PM, Lisandro Dalcin wrote: > On 16 March 2011 22:47, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> On Mar 16, 2011, at 6:21 AM, Lisandro Dalcin wrote: >> >>> From petscdmda.h: >>> >>> extern PetscErrorCode MatSetDA(Mat,DM); >>> >>> Could you rename it? (sorry, I'm really busy with other stuff) >> >> Fixed. >> > > Many thanks, > >>> >>> BTW, we should have DMSetMatType() ... >> >> Actually my plan is to remove DMSetVecType() and change DMGetGlobalVector(), DMGGetLocalVector() and DMGetMatrix() to take an already created Vec or Mat and if the type is set inside that object then to use that type otherwise to use a default type. This will match the new style of VecLoad() and MatLoad(). >> >> The rational for this change is I want to remove all the MatCreate()s and VecCreates() and setting of types inside other parts of PETSc. This allows new Vec and Mat types to be introduced without also adding into DMGetMatrxi() etc new code whenever a new type is introduced. >> > > I like it, but... Could we have DMGetComm(dm,&comm) ?... the casting > required for PetscObjectGetComm((PetscObject)dm,&comm) is a bit > ugly... No. Then we need VecGetComm(), KSPGetComm(), MonkeyGetComm() and it never ends Perhaps PetscErrorCode PetscObjectGetComm_(PetscObject,MPI_Comm*); #define PetscObjectGetComm(A,B) PetscObjectGetComm_((PetscObject)A,B) to hide the uglyness? In fact, XXXXSetOptionsPrefix() could be all wrapped up in PetscObjectSetOptionsPrefix(). Heck even XXXSetFromOptions() and XXXSetUp() could be wrapped in PetscObjectSetFromOptions(), PetscObjectSetUp() but that may be going too far :-) Barry > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0