[petsc-dev] Making FE fields in the beginning

Matthew Knepley knepley at gmail.com
Wed Nov 27 15:56:05 CST 2013


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:


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

Adding the ctx will not slow anything down as it is now.


> The batching is a separate issue, and seems like it would also require
> changes to PetscDualSpaceApply.


Yep.


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


Cool.

  Thanks,

     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/bcaa6075/attachment.html>


More information about the petsc-dev mailing list