[petsc-dev] attaching field information to PetscLayout?
Barry Smith
bsmith at mcs.anl.gov
Sat May 14 15:57:27 CDT 2011
On May 14, 2011, at 3:51 PM, Jed Brown wrote:
> On Sat, May 14, 2011 at 22:39, Barry Smith <bsmith at mcs.anl.gov> wrote:
> and get things like MatGetVecs() to properly pass local to global information to the created vectors.
>
> This currently happens.
Good.
>
> So for example we could have something like
>
> typedef struct _n_PetscLayout* PetscLayout;
> struct _n_PetscLayout{
> MPI_Comm comm;
> PetscInt n,N; /* local, global vector size */
> PetscInt rstart,rend; /* local start, local end + 1 */
> PetscInt *range; /* the offset of each processor */
> PetscInt bs; /* number of elements in each block (generally for multi-component problems) Do NOT multiply above numbers by bs */
> PetscInt refcnt; /* MPI Vecs obtained with VecDuplicate() and from MatGetVecs() reuse map of input object */
>
> PetscInt nfields; IS *fields;
> IS localtoglobalmapping,blocklocaltoglobalmapping.
> USER INFO LIKE boundary condition locations;
> };
>
> My only concern here is that there is a bit of duplicated information between the IS (or ISLocalToGlobalMapping?) and the PetscLayout.
What is that duplicate information? Can it be removed or can we provide automatic consistency checks so that the "duplication" is not a problem?
> I would like to see the local space become a more central property of Mat and Vec (this would simplify DMComposite and allow fusing the scatters which should be good for performance), so putting it in PetscLayout makes sense to me. For (rare) memory reasons, I think it should be possible for the ISLocalToGlobalMapping to be NULL.
Of course it can be null now and would be able to be null in the future.
Barry
More information about the petsc-dev
mailing list