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)