[petsc-dev] PetscSection

[Shri]

On Sep 10, 2013, at 8:47 PM, Matthew Knepley wrote:

> On Tue, Sep 10, 2013 at 8:43 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 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).
> 
> The way I understand it, he never had a single MPI_BYTE, but always a bunch.
> Shouldn't that packing handle that case?
> 
>    Matt
>  
> 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.
   For my toy example, using four sections is fine. But in general I think there needs to 
be a mechanism that the user can easily pack the data and I don't think the user would want
to create tens of sections. 

> 
> 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).

I'll take a look at in the next few days and get back to you. One thing that I am struggling to understand, and this is in reference to having one chunk of memory holding all the
different parameters for vertices, edges etc, is how to manage heteregenous data, i.e., for example one vertex has a struct of type G1 and another has a type G2. Currently from
PetscSection, we can only get the offset and the size.

Shri
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130910/337855cb/attachment.html>