<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 15, 2013 at 11:42 AM, 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, Nov 14, 2013 at 6:21 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> 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>> wrote:<br>
>> >><br>
>> >> It doesn't look like there's currently a way to pass user data down 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 CUDA<br>
>> > or OpenCL<br>
>> > to evaluate these low-level FEM integration routines, so you can't pass<br>
>> > in arbitrary context.<br>
>> ><br>
>> > I really don't think we should need arbitrary information at the lowest level integration.<br>
>> > Right now you can pass in information using auxiliary fields. How 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 only integrates a few cells<br>
> (like 32), but I would think that what you would do is write another PetscFE that calls Python<br>
> (I have one for the CPU and one for OpenCL), and it has a context.<br>
<br>
</div></div>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></blockquote><div><br></div><div>Don't understand the vector comment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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></blockquote><div><br></div><div>I would probably use a field since then I can make it non-constant if I want, and</div><div>memory is not usually an issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.</blockquote><div><br></div><div>That is absolute crap I agree. This is a stopgap until we learn how to have a</div><div>unified representation.</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>