[MOAB-dev] Tag values problem,

[Lukasz Kaczmarczyk]

> I would like to be able to compile your code; it seems you depend on PETSc; any other dependencies?

PETSc and boost.

If you need test mesh refinement, 
./test_mesh_refinment -my_file ../meshes/cub_with_interface.cub -my_out_file "out.vtk"

How it works with elastic mechanics problem, see example simple_elastic_interface. Look to the code is there how you can only split and refine or just split mesh. 
 
This is code at very early stage, approx. 3 months.  


Regards,
Lukasz

On 15 Jul 2013, at 00:00, Iulian Grindeanu <iulian at mcs.anl.gov> wrote:
> 
> 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