Fix(input): reject esolver_type=lr with a self-consistent calculation

[Stardust0831]

Summary

esolver_type=lr ("LR-TDDFT with given KS orbitals") reads the ground state wave function (and charge density) from a separate, prior SCF run, so it is only meaningful as a non-self-consistent step. It cannot be combined with calculation=scf.

Previously the reset hook in read_input_item_system.cpp silently rewrote calculation from scf to nscf, hiding a contradictory user input and leaving a silently-mutated INPUT state. This is exactly the behavior that issue #7719 asks to eliminate ("A user-specified value should not be silently changed unless that behavior is deliberate, documented, and tested").

This PR removes the silent rewrite and rejects the contradictory combination in check_value with an explicit diagnostic that also states the required value (calculation=nscf), consistent with the approach already adopted for noncolin/lspinorb → nspin and bndpar in #7731.

Changes

• source/source_io/module_parameter/read_input_item_system.cpp
  • Remove the esolver_type reset_value hook that rewrote calculation=scf → nscf.
  • Add a check_value rule that WARNING_QUITs when esolver_type=lr && calculation=scf, with a message that names the required value and explains why.
• Tests
  • read_input_test.cpp: new ValidateLrRequiresNscf end-to-end test — rejects the default (esolver_type lr alone) and the explicit contradiction (esolver_type lr + calculation scf), and accepts the valid combination (esolver_type lr + calculation nscf).
  • read_input_item_test.cpp: update the Item_test esolver_type block to assert the new check_value rejection instead of the removed reset-to-nscf behavior.

Verification

• Per ABACUS governance, INPUT behavior changes were verified against the CLI/manual path where possible. The new rule is covered by the unit tests added/modified above; check_value is invoked in the final validation phase after all inputs are read (see read_input.cpp).
• No parameters.yaml / input-main.md regeneration is required: this change does not modify any parameter's description, default_value, or legal values; it only adds a cross-parameter validation, which is not represented in the generated documentation.

Related

• Issue Audit INPUT reset semantics and formalize final parameter validation #7719 — "Audit INPUT reset semantics and formalize final parameter validation"
• PR Fix(input): validate contradictory final parameters #7731 — "Fix(input): validate contradictory final parameters" (adopts the same reject-instead-of-rewrite pattern)

Notes

esolver_type=ks-lr is unaffected: it performs its own KS ground state SCF internally and therefore does not require calculation=nscf.

[Growl1234]

I'm surprised that CI tests fails due to PEXSI, given that Docker build has succeed and the PEXSI32_ROOT is even included again in CMAKE_PREFIX_PATH.

[Stardust0831]

@Growl1234 Thanks for checking. This failure is unrelated to this PR and was caused by the mutable Intel container tag being overwritten by the LTS branch: the same job succeeded at 09:59 UTC with abacus-intel:latest digest sha256:c38db3f... (IntelLLVM 2025.2.1, with the PEXSI environment exported), then the LTS Container workflow pushed digest sha256:815bcab... to that same latest tag at 10:15 UTC, and the next run failed with IntelLLVM 2026.1.1 because that LTS image does not contain/export PEXSIConfig.cmake or PEXSI32_ROOT. The prepend_path CMAKE_PREFIX_PATH ${PEXSI32_ROOT}:... line shown in the Actions log is the shell command text printed before execution; it does not prove that PEXSI32_ROOT has a value, and in the overwritten image it expands to an empty entry. The LTS Docker build can still succeed because it does not enable the develop-only PEXSI build check. The full timeline and proposed separation of latest and lts-latest are documented in #7780.

[Growl1234]

Uh it's really unfortunate...