Re: [Libmesh-users] Libmesh sticks in prepare_for_use() when using 65536 MPIs

[Li L. <li...@ka...>]

Thank you for your reply!

I changed from "typename IdxType=unsigned int" to "typename
IdxType=dof_id_type" in parallel_sort.h (libmesh_dir/include/parallel/),
and then reconfigure and make. Errors occur as follows:
  ...
  CXXLD    libmesh_opt.la
  CXX      src/apps/getpot_parse_opt-getpot_parse.o
  CXXLD    getpot_parse-opt
/usr/bin/ld: ./.libs/libmesh_opt.so: undefined reference to
`libMesh::Parallel::Sort<Hilbert::HilbertIndices, unsigned long>::bin()'
/usr/bin/ld: ./.libs/libmesh_opt.so: undefined reference to
`libMesh::Parallel::Sort<Hilbert::HilbertIndices, unsigned
long>::Sort(libMesh::Parallel::Communicator const&,
std::vector<Hilbert::HilbertIndices,
std::allocator<Hilbert::HilbertIndices> >&)'
/usr/bin/ld: ./.libs/libmesh_opt.so: undefined reference to
`libMesh::Parallel::Sort<Hilbert::HilbertIndices, unsigned long>::sort()'
/usr/bin/ld: link errors found, deleting executable `.libs/getpot_parse-opt'
/usr/bin/sha1sum: .libs/getpot_parse-opt: No such file or directory
collect2: error: ld returned 1 exit status
Makefile:10169: recipe for target 'getpot_parse-opt' failed
make[1]: *** [getpot_parse-opt] Error 1
make[1]: Leaving directory '/lustre/project/k1305/liluo/lib/libmesh-0.9.3'
Makefile:27210: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

To John:
I am an old fan of libMesh and I am now still using libmesh0.9.3, yes, it
is very old, but due to the large amount of early codes, I hope to fix this
issue on the current version.
The config.log shows
#define DOF_ID_BYTES 8
#define PROCESSOR_ID_BYTES 4
#define SUBDOMAIN_ID_BYTES 4
#define UNIQUE_ID_BYTES 8

Best,
Li Luo

On Thu, Jan 31, 2019 at 5:49 PM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Jan 30, 2019 at 11:08 AM Stogner, Roy H <roy...@ic...>
> wrote:
>
>>
>> On Wed, 30 Jan 2019, Li Luo wrote:
>>
>> > I am using libMesh for large scale parallelization. To enable the usage
>> of
>> > 65536 processor cores, the options
>> > --with-dof-id-bytes=8 --with-processor-id-bytes=4
>> > --with-subdomain-id-bytes=4
>> > are already used for configuration.
>>
>
> Would you mind looking in your
> $LIBMESH_DIR/include/libmesh/libmesh_config.h file and verifying that
>
> #define LIBMESH_PROCESSOR_ID_BYTES 4
>
> is indeed set?  65536 is right at the uint16_t limit, so I just want to
> rule out any funny business with the configure test that sets that value.
> Also, 4 bytes is now the default for processor_id_type so you should be
> able to safely omit that option if you are using a relatively recent
> version of libmesh. Speaking on which, can you let us know what version of
> libmesh you are using? A number of improvements have been made to the
> parallel communications routines since the last tagged release, so you'd be
> best off using libmesh master for any huge runs you are attempting.
>
> --
> John
>


-- 

Postdoctoral Fellow
Extreme Computing Research Center
King Abdullah University of Science & Technology
https://sites.google.com/site/rolyliluo/

-- 

This message and its contents, including attachments are intended solely 
for the original recipient. If you are not the intended recipient or have 
received this message in error, please notify me immediately and delete 
this message from your computer system. Any unauthorized use or 
distribution is prohibited. Please consider the environment before printing 
this email.