Skip to content

Fix DFT+U occupation matrix output format - #7829

Open
lanshuyue wants to merge 1 commit into
deepmodeling:developfrom
lanshuyue:fix-dftu-onsite-output-format
Open

Fix DFT+U occupation matrix output format#7829
lanshuyue wants to merge 1 commit into
deepmodeling:developfrom
lanshuyue:fix-dftu-onsite-output-format

Conversation

@lanshuyue

Copy link
Copy Markdown
Collaborator

Problem

write_occup_m() currently writes DFT+U occupation-matrix labels and integer values without whitespace separation:

Atom=1 L=2 ORBITAL=0
spin=1

However, read_occup_m() uses whitespace-delimited stream extraction and expects the labels and values as separate tokens:

Atom= 1 L= 2 ORBITAL= 0
spin= 1

As a result, the DFT+U band workflow cannot read the dm_onsite.txt generated by the preceding SCF calculation and fails with:

WRONG IN READING LOCAL OCCUPATION NUMBER MATRIX FROM Plus_U FILE

The regression context is fa14bddd5666ba254b02d3cbc2c83a4db6b3bb98 (DFT+U Refactor (#7538)).

Fix

This adds the missing whitespace separator between the labels and their integer values in write_occup_m().

No reader logic is changed.
No DFT+U numerical behavior is changed.
No occupation matrix values are changed.
No INPUT behavior is changed.

Validation

  • Reproduced the failure using the existing NiO DFT+U SCF -> band workflow.

  • Confirmed that the original writer generated compact tokens such as Atom=1 and spin=1.

  • Confirmed that adding whitespace after = alone allowed the existing reader to complete the band calculation.

  • Confirmed that source/source_lcao/module_dftu/dftu_io.cpp has no writer/reader diff from v3.11.0-beta8 to current upstream/develop.

  • Rebuilt beta8-equivalent DFT+U code after applying this writer fix.

  • Confirmed that SCF now generates the expected whitespace-separated labels and values automatically:

    Atom= 1 L= 2 ORBITAL= 0
    spin= 1
    
  • Used the newly generated dm_onsite.txt directly, without manual modification.

  • Confirmed that the subsequent band calculation completed and produced bands1.txt and bands2.txt.

Automated regression test added: no.
Runtime reproduction/validation: yes.

Note: the current upstream/develop full local Intel build is blocked on this workstation by an unrelated LR compile error in source/source_lcao/module_lr/utils/exciton_plotter.cpp. Runtime validation was therefore performed with the beta8-based validation worktree, whose dftu_io.cpp writer/reader code is unchanged from current upstream/develop before this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant