Matthew Knepley <[email protected]> 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).
pgptr8v0bb9RO.pgp
Description: PGP signature
