[Wien] Bad optimizations with MSR1a for non-centrosymmetric cases

[Laurence Marks]

There is an algorithmic error in MSR1a that effects release 14. Non
centro-symmetric cases may converge poorly or not at all, and fixing an
atom may not help. This is associated with an addition I made to try and
avoid the atoms drifting across the cell which may fail.

Two, equivalent patches can be used:
a) A "soft" patch is to add the word "DRIFT" at the bottom of case.inm
b) A "hard" patch is to change in GetOpts.f the variable "NoDrift" to
false, e.g. in line 32 have
       NoDrift  =.false.

Caveat. In rare cases it may happen that the contents of the unit cell will
drift along one or more axes, because there is nothing to fix the origin
along it. In that case I suggest editing by hand case.inM to fix the
relevant atom displacement by changing a 1.0 to 0.0. For instance, to fix
the z-component of atom 1 (if there is no inversion symmetry along z) the
first line of case.inM would be changed from

1.0 1.0 1.0 1.0   #Atom    1 Generated by pairhess

to

1.0 1.0 0.0 1.0   #Atom    1 Generated by pairhess

N.B., in many cases this may not be an issue. If you are concerned that
your calculation did not properly converge check the forces at the end of
case.scf or case.scfm.

N.N.B., the technical explanation is that with the trap that was introduced
the algorithm can converge to a spurious fixed-point solution cwhere all
the forces are the same (along the unfixed direction), and :FCHECK is large.


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: MURI4D.numis.northwestern.edu
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20150421/7c31fecb/attachment.html>