This is some interesting stuff. Ok here's stepping through the
system_of_equations example 3, which calls exodus file writing methods:
(lldb)
Process 45495 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x00000001008b039c
libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x000000010d01b800,
filename="out.e") at exodusII_io_helper.C:1207
1204 mode |= EX_NOCLASSIC;
1205 #endif
1206
-> 1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws,
&io_ws);
1208
1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file.");
1210
Target 0: (example-dbg) stopped.
(lldb) p mode
(int) $1 = 584
(lldb) p comp_ws
(int) $2 = 8
(lldb) p io_ws
(int) $3 = 8
(lldb) p filename.c_str()
(const std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::value_type *) $4 = 0x00007ffeefbfdc29 "out.e"
(lldb) n
Process 45495 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x00000001008b03cb
libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x000000010d01b800,
filename="out.e") at exodusII_io_helper.C:1209
1206
1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws,
&io_ws);
1208
-> 1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file.");
1210
1211 if (verbose)
1212 libMesh::out << "File created successfully." << std::endl;
Target 0: (example-dbg) stopped.
(lldb) p ex_id
(int) $5 = 65536
And then here is MOOSE's simple_diffusion:
(lldb)
Process 45477 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x000000010758d39c
libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x0000000111831e00,
filename="simple_diffusion_out.e") at exodusII_io_helper.C:1207
1204 mode |= EX_NOCLASSIC;
1205 #endif
1206
-> 1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws,
&io_ws);
1208
1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file.");
1210
Target 0: (moose_test-dbg) stopped.
(lldb) p mode
(int) $0 = 584
(lldb) p comp_ws
(int) $1 = 8
(lldb) p io_ws
(int) $2 = 8
(lldb) p filename.c_str()
(const std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::value_type *) $3 = 0x00007ffeefbfdbb9
"simple_diffusion_out.e"
(lldb) n
Exodus Library Error: [ex_create]
Error: file create failed for simple_diffusion_out.e in NETCDF4 and CLOBBER
mode.
This library probably does not support netcdf-4 files.
exerrval = 13
Process 45477 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x000000010758d3cb
libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x0000000111831e00,
filename="simple_diffusion_out.e") at exodusII_io_helper.C:1209
1206
1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws,
&io_ws);
1208
-> 1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file.");
1210
1211 if (verbose)
1212 libMesh::out << "File created successfully." << std::endl;
Target 0: (moose_test-dbg) stopped.
(lldb) p ex_id
(int) $4 = -1
The arguments into exII::ex_create (except for the name of course) are the
exact same!!
So if I look into the hdf5 libraries that the different executables are
dynamically linking to I get different libraries:
$ otool -L moose_test-dbg | grep hdf5
/Users/lindad/hdf5/build-1.10.5/../installed-1.10.5/lib/libhdf5_hl.100.dylib
(compatibility version 102.0.0, current version 102.2.0)
/Users/lindad/hdf5/build-1.10.5/../installed-1.10.5/lib/libhdf5.103.dylib
(compatibility version 105.0.0, current version 105.0.0)
$ otool -L example-dbg | grep hdf5
/Users/lindad/hdf5/build-1.10.5/../installed-1.10.5/lib/libhdf5_hl.100.dylib
(compatibility version 102.0.0, current version 102.2.0)
The moose executable is somehow linking to multiple hdf5 libraries, one the
traditional library and the other the "high level" library. The libmesh
executable only links to the high level. This is despite the fact that they
are using the exact same linking flags:
-Wl,-rpath,/Users/lindad/projects/moose/scripts/../libmesh/installed-hdf5-1.10.5/lib
-L/Users/lindad/projects/moose/scripts/../libmesh/installed-hdf5-1.10.5/lib
-lmesh_dbg -L/Users/lindad/hdf5/installed-1.10.5/lib -lhdf5
-Wl,-rpath,/Users/lindad/hdf5/installed-1.10.5/lib
-L/Users/lindad/projects/moose/petsc/arch-moose/lib
-Wl,-rpath,/Users/lindad/projects/moose/petsc/arch-moose/lib
-Wl,-rpath,/opt/X11/lib -L/opt/X11/lib
-Wl,-rpath,/opt/moose/mpich-3.3/clang-8.0.0/lib
-L/opt/moose/mpich-3.3/clang-8.0.0/lib -Wl,-rpath,/opt/moose/llvm-8.0.0/lib
-L/opt/moose/llvm-8.0.0/lib
-Wl,-rpath,/opt/moose/gcc-8.3.0/lib/gcc/x86_64-apple-darwin18.5.0/8.3.0
-L/opt/moose/gcc-8.3.0/lib/gcc/x86_64-apple-darwin18.5.0/8.3.0
-Wl,-rpath,/opt/moose/gcc-8.3.0/lib -L/opt/moose/gcc-8.3.0/lib
-Wl,-rpath,/opt/moose/llvm-8.0.0/lib/clang/8.0.0/lib/darwin
-L/opt/moose/llvm-8.0.0/lib/clang/8.0.0/lib/darwin -lpetsc -lHYPRE -lcmumps
-ldmumps -lsmumps -lzmumps -lmumps_common -lpord -lscalapack -lsuperlu_dist
-lflapack -lfblas -lparmetis -lmetis -lptesmumps -lptscotchparmetis
-lptscotch -lptscotcherr -lesmumps -lscotch -lscotcherr -lX11 -lmpifort
-lgfortran -lgomp -lquadmath -lc++ -lmpicxx -lmpi -lpmpi -lomp
-lclang_rt.osx -lm -lz -lstdc++ -ldl
I simply don't understand why the hdf5_hl library would get picked up in
either case. Shouldn't I have to specify -lhdf5_hl in order for that to
happen?
On Sun, Jul 14, 2019 at 5:10 PM John Peterson <jwpeter...@gmail.com> wrote:
> Regarding HDF versions, I can’t remember exactly what we are using at the
> moment but I think it’s 1.8.x? I will check and get back to you.
>
> On Jul 14, 2019, at 5:00 PM, John Peterson <jwpeter...@gmail.com> wrote:
>
> There isn’t a lot of logic behind what gets updated when beyond “as
> necessary”. The most recent netcdf update fixed an issue with writing hdf5
> files for us. I didn’t update exodusII at the time since it there was no
> specific issue that needed to be addressed, but it is quite old relative to
> what’s available on github, so it should probably be done at some point.
>
>
> On Jul 14, 2019, at 4:35 PM, Alexander Lindsay <alexlindsay...@gmail.com>
> wrote:
>
> So I didn't get any replies to this
> <https://sourceforge.net/p/libmesh/mailman/message/36709086/>, but now
> I'm getting more curious. I'm curious why we fairly consistently update our
> netcdf version, but seem to never update our exodusii contrib? Are we sure
> that everything is compatible? I ran `make check` on my personal build of
> netcdf 4.6.2 with hdf5-1.10.5 and all tests pass, so I'm wondering whether
> the incompatibility may be at a higher level? Is our older exodusii source
> using "incorrect" APIs in the newer netcdf versions when hdf5 is available?
>
> I can look this up, but what does netcdf do differently when hdf5 is or is
> not enabled in our configure?
>
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
