<div dir="ltr">On Tue, Sep 10, 2013 at 8:55 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> PetscSF cannot currently scatter individual bytes (4 bytes minimum), and<br>
>> even if it could, it's a horribly inefficient representation (4 or 8<br>
>> bytes of metadata for each byte of payload).  The quick fix at that<br>
>> moment was to send in units of size PetscInt (the struct was always<br>
>> going to be divisible by that size).<br>
>><br>
><br>
> The way I understand it, he never had a single MPI_BYTE, but always a bunch.<br>
> Shouldn't that packing handle that case?<br>
<br>
</div>In DMPlexDistributeData, your fieldSF is blown up so that every unit has<br>
its own metadata (rank, offset).  That's a terrible mechanism for moving<br>
structs with hundreds of bytes.<br></blockquote><div><br></div><div>Hmm, okay we can probably handle some of the packing there. I will think about</div><div>it.</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">

I would rather not make PetscSF deal with fully-heterogeneous data<br>
(where each node can have a different size) because it makes indexing a<br>
nightmare (you need a PetscSection or similar just to get in the door; I<br>
don't want PetscSF to depend on PetscSection).<br>
</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>