[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


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