Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plot spinor-valued WFs #155

Merged
merged 7 commits into from
Dec 21, 2017
Merged

plot spinor-valued WFs #155

merged 7 commits into from
Dec 21, 2017

Conversation

hjunlee
Copy link
Contributor

@hjunlee hjunlee commented Dec 21, 2017

Dear developers:

These files are for plotting spinor-valued Wannier functions.
I used them with QE v6.x and VASP v5.x and included pw2wannier90.f90 for QE v6.2.1 (I think that it can be used with QE v6.2 since there is no change in pw2wannier90.f90 between QE v6.2 and v6.2.1).
UNK files for spinor Bloch functions are formatted as follows:
format ('UNK',i5.5,'.','NC')

With these simple extension, we can plot spinor-valued WFs in three ways: total norm ("total"), norm of up-spinor WF ("up"), or norm of down-spinor WF ("down").
They are controlled by the new parameter (wannier_plot_spinor_mode);
for example, wannier_plot_spinor_mode = up
In default, total is chosen.

Sincerely,

H. Lee

Currently, Wannier90 spends the useless memory in some parts, especially in the parallel run.
For this reason, for considering systems with large number of k points and bands, it might lead to memory error.

In addition to this, there are some points in which memory is used uselessly and they are also related to the parallelisation of both core parts (wannierization and disentanglement) and post-processing parts. 
Although I have my working parallel version of Wannier90, I will make an effort to apply, if any, the difference to the already-committed version.

H. Lee
@jryates
Copy link
Member

jryates commented Dec 21, 2017

Thanks! This addresses a long standing issue. I'm going to merge it into a branch, so that I can fix a compile issue, update the manual, and run some tests

@jryates jryates changed the base branch from develop to fix_155_plot_spinor_WF December 21, 2017 21:42
@jryates jryates merged commit 102584b into wannier-developers:fix_155_plot_spinor_WF Dec 21, 2017
@jryates
Copy link
Member

jryates commented Dec 27, 2017

After running some tests it occurred to me that in the case of 'up' or 'down' it is better to write out a signed norm i.e. |phi|*sign(Re{phi}) where phi is either the up or down part of the spinor. This has the advantage that for, say, ferromagnetic iron, the WF plotted are visually very similar to the collinear ones.
I thought about having a keyword to control this behavior (signed vs not signed) but decided against this as it is trivial to ignore the sign if you don't want it.
i need to finish the documentation before making a pull request into the main branch, but any thoughts or suggestions welcome.

@mostofi
Copy link
Member

mostofi commented Dec 29, 2017 via email

@hjunlee
Copy link
Contributor Author

hjunlee commented Dec 29, 2017

Dear developers:

I have no objection, but I think that you had better add some comment about the possible issue in the manual.

This has the advantage that for, say, ferromagnetic iron, the WF plotted are visually very similar to the collinear ones.

I am afraid that this similarity might be specific to this case; I am not sure whether this similarity can be achieved if we wouldn't start from the good initial choice of projections and the calculation of WFs wouldn't converge well.

I think that in general we need an additional step like that described in your paper (https://journals.aps.org/prb/abstract/10.1103/PhysRevB.74.195118) if we want to give the phase of spinor-valued WFs some physical meaning.

Also, I think that for materials with non-collinear magnetism, it is nontrivial to give the phase of spinor-valued WFs physical meaning.

Sincerely,

Hyungjun Lee

@hjunlee hjunlee deleted the hjunlee-w90-2 branch November 16, 2018 12:42
manxkim pushed a commit to manxkim/wannier90 that referenced this pull request Jan 10, 2021
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.

3 participants