[MOAB-dev] EntityHandle?

Lukasz Kaczmarczyk Lukasz.Kaczmarczyk at glasgow.ac.uk
Mon Jul 11 09:19:45 CDT 2016


Hello,

I working on example where I do remeshing part of the mesh. Results are consistent when I do not delete entities, however if I do remove entities I start to run into problems. EntityHandles are not consistent across runs.

It is something strange as well, I run ReorderTool at it works ok fine, however if I delete some entities from database I get error;
Unreconverable error during mesh reorder.
Error Code 4 at ReorderTool.cpp:486
[likask:88241] *** Process received signal ***

In general I stick to GID, one of the data models is that I have non-distributed mesh, but distributed algebra, i.e. mesh is the same on each proc, however I do all algebra as distributed, inconsistent handlers makes a problem for me.

All problems start when I delete something form mesh, then if I create entity and adjacencies to those entities have handlers inconsistent cross processors, so I can not attache GID or guarantee order without some additional communication.

Kind regards,
Lukasz

> On 11 Jul 2016, at 15:03, Grindeanu, Iulian R. <iulian at mcs.anl.gov> wrote:
> 
> Hi Lukasz,
> The entity handle is associated with the moab instance. Of course, different tasks have different moab instances.
> Shared entities between processors can have different handles.
> If the options used to read the mesh are consistent between runs, you should expect that the entity handles are consistent, reproducible between runs.
> Global IDs, which are just tags on entities, if read from the file, should be the same for shared entities.
> If you use ghosting for reading, global ids will be correctly propagated, if they exist in the file.
> 
> Most of the readers use ReadUtil interface, which means that entity handles are assigned in bulk, for the entity sequence created ; 
> 
> vertices:
> ErrorCode get_node_coords(const int num_arrays,
>                                    const int num_nodes,
>                                    const int preferred_start_id,
>                                    EntityHandle& actual_start_handle,
>                                    std::vector<double*>& arrays,
>                                    const int sequence_size = -1)
> elements:
> ErrorCode get_element_connect(const int num_elements,
>                                        const int verts_per_element,
>                                        const EntityType mdb_type,
>                                        const int preferred_start_id,
>                                        EntityHandle& actual_start_handle,
>                                        EntityHandle*& array,
>                                        int sequence_size = -1)
> 
> 
> ghosted entities are usually created one by one, so that means the first "free" entity handle is used, in ascending order, for the ghosted entities.
> 
> Do you have a particular example for which you have issues with the entity handles or global ids?
> 
> Iulian
> 
> 
> ________________________________________
> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf of Lukasz Kaczmarczyk [Lukasz.Kaczmarczyk at glasgow.ac.uk]
> Sent: Sunday, July 10, 2016 4:08 PM
> To: moab-dev at mcs.anl.gov
> Subject: [MOAB-dev] EntityHandle?
> 
> Hello,
> 
> I like to ask how entity handle is given to created entity.
> 
> In particular if I the same mesh is read, then on that mesh the some entities are create and delete in particular order, do resulting mesh has entities with the same handles for each execution of program.
> 
> I understand that mesh distributed on several processes, has different entities handles on shared entities. That is clear.
> 
> However what if exactly the same (non-distributed) mesh is stored on the several processor, should I expect that such mesh has that entities with the same GID has the same entity handle. What if next I apply the same sequence of operations, deletion and creation of entities. Should I expect the same handles on all meshes?
> 
> Kind regards,
> Lukasz
> 



More information about the moab-dev mailing list