On Wed, Nov 27, 2013 at 1:56 PM, Matthew Knepley <[email protected]> wrote: > On Wed, Nov 27, 2013 at 3:44 PM, Geoffrey Irving <[email protected]> wrote: >> >> 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 > > > I have no problem with you doing it. I will look over the branch or pull > request:
Branch irving/dual-space-context pushed. Unfortunately, only 2 out of the 5 affected examples work for me on master (I lack cuda), so I may have introduced compile errors in the others. Geoffrey
