<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 27, 2013 at 3:44 PM, Geoffrey Irving <span dir="ltr"><<a href="mailto:irving@naml.us" target="_blank">irving@naml.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Nov 27, 2013 at 12:09 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>

>> > The original intention is to pass evaluation data in as a mesh field. How<br>
>> > does this break down?<br>
>><br>
>> Who makes the first mesh field?  God?<br>
>><br>
>> Less sarcastically, I am trying to shoehorn data into petsc from some<br>
>> other source.  In this case, the other source is a Python script, but<br>
>> it doesn't matter: the important thing is that the data does not<br>
>> magically start out as a mesh field.  It also does not start out as a<br>
>> parameter free C function pointer.<br>
><br>
> I have missed the point of the whole discussion. This is about bootstrapping data<br>
> into the system, Sorry, sometimes it takes a while for me to see the point.<br>
<br>
</div>No worries, I may have been less than clear.<br>
<div class="im"><br>
> Okay, forget what I said above. Yes, you really want f to be a closure, so pulling<br>
> along the pointer makes perfect sense. We have to change the PetscDualSpaceApply()<br>
> signature too.<br>
<br>
</div>I can give this a try unless you feel like doing it.  It will touch a<br>
lot of code, since all the interfaces above PetscDualSpaceApply need<br>
to change, then all the examples, etc.  Concretely, I'd be changing<br>
the signature of PetscDualSpaceApply to<br></blockquote><div><br></div><div>I have no problem with you doing it. I will look over the branch or pull request:</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

PetscErrorCode PetscDualSpaceApply(PetscDualSpace sp, PetscInt f,<br>
PetscCellGeometry geom, PetscInt numComp, void (*func)(const PetscReal<br>
[], PetscScalar *), void *ctx, PetscScalar *value);<br>
<br>
I'm a little uneasy about slowing down every use of<br>
PetscDualSpaceApply, so an alternative would be to make<br>
PetscDualSpaceApplyContext (and a similar duplicate of<br>
DMPlexProjectFunction).  Let me know which you prefer if you want me<br>
to do it.<br></blockquote><div><br></div><div>Adding the ctx will not slow anything down as it is now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The batching is a separate issue, and seems like it would also require<br>
changes to PetscDualSpaceApply.</blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> I still don't like passing the cell number in since its so specific.<br>
<br>
</div>I agree that it would be frustrating to add this information to<br>
PetscDualSpaceApply, which knows nothing about the surrounding DMPlex<br>
mesh structure.  I don't need cell information yet, so I'm happy to<br>
push it down the road.</blockquote><div><br></div><div>Cool.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Geoffrey<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>