<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 23, 2014 at 1:30 PM, Geoffrey Irving <span dir="ltr"><<a href="mailto:irving@naml.us" target="_blank">irving@naml.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Jan 23, 2014 at 6:43 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>

> On Wed, Jan 22, 2014 at 4:16 PM, Geoffrey Irving <<a href="mailto:irving@naml.us">irving@naml.us</a>> wrote:<br>
>><br>
>> On Tue, Jan 21, 2014 at 9:52 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>> > Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> writes:<br>
>> >> I thought to do that in PetIGA, but then realized that a reducer+eval<br>
>> >> at quadrature points+MPI_MAX sounds weird (though I can imagine some<br>
>> >> use cases). A reduce with MPI_MAX is a lucky consequence of computing<br>
>> >> integrals through quadrature.<br>
>> ><br>
>> > Suppose we want to know the max stress in a structure to determine<br>
>> > whether it will be damaged by a given loading scenario?  The quadrature<br>
>> > points are not sufficient to determine a max stress for the discrete<br>
>> > solution, but it is a convergent method for determining the max stress<br>
>> > of the continuum structure.<br>
>><br>
>> So I wrote PetscFEIntegrateScalars, but then realized that I have no<br>
>> idea how to organize the DM level.  Residuals and jacobians can be<br>
>> only be "turned on" via DMSNESSetFunctionLocal, and then accessed via<br>
>> the SNES.  This would work in the specific case of an objective, but<br>
>> not for the general case where we're integrating some arbitrary number<br>
>> of PetscScalars.<br>
>><br>
>> Where should the outer "integrate a bunch of scalars over a DM with a<br>
>> bunch of PetscFE" objects go, and what should it be called?  The<br>
>> naming conventions at this level are rather obscure.<br>
>><br>
>> Relatedly, is it going to be a problem if I want to use PetscFE<br>
>> routines outside an SNES, such as inside a TAO optimization problem?<br>
>> Should I make a dummy SNES and then point TAO to SNESComputeObjective<br>
>> and such, or is there a cleaner way?<br>
><br>
><br>
> 1) I have been putting functions like this (DMPlexComputeL2Diff) in DM<br>
> because there seemed to be no other place.<br>
><br>
> 2) Nope you can use them anywhere<br>
<br>
</div></div>It looks like the local versions are usable from anywhere, but the<br>
global versions including communication are not.  I.e.,<br>
DMPlexComputeResidualFEM does no communication, and its global version<br>
is the internal function SNESComputeFunction_DMLocal plus a pointer to<br>
DMPlexComputeResidualFEM.  Is this how I should expose the scalar<br>
integration as well: local version only, with the user responsible to<br>
doing the field synchronization before and the reduce afterwards?</blockquote><div><br></div><div>I prefer light wrappers for the DMGlobalToLocal(), as I use in ComputeL2Diff(). I sw</div><div>no reason for a residual wrapper since its integrated into the DM.</div>
<div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
Geoffrey<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>