Ed Bueler <[email protected]> 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.
signature.asc
Description: PGP signature
