So we would just have to know whether the function calling PETSc is trying
to solve the transpose or a different rhs. Do we want to pass a vector of
bools ? One for the reuse_preconditioner flag, and one to check whether we
are doing the transpose or a different rhs ?
Thanks.
On Thu, Apr 14, 2011 at 6:05 PM, <
[email protected]> wrote:
> Send Libmesh-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Libmesh-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: libmesh 0.7.1 (Kirk, Benjamin (JSC-EG311))
> 2. Re: libmesh 0.7.1 (Kirk, Benjamin (JSC-EG311))
> 3. Re: libmesh 0.7.1 (Roy Stogner)
> 4. Re: libmesh 0.7.1 (Kirk, Benjamin (JSC-EG311))
> 5. libMesh interface to PETSc function: KSPSolveTranspose
> (Vikram Garg)
> 6. Re: libMesh interface to PETSc function: KSPSolveTranspose
> (Roy Stogner)
> 7. libMesh interface to PETSc function: KSPSolveTranspose
> (Vikram Garg)
> 8. Re: libMesh interface to PETSc function: KSPSolveTranspose
> (David Knezevic)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Apr 2011 15:49:15 -0500
> From: "Kirk, Benjamin (JSC-EG311)" <[email protected]>
> Subject: Re: [Libmesh-devel] libmesh 0.7.1
> To: Roy Stogner <[email protected]>,
> "[email protected]"
> <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID: <c9cb767b.1735d%[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> > The tentative plan is to release 0.7.2 in ~5 months, so anything that
> > misses this release will get into the next one soon enough. I'd like
> > to stay in the habit of getting a tarball out twice a year; no more
> > year-plus droughts like we had between 0.5.0 and 0.6.0.
>
> I agree. I've got no outstanding changes, and buildbot coverage for three
> intel flavors and gcc=4.{1-6} releases which all compile head cleanly.
>
> -Ben
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 13 Apr 2011 15:52:57 -0500
> From: "Kirk, Benjamin (JSC-EG311)" <[email protected]>
> Subject: Re: [Libmesh-devel] libmesh 0.7.1
> To: Roy Stogner <[email protected]>,
> "[email protected]"
> <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID: <c9cb7759.17363%[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> On 4/13/11 3:49 PM, "Kirk, Benjamin (JSC-EG311)" <[email protected]
> >
> wrote:
>
> > I agree. I've got no outstanding changes, and buildbot coverage for
> three
> > intel flavors and gcc=4.{1-6} releases which all compile head cleanly.
>
>
> Whoa... what is this "Intel Parallel Studio XE 2011" stuff? I'm
> downloading it now - may be worth waiting to tweak ./configure to detect
> the
> latest intel compilers...
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 13 Apr 2011 16:04:39 -0500 (CDT)
> From: Roy Stogner <[email protected]>
> Subject: Re: [Libmesh-devel] libmesh 0.7.1
> To: "Kirk, Benjamin (JSC-EG311)" <[email protected]>
> Cc: "[email protected]"
> <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
> On Wed, 13 Apr 2011, Kirk, Benjamin (JSC-EG311) wrote:
>
> > Whoa... what is this "Intel Parallel Studio XE 2011" stuff? I'm
> > downloading it now - may be worth waiting to tweak ./configure to detect
> the
> > latest intel compilers...
>
> Definitely, thanks - I had to futz with our compiler.m4 just a week or
> so ago when we barfed on Intel 12; I'd rather avoid making users do
> the same.
> ---
> Roy
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 14 Apr 2011 10:59:38 -0500
> From: "Kirk, Benjamin (JSC-EG311)" <[email protected]>
> Subject: Re: [Libmesh-devel] libmesh 0.7.1
> To: Roy Stogner <[email protected]>
> Cc: "[email protected]"
> <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID: <c9cc841a.173a5%[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> >> Whoa... what is this "Intel Parallel Studio XE 2011" stuff? I'm
> >> downloading it now - may be worth waiting to tweak ./configure to detect
> the
> >> latest intel compilers...
> >
> > Definitely, thanks - I had to futz with our compiler.m4 just a week or
> > so ago when we barfed on Intel 12; I'd rather avoid making users do
> > the same.
>
> HEAD is clean for what John so accurately described as a marketing ploy to
> sell intel-12.0.
>
> -Ben
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 14 Apr 2011 17:01:03 -0500
> From: Vikram Garg <[email protected]>
> Subject: [Libmesh-devel] libMesh interface to PETSc function:
> KSPSolveTranspose
> To: [email protected], libmesh-devel-request
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> All,
> We have recently added adjoint capability to libMesh. In matrix terms,
> this implies that after solving a system "Ax = b", PETSc will have to solve
> "A^{t} z = q", where A^{t} is transpose(A).
>
> However, PETSc can use information it generated while solving "Ax = b" to
> quickly solve "A^{t} z = q". For example, if we solve "Ax = b" using LU
> factorization, we have z = (A^{t})^{-1} q = (A^{-1})^{t} q = (L^{-1})^{T}
> (U^{-1})^{T} q. In this case, the transpose solution reduces to matrix
> vector multiplies.
>
> The PETSc function that provides this kind of functionality is
> KSPSolveTranspose<
> http://www.mcs.anl.gov/petsc/petsc-2/snapshots/petsc-current/docs/manualpages/KSP/KSPSolveTranspose.html
> >and
> it would be good to add an interface to it. Currently we have the
> following interface planned:
>
> 1) Declare a new virtual function in linear_solver.h: virtual bool
> reuse_preconditioner()
> 2) Define it in petsc_linear_solver.h as accessing a flag
> 3) Rework petsc_linear_solver.C to accomodate the use of KSPSolveTranspose
> 4) Add to examples, and verify performance improvement in adjoint_solve
> call
>
> If anybody has a better interface or suggestions on the current plan,
> please
> let us know.
>
> Thanks.
> --
> Vikram Garg
> PhD Candidate
> Institute for Computational and Engineering Sciences
> The University of Texas at Austin
>
> http://users.ices.utexas.edu/~vikram/
> http://www.runforindia.org/runners/vikramg
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 6
> Date: Thu, 14 Apr 2011 17:07:16 -0500 (CDT)
> From: Roy Stogner <[email protected]>
> Subject: Re: [Libmesh-devel] libMesh interface to PETSc function:
> KSPSolveTranspose
> To: Vikram Garg <[email protected]>
> Cc: libmesh-devel-request
> <[email protected]>,
> [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> On Thu, 14 Apr 2011, Vikram Garg wrote:
>
> > All,
> > ???? We have recently added adjoint capability to libMesh. In matrix
> terms, this implies that after solving a system "Ax = b", PETSc will have to
> > solve "A^{t} z = q", where A^{t} is transpose(A).
> >
> > However, PETSc can use information it generated while solving "Ax = b" to
> quickly solve "A^{t} z = q". For example, if we solve "Ax = b" using LU
> > factorization, we have z = (A^{t})^{-1} q = (A^{-1})^{t} q = (L^{-1})^{T}
> (U^{-1})^{T} q. In this case, the transpose solution reduces to matrix
> > vector multiplies.
> >
> > The PETSc function that provides this kind of functionality is
> KSPSolveTranspose and it would be good to add an interface to it. Currently
> we have
> > the following interface planned:
> >
> > 1) Declare a new virtual function in linear_solver.h: virtual bool
> reuse_preconditioner()
>
> Two new virtual functions, to get into more detail: by default
> LinearSolver::adjoint_solve() would do the same get_transpose()
> hackery that we've currently got in the System::adjoint_solve()
> implementations, but the PetscLinearSolver specialization would just
> use KSPSolveTranspose directly.
>
> > 2) Define it in petsc_linear_solver.h as accessing a flag
> > 3) Rework petsc_linear_solver.C to accomodate the use of
> KSPSolveTranspose
> > 4) Add to examples, and verify performance improvement in adjoint_solve
> call
> ---
> Roy
>
> ------------------------------
>
> Message: 7
> Date: Thu, 14 Apr 2011 17:07:17 -0500
> From: Vikram Garg <[email protected]>
> Subject: [Libmesh-devel] libMesh interface to PETSc function:
> KSPSolveTranspose
> To: libmesh-devel-request
> <[email protected]>,
> [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> All,
> ???? We have recently added adjoint capability to libMesh. In matrix
> terms, this implies that after solving a system "Ax = b", PETSc will
> have to solve "A^{t} z = q", where A^{t} is transpose(A).
>
> However, PETSc can use information it generated while solving "Ax = b"
> to quickly solve "A^{t} z = q". For example, if we solve "Ax = b"
> using LU factorization, we have z = (A^{t})^{-1} q = (A^{-1})^{t} q =
> (L^{-1})^{T} (U^{-1})^{T} q. In this case, the transpose solution
> reduces to matrix vector multiplies.
>
> The PETSc function that provides this kind of functionality is
> KSPSolveTranspose and it would be good to add an interface to it.
> Currently we have the following interface planned:
>
> 1) Declare a new virtual function in linear_solver.h: virtual bool
> reuse_preconditioner()
> 2) Define it in petsc_linear_solver.h as accessing a flag
> 3) Rework petsc_linear_solver.C to accomodate the use of KSPSolveTranspose
> 4) Add to examples, and verify performance improvement in adjoint_solve
> call
>
> If anybody has a better interface or suggestions on the current plan,
> please let us know.
>
> Thanks.
>
> --
> Vikram Garg
> PhD Candidate
> Institute for Computational and Engineering Sciences
> The University of Texas at Austin
> http://users.ices.utexas.edu/~vikram/
> http://www.runforindia.org/runners/vikramg
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 14 Apr 2011 19:06:18 -0400
> From: David Knezevic <[email protected]>
> Subject: Re: [Libmesh-devel] libMesh interface to PETSc function:
> KSPSolveTranspose
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> > On Thu, 14 Apr 2011, Vikram Garg wrote:
> >
> >> All,
> >> We have recently added adjoint capability to libMesh. In matrix
> >> terms, this implies that after solving a system "Ax = b", PETSc will
> >> have to
> >> solve "A^{t} z = q", where A^{t} is transpose(A).
> >>
> >> However, PETSc can use information it generated while solving "Ax =
> >> b" to quickly solve "A^{t} z = q". For example, if we solve "Ax = b"
> >> using LU
> >> factorization, we have z = (A^{t})^{-1} q = (A^{-1})^{t} q =
> >> (L^{-1})^{T} (U^{-1})^{T} q. In this case, the transpose solution
> >> reduces to matrix
> >> vector multiplies.
> >>
> >> The PETSc function that provides this kind of functionality is
> >> KSPSolveTranspose and it would be good to add an interface to it.
> >> Currently we have
> >> the following interface planned:
> >>
> >> 1) Declare a new virtual function in linear_solver.h: virtual bool
> >> reuse_preconditioner()
> >
> > Two new virtual functions, to get into more detail: by default
> > LinearSolver::adjoint_solve() would do the same get_transpose()
> > hackery that we've currently got in the System::adjoint_solve()
> > implementations, but the PetscLinearSolver specialization would just
> > use KSPSolveTranspose directly.
> >
> >> 2) Define it in petsc_linear_solver.h as accessing a flag
> >> 3) Rework petsc_linear_solver.C to accomodate the use of
> >> KSPSolveTranspose
> >> 4) Add to examples, and verify performance improvement in
> >> adjoint_solve call
>
>
> I currently use the same_preconditioner flag in LinearSolver a lot since
> I often do LU solves with multiple right-hand sides. This is especially
> useful if you're using a direct solver since if same_preconditioner =
> true then PETSc doesn't refactorize the matrix. It would be good to
> unify the API for these cases.
>
>
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>
> ------------------------------
>
> _______________________________________________
> Libmesh-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>
> End of Libmesh-devel Digest, Vol 58, Issue 9
> ********************************************
>
--
Vikram Garg
PhD Candidate
Institute for Computational and Engineering Sciences
The University of Texas at Austin
http://users.ices.utexas.edu/~vikram/
http://www.runforindia.org/runners/vikramg
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
