Output of DOS and PDOS for noncollinear and spin-orbit coupling do not give the expected result

Bug #1645749 reported by Roberto Robles
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Siesta
Fix Released
Undecided
Unassigned
4.1
Fix Released
High
Nick Papior

Bug Description

This bug affects all current versions as far as I know.

When asking for DOS and PDOS in noncollinear and spin-orbit calculations four components are expected. In the current implementation they are: (spin up projected along z), (same for spin down),
(spin in x), (spin in y).

1.- In the file <system>.PDOS the two last components are missing.

2.- The last two components are now the spin along x and y. It would be more consistent if they were the magnetization (factor 2).

Both things require a tiny modification of pdos.F and have been changed in revision 576 of branch trunk-RRR.

In addition a different output could be considered, which I find more consistent. The first two components could be rearranged so the final result is:
total charge, magnetization in x, y and z.
(total charge = spin up + spin down along z), (mz = spin up - spin down).

That would emphasize that in noncollinear or spin-orbit calculations spin up and spin down only make sense referred to a particular axis.

In any case the chosen output has to be documented in the manual.

In addition, the calculation of DOS and PDOS only works in serial. In parallel they are not calculated as controlled in subroutine init_projected_DOS of projected_DOS.F. However, the relevant routines (pdos2g, pdos2k, pdos3g, pdos3k) seem to consider a parallel run, but they give wrong results in their current form. For example, pdos3g gives correct results for the first two components, but wrong results for third and fourth (tested with the Pt2 example with magnetization oriented along x or y). It would be nice to do everything in parallel. For example, sometimes a finer grid of K-points is needed for smooth DOS, and the calculations can take quite some time.

Revision history for this message
Nick Papior (nickpapior) wrote :

This has now been partially fixed in 4-1, r629 (will enter trunk on next merge), point 1 and 2. The parallel run is still not fixed.

Nick Papior (nickpapior)
Changed in siesta:
status: New → Fix Committed
Nick Papior (nickpapior)
Changed in siesta:
milestone: none → 4.1-b3
Nick Papior (nickpapior)
Changed in siesta:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.