Segmentation fault on setting up symmetries

[QuantumFelidae]

I was attempting to calculate band structures and density of states for a set of materials. Following the tutorials from the docs, I generated the following input file: common.in.txt When running this with:

srun --mpi=pmix -n 1 -c 24 jdftx -i common.in

I receive the following output and segmentation fault: res.txt

jdftx-stacktrace.txt

Using the print stacktrace script on the generated file yields:

printStack(bool) at ??:?
stackTraceExit(int) at ??:?
/data/apps/extern/jdftx/1.7.0/usr/local/share/jdftx/scripts/printStackTrace: line 27: 0xU: value too great for base (error token is "0xU")
?? ??:0
unsigned long PeriodicLookup<vector3<double> >::find<double, std::equal_to<double> >(vector3<double>, double, std::vector<double, std::allocator<double> > const*, std::equal_to<double>) const at ??:?
Symmetries::findSpaceGroup(std::vector<matrix3<int>, std::allocator<matrix3<int> > > const&) const at ??:?
Symmetries::calcSymmetries() at ??:?
Symmetries::setup(Everything const&) at ??:?
Everything::setup() at ??:?
main at ??:?
__libc_start_main at ??:?
_start at ??:?

Am I doing something wrong, or is there some greater issue at play here?

Thanks.

[shankar1729]

I'm unable to reproduce this error from your input file. Could you try a dry run without MPI (jdftx -ni common.in ) locally first? This worked correctly on my laptop within a second yielding 8 space group symmetries and crossing where you found the crash.

If your serial dry run also crashes at the same point, the next question will be how you compiled jdftx and whether a compiler/library combination is triggering this issue. Also, update the code to current HEAD on git, although I can't see any changes between your current version and now that should affect this behavior.

Thanks! Best, Shankar

[QuantumFelidae]

Testing the input file as above verifies the correctness of the input file, but the same crash occurs. Here's what is loaded in Lmod:

prepend_path("CMAKE_PREFIX_PATH","/data/apps/extern/jdftx/1.7.0/usr/local/")
prepend_path("CPATH","/data/apps/extern/jdftx/1.7.0/usr/local/include")
prepend_path("PATH","/data/apps/extern/jdftx/1.7.0/usr/local/bin")
prepend_path("LD_LIBRARY_PATH","/data/apps/extern/jdftx/1.7.0/usr/local/lib")
prepend_path("LIBRARY_PATH","/data/apps/extern/jdftx/1.7.0/usr/local/lib")
prepend_path("MANPATH","/data/apps/extern/jdftx/1.7.0/usr/local/share/jdftx")
prepend_path("XDG_DATA_DIRS","/data/apps/extern/jdftx/1.7.0/usr/local/share")
setenv("JDFTX_BIN","/data/apps/extern/jdftx/1.7.0/usr/local/bin")
always_load("slurm/19.05.7")
always_load("intel/2020.1")
always_load("cmake/3.18.4")
always_load("cuda/11.6.0")
always_load("gsl/2.7")
always_load("intel-mkl/2022.0")
always_load("fftw/3.3.9")
always_load("hdf5/1.12.2-intel-mpi")
always_load("openmpi/4.1.1_gpfs")

I also see this at the top of the dry run:

Due to MODULEPATH changes, the following have been reloaded:
  1) git/2.28.0

The following have been reloaded with a version change:
  1) openmpi/4.1.1_gpfs => openmpi/3.1.6

Are these the correct runtime dependencies?

As for updating to current head, I'd have to speak with the support team for this resource, so I can't as easily test this :)

[shankar1729]

Based on past experience with such weird bugs, I would suspect the intel compilers to be the culprit. Try compiling with GNU compilers if you can. Also, do you get this crash for any input file?

[QuantumFelidae]

Testing the input file from the bandstructures tutorial in the docs results in the same crash, so I assume that it is with all similar input files. I'll reach to the team that manages the resource and inquire about how they compiled the module.

[QuantumFelidae]

Well, gcc fixed my issue, and I'm no longer experiencing crashes!

Thanks for all the help!