July 2016 - moab-dev - mailman3.cels.anl.gov

a bug in Coupler::locate_points
by Huayi Wei 17 Apr '17

17 Apr '17

Hi, Moab Dev, In the following member function, I think it is a bug for line ` tl = new TupleList(3, 0, 0, 0, num_points);`. Here create new TupleList which address will cover the address tl passed by user, and then user can not accsess it. I think it should be ' tl->initialize(3, 0, 0, 0, num_points)`, ```` ErrorCode Coupler::locate_points(double *xyz, unsigned int num_points, double rel_eps, double abs_eps, TupleList *tl, bool store_local) { ....... // Copy into tl if passed in and storing locally if (tl && store_local) { tl = new TupleList(3, 0, 0, 0, num_points); tl->enableWriteAccess(); memcpy(tl->vi_wr, tl_tmp->vi_rd, 3 * tl_tmp->get_n() * sizeof(int)); tl->set_n(tl_tmp->get_n()); tl->disableWriteAccess(); } .... } ``` Best Huayi

4 6

Setting tags of non-owned entities
by Alexander Nikolas Breuer 26 Jul '16

26 Jul '16

Dear MOAB-team, I have a (hopefully) quick questions on the User Guide: > Owning Processor: Each shared entity is owned by exactly one processor. This processor has the right to set tag values on the entity and have those values propagated to any sharing processors. Would like to create an (globally) inconsistent state by setting values (dense tag) of non-owned entities. Don’t need this info on neighboring ranks -> I’ll never propagate that info through pcomm. Are there any technical reasons existing against doing so? Should I initialize the ghost entities remotely first so that the memory gets allocated properly? > Storage for a given dense tag is not allocated until a tag value is set on an entity; memory for a given dense tag is allocated for all entities in a given sequence at the same time. Thanks, Alex PS: [6] “MOAB Users Email List.”, moab(a)mcs.anl.gov. in http://ftp.mcs.anl.gov/pub/fathom/moab-docs/contents.html#references seems to be broken: > The following message to <moab(a)mcs.anl.gov> was undeliverable. > The reason for the problem: > 5.1.0 - Unknown address error 550-'#5.1.0 Address rejected.' -- Alexander Breuer University of California, San Diego San Diego Supercomputer Center 9500 Gilman Drive MC 0505 La Jolla, California 92093-0505, USA http://hpgeoc.sdsc.edu +1 (858) 822-5692

2 3

Error message when MeshTag is set and entities are removed from database.
by Lukasz Kaczmarczyk 26 Jul '16

26 Jul '16

Hello, I found this bug, it always happens when MeshTag is defined and entities are removed from database. Bug is not critical, but annoying making unnecessary printing on the screen when error not really happened. [0]MOAB ERROR: --------------------- Error Message ------------------------------------ [0]MOAB ERROR: Cannot get/set mesh/global tag _FieldShift on non-root-set EntitySet 3! [0]MOAB ERROR: not_root_set() line 18 in src/MeshTag.cpp [0]MOAB ERROR: --------------------- Error Message ------------------------------------ [0]MOAB ERROR: Cannot get/set mesh/global tag _FEShift on non-root-set EntitySet 3! [0]MOAB ERROR: not_root_set() line 18 in src/MeshTag.cpp [0]MOAB ERROR: --------------------- Error Message ------------------------------------ [0]MOAB ERROR: Cannot get/set mesh/global tag _ProblemShift on non-root-set EntitySet 3! [0]MOAB ERROR: not_root_set() line 18 in src/MeshTag.cpp [0]MOAB ERROR: --------------------- Error Message ------------------------------------ [0]MOAB ERROR: Cannot get/set mesh/global tag _MoFEMBuild on non-root-set EntitySet 3! [0]MOAB ERROR: not_root_set() line 18 in src/MeshTag.cpp [0]MOAB ERROR: remove_data() line 332 in src/SparseTag.cpp [0]MOAB ERROR: remove_data() line 332 in src/SparseTag.cpp [0]MOAB ERROR: remove_data() line 332 in src/SparseTag.cpp I think that problem is in Core::delete_entities for (std::list<TagInfo*>::iterator i = tagList.begin(); i != tagList.end(); ++i) { temp_result = (*i)->remove_data( sequenceManager, mError, range ); // ok if the error is tag_not_found, some ents may not have every tag on them if (MB_SUCCESS != temp_result && MB_TAG_NOT_FOUND != temp_result) result = temp_result; } when MeshTag through virtual functions is deleted, then error is printed from not_root_set. This is not consistent how other tags are responding, for example in case of SparseTag an error is resulted MB_TAG_NOT_FOUND and no error is printed. I think that MeshTag should behave in exactly the same way. I can make quick fix, my proposition is to not_root_set change that it return MB_TAG_NOT_FOUND in case of non root meshset. Kind regards, Lukasz

2 1

EntityHandle?
by Lukasz Kaczmarczyk 14 Jul '16

14 Jul '16

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

3 11