Skip to content

[Question] P atoms receive zero Bader basin from out_chg cube with NC pseudopotential and NLCC #8220

Open

Description

@jiazexiao200525-del

Details

Details

I am performing Bader analysis on ABACUS charge-density cube files for a Li-rich layered oxide/Li3PO4 heterojunction. After merging the spin-up and spin-down charge densities, Henkelman Bader 1.05 assigns all P atoms in the Li3PO4 part to 0 electrons and 0 volume.

I would like to confirm whether this is expected for the charge density exported by out_chg, and what workflow ABACUS recommends for obtaining a core-corrected or all-electron density for per-atom Bader analysis.

Current setup

  • ABACUS: v3.10.1 (LTS)
  • Basis: lcao
  • Exchange-correlation functional: PBE
  • Spin: nspin = 2
  • Charge-density output: out_chg = 1
  • P pseudopotential: P.PD04.PBE.UPF
  • P pseudopotential header:
pseudo_type="NC"
is_paw="F"
core_correction="T"
z_valence="5.00"

The UPF contains PP_NLCC and PP_RHOATOM sections.

The charge-density grid is 480 × 125 × 216, and the cube density is in e/Bohr^3.

Reproduction steps

  1. Run ABACUS SCF with nspin = 2 and out_chg = 1.
  2. Obtain SPIN1_CHG.cube and SPIN2_CHG.cube.
  3. Merge the two spin channels pointwise.
  4. Run Henkelman Bader 1.05 on the merged cube.
  5. Read the atomic populations from ACF.dat.

The procedure follows the Bader workflow in ABACUS-agent-tools bader.py.

Observed result

System Number of atoms Empty atomic basins
Complete heterojunction 192 P atoms 181–192: 0 electrons, 0 volume
Frozen oxide fragment 97 None
Frozen Li3PO4 fragment 95 P atoms 84–95: 0 electrons, 0 volume

For the complete heterojunction:

Integrated density:    1131.0051225 e
Assigned Bader charge: 1131.0051140 e

The total electron conservation is therefore valid. The empty P basins are reproduced by both neargrid and ongrid modes. The same behavior in the frozen Li3PO4 fragment shows that it is not caused only by the interface.

Interpretation concern

The CUBE atom records contain a reference value of 5 for P. The post-processing convention in bader.py computes:

net_bader_charge = cube_atom_reference_charge - ACF_bader_electrons

For an empty P basin this gives 5 - 0 = +5 e. I do not interpret this as a physical P chemical charge. It appears to result from using a pseudopotential valence density whose topology has no Bader basin at the P sites.

Questions

  1. Is SPIN*_CHG.cube from out_chg expected to contain only the self-consistent pseudopotential valence density, rather than an all-electron or core-reconstructed density?
  2. Does ABACUS provide a documented parameter or post-processing tool to export the core-correction density or a reconstructed all-electron density on the same real-space grid for Bader analysis?
  3. If PP_NLCC and PP_RHOATOM are used internally, is there a supported method to reconstruct their contribution into a compatible CUBE file?
  4. Is an empty Bader basin for P expected or known for this norm-conserving P pseudopotential?
  5. What workflow does the ABACUS team recommend for quantitative per-atom Bader charges in P-containing systems?

Attached evidence

I attached a compact evidence bundle containing the per-atom CSV files, JSON summaries, the P pseudopotential header, and the independent Bader validation summary. The large CUBE and complete ACF.dat files can be provided if needed.

ABACUS Bader issue evidence.zip

Have you read FAQ on the online manual http://abacus.deepmodeling.com/en/latest/community/faq.html

  • Yes, I have read the FAQ part on online manual.

Task list for Issue attackers (only for developers)

  • Understand the problem or question described by the user.
  • Check if the issue is a known problem or has been addressed in the documentation.
  • Test the issue or problem on a similar system or environment, if possible.
  • Identify the root cause or provide clarification on the user's question.
  • Provide a step-by-step guide, including any necessary resources, to resolve the issue or answer the question.
  • If the issue is related to documentation, update the documentation to prevent future confusion (optional).
  • If the issue is related to code, consider implementing a fix or improvement (optional).
  • Review and incorporate any relevant feedback from users or developers.
  • Ensure the user's issue is resolved or their question is answered and close the ticket.

Activity

  1. ABACUS-PR-BOT commented on Oct 26, 2026

    @ABACUS-PR-BOT
    Collaborator

    For your v3.10.1 NC/LCAO, nspin=2 setup, the density semantics are clear; the specific cause of the empty P assignments still needs the original grids.

    1. The spin CHG cubes contain the pseudopotential valence density, without added core density. The v3.10.1 exporter writes the valence-density array, while NLCC remains separate and enters XC. NLCC can still affect the SCF valence density through XC. Add the two spin channels once to obtain total valence density. P's CUBE reference 5 is the pseudopotential valence count, not an exported core population.

    2. I found no documented core/all-electron CUBE exporter for this v3.10.1 NC workflow in the checked output parameters, source and tools. The out_chg documentation describes charge output and precision, without a reconstruction option. The inspected bader.py subtracts the Bader population from the CUBE reference; its field named core_charge does not construct or export core density. The reporter's installed helper revision remains unknown.

    3. PP_NLCC and PP_RHOATOM should not both be added as “missing core.” PP_RHOATOM initializes pseudoatomic valence density; adding it again would add another valence contribution. PP_NLCC supplies the separate NLCC model density. Their radial conventions differ: PP_RHOATOM includes 4πr², PP_NLCC does not. NLCC may be smoothed inside a core radius, so it is not a validated all-electron reconstruction. ABACUS has an internal NLCC-grid construction, but no supported standalone converter was found; simply exporting it would not reconstruct all-electron valence density.

    4. A pseudovalence-density topology problem is plausible, but these zeros are not established as an inevitable property of P.PD04.PBE.UPF. Bader 1.05 assigns each maximum's basin to its nearest atom. Thus global conservation can coexist with an atom receiving no volume; it does not validate the atomic partition or establish physical P charge +5. Your attached tables consistently contain the P zeros, but they are derived results, not original-grid verification. Inspect maxima/assignments and convergence: BCF.dat omits insignificant basins, and neargrid/ongrid agreement on one grid does not establish density-grid convergence.

    5. Quantitative charges require a validated partition and a matching charge convention. First verify the exact spin pair, grid/origin/lattice/atom ordering, SCF convergence and total electron count; use sufficient output precision (the release recommends out_chg 1 10) and converge spatial resolution and atomic populations. Precision alone cannot restore core density. If a validated compatible total-density reference becomes available, Henkelman's reference-density method supports bader valence.cube -ref validated_reference.cube: the reference defines basins, while the primary file supplies the integrated electrons. This is conditional guidance, not an identified ABACUS-supported NC all-electron pipeline. With a valence integral use q=Zval−Nv (P: 5−Nv); with a genuine all-electron integral use q=Z−N (P: 15−N). Do not mix these conventions or treat an arbitrary NLCC integral as the missing ten electrons.

    To distinguish the causes, please provide just the frozen Li3PO4 fragment initially: its original two spin cubes, complete ACF.dat and BCF.dat, Bader stdout and exact merge/Bader commands, full P.PD04.PBE.UPF, and INPUT/STRU plus the SCF log showing version, grid/cutoffs, electron count and convergence. If a helper was used, include its version/commit. A compressed archive is fine; the other two large cases are not needed initially.

    This assessment used source/document inspection and static checks of your attached tables; ABACUS and Bader were not rerun.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    QuestionsRaise your quesiton! We will answer it.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions