On Mon, Apr 16, 2012 at 5:11 PM, Juha J?ykk? <juhaj at iki.fi> wrote:
> Hi list! > > I am trying to create a 3D DA such that I can use DMDAVecGetArray() and > access > it using array indexing. I know how to get several dof in the DA and how > using > a struct to access the members works, when the dof is determined at > compile- > time (so accesses like array[1][2][3].member1[2] are computed correctly. > > However, I would like to determine dof at run-time. Creating a struct with > pointers (even of the type member[]) of course gives me a struct whose size > depends on the *pointer* size, not my dof. So I was wondering if I could > work > around this somehow, but do not seem to be able to. > http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/DM/DMDAVecGetArrayDOF.html Matt > My DA is created by > > DMDACreate3d(PETSC_COMM_WORLD, > DMDA_BOUNDARY_GHOSTED, DMDA_BOUNDARY_GHOSTED, > DMDA_BOUNDARY_GHOSTED, DMDA_STENCIL_BOX, > 2, 2, 2, > PETSC_DECIDE, PETSC_DECIDE, PETSC_DECIDE, > ndof, NGHOSTS, > PETSC_NULL, PETSC_NULL, PETSC_NULL, > &da); > > so my Vec does have the correct dof, but I cannot seem to fool C to address > this as array[z][y][x][n] or something of the like, where the last index is > the index to ndof. (Usually I would index that as array[z][y][x].member[n], > but now I do not know how to make that happen since I cannot define a > struct > whose storage size is not known to the compiler.) > > Any ideas? Or am I trying to accomplish something which is not possible? > (If > so, why would that be? The vector is of the correct size.) > > Cheers, > -Juha > > -- > ----------------------------------------------- > | Juha J?ykk?, juhaj at iki.fi | > ----------------------------------------------- > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120416/eb57cd02/attachment-0001.htm>
