Added an option to disable it. In general, since real_space routines are "high level", that is, they involve
many operations, their precision is rather low (best zero ~ 1e-11 ). Anyone employing chain algorithms
should pay extra attention to drift caused by them. I am more than welcome to any contribution that will
improve accuracy without comprimising performance too much.
2) Some routines that I have used for testing is removed from realus. This module is getting huge...
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6326 c92efa57-630b-4861-b058-cf58834340f0
I have splitted them and collected all in a module. Usual calls to newd is not changed, apart from necessity
to include the module, newq is the part I use for calculating response charge density.
2) Some gamma only additions to PH/dv_of_drho.f90 proved to be unnecessary, removing. I am still trying to
find an efficient/minimal impact way to cast this subroutine to use real instead of complex input.
As usual, I have tested before posting, however be sure to check before in your applications.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6322 c92efa57-630b-4861-b058-cf58834340f0
sense. All kind of funny problems can result otherwise. Problem noticed by
Lorenzo. Maybe a similar check should also be added after calculation of the
small group of q in the phonon code, just in case.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6310 c92efa57-630b-4861-b058-cf58834340f0
(large system have seldom symmetries) and not a big effort either (but
the variable-cell case was really nasty, due to the loss of G-vector
ordering). Currently the new routines are hidden into module symme and
called by wrappers that make it simple to revert to the old algorithm.
It works for all examples in tests/ in both serial and parallel execution,
but needs real-life testing. In the noncolinear case the results seem to
be invariant with respect to usage of S or S^-1 to rotate the magnetization,
so more testing (or a more reliable theory) is needed.
For the time being, it works only for PW and (untested) PP. PHonon etc
still use the old-fashioned real-space symmetrization.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6261 c92efa57-630b-4861-b058-cf58834340f0
Symmetrization of the charge density for the gamma_only case is no longer
performed (it is not needed). Symmetrization of forces and stresses is
still performed to prevent loss of symmetry during structural optimization.
Minor numerical differences may follow, but I haven't noticed any nasty
side effects
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6257 c92efa57-630b-4861-b058-cf58834340f0
think there will be any side effects, but in case, it is easy to revert to
the previous case (by just removing a "go to"). In principle, symmetrization
of the charge density is needed only if we have k-points in the BZ that are
not in the IBZ. Symmetrization of forces and stresses is still there, because
it ensures the correct symmetry.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6256 c92efa57-630b-4861-b058-cf58834340f0
subroutines which basically do the same with only slight modifications. However, this requires some technical
touches to PWSCF. I am trying to keep this organic and minimal-impact since QE still lacks a SDE.
I will be adding the changes gradually as the tests complete.
In this part I add rho as a explictly read variable in addusdens, since it is used for "response charge densit
y"
not the "ground state density" in TDDFPT code. PWSCF tests show no impact. Please check.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6249 c92efa57-630b-4861-b058-cf58834340f0
output. Nothing nasty happens, but the determinant, which is calculated for
3x3 matrices only, will be incorrect. Not a big deal, since it is never used,
but an input matrix with large coefficients can result in a bogus error message.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6227 c92efa57-630b-4861-b058-cf58834340f0
Aschauer, to prevent problems on Lustre filesystem (whatever it is). It
should be harmless on all machines. Maybe it would be a good idea not to
read the same PP file from all processors, though.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6212 c92efa57-630b-4861-b058-cf58834340f0
modify the output organization. Otherwise after calling this routine
the images cannot write any more in their output files. Please check.
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6202 c92efa57-630b-4861-b058-cf58834340f0
(seems to me a more appropriate place tahn Modules/). Minor cleanup: two
variables, one for CP and one for PW, with the same meaning and equally
misleading names (atomic_positions and tau_units) merged into one with
a more descriptive name (tau_format)
git-svn-id: http://qeforge.qe-forge.org/svn/q-e/trunk/espresso@6165 c92efa57-630b-4861-b058-cf58834340f0
dalcorso