I’m seeing a reproducible segmentation fault related to PPPM/FFTW on macOS. The simulation itself completes (thermo output reaches the end of the run), but the job crashes during cleanup (PPPM deallocation / FFT3d destructor), and in some cases also when entering write_data (“System init for write_data … PPPM initialization …”). Smaller systems (N<1000)sometimes succeed, but larger systems(5000<N) crash.
Reproduction
• A run with PPPM enabled completes (e.g., run 10000) and prints Loop time …
• Immediately after that, the program crashes with SIGSEGV on all ranks
• Backtrace includes:
• libfftw3.3.dylib : fftw_plan_awake
• LAMMPS_NS::FFT3d::~FFT3d
• LAMMPS_NS::PPPM::deallocate
• LAMMPS_NS::PPPM::~PPPM
• LAMMPS_NS::Force::~Force
• LAMMPS_NS::LAMMPS::destroy
Notes / what I tried
• The issue is size-dependent: smaller systems may finish without crashing; larger systems crash consistently.
• Changing pair cutoff/neighbor settings affects other errors (e.g., neighbor overflow), but does not remove this FFTW/PPPM cleanup segfault.
• The system is not charge neutral (LAMMPS warning: net charge = 68.8128), but the crash occurs after the run and looks like an FFTW deallocation issue; the run itself completes.
• kspace_style none before output can also trigger the segfault (PPPM cleanup).
Is this a known issue with PPPM + FFTW + MPI on macOS (Apple Silicon)? Any recommended workaround (e.g., building with KISS FFT instead of FFTW, using a different FFTW/MPI build combination, or known patches)?
Output validity / necessity of write_data:
Even when the job crashes (either during write_data initialization or during PPPM/FFTW cleanup after the run), the dump/trajectory file is written up to the last printed timestep. Since my downstream analysis will be performed from the trajectory, I would like to confirm:
2-1 If the trajectory/dump file is written up to step N and thermo output also reaches step N, is it generally safe to assume that the simulation results are valid up to that last dumped step, despite the crash during finalization?
2-2 In typical workflows, what important information would I lose by not having a write_data output (e.g., topology, force-field settings, reproducibility / ability to restart), assuming I keep the original input script and data file used to start the run?
If there is a recommended best-practice alternative in this situation (e.g., using write_restart periodically and post-processing from restart files), I would appreciate advice.
The backtrace makes this likely an issue of the installed FFTW library. This can be due to a bug in FFTW itself (unlikely since it is a very widely used and extremely mature software), or in the compiler that was used to compile it (you don’t provide any information about how you installed FFTW, and what compiler or OS version was used, so I cannot comment any further). Using the built in KISS FFT library is the obvious alternative. If that can be used without segfaulting, then it is likely that this is not a LAMMPS problem. If it also segfaults, we have to look closer. However, this is a very mature part of LAMMPS and used a lot, so issues are not common, especially for common use cases.
Not generally. You have to understand why it crashes. From the information you provide, the segmentation fault could be caused by some kind of memory corruption that has happened earlier and thus all bets are off unless it is understood why this happens. A completed simulation without crash does not mean it is correct, even if it does not trigger any bugs.
The documentation of the read_data command documents what information is stored in a data file. What you would be missing depends on what you do in the simulation. If you make any changes that affects any of the information that is stored and read from a data file, you would lose it by not storing that data. You would definitely lose the information about the current atom velocities. Please note that a data file stores only a subset of information of a simulation. A restart file stores much more, including the state of fixes and thus using a restart file will allow a more complete restauration of the state of a system at the end of a simulation. With a data file, you have to re-initialize more parts. However, how much this impacts a simulation strongly depends on what you do. E.g. for a simple run with only fix nve, there is not much additional information, but for complex simulations with many fixes, this can make a big difference.
When a simulation crashes, you have to understand why this happens. Only then can you make an informed decision. There is no simple “do this, not that” kind of advice beyond that.