Hi Alberto,
thank you for the detailed clarification.
I don't know whether there's a universal convention which energy to pass
to a socket. I know that FHI-Aims sends the free energy, and that i-PI
is designed to be agnostic about the "force codes" it uses. I-PI uses
DFT codes as well as forcefields, and, I think, it always assumes that
the forces are consistent with the energy landscape. Though I cannot
right now name any algorithm inside i-PI that would be broken completely
because of such inconsistency, it makes life harder if one wants to
analyze e.g. energy conservation along an NVE trajectory. I discussed
this issue with the core developers of i-PI, and they prefer to receive
free energy.
But, since the same socket protocol is used by ASE and, potentially,
many other projects, and since it was E_tot for a long time, I see the
point of having E_tot in some cases, so, introducing a flag in Siesta
would be a compromise and backward-compatible solution. Say,
Master.EnergyKind.
I can create an issue on Gitlab to discuss it further.
Best regards,
Karen Fidanyan
PhD student
Max Planck Institute for the Structure and Dynamics of Matter
Hamburg, Germany
On 11/10/21 9:45 AM, Alberto Garcia wrote:
Hi, Karen,
There are several facets in this issue:
* When a finite temperature (smearing) is used just for convergence
acceleration, the free energy is a
computational artifact that is formally needed to restore the variational
property. Tests for the size of the smearing and
for the fineness of the k-point grid should be carried out to monitor the
convergence.
* A given client code might be interested, rather than in the free energy, in
the zero-temperature (extrapolation to zero-smearing) E_tot, rather than in the
free energy. Depending on the type of smearing, E_tot and E_free deviate from
each other: the difference is quadratic in the smearing for Fermi-Dirac
smearing, but much smaller for Methfessel-Paxton or for the cold-smearing of
Marzari and Vanderbilt. (See the article by Kresse and Furthmuller [1])
* There is only one slot for the energy in the i-PI protocol specification, and
it is not clear what that energy should be.
Depending on your use case, you might want to use MP or cold smearing. There
could also be an enhancement of the i-PI protocol to negotiate the kind of
'energy' to be sent. Maybe an fdf flag in Siesta could be used to select what
is sent through the interface. What do other codes send through the interface?
Best regards,
Alberto
[1] Kresse, G., and J. Furthmüller. 1996. “Efficiency of Ab-Initio Total Energy
Calculations for Metals and Semiconductors Using a Plane-Wave Basis Set.”
Computational Materials Science 6 (1): 15–50.
https://doi.org/10.1016/0927-0256(96)00008-0.
----- El 2 de Noviembre de 2021, a las 22:22, Karen Fidanyan
karen.fidan...@mpsd.mpg.de escribió:
| Dear Siesta users,
|
| I noticed that when communicating with a Master code, e.g. via i-PI
| socket, the values that would be sent to a socket are
| the forces and the _total_ energy, not the _free_ energy, even though I
| use Fermi-Dirac smearing.
| At the same time, in the manual I read: "We finally note that, in both
| cases (Fermi-Dirac and Methfessel-Paxton), once a finite temperature has
| been chosen, the relevant energy is not the Kohn-Sham energy, but the
| Free energy. In particular, the atomic forces are derivatives of the
| Free energy, not the KS energy."
| This means, to my understanding, that a client code receives an energy
| and forces that are inconsistent to each other, and the energy is
| somewhat ill-defined. Do you know why such choice was made? Is there any
| problem with sending the free energy?
|
| Many thanks,
| Karen Fidanyan
| PhD student
| Max Planck Institute for the Structure and Dynamics of Matter
| Hamburg, Germany
|
|
|
| --
| SIESTA is supported by the Spanish Research Agency (AEI) and by the European
| H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
--
SIESTA is supported by the Spanish Research Agency (AEI) and by the European
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
