[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