Efermi

[MIraola]

This PR deals with the Fermi-energy used to shift energy-levels. A referee pointed out that different interfaces followed different default convenctions to deal with EF, for example: in VASP's interface the default choice is EF=0, while in Abinit interface was by default parsed from WFK file.

Now, the approach is the following: In the CLI, EF can be set either to auto or to a number.

• EF set to auto: the code will try to parse it from DFT files. If it could not (it never can be for VASP, as it is not written to WAVECAR), it will be set to EF=0and a WARNING will be printed.
• EF set to a number: this value will be used for EF.
• Otherwise: the code will stop with an error message.

[MIraola]

@stepan-tsirkin @mkhorton

When I tried to rebase the branch master of my fork, in order to include the last modification in stepan-tsirkin/master, it threw me a conflict with spacegroup.py and irreptables/init.py. However, this files were up to date w.r.t. stepan-tsirkin/master, so I think that it is an issue coming from squashing the commits in some PR. Do you know which is the best way of fixing this, so that we can update the forks with rebase, rather than with merge (which generates a merge-confirmation commit that is later included in the history).

[MIraola]

Also, squashed commits of former PR are dragged in this PR, while only the last 5 commits correspond to this PR. Is there a way to leave behind those squashed commits of former PRs?

[stepan-tsirkin]

Hi Mikel, I think the best thing is not to squash any commits. It produces a lot of conflicts and problems. especially when several branches are being developed and if they mutually pull commits from each other. If you've made too small commits locally (on you computer) you may squash them locally. But not directly before merging.

[MIraola]

@stepan-tsirkin Do you think that the plane merge will fix the problem of the commits? or will repeat them in the history?

[stepan-tsirkin]

I think they will repeat. If you squash-merge, they will not appear, as I understand. If it is the only branch that is being developed now, you may squash-merge, and all future branches should be started from the master after this merge commit. But let it be the last squash merge.

Long history does not look nice, but honestly, will you ever look into it?

[MIraola]

True, I guess that no one goes through long histories. I am developing in another branch the refUC/shiftUC automatization. This branch was created from master, in the sense that I first updated my-fork/master by merging stepan/master to it and then branched my-fork/master.

Then, I squash, right?

[stepan-tsirkin]

yes, try it