<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 27, 2013 at 1:58 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="im">On Wed, Nov 27, 2013 at 11:38 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>

> On Wed, Nov 27, 2013 at 12:43 PM, Geoffrey Irving <<a href="mailto:irving@naml.us">irving@naml.us</a>> wrote:<br>
>><br>
>> Currently, FE fields on a DMPlex are created with the function<br>
>><br>
>>     DMPlexProjectFunction<br>
>><br>
>> This function has three issues:<br>
>><br>
>> 1. It doesn't take a void* argument, and therefore requires global<br>
>> variables if you need to pass in additional data.<br>
><br>
> I am not opposed to DMPlex functions taking contexts. However, my<br>
> question is: how is intended to receive this context? So far, I am<br>
> unconvinced that PetscFE needs an outside context. It just seems like<br>
> bad design to me.<br>
<br>
</div>Currently the PetscFE functions take raw function pointers with no<br>
context.  The new one would take a function pointer and a context.  If<br>
it's bad design for these functions to take a context, why isn't it<br>
bad design for them to take raw function pointers?</blockquote><div><br></div><div>The bad part here is that C has few ways for me to tell it what kinds of functions</div><div>are admissible. However, the convention is that the function depends on no</div>
<div>other information than the real space coordinate x, the field values u(x) and</div><div>derivatives gradU(x), and auxiliary fields a(x) and gradA(x). With this, I can</div><div>optimize the evaluation. If I allow arbitrary information into the evaluation, I can't</div>
<div>do any optimization, and I don't think it adds anything.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> The original intention is to pass evaluation data in as a mesh field. How<br>
> does this break down?<br>
<br>
</div>Who makes the first mesh field?  God?<br>
<br>
Less sarcastically, I am trying to shoehorn data into petsc from some<br>
other source.  In this case, the other source is a Python script, but<br>
it doesn't matter: the important thing is that the data does not<br>
magically start out as a mesh field.  It also does not start out as a<br>
parameter free C function pointer.<br></blockquote><div><br></div><div>I have missed the point of the whole discussion. This is about bootstrapping data</div><div>into the system, Sorry, sometimes it takes a while for me to see the point.</div>
<div><br></div><div>Okay, forget what I said above. Yes, you really want f to be a closure, so pulling</div><div>along the pointer makes perfect sense. We have to change the PetscDualSpaceApply()</div><div>signature too.</div>
<div><br></div><div>I still don't like passing the cell number in since its so specific.</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">

If you think it's best, I can hardwire understanding of the layout of<br>
mesh fields into my code and just build them directly, but this is<br>
rather annoying to have to do for anything higher than linear<br>
elements.<br>
<div class="im"><br>
>> 2. It operates one quadrature point and a time, so is inefficient in<br>
>> situations where evaluation overhead can be amortized across multiple<br>
>> points (especially from scripts).  For the workhorse FE routines this<br>
>> is inconvenient but acceptable since the goal is probably OpenCL, but<br>
>> it'd would be nice to have access to python and numpy in the setup<br>
>> phase.<br>
><br>
> I think this is oversimplified. DMPlex does operate in batches of quadrature<br>
> points, in fact in batches of cells (although the batch size is 1 now). It is<br>
> PetscDualSpace that calls things one quad point at a time. I would think that<br>
> he Python interface would come in at the level of the PetscDualSpace evaluator. How<br>
> does this differ from what you had planned?<br>
<br>
</div>I realize that part of the code is batched already, and don't really<br>
understand the design motivation well enough to have an opinion.  Do<br>
you mean that we'd make a new type of PetscDualSpace that would<br>
internally store the context that matches the function pointers passed<br>
in from DMPlexProjectFunctionLocal?  PetscDualSpace doesn't currently<br>
have any control over the shape of the function pointers that it<br>
receives from the DMPlex routines.<br>
<div class="im"><br>
>> 3. It doesn't pass a cell argument, so data in an existing mesh fields<br>
>> requires a hierarchy traversal to access.<br>
><br>
> I think I do not understand something fundamental about how you are using this<br>
> function. This is intended to be an orthogonal projection of the function f onto the<br>
> finite element space V. Why would we need a cell index or additional information?<br>
> Is it because the function f you have is not analytic, but another mesh field? I will<br>
> think about optimizing this case.<br>
<br>
</div>Correct, I'm imagining functions that are not analytic, but are not<br>
already petsc mesh fields.  I know what to do once I make them mesh<br>
fields, but they are not there yet.  I don't need this support at the<br>
moment, but I am going to in the not very distant future.  Simple<br>
examples of nontrivial piecewise analytic functions are NURBS in 2D,<br>
splines in 1D, or subdivision surfaces.<br>
<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>