[petsc-dev] Making FE fields in the beginning

Matthew Knepley knepley at gmail.com
Wed Nov 27 18:00:57 CST 2013


On Wed, Nov 27, 2013 at 5:41 PM, Geoffrey Irving <irving at naml.us> wrote:

> 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.


I have given up on CUDA for the forseeable future. OpenCL has a much better
development model now. What I suspect will happen is that CUDA will adopt
the
library compile model of OpenCL and Nvidia will kill the OpenCL support in
its
compiler, so then I will switch back.

   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131127/2230ed7c/attachment.html>


More information about the petsc-dev mailing list