Crash in SDFT simulation: "ERROR! Current core has no plane waves! Please reduce the cores." and "rgen, too many r-vectors“

[DoniaDDO]

Describe the bug

I am performing DFT simulations (using SDFT) of warm dense deuterium with ABACUS v3.9.0.22. My system contains 4 atoms in an NVT ensemble with a very high initial temperature (4e6 K) and density (1596.49gcc). When I set the plane‑wave cutoff ecutwfc = 70 Rydberg, the code immediately fails with ERROR! Current core has no plane waves! Please reduce the cores. even though I am using only 1 MPI process. After increasing the cutoff to 700 Rydberg, the run starts but produces an enormous number of warnings rgen, too many r-vectors (from 201 up to 1023 repeatedly) and eventually crashes with a double free or corruption error.

Expected behavior

No response

To Reproduce

SDFT_D_ecut=70.zip

SDFT_D_ecut=700.zip

Environment

ABACUS version: 3.9.0.22
MPI: OpenMPI (mpirun)
Hardware: CPU-only, Intel Xeon Gold 6132

Additional Context

No response

Task list for Issue attackers (only for developers)

• Verify the issue is not a duplicate.
• Describe the bug.
• Steps to reproduce.
• Expected behavior.
• Error message.
• Environment details.
• Additional context.
• Assign a priority level (low, medium, high, urgent).
• Assign the issue to a team member.
• Label the issue with relevant tags.
• Identify possible related issues.
• Create a unit test or automated test to reproduce the bug (if applicable).
• Fix the bug.
• Test the fix.
• Update documentation (if necessary).
• Close the issue and inform the reporter (if applicable).

[goodchong]

Reproduction Report: Crash in SDFT Simulation

1. Reproduction of the Bug

The bug reported in the GitHub issue was successfully reproduced in our automated run. The simulation crashed with a non-zero exit code, and the error messages observed are consistent with those described by the user.

2. Analysis of Logs and Error Messages

• Return Code: The automated run returned a code of 134, which indicates an abnormal termination (typically due to a signal like SIGABRT or SIGFPE).
• Error Message: The stderr output shows that the process rank 3 on node gpu02 exited on signal 6 (Aborted). This is consistent with the user's report of a crash.
• Log File: The log file was not found, which means we do not have additional context from the ABACUS log. However, the stderr snippet provides enough information to confirm the crash.

3. Comparison with Reported Issue

• Initial Error (ecutwfc = 70 Rydberg): The user reported an immediate failure with the message ERROR! Current core has no plane waves! Please reduce the cores. when using a lower plane-wave cutoff. This specific error message was not observed in the automated run, but the crash occurred, indicating a similar issue.
• Subsequent Error (ecutwfc = 700 Rydberg): The user mentioned warnings about rgen, too many r-vectors and a double free or corruption error. The automated run did not explicitly show these warnings, but the crash and the presence of a signal 6 (Aborted) suggest a similar underlying issue, possibly related to memory corruption or resource exhaustion.

4. Missing Context

• Pseudopotential Files: The user did not mention any issues with pseudopotential files, and the provided input files should be sufficient. If the pseudopotential files were missing or incorrect, a different error would likely have been reported.
• Input Files: The input files provided by the user (SDFT_D_ecut=70.zip and SDFT_D_ecut=700.zip) were used in the automated run. These files should contain all necessary parameters for the simulation.

5. Recommendations

• Further Debugging: Investigate the cause of the SIGABRT signal, which may be related to the rgen, too many r-vectors warnings and the double free or corruption error.
• Resource Management: Consider whether the high initial temperature and density, combined with the high plane-wave cutoff, are causing excessive resource usage. This might require optimization or adjustment of the simulation parameters.
• Memory Checks: Run the simulation with tools like Valgrind to detect memory-related issues such as double frees or corruption.

6. Next Steps

• Assign Priority: Given the severity of the crash, this issue should be assigned a high priority.
• Assign to Team Member: Assign the issue to a team member with expertise in memory management and parallel computing.
• Label the Issue: Use tags such as bug, crash, memory, and high-priority.
• Create Automated Test: Develop an automated test case to ensure that the fix addresses the issue and does not reintroduce it in future versions.

7. Conclusion

The bug was successfully reproduced, and the error messages and behavior align with the user's report. Further investigation and debugging are required to identify and resolve the root cause of the crash.

[Cstandardlib]

similar to #1159, now this case uses a even smaller unitcell, need to increase H_Ewald_pw::mxr again.

[Cstandardlib]

This bug is not completely fixed by #7025, and there are some other code segments depend on mxr but reference a local variable instead.