[petsc-users] use of VecGetArray() with dof>1 (block size > 1)

[Jed Brown]

Ed Bueler <elbueler at alaska.edu> writes:

> 1)  The third argument to DMDAVec{Get,Restore}Array() is of type "void *".
> It makes the above convenient.  But the third argument of the unstructured
> version Vec{Get,Restore}Array() is of type "PetscScalar **", which means
> that in an unstructured case, with the same Node struct, I would write
> "VecGetArray(DM da,Vec local,(PetscScalar **)&u);"
> to get the same functionality.  Why is it this way?  More specifically, why
> not have the argument to VecGetArray() be of type "void *"?

My philosophy is that unstructured indexing needs more information
anyway, so you wouldn't typically use the generic VecGetArray() anyway.
For example, we use DMPlexPointLocalRead() to access the arrays.

> 2) Given that the "recommended approach" above works just fine, why
> do DMDAVec{Get,Restore}ArrayDOF() exist?  (I.e. is there something I am
> missing about C indexing?)

The struct approach is nice if the number of components is known at
compile time, but if the number of variables is dynamic (e.g., species
in a reacting flow) then it can't be used.  The DOF variants are
convenient for that.

> 3) There are parts of the PETSc API that refer to "dof" and parts that
> refer to "block size".  Is this a systematic distinction with an underlying
> reason?  It seems "block size" is more generic, but also it seems that it
> could replace "dof" everywhere.

I think that's correct.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160527/40882793/attachment.pgp>