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

Ed Bueler elbueler at alaska.edu
Fri May 27 14:34:53 CDT 2016

Dear PETSc --

This is an "am I using it correctly" question.  Probably the API has the
current design because of something I am missing.

First, a quote from the PETSc manual which I fully understand; it works
great and gives literate code (to the extent possible...):

The recommended approach for multi-component PDEs is to declare a struct
representing the fields defined
at each node of the grid, e.g.

typedef struct {
PetscScalar u,v,omega,temperature;
} Node;

and write residual evaluation using

Node **f,**u;
DMDAVecGetArray(DM da,Vec local,&u);
DMDAVecGetArray(DM da,Vec global,&f);
f[i][j].omega = ...
DMDAVecRestoreArray(DM da,Vec local,&u);
DMDAVecRestoreArray(DM da,Vec global,&f);

Now the three questions:

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 *"?

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

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.

Thanks for addressing silly questions.


Ed Bueler
Dept of Math and Stat and Geophysical Institute
University of Alaska Fairbanks
Fairbanks, AK 99775-6660
301C Chapman and 410D Elvey
907 474-7693 and 907 474-7199  (fax 907 474-5394)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160527/ec04a11c/attachment.html>

More information about the petsc-users mailing list