[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