On Thu, Nov 14, 2013 at 8:14 PM, Geoffrey Irving <[email protected]> wrote:
> On Thu, Nov 14, 2013 at 6:03 PM, Matthew Knepley <[email protected]> > wrote: > > On Thu, Nov 14, 2013 at 7:43 PM, Geoffrey Irving <[email protected]> wrote: > >> > >> It doesn't look like there's currently a way to pass user data down to > >> the various fields in PetscFEM. Can I add an extra argument to each > >> function, or is that part of the API going to change in a way that > >> would obviate the extra argument? > > > > > > That is by design. Here is the rationale. I want to be able to use CUDA > or OpenCL > > to evaluate these low-level FEM integration routines, so you can't pass > in arbitrary context. > > > > I really don't think we should need arbitrary information at the lowest > level integration. > > Right now you can pass in information using auxiliary fields. How would > you use > > other stuff? > > Well, you're probably not going to like application 1, which is > passing around PyObject*'s so I can write little FEM explorations in > numpy. Is the field support the right thing to do for constant > fields, or integer valued constant fields? I should explain further. Here is the hierarchy: SNESComputeFunction (global) --> SNESComputeFunction_DMLocal (l2g) --> DMPlexComputeResidualFEM (local) --> PetscFEIntegrateResidual (chunk of cells) --> kernel (batch of cells) I can be talked into a context all the way down to the kernel, which only integrates a few cells (like 32), but I would think that what you would do is write another PetscFE that calls Python (I have one for the CPU and one for OpenCL), and it has a context. 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
