Why is dft_functional mandatory when vdw_method is enabled

[xdzhu]

Describe the bug

When performing structural optimization tasks for 2D materials, I set:

markdown
#vdW correction
vdw_method d3_0
However, the calculation failed with the error:
**KILLED BY SIGNAL: 9 (Killed)**​

After troubleshooting, I discovered that enabling vdw_method requires explicitly declaring dft_functional. While I believe this mandatory requirement is unnecessary (as defaulting to PBE should be acceptable), I adjusted the input accordingly.

However, I need to understand why the error directly triggered ​SIGNAL: 9​ instead of a predefined error message.

Key Questions:
​**Why is dft_functional mandatory when vdw_method is enabled?**​

Even if the code defaults to PBE, some implementations may enforce explicit declarations for consistency or to avoid ambiguity in parameter selection (e.g., D3 corrections may require functional-specific settings).
​**Why does the code crash with SIGNAL: 9 instead of a user-friendly error?**​

​SIGNAL: 9​ typically indicates a process was forcibly terminated by the system (e.g., out-of-memory, segmentation fault, or resource limits). Possible causes:
​**Missing Input Handling:​ The code might lack proper error-checking for unset dft_functional, leading to undefined behavior (e.g., accessing uninitialized variables).
​Memory Issues:​ Incorrect parameterization could cause abnormal memory allocation, triggering system-level termination.
​Code-Specific Bugs:**​ Poor error handling in the DFT code itself (e.g., uncaught exceptions or asserts).
Suggested Actions:
Explicitly declare dft_functional even if using default values.
Check logs/debug outputs for memory or segmentation fault clues.
Report the issue to the code developers, emphasizing the need for graceful error handling.

Expected behavior

No response

To Reproduce

No response

Environment

No response

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).

[kirk0830]

At the viewpoint of developer:
I think the central problem is the default as the xc_functional's value is not set/refreshed soon after the pseudopotential is read (ABACUS is designed to infer the functional from pseudopotential, while it will actually fail in cases when the key in PP_HEADER is DFT or something others), while it is hard to say it is a ill design of D3 parameter automatic setting functionality because it does not have the duty of inferring the functional name.

At the viewpoint of a DFT software user:
Frankly speaking, it should be understood by users that the D3 parameter is always xc functional specific, and it is not a good habit if user requires one DFT machine to perform some calculation without explicitly setting the functional to use.
Moreover, there are also often the cases that users expecting to perform calculation with functionals other than PBE but still with the pseudopotential of PBE, is that really correct? If so, there would not be SCAN or even HYB-specific pseudopotential developed by CP2K developer team. But if one perform HSE06 calculation, with pseudopotential generated with PBE functional, and requires a D3 correction, what will be the outcome of ABACUS? In the past it would be: with HSE06 functional and D3 parameter of PBE (because those D3 parameters are set as those of PBE in previous implementation, but few users will change their values by hand), it was totally incorrect. This abuse should be stopped.
The corresponding document has been updated along with the PR which updates the D3 behavior in a develop version earlier than 3.8.3: https://abacus.deepmodeling.com/en/latest/advanced/input_files/input-main.html#vdw-method, so please always check the document before the practical use.

In the end, your inference (or it is generated from one LLM, maybe) is correct. This is related to the implementation of the function "WARNING_QUIT", this function will directly call the exit function in-place, that is the reason why you see such errors and the warning message is hidden somewhere that makes you hard to see at once.

Regards.

[kirk0830]

I have transferred part of this issue to another: #5944

[kirk0830]

partially fixed by PR #5949