On Wed, Nov 27, 2013 at 12:09 PM, Matthew Knepley <[email protected]> wrote: >> > The original intention is to pass evaluation data in as a mesh field. How >> > does this break down? >> >> Who makes the first mesh field? God? >> >> Less sarcastically, I am trying to shoehorn data into petsc from some >> other source. In this case, the other source is a Python script, but >> it doesn't matter: the important thing is that the data does not >> magically start out as a mesh field. It also does not start out as a >> parameter free C function pointer. > > I have missed the point of the whole discussion. This is about bootstrapping > data > into the system, Sorry, sometimes it takes a while for me to see the point.
No worries, I may have been less than clear. > Okay, forget what I said above. Yes, you really want f to be a closure, so > pulling > along the pointer makes perfect sense. We have to change the > PetscDualSpaceApply() > signature too. I can give this a try unless you feel like doing it. It will touch a lot of code, since all the interfaces above PetscDualSpaceApply need to change, then all the examples, etc. Concretely, I'd be changing the signature of PetscDualSpaceApply to PetscErrorCode PetscDualSpaceApply(PetscDualSpace sp, PetscInt f, PetscCellGeometry geom, PetscInt numComp, void (*func)(const PetscReal [], PetscScalar *), void *ctx, PetscScalar *value); I'm a little uneasy about slowing down every use of PetscDualSpaceApply, so an alternative would be to make PetscDualSpaceApplyContext (and a similar duplicate of DMPlexProjectFunction). Let me know which you prefer if you want me to do it. The batching is a separate issue, and seems like it would also require changes to PetscDualSpaceApply. > I still don't like passing the cell number in since its so specific. I agree that it would be frustrating to add this information to PetscDualSpaceApply, which knows nothing about the surrounding DMPlex mesh structure. I don't need cell information yet, so I'm happy to push it down the road. Geoffrey
