Possible inconsistent behavior of nupdown = 0.0 and omitted nupdown in nspin=2 FM calculation

[stellariums]

Describe the bug

Description

I observed a possible inconsistency in the behavior of nupdown = 0.0 and an omitted nupdown keyword in an nspin = 2 calculation.

According to the documentation in https://abacus.deepmodeling.com/, nupdown = 0.0 should mean no constraint on the total magnetization. However, in my calculations, explicitly setting

nupdown 0.0000

seems to force the total magnetization TMAG to remain very close to zero.

In contrast, when I completely remove or comment out the nupdown line, the same FM initial structure gives a clearly non-zero TMAG, and the calculation starts to evolve toward a ferromagnetic-like state.

This suggests that, at least in my ABACUS version, explicitly setting nupdown = 0.0 may not be equivalent to omitting nupdown.

---

ABACUS Version

ABACUS v3.10.1

System：

RUNNING WITH DEVICE  : GPU / NVIDIA GeForce RTX 4090

---

##System

Calculation type:

calculation scf
basis_type lcao
nspin 2

The structure is a phonopy-displaced supercell generated from a cell-relaxed FM structure. It contains 32 A atoms and 32 B atoms.

The initial magnetic moments in STRU are ferromagnetic-like. For example:

A atoms: mag 1.4993
B atoms: mag -0.1214

The estimated initial total magnetic moment is approximately:

32 × 1.4993 + 32 × (-0.1214) ≈ 44.1 μB

---

Case A: Explicit nupdown 0.0000

INPUT ：

nspin 2
nupdown 0.0000

The calculation repeatedly gives TMAG very close to zero, even though the initial magnetic moments in STRU are ferromagnetic-like.

log:

 ITER      TMAG       AMAG        ETOT/eV          EDIFF/eV         DRHO     TIME/s
 CU1      4.69e-09   4.04e+00  -4.41838278e+05   0.00000000e+00   9.2146e-02 731.30
 CU2     -1.69e-08   3.12e+00  -4.41750654e+05   8.76233279e+01   5.9333e-02 169.95
 CU3     -2.45e-09   8.54e-01  -4.41797134e+05  -4.64793260e+01   1.7658e-02 169.98
 CU4     -2.85e-09   6.81e-01  -4.41792740e+05   4.39402921e+00   3.1401e-02 169.79
 CU5     -2.50e-09   5.72e-01  -4.41796243e+05  -3.50296308e+00   1.8181e-02 169.92
 CU6     -8.10e-10   2.19e-01  -4.41791612e+05   4.63056977e+00   3.0570e-02 169.83

At the same time, AMAG is still relatively large, which suggests that local magnetic moments exist but the total magnetization is constrained or driven to zero.

TMAG ≈ 0
AMAG relatively large

This looks as if the calculation is effectively constrained to

N_up - N_down = 0

---

Case B: Omitted nupdown

In this case, I completely removed the nupdown：

nspin 2
# nupdown 0.0000

With the same initial FM-like STRU, the total magnetization no longer stays close to zero.

Example output:

ITER      TMAG       AMAG        ETOT/eV          EDIFF/eV         DRHO     TIME/s
CU1      1.73e+01   1.96e+01  -4.41841170e+05   0.00000000e+00   8.7514e-02 890.29
CU2      2.47e+01   2.70e+01  -4.41764492e+05   7.66788075e+01   5.6249e-02  28.64
CU3      3.10e+01   3.37e+01  -4.41796317e+05  -3.18259727e+01   2.4120e-02  28.45
CU4      2.81e+01   3.09e+01  -4.41793528e+05   2.78951759e+00   3.4271e-02  28.41
CU5      3.19e+01   3.49e+01  -4.41799794e+05  -6.26563909e+00   2.1176e-02  28.44
CU6      3.19e+01   3.50e+01  -4.41799378e+05   4.15313271e-01   1.7102e-02  28.45
CU7      3.26e+01   3.61e+01  -4.41798551e+05   8.27480924e-01   1.5823e-02  28.47

This behavior is much more consistent with a free spin-polarized FM calculation.

---

Charge Initialization

In both cases, the calculation used atomic initialization because ABACUS failed to read charge density from file.

The log contains:

START CHARGE      : auto

WARNING: "init_chg" is enabled but ABACUS failed to read charge density from file.
Please check if there is SPINX_CHG.cube (X=1,...) or {suffix}-CHARGE-DENSITY.restart in the directory.
Charge::init_rho: use atomic initialization instead.

---

Minimal Relevant INPUT Parameters

basis_type      lcao
calculation     scf
nspin           2

smearing_method mp2
smearing_sigma  0.01

mixing_type     pulay
mixing_beta     0.10

scf_thr         1.0e-6
scf_nmax        300

cal_force       1
cal_stress      0

init_chg        auto
out_mul         1

The only tested difference is:

nupdown 0.0000

versus omitting the nupdown line.

#nupdown 0.0000

---

##Question

Could this be a bug in the handling of nupdown = 0.0 for nspin = 2 calculations in ABACUS v3.10.1?

If the current behavior is intended, could the documentation clarify the difference between explicitly setting nupdown = 0.0 and omitting nupdown?

Thank you very much！

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