[petsc-dev] Making FE fields in the beginning

[Geoffrey Irving]

On Wed, Nov 27, 2013 at 1:56 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Wed, Nov 27, 2013 at 3:44 PM, Geoffrey Irving <irving at naml.us> wrote:
>>
>> On Wed, Nov 27, 2013 at 12:09 PM, Matthew Knepley <knepley at gmail.com>
>> 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