[petsc-dev] PetscSection

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:
>>   I was unclear.  The offset value should be in bytes from the beginning
>> of the array, currently it is in ints from the beginning of the array. Ints
>> is just plan confusing, Shri has to have this strange size sizeof(his
>> struct)/sizeof(PetscInt) to indicate how big his chunk is.
>
>
> No, its has nothing to do with Int. Where did this come from? In fact, I
> use it all the time to mean Scalar offsets. It is
> interpreter by the creator of the Section. I told him to put in bytes for
> the sizes. Then you do not need any of that crap.

PetscSF cannot currently scatter individual bytes (4 bytes minimum), and
even if it could, it's a horribly inefficient representation (4 or 8
bytes of metadata for each byte of payload).  The quick fix at that
moment was to send in units of size PetscInt (the struct was always
going to be divisible by that size).

After looking at code with him yesterday, it looks like he just needs a
separate Section for each of four different types of node.  Within each
node type, the sizes are homogeneous (though there may be multiple
structs at a vertex of the graph).  In that case, he can make an
MPI_Datatype for sizeof(struct Node) bytes and communicate those.
PetscSF should do fine with that.

The indexing still needs the size of a unit, but there would be no stray
sizeof(Int) running around.


In that discussion, we also concluded that having the user add code to
one big struct definition was a terrible approach and we should
dynamically build structures by registration.  I pointed him to the
monitor infrastructure in Parmod (like in TS ex11).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130910/e3542271/attachment.sig>