[MOAB-dev] DMMoabOutput

[Grindeanu, Iulian R.]

OK, I was able to reproduce it.
It is a problem with the writer (or maybe the reader?) in parallel. I modified addfield to run in parallel, and I can see it now.
Thank you for finding this; 

Iulian

________________________________________
From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf of Gerd Heber [gheber at hdfgroup.org]
Sent: Wednesday, December 17, 2014 11:37 AM
To: MOAB dev
Subject: Re: [MOAB-dev] DMMoabOutput

I'll write a simple test program that might reproduce the
problem. (later this afternoon) The program will look like this:

- create a DMMoab via DMMoabLoadFromFile
- get the interface via DMMoabGetInterface
- create the two (dense) tags
- call DMMoabOutput

and see what happens. I'll keep you posted...
G.


-----Original Message-----
From: Grindeanu, Iulian R. [mailto:iulian at mcs.anl.gov]
Sent: Wednesday, December 17, 2014 11:21 AM
To: Gerd Heber; MOAB dev
Subject: RE: [MOAB-dev] DMMoabOutput

Hi Gerd,
I am sorry, I do not know how to reproduce the error you are seeing.
It seems to me that some tags that you create are sparse. Or something gets corrupted somewhere, I do not know where.
The utility addfield in tools/mbcoupler will add 2 dense tags on your input file, one on elements, one on vertices.

to use it, you just do

 tools/mbcoupler/addfield feawd.3.h5m out.h5m 1

the new file that gets created (out.h5m) seems to have all tags in the right place, and that GLOBAL_ID tags are still fine. (element_field and vertex_field are 2 new dense tags)

can you verify?


Iulian


_________________________________
From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf of Gerd Heber [gheber at hdfgroup.org]
Sent: Wednesday, December 17, 2014 9:14 AM
To: MOAB dev
Subject: Re: [MOAB-dev] DMMoabOutput

Any other thoughts? (This is a real showstopper for me...)

G.

-----Original Message-----
From: moab-dev-bounces at mcs.anl.gov [mailto:moab-dev-bounces at mcs.anl.gov] On Behalf Of Gerd Heber
Sent: Monday, December 15, 2014 6:59 AM
To: MOAB dev
Subject: Re: [MOAB-dev] DMMoabOutput

No iMesh here. The tags are created as dense tags via get_tag_handle/tag_set_data.

G.

-----Original Message-----
From: Grindeanu, Iulian R. [mailto:iulian at mcs.anl.gov]
Sent: Saturday, December 13, 2014 9:14 AM
To: Vijay S. Mahadevan; Gerd Heber
Cc: MOAB dev
Subject: RE: [MOAB-dev] DMMoabOutput

The problem is the type of the tags
Probably the new tags are created with iMesh_createTag() method from iMesh This method creates sparse tags (I don't remember why it is not sparse by default; maybe to be more general) In order to create a dense tag with iMesh, you need to use iMesh extensions method

iMesh_createTagWithOptions

something like
 iBase_TagHandle tagh;
  iMesh_createTagWithOptions(mesh, "dum", "moab:TAG_STORAGE_TYPE=DENSE", 1, iBase_DOUBLE, &tagh, &err, 3, 27);


With the right options, the tag will be dense, and saved in the entities portion of the h5m file


Iulian


________________________________________
From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf of Vijay S. Mahadevan [vijay.m at gmail.com]
Sent: Friday, December 12, 2014 10:31 PM
To: Gerd Heber
Cc: MOAB dev
Subject: Re: [MOAB-dev] DMMoabOutput

Gerd, this is possibly a bug in MOAB writer. I'll test your input file and see if I can replicate the issue on output. DMMoabOutput does not do anything else explicitly other than calling save on the Core object itself.

Iulian, can you also take a look at this to see if you can replicate the issue. I want to make sure that the problem is not just due to mixed elements + element tag combinations.

Vijay

On Fri, Dec 12, 2014 at 7:24 AM, Gerd Heber <gheber at hdfgroup.org> wrote:
> Maybe I'm doing something stupid, but I see some weird behavior from
> DMMoabOutput. My input mesh is feawd.3.h5m. It has a mixture of Hex8
> and Prism6 elements. I create a few nodal and element tags and call
> DMMoabOutput to create feawd.out.h5m. The nodal tags look fine, but
> the element tags get written correctly only for the prisms.
> Something gets written for the hex elements, but it gets written in
> the wrong place (under /tstt/tags/ instead of /tstt/elements/Hex8/tags).
> Another indicator that something fishy is going on is that the
> GLOBAL_ID tag has disappeared from Hex8 in the output file.
> Maybe another "protocol error"?
>
> Thanks for your help.
> G.