On Sep 11, 2014, at 11:36 AM, Jose E. Roman <[email protected]> wrote:
>
> El 11/09/2014, a las 00:32, Barry Smith escribió:
>
>>
>> Jose,
>>
>> Start by making PetscSplitReduction an opaque pointer to the actual struct.
>>
>> For example
>>
>> typedef struct _n_PetscSplitReduction *PetscSplitReduction;
>>
>> goes in the public include include/petscsys.h
>>
>> typedef struct {
>> - MPI_Comm comm;
>> - MPI_Request request;
>> - PetscBool async;
>> - PetscScalar *lvalues; /* this are the reduced values before call to
>> MPI_Allreduce() */
>> - PetscScalar *gvalues; /* values after call to MPI_Allreduce() */
>> - void **invecs; /* for debugging only, vector/memory used with
>> each op */
>> - PetscInt *reducetype; /* is particular value to be summed or maxed? */
>> - SRState state; /* are we calling xxxBegin() or xxxEnd()? */
>> - PetscInt maxops; /* total amount of space we have for requests */
>> - PetscInt numopsbegin; /* number of requests that have been queued in
>> */
>> - PetscInt numopsend; /* number of requests that have been gotten by
>> user */
>> -} _n_PetscSplitReduction;
>>
>> goes in the private include include/petsc-private/petscimpl.h
>>
>> Then you need to decide how to access the material inside the struct.
>>
>> 1) Do you want all PETSc users to be able to access stuff in the struct and
>> modify it or
>>
>> 2) Do you want a few places in SLEPc to take advantage of the
>> PetscSplitReduction abilities?
>>
>> I am guessing you want 2) in that case just have your SLEPc code include the
>> petscimpl.h and access the structure directly. This is what we do in, for
>> example VecDotBegin() etc
>
> Thanks for the explanation.
> Yes, I want 2)
> If I am going to include petscimpl.h then there is no need to define a public
> opaque pointer, just put the necessary definitions in petscimpl.h, right?
Yes, there is no need.
Everybody gets on Jed’s bad side gitwise once in a while, don’t let that
inhibit you getting work done.
Barry
> There will be no public functions after all.
>
>>
>> If you want 1) then you have a lot of work ahead of you because you need to
>> abstract all the operations you want to do on PetscSplitReduction and
>> provide methods to do those operations and then call those operations from
>> SLEPc.
>
> I think I would only need the three functions I put in the commit, plus the
> REDUCE_SUM REDUCE_MAX REDUCE_MIN defines. But anyway, it is easier to put
> them in petscimpl.h.
>
>>
>> Basically your “Jed sin” (which is far worse than a cardinal sin) was
>> putting this private data structure directly in the public interface of
>> PETSc, i.e. in petscsys.h
>
> Next time I will avoid committing a Jed sin by not making a commit myself.
>
> Jose
>
>>
>> Barry
