[MOAB-dev] DMMoabCreateVector

[Vijay S. Mahadevan]

Those are valid comments and criticisms. I completely agree that the
flow and usage of the API needs to be better documented, partly in the
functions themselves and mostly through additional examples. This is
where DMMoab is sorely lacking right now. Unfortunately, I've been
quite swamped with several other things but hope to put in some
serious effort starting January on making DMMoab a little more
complete. If you want to contribute examples on the usages, I would
love to take a patch or PR.

In the pipeline, we also have some work proceeding on a small
lightweight discretization library that can be used with MOAB or
DMMoab to associate field dofs with a valid basis so that the FEM
assembly operations can be handled much more smoothly. We also have a
uniform refinement capability in the works (should be in MOAB master
by mid-December) which will expose the ability to do geometric
multigrid with different level representations handled via DMMoab.
This is the part we are going to be concentrating from January and so
I will make sure to update examples/documentation during this process
to make things lot clearer.

Meanwhile, if there are more comments or suggestions, I'm always open
to hear them.

Vijay

On Tue, Nov 25, 2014 at 3:50 PM, Gerd Heber <gheber at hdfgroup.org> wrote:
> Vijay, thanks, I finally figured that (DMMoabSetFieldNames...)
> does the trick. I think much of the confusion comes from that
> there doesn't seem to be any documentation of the DMMoab
> "protocol", for the lack of a better term.
> The functions are all reasonably documented individually,
> but there's no documentation that explains what the protocol is,
>  i.e., which calls are supposed (or not! supposed) to happen
>  before certain other calls. For example, is DMMoabSetBlockSize
> supposed to be called before DMSetup or after, or maybe
> it's not supposed to be called at all under certain
> circumstances. How do I know? Does DMMoabSetBlockSize interfere
> with DMMoabSetFieldNames? maybe. Maybe not. Other than trial
> and error, how can I determine that?
>
> Don't get me wrong, I really like what I see in DMMoab!
> I only wish the model scenarios were documented somewhere.
>
> Best, G.
>
>
>
> -----Original Message-----
> From: Vijay S. Mahadevan [mailto:vijay.m at gmail.com]
> Sent: Tuesday, November 25, 2014 2:11 PM
> To: Gerd Heber
> Cc: MOAB dev
> Subject: Re: [MOAB-dev] DMMoabCreateVector
>
> 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.
>>
>>
>>