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

Re: [petsc-dev] configure error
by Lisandro Dalcin 19 Apr '12

19 Apr '12

On 19 April 2012 18:04, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Apr 19, 2012 at 08:01, Mark F. Adams <mark.adams(a)columbia.edu> > wrote: >> >> [I sent this error message but it "Your message to petsc-dev awaits >> moderator approval" because the configure.log was > 512 Kb???] > > > Configure issues (and especially configure.log attachments) belong on > petsc-maint, not petsc-dev. Have ever considered an email filter for petsc-dev looking for a configure.log attachement that automatically forwards the email to petsc-maint and reply the OP informing that? -- 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] Matlab writes dense matrices as vectors
by Jed Brown 19 Apr '12

19 Apr '12

On Thu, Apr 19, 2012 at 07:52, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Apr 19, 2012, at 9:06 AM, Jed Brown wrote: > > > It writes the whole thing as one vector, should we require the caller to > reshape to clearly identify it as a vector? Then anything with multiple > columns could be written as a matrix (e.g. by internally calling sparse()). > > I cannot remember why I defaulted to this behavior. (Probably for > people using DMDA and automatically reshaping a read in vector into its > DMDA defined shape and then later wanting to save that as a vector). I > guess it might be more intuitive to change it as you suggest. > It was a size mismatch in that case anyway, so I chose this rather than an implicit reshape. Dense row and column vectors are both written as vectors. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/03d36104f143

1 0

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

19 Apr '12

Jed, Thanks a lot. On 19.04.2012 17:13, Jed Brown wrote: > On Wed, Apr 18, 2012 at 08:33, Barry Smith <bsmith(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > > Are there other methods affected by that? > > Possibly. > > > I gave a list in the other email of KSPs that are currently incorrect > for complex. TCQMR is correct now. > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/3c24df8cc424 -- Regards, Alexander

1 0

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

19 Apr '12

On Wed, Apr 18, 2012 at 08:33, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Are there other methods affected by that? > > Possibly. > I gave a list in the other email of KSPs that are currently incorrect for complex. TCQMR is correct now. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/3c24df8cc424

1 0

Re: [petsc-dev] configure error
by Satish Balay 19 Apr '12

19 Apr '12

yes - such issues [with huge attachments] shouldn't flood mailing list user mailboxes - and are best sent to petsc-maint. suggestion is to use: CC=/sw/lib/gcc4.4/bin/gcc-4 CFLAGS=-malign-double [instead of CC="/sw/lib/gcc4.4/bin/gcc-4 -malign-double"] Satish On Thu, 19 Apr 2012, Mark F. Adams wrote: > [I sent this error message but it "Your message to petsc-dev awaits moderator approval" because the configure.log was > 512 Kb???] > > I'm moving to a serial build on my Mac and am getting this error: > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:2 (project) > > > CMake Error: your C compiler: "/sw/lib/gcc4.4/bin/gcc-4 -malign-double" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. > ******************************************************************************* > > ~/Codes/petsc-dev-merge> > ~/Codes/petsc-dev-merge>ll /sw/lib/gcc4.4/bin/gcc-4 > lrwxr-xr-x 1 root admin 30 Jan 7 2011 /sw/lib/gcc4.4/bin/gcc-4 -> /sw/lib/gcc4.4/bin/gcc-fsf-4.4 > ~/Codes/petsc-dev-merge>ll /sw/lib/gcc4.4/bin/gcc-fsf-4.4 > -rwxr-xr-x 3 root admin 305400 Jan 7 2011 /sw/lib/gcc4.4/bin/gcc-fsf-4.4 > >

1 0

Re: [petsc-dev] configure error
by Jed Brown 19 Apr '12

19 Apr '12

On Thu, Apr 19, 2012 at 08:01, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > [I sent this error message but it "Your message to petsc-dev awaits > moderator approval" because the configure.log was > 512 Kb???] Configure issues (and especially configure.log attachments) belong on petsc-maint, not petsc-dev.

1 0

configure error
by Mark F. Adams 19 Apr '12

19 Apr '12

[I sent this error message but it "Your message to petsc-dev awaits moderator approval" because the configure.log was > 512 Kb???] I'm moving to a serial build on my Mac and am getting this error: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:2 (project) CMake Error: your C compiler: "/sw/lib/gcc4.4/bin/gcc-4 -malign-double" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. ******************************************************************************* ~/Codes/petsc-dev-merge> ~/Codes/petsc-dev-merge>ll /sw/lib/gcc4.4/bin/gcc-4 lrwxr-xr-x 1 root admin 30 Jan 7 2011 /sw/lib/gcc4.4/bin/gcc-4 -> /sw/lib/gcc4.4/bin/gcc-fsf-4.4 ~/Codes/petsc-dev-merge>ll /sw/lib/gcc4.4/bin/gcc-fsf-4.4 -rwxr-xr-x 3 root admin 305400 Jan 7 2011 /sw/lib/gcc4.4/bin/gcc-fsf-4.4

1 0

Re: [petsc-dev] Matlab writes dense matrices as vectors
by Barry Smith 19 Apr '12

19 Apr '12

On Apr 19, 2012, at 9:06 AM, Jed Brown wrote: > It writes the whole thing as one vector, should we require the caller to reshape to clearly identify it as a vector? Then anything with multiple columns could be written as a matrix (e.g. by internally calling sparse()). I cannot remember why I defaulted to this behavior. (Probably for people using DMDA and automatically reshaping a read in vector into its DMDA defined shape and then later wanting to save that as a vector). I guess it might be more intuitive to change it as you suggest. Barry

1 0

Matlab writes dense matrices as vectors
by Jed Brown 19 Apr '12

19 Apr '12

It writes the whole thing as one vector, should we require the caller to reshape to clearly identify it as a vector? Then anything with multiple columns could be written as a matrix (e.g. by internally calling sparse()).

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 22:28, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > I still don't know if CG is correct, but it should be easy to check. So I tested with a random SPD matrix octave:1> m = 10; A = rand(m) + 1i*rand(m); B = sparse(A'*A); b = rand(m,1) + 1i*rand(m,1); PetscBinaryWrite('csmat',B,b) $ ./ex10 -f csmat -pc_type none -ksp_monitor_true_residual -ksp_converged_reason -ksp_rtol 1e-10 -ksp_type cg 0 KSP preconditioned resid norm 2.336843772649e+00 true resid norm 2.336843772649e+00 ||r(i)||/||b|| 1.000000000000e+00 1 KSP preconditioned resid norm 1.288273018515e+00 true resid norm 1.288273018515e+00 ||r(i)||/||b|| 5.512876100632e-01 2 KSP preconditioned resid norm 1.728603874706e+00 true resid norm 1.728603874706e+00 ||r(i)||/||b|| 7.397173465072e-01 3 KSP preconditioned resid norm 2.219311079430e+00 true resid norm 2.219311079430e+00 ||r(i)||/||b|| 9.497045140135e-01 4 KSP preconditioned resid norm 1.417400703557e+00 true resid norm 1.417400703557e+00 ||r(i)||/||b|| 6.065449133342e-01 5 KSP preconditioned resid norm 2.569214150239e+00 true resid norm 2.569214150239e+00 ||r(i)||/||b|| 1.099437703243e+00 6 KSP preconditioned resid norm 3.358881724039e+00 true resid norm 3.358881724039e+00 ||r(i)||/||b|| 1.437358270738e+00 7 KSP preconditioned resid norm 3.716784177439e+00 true resid norm 3.716784177439e+00 ||r(i)||/||b|| 1.590514616741e+00 8 KSP preconditioned resid norm 2.185304345331e+00 true resid norm 2.185304345331e+00 ||r(i)||/||b|| 9.351520931385e-01 9 KSP preconditioned resid norm 3.653287110983e+00 true resid norm 3.653287110983e+00 ||r(i)||/||b|| 1.563342468051e+00 10 KSP preconditioned resid norm 2.935982891703e+01 true resid norm 2.935982891703e+01 ||r(i)||/||b|| 1.256388178819e+01 11 KSP preconditioned resid norm 9.746366642500e-10 true resid norm 9.747315023720e-10 ||r(i)||/||b|| 4.171145344761e-10 12 KSP preconditioned resid norm 1.046840786761e-11 true resid norm 1.030180230459e-11 ||r(i)||/||b|| 4.408425768623e-12 Linear solve converged due to CONVERGED_RTOL iterations 12 Number of iterations = 12 Residual norm 1.03018e-11 This looks okay. Interestingly, flipping the dot products produces essentially the same convergence behavior, though it is not identical. I guess CG has enough symmetry that it doesn't matter which way you conjugate. The same test shows that broyden, lsqr, tcqmr, and cgne are currently incorrect for complex systems.

1 0