[MOAB-dev] Tag values problem,

Iulian Grindeanu iulian at mcs.anl.gov
Sun Jul 14 18:00:14 CDT 2013


----- Original Message -----

| On 13 Jul 2013, at 23:52, Iulian Grindeanu <iulian at mcs.anl.gov>
| wrote:

| > Hello Lukasz,
| >
| > Hello,
| >
| > I storing entity handle on tags. I use that to store handle to
| > parent element in edge mesh refine algorithm. To create tag I use,
| >
| > //CASE 1
| > rval = moab.tag_get_handle("_RefParentHandle",sizeof(EntityHandle),
| > MB_TYPE_OPAQUE,th_RefParentHandle,MB_TAG_CREAT|MB_TAG_SPARSE|MB_TAG_BYTES,&no_handle);
| > CHKERR(rval); CHKERR_THROW(rval);
| >
| > or
| >
| > //CASE 2
| > rval = moab.tag_get_handle("_RefParentHandle",1,
| > MB_TYPE_HANDLE,th_RefParentHandle,MB_TAG_CREAT|MB_TAG_SPARSE,&no_handle);
| > CHKERR(rval); CHKERR_THROW(rval);
| >
| > I think the issue is "no_handle" definition in your code.
| > EntityHandle is basically unsigned long int. (-1) will be probably
| > converted to 0xfff...fff, but I think it depends on compiler.
| > for type MB_ENTITY_HANDLE, during writing, it will try to map with
| > an actual handle, and it will not be able to.
| > It should probably give some warning at least.
| It was my intention to have impossible tag. However in that case
| root_mesh is also impossible, to be parent and will do work.

| It is funny, that no_hanle(-1) working without warning, problems is
| when I read file. In other words I can create tag and use it without
| problems. However when I restart calculations and read file I have
| error.

well, we use ~(EntityHandle)0 in our tests, and it would be the same problem during saving to an h5m file. 

| > It is not advisable to use OPAQUE type, because it will just set
| > the handle in bytes. If some reordering is involved, you could get
| > a different handle than you expect.
| > Would it be difficult to use 0 as default in your code? (root set?)
| > Nobody should have as "parent" the root set, but I am not
| > understanding your code enough;
| > Or create an actual entity (or an entity set) that you know that
| > you will never use, and use that for default. I assume that you
| > need a default, but maybe you don't.
| I was not aware of that tags which has type ENTITYHANDLE are
| automatically updated in case of reordering. I was thinking that
| Handle is given to Entity for its life in database and no other,
| dead or alive entity can share the same handle.

Yes, entity handle is unique per moab instance. But the tag of type MB_TYPE_HANDLE can point to any entity handle; 
Of course, if you delete that entity handle, all bets are off, we do not keep track. It would be like a pointer to deleted memory. 

The entities are mapped to hdf5 file entity ids during writing, and during reading they are mapped back to moab entity handles. 

If you want to know more about h5m format, you can find here some info 
http://trac.mcs.anl.gov/projects/ITAPS/wiki/MOAB/h5m 

| Ok mesh merging is a problem.

yes, it would be; if you use handle tag, you would have no problems. Please report if you find any bugs. 

| > I looked a little at your h5m files, there are a lot of tags, nice
| > and elaborate work :) I hope you keep track of them :)
| I hope as well, tags content is controlled by boost multi-index
| containers.

I would like to be able to compile your code; it seems you depend on PETSc; any other dependencies? 
We want to add more support for mesh refinement, and your experience would help us. 

Thanks, 
Iulian 

| > I did not compile your code, are there any instructions? I see that
| > for cmake you need some file to be defined. (for PETSc?)

| Yes, mesh is serial, calculations are parallel and I use PETSc to do
| that.

| > Best regards,
| > Iulian
| >
| > I save mesh in native moab format and read it once again.
| >
| > In CASE 1, moab works as expected, no problem. See example file
| > restart_case1.h5m.
| > In CASE 2, moab generate error,
| > Error code 10 at
| > /Users/likask/MyBuild/mofem-bitbucket/mofem_v0.0.1/do_not_blink/moabField_Core.cpp:46
| > See example file restart_case2.h5m
| >
| > I don't know if error is result of my ignorance about moab, or
| > problem is somewhere in moab implementation. I using version
| > moab-4.6.0.
| >
| >
| > If you need more details about my code, you can find code here,
| > https://bitbucket.org/likask/mofem-joseph/overview
| > Tag:
| > v0.0.1.1_moab_problem_with_tag
| >
| > Thanks for help,
| > Regards,
| > Lukasz Kaczmarczyk
| > Lecturer
| > School of Engineering,
| > University of Glasgow,
| > GLASGOW, G12 8LT
| > Tel: +44 141 3308113
| > email: likask at civil.gla.ac.uk
| > web: http://userweb.eng.gla.ac.uk/lukasz.kaczmarczyk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20130714/769fcf68/attachment.html>


More information about the moab-dev mailing list