fleur issueshttps://iffgit.fz-juelich.de/groups/fleur/-/issues2021-06-07T09:46:21Zhttps://iffgit.fz-juelich.de/fleur/fleur/-/issues/629Different default maxIterBroyd?2021-06-07T09:46:21ZGregor MichalicekDifferent default maxIterBroyd?A rather common problem faced by users is that a system doesn't converge. In such situations it is often a solution to reduce the maxIterBroyd parameter from 99 to 15 or so. It may be a good idea to reduce the default value for that parameter to about 15. I am not aware of situations where you benefit from really large maxIterBroyd parameters. Maybe other people made other experiences. I would like to gather a few experiences here and then decide on a new default for that parameter.
It may also be a good idea to write out the mixing_history files only if explicitly asked for by the user. I sometimes have the situation that an existing mixing_history file inhibits convergence after changing a few parameters.A rather common problem faced by users is that a system doesn't converge. In such situations it is often a solution to reduce the maxIterBroyd parameter from 99 to 15 or so. It may be a good idea to reduce the default value for that parameter to about 15. I am not aware of situations where you benefit from really large maxIterBroyd parameters. Maybe other people made other experiences. I would like to gather a few experiences here and then decide on a new default for that parameter.
It may also be a good idea to write out the mixing_history files only if explicitly asked for by the user. I sometimes have the situation that an existing mixing_history file inhibits convergence after changing a few parameters.https://iffgit.fz-juelich.de/fleur/fleur/-/issues/632Speed up single test run2021-06-11T10:40:41ZJens BrĂ¶derSpeed up single test runIn general a full CI run on develop is fairly slow.
There are several ways around this:
1. Parallel run on the CI:
One can execute certain test groups with the identifier labels we use. ```pytest -m <markername>```
This one can use to split the sessions on the CI.
like
```
pytest -m inpgen
pytest -m fleur,serial
pytest -m fleur,mpi
```
If we do this nice, it may also be easier to see where problem lie.
Drawback, we end up with several test reports, instead of one.
On has to be careful about the parser tests here, because one wants to run them in all cases.
2. Speed up slowest tests.
For this on could continue on a certain state, which one can stage when developing the tests.
I.e change the input files containing some iterations already run, if they are just overhead.In general a full CI run on develop is fairly slow.
There are several ways around this:
1. Parallel run on the CI:
One can execute certain test groups with the identifier labels we use. ```pytest -m <markername>```
This one can use to split the sessions on the CI.
like
```
pytest -m inpgen
pytest -m fleur,serial
pytest -m fleur,mpi
```
If we do this nice, it may also be easier to see where problem lie.
Drawback, we end up with several test reports, instead of one.
On has to be careful about the parser tests here, because one wants to run them in all cases.
2. Speed up slowest tests.
For this on could continue on a certain state, which one can stage when developing the tests.
I.e change the input files containing some iterations already run, if they are just overhead.https://iffgit.fz-juelich.de/fleur/fleur/-/issues/640Unique eigenvectors for Wannier2021-06-28T16:40:45ZMatthias RediesUnique eigenvectors for WannierI created a testbranch https://iffgit.fz-juelich.de/fleur/fleur/-/tree/wannier_testbranch that uses the routine to unity the eigenvectors and @dgo ran a test with it:
![image](/uploads/2a37919f7eebd9cb9087412cb7920cd0/image.png)
It seems to work quite well at least in this system. Dongwook as some concerns about the wannier centers & spread, but he said he will investigate this more. I wanted to use this issue to discuss if and how we implement this. Right now I see a few issues:
1) only inversion symmetric case (should be an easy fix)
2) In some (few) systems it's very hard to find a set of linear independent rows within a group of degenerate eigenvectors. I don't understand why, but if it's the case it can ruin the numerics.
I currently have 2 theories on why this happens:
1) They are orthogonal with respect to the overlap matrix, but I am looking for orthogonality with the identity matrix
2) I assmue degeneracy where there is none (or vice versa). But even then I should find linear independent rows, right?
I can detect this, but I don't know how to solve it.
3) We need to think if we want this for ScaLAPACK & ELPA and if so we should do it in a smart way.
4) Some tests fail if I apply this. If we do it correctly it shouldn't matter.
`test_Fe_Tetra_noSYM` has a different last distance (do we care?)
and the plotting one seems to check for one very specific number.
This could be triggered by linear dependent rows in my QR matrix, which then brings errors into my unitary Q matrix, that I multiply to the eigenvectors.I created a testbranch https://iffgit.fz-juelich.de/fleur/fleur/-/tree/wannier_testbranch that uses the routine to unity the eigenvectors and @dgo ran a test with it:
![image](/uploads/2a37919f7eebd9cb9087412cb7920cd0/image.png)
It seems to work quite well at least in this system. Dongwook as some concerns about the wannier centers & spread, but he said he will investigate this more. I wanted to use this issue to discuss if and how we implement this. Right now I see a few issues:
1) only inversion symmetric case (should be an easy fix)
2) In some (few) systems it's very hard to find a set of linear independent rows within a group of degenerate eigenvectors. I don't understand why, but if it's the case it can ruin the numerics.
I currently have 2 theories on why this happens:
1) They are orthogonal with respect to the overlap matrix, but I am looking for orthogonality with the identity matrix
2) I assmue degeneracy where there is none (or vice versa). But even then I should find linear independent rows, right?
I can detect this, but I don't know how to solve it.
3) We need to think if we want this for ScaLAPACK & ELPA and if so we should do it in a smart way.
4) Some tests fail if I apply this. If we do it correctly it shouldn't matter.
`test_Fe_Tetra_noSYM` has a different last distance (do we care?)
and the plotting one seems to check for one very specific number.
This could be triggered by linear dependent rows in my QR matrix, which then brings errors into my unitary Q matrix, that I multiply to the eigenvectors.