<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 15, 2013 at 12:14 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 Fri, Nov 15, 2013 at 9:59 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Fri, Nov 15, 2013 at 11:42 AM, Geoffrey Irving <<a href="mailto:irving@naml.us">irving@naml.us</a>> wrote:<br>
>><br>
>> On Thu, Nov 14, 2013 at 6:21 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
>> wrote:<br>
>> > On Thu, Nov 14, 2013 at 8:14 PM, Geoffrey Irving <<a href="mailto:irving@naml.us">irving@naml.us</a>> wrote:<br>
>> >><br>
>> >> On Thu, Nov 14, 2013 at 6:03 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > On Thu, Nov 14, 2013 at 7:43 PM, Geoffrey Irving <<a href="mailto:irving@naml.us">irving@naml.us</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> It doesn't look like there's currently a way to pass user data down<br>
>> >> >> to<br>
>> >> >> the various fields in PetscFEM. Can I add an extra argument to each<br>
>> >> >> function, or is that part of the API going to change in a way that<br>
>> >> >> would obviate the extra argument?<br>
>> >> ><br>
>> >> ><br>
>> >> > That is by design. Here is the rationale. I want to be able to use<br>
>> >> > CUDA<br>
>> >> > or OpenCL<br>
>> >> > to evaluate these low-level FEM integration routines, so you can't<br>
>> >> > pass<br>
>> >> > in arbitrary context.<br>
>> >> ><br>
>> >> > I really don't think we should need arbitrary information at the<br>
>> >> > lowest level integration.<br>
>> >> > Right now you can pass in information using auxiliary fields. How<br>
>> >> > would you use<br>
>> >> > other stuff?<br>
>> >><br>
>> >> Well, you're probably not going to like application 1, which is<br>
>> >> passing around PyObject*'s so I can write little FEM explorations in<br>
>> >> numpy. Is the field support the right thing to do for constant<br>
>> >> fields, or integer valued constant fields?<br>
>> ><br>
>> ><br>
>> > I should explain further. Here is the hierarchy:<br>
>> ><br>
>> > SNESComputeFunction (global)<br>
>> > --> SNESComputeFunction_DMLocal (l2g)<br>
>> > --> DMPlexComputeResidualFEM (local)<br>
>> > --> PetscFEIntegrateResidual (chunk of cells)<br>
>> > --> kernel (batch of cells)<br>
>> ><br>
>> > I can be talked into a context all the way down to the kernel, which<br>
>> > only integrates a few cells<br>
>> > (like 32), but I would think that what you would do is write another<br>
>> > PetscFE that calls Python<br>
>> > (I have one for the CPU and one for OpenCL), and it has a context.<br>
>><br>
>> Thanks for the explanation, that helps. And apologies for my<br>
>> denseness, somehow I read the functions I was imagining adding a void*<br>
>> to as having another layer of loop, when actually they are called per<br>
>> quadrature point. Obviously I need a slower more vectorized version<br>
><br>
> Don't understand the vector comment.<br>
<br>
</div></div>Replace<br>
<br>
void f0_u(const PetscScalar u[], ...)<br>
{<br>
f0[0] = 4.0;<br>
}<br>
<br>
with<br>
<br>
void f0_u(const PetscInt n, PetscScalar u[], ...)<br>
{<br>
PetscInt i;<br>
for (i=0; i<n; i++)<br>
f0[i] = 4.0;<br>
}<br>
<br>
and then call it either once with data for all quadrature points for a<br>
few times for batches. I don't really think it's worth doing this,<br>
when I could instead spend time setting up OpenCL kernels. Again, I<br>
somehow hallucinated that it was already like this, which is why I<br>
thought of writing a Python testbed.<br>
<div class="im"><br>
>> to send to Python as numpy arrays. Since another version is required,<br>
>> I will probably abandon my plan to write Python unit tests (I only<br>
>> considered it because I hallucinated that it would be trivial), so I'm<br>
>> good to go.<br>
>><br>
>> Getting back to actual physics examples, what would be the right way<br>
>> to implement a uniform shell pressure term in this context? In other<br>
>> words, the force density at a point is pN, where p is a variable but<br>
>> globally constant pressure and N is the shell surface normal. Should<br>
>> I just use a global variable?<br>
><br>
><br>
> I would probably use a field since then I can make it non-constant if I want, and<br>
> memory is not usually an issue.<br>
<br>
</div>Will do.<br>
<div class="im"><br>
>> It seems like a slight design blemish that the OpenCL version owns the<br>
>> OpenCL versions of its compute routines but accepts the CPU versions<br>
>> as arguments, but feel free to ignore that as nitpickiness.<br>
><br>
> That is absolute crap I agree. This is a stopgap until we learn how to have a<br>
> unified representation.<br>
<br>
</div>Sounds good. The most incremental solution would just be to move<br>
control over those functions down to PetscFE. Indeed, they pretty<br>
much have to go at whichever level is supposed to know about OpenCL<br>
kernels and the like.</blockquote><div><br></div><div>The problem here is that the DM is supposed to know about the physics, not the FE.</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>