Open ExpHP opened 5 years ago
I believe this affects all data of sufficiently small unit cells that used the rsp2 disp-finder, ever, unless phonons.supercell
was used. (and I haven't used it in a long time!)
When I switched the unit tests to stop using phonopy, I think some of the frequencies changed by about 0.02 eV. I assumed it was a chaotic effect from relaxing into a different state, but in hindsight that makes no sense (the Nope, that's not related because that test was already giving phonopy a supercell of simple
tests don't relax along eigenvectors). That change was probably due to this bug.target: [0,0,0]
.
Evidence:
function() run {
cargo run --release --bin=rsp2 -- \
-c ../tests/resources/defaults.yaml \
-c ../tests/resources/simple.yaml \
../tests/resources/simple.vasp \
"$@"
}
run -c 'phonons.supercell.~~REPLACE~~.target:[0,0,0]' -o out-1
run -c 'phonons.supercell.~~REPLACE~~.target:[35,35,35]' -o out-2
run -c 'phonons.supercell.~~REPLACE~~.target:[70,70,70]' -o out-3
out-1/eigenvalues.final
# (C) Frequency(cm-1) Acou RamnA RamnB X Y Z
(T) 0.00007573708821266394 1.00 2e-23 2e-23 0.00 0.00 1.00
(T) 0.00027612600568365224 1.00 2e-25 2e-25 0.00 1.00 0.00
(T) 0.0002770808164830437 1.00 3e-25 3e-25 1.00 0.00 0.00
(-) 19.726084222003376 0.00 5e-5 5e-5 0.31 0.69 0.00
(-) 19.72608422200816 0.00 5e-5 5e-5 0.69 0.31 0.00
(-) 84.07792977084624 0.00 1e-7 1e-7 0.00 0.00 1.00
(-) 963.3600027716088 0.00 3e-27 2e-27 0.00 0.00 1.00
(-) 967.560958064369 0.00 2e-4 1e-4 0.00 0.00 1.00
(-) 1667.0423926213853 0.00 1e0 1e0 0.00 1.00 0.00
(-) 1667.0423926213869 0.00 1e0 1e0 1.00 0.00 0.00
(-) 1667.6776661642089 0.00 8e-25 7e-25 0.00 1.00 0.00
(-) 1667.6776661642095 0.00 1e-26 1e-26 1.00 0.00 0.00
out-2/eigenvalues.final
# (C) Frequency(cm-1) Acou RamnA RamnB X Y Z
(T) -0.000033616796776970064 1.00 0 0 0.00 0.00 1.00
(T) 0.00044366861095801127 1.00 1e-24 1e-24 0.00 1.00 0.00
(T) 0.000444724812062967 1.00 6e-26 5e-26 1.00 0.00 0.00
(-) 19.71801444586797 0.00 5e-5 5e-5 0.01 0.99 0.00
(-) 19.7180144458915 0.00 5e-5 5e-5 0.99 0.01 0.00
(-) 84.1209627770934 0.00 1e-7 1e-7 0.00 0.00 1.00
(-) 963.3618866402196 0.00 3e-27 2e-27 0.00 0.00 1.00
(-) 967.5628372822749 0.00 2e-4 1e-4 0.00 0.00 1.00
(-) 1666.9925961079614 0.00 1e0 1e0 0.00 1.00 0.00
(-) 1666.9925961079623 0.00 1e0 1e0 1.00 0.00 0.00
(-) 1667.627888125847 0.00 1e-24 9e-25 0.00 1.00 0.00
(-) 1667.6278881258481 0.00 4e-26 4e-26 1.00 0.00 0.00
out-3/eigenvalues.final
# (C) Frequency(cm-1) Acou RamnA RamnB X Y Z
(T) 0.00004174824200528189 1.00 4e-24 4e-24 0.00 0.00 1.00
(T) 0.00019640518291168715 1.00 1e-23 1e-23 0.01 0.99 0.00
(T) 0.0001972130445849585 1.00 2e-24 2e-24 0.99 0.01 0.00
(-) 19.718014446684876 0.00 5e-5 5e-5 0.00 1.00 0.00
(-) 19.71801444669673 0.00 5e-5 5e-5 1.00 0.00 0.00
(-) 84.12096277714397 0.00 1e-7 1e-7 0.00 0.00 1.00
(-) 963.3618866402364 0.00 3e-27 2e-27 0.00 0.00 1.00
(-) 967.5628372822955 0.00 2e-4 1e-4 0.00 0.00 1.00
(-) 1666.9925961183683 0.00 1e0 1e0 0.00 1.00 0.00
(-) 1666.9925961183687 0.00 1e0 1e0 1.00 0.00 0.00
(-) 1667.6278881362914 0.00 7e-25 6e-25 0.00 1.00 0.00
(-) 1667.627888136292 0.00 9e-27 9e-27 1.00 0.00 0.00
out-1
and out-2
match up to only 3 sig figs, but out-2
and out-3
match up to about 10 sig figs. This indicates that out-1
is affected by the movement of periodic images.
Okay, so this is not high priority because you can fix it with phonons.supercell
. (Good thing I didn't remove that!)
It is not a bug in the code because there's no way to work around the supercell requirement for lammps and DFTB+.
It is however a bug in the documentation. The documentation needs to be fixed so that it no longer claims that gamma point does not require a supercell.
Okay, I fixed all the mentions I could find in the documentation and comments, but this one's a puzzler:
How is that check succeeding with such a small tolerance? How on earth did I even generate those force constants files, anyways?
I don't know how on earth something like this slipped by, but upon reviewing the code I have a very hard time seeing how
DefaultDispFn
is correct for small unit cells.As far as I can tell, the current implementation will displace all images of an atom!
This is...very not cool.