On Thu, Jan 23, 2014 at 1:30 PM, Geoffrey Irving <[email protected]> wrote:
> On Thu, Jan 23, 2014 at 6:43 AM, Matthew Knepley <[email protected]> > wrote: > > On Wed, Jan 22, 2014 at 4:16 PM, Geoffrey Irving <[email protected]> wrote: > >> > >> On Tue, Jan 21, 2014 at 9:52 PM, Jed Brown <[email protected]> wrote: > >> > Lisandro Dalcin <[email protected]> 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
