On Tue, Mar 9, 2021 at 12:59 PM Pilhwa Lee <jpilp...@gmail.com> wrote:
> Dear All, > > In TACC, I’m trying to do mesh partitioning by subdomain_partitioner. > There comes the following error: > > map_find() error: key "22484" not found in file > /admin/build/admin/rpms/stampede2/BUILD/libmesh-1.6.0/src/partitioning/mapped_subdomain_partitioner.Cmap_find() > error: key "12288" not found in file > /admin/build/admin/rpms/stampede2/BUILD/libmesh-1.6.0/src/partitioning/mapped_subdomain_partitioner.C > on line 54map_find() error: key "19121" not found in file > /admin/build/admin/rpms/stampede2/BUILD/libmesh-1.6.0/src/partitioning/mapped_subdomain_partitioner.C > on line 54 > on line 54 > > [0] [2] ./include/libmesh/utility.h, line 135, compiled [3] > ./include/libmesh/utility.h, line 135, compiled Feb 3 2021 at > ./include/libmesh/utility.h, line 135, compiled Feb 3 2021 at 17:00:42 > > When I test in a local workstation based on GCC, there is no problem. I > wonder whether there are some issues of configuration depending on GCC > versus Intel64 compilers and permission. The key which is not found in this case, 22484, seems pretty large to be a subdomain id. Are you sure you're using the subdomain_to_proc map correctly? From the documentation: /** * Before calling partition() or partition_range(), the user must * assign all the Mesh subdomains to certain processors by adding * them to this std::map. For example: * subdomain_to_proc[1] = 0; * subdomain_to_proc[2] = 0; * subdomain_to_proc[3] = 0; * subdomain_to_proc[4] = 1; * subdomain_to_proc[5] = 1; * subdomain_to_proc[6] = 2; * Would partition the mesh onto three processors, with subdomains * 1, 2, and 3 on processor 0, subdomains 4 and 5 on processor 1, * and subdomain 6 on processor 2. */ What are the contents of the subdomain_to_proc map when the error occurs? Note that this map will generally need to be changed as you vary the number of processors that you run on, and it is up to the user to set it up correctly. I don't really see how the error could be due to different compiler toolchains, but I guess anything is possible. -- John _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
