[petsc-dev] resurrecting the finite element energy functions thread

[Matthew Knepley]

On Thu, Jan 23, 2014 at 1:30 PM, Geoffrey Irving <irving at naml.us> wrote:

> On Thu, Jan 23, 2014 at 6:43 AM, Matthew Knepley <knepley at gmail.com>
> wrote:
> > On Wed, Jan 22, 2014 at 4:16 PM, Geoffrey Irving <irving at naml.us> wrote:
> >>
> >> On Tue, Jan 21, 2014 at 9:52 PM, Jed Brown <jed at jedbrown.org> wrote:
> >> > Lisandro Dalcin <dalcinl at gmail.com> writes:
> >> >> I thought to do that in PetIGA, but then realized that a reducer+eval
> >> >> at quadrature points+MPI_MAX sounds weird (though I can imagine some
> >> >> use cases). A reduce with MPI_MAX is a lucky consequence of computing
> >> >> integrals through quadrature.
> >> >
> >> > Suppose we want to know the max stress in a structure to determine
> >> > whether it will be damaged by a given loading scenario?  The
> quadrature
> >> > points are not sufficient to determine a max stress for the discrete
> >> > solution, but it is a convergent method for determining the max stress
> >> > of the continuum structure.
> >>
> >> So I wrote PetscFEIntegrateScalars, but then realized that I have no
> >> idea how to organize the DM level.  Residuals and jacobians can be
> >> only be "turned on" via DMSNESSetFunctionLocal, and then accessed via
> >> the SNES.  This would work in the specific case of an objective, but
> >> not for the general case where we're integrating some arbitrary number
> >> of PetscScalars.
> >>
> >> Where should the outer "integrate a bunch of scalars over a DM with a
> >> bunch of PetscFE" objects go, and what should it be called?  The
> >> naming conventions at this level are rather obscure.
> >>
> >> Relatedly, is it going to be a problem if I want to use PetscFE
> >> routines outside an SNES, such as inside a TAO optimization problem?
> >> Should I make a dummy SNES and then point TAO to SNESComputeObjective
> >> and such, or is there a cleaner way?
> >
> >
> > 1) I have been putting functions like this (DMPlexComputeL2Diff) in DM
> > because there seemed to be no other place.
> >
> > 2) Nope you can use them anywhere
>
> It looks like the local versions are usable from anywhere, but the
> global versions including communication are not.  I.e.,
> DMPlexComputeResidualFEM does no communication, and its global version
> is the internal function SNESComputeFunction_DMLocal plus a pointer to
> DMPlexComputeResidualFEM.  Is this how I should expose the scalar
> integration as well: local version only, with the user responsible to
> doing the field synchronization before and the reduce afterwards?


I prefer light wrappers for the DMGlobalToLocal(), as I use in
ComputeL2Diff(). I sw
no reason for a residual wrapper since its integrated into the DM.

    Matt


>
> Geoffrey
>



-- 
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-dev/attachments/20140123/c3c7c3a9/attachment.html>