[petsc-dev] PetscLayoutSetWeights?

[Barry Smith]

On Sep 23, 2013, at 2:06 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> If the row lengths are not uniform, the threadcomm implementations of
> MatMult and such should be able to partition by some other metric, most
> obviously, the nonzeros.  Since we currently keep thread offsets in
> PetscLayout, this is an obvious place to put it.  To start the
> discussion, consider this interface where there is one integer-valued
> weight per block (set via PetscLayoutSetBlockSize).
> 
> PetscErrorCode PetscLayoutSetWeights(PetscLayout,const PetscInt[],PetscCopyMode);
> 
> Reasonable?  Should we allow PetscLayoutGetWeights to be implementable?

   So we then freely change the thread offsets in the layout based on the matrix entries? This means the Vec and Mat Layouts have to be same? This is true if the Vecs are obtained with MatGetVecs() after the matrix is created but not if the Vecs are created independently. Of for the MatMult do you just use the thread offsets from the Mat layout and ignore the Vec layout if it is different? 


> If so, we have to make a copy of the integer weights.  If not, we can
> pledge to discard our reference in PetscLayoutSetUp and then the caller
> (e.g., MatSeqAIJSetPreallocation_SeqAIJ) can just pass its const
> PetscInt[] along rather than needing to make a copy.
> 
>