<div dir="ltr">On Tue, Sep 10, 2013 at 8:43 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>
>>   I was unclear.  The offset value should be in bytes from the beginning<br>
>> of the array, currently it is in ints from the beginning of the array. Ints<br>
>> is just plan confusing, Shri has to have this strange size sizeof(his<br>
>> struct)/sizeof(PetscInt) to indicate how big his chunk is.<br>
><br>
><br>
> No, its has nothing to do with Int. Where did this come from? In fact, I<br>
> use it all the time to mean Scalar offsets. It is<br>
> interpreter by the creator of the Section. I told him to put in bytes for<br>
> the sizes. Then you do not need any of that crap.<br>
<br>
</div>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></blockquote><div><br></div><div>The way I understand it, he never had a single MPI_BYTE, but always a bunch.</div><div>Shouldn't that packing handle that case?</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">
After looking at code with him yesterday, it looks like he just needs a<br>
separate Section for each of four different types of node.  Within each<br>
node type, the sizes are homogeneous (though there may be multiple<br>
structs at a vertex of the graph).  In that case, he can make an<br>
MPI_Datatype for sizeof(struct Node) bytes and communicate those.<br>
PetscSF should do fine with that.<br>
<br>
The indexing still needs the size of a unit, but there would be no stray<br>
sizeof(Int) running around.<br>
<br>
<br>
In that discussion, we also concluded that having the user add code to<br>
one big struct definition was a terrible approach and we should<br>
dynamically build structures by registration.  I pointed him to the<br>
monitor infrastructure in Parmod (like in TS ex11).<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>