[MOAB-dev] DMMoabCreateVector

[Vijay S. Mahadevan]

Hi Gerd,

I think you've uncovered a bug (part in design and part in
implementation) and it wasn't technically supposed to be confusing.
When you set a tag_size that is not 1, currently there isn't support
to decipher this from the tag and allocate a vector accordingly. This
is an implementation bug that I will fix soon. Thanks for reporting.

But a more relevant design question is whether you are creating fields
in DMMoab and if the number there is the same as the one defined here
(=3). This is necessary to ensure that the matrices are also getting
allocated properly based on whether you want interleaved or strided
representation, which will also affect the Vec representation with a
size 3*N. To get a hold of this resulting vector, you would need to
call DMCreateGlobalVector [1] instead of calling the more specific
DMMoabCreateVector API function.

Note that with the usage of DMMoabCreateVector, you've requested for
interleaved access by default. I'm not sure how to handle the
inconsistency here yet.

Vijay

[1] http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMCreateGlobalVector.html

On Tue, Nov 25, 2014 at 9:21 AM, Gerd Heber <gheber at hdfgroup.org> wrote:
> I'm a little confused about the use of DMMoabCreateVector.
> I create a tag like this:
>
> Field default_value = { 0.0, 0.0, 0.0 };
> size_t u_tag_size = sizeof(Field)/sizeof(PetscScalar);
> Tag u_tag;
> merr = mbiface->tag_get_handle("u", u_tag_size,
>                                      MB_TYPE_DOUBLE, u_tag,
>                                      MB_TAG_DENSE|MB_TAG_CREAT,
>                                      &default_value);
>
> Let N be the number of entities. If I then go on to create a PETSc Vec via
>
> ierr = DMMoabCreateVector(dm, u_tag, owned, PETSC_TRUE, PETSC_FALSE, &u);
>
> and retrieve the (global) size of the Vec
>
> ierr = VecGetSize(u, &size);
>
> I get N as the answer. Why is it N rather than 3*N?
>
> Should it be 3*N and I'm doing something stupid, or is it supposed to be N, which
> I'd find somewhat counterintuitive. (What would be the relationship between that
> Vec and the tag data?)
>
> Thanks, G.
>
>
>