Hi Tobias,
Thanks for your interest in TAMkin. I'm going to reply below between
your questions and comments to keep things overseeable.
On 11/03/2015 04:19 PM, Tobias Kraemer wrote:
> Dear all,
>
> I have started using the TAMkin software ((latest stable release
> 1.0.5) recently, in order to calculate thermochemistry data (in
> particular Gibbs Free Energies) from CP2K output. To begin with I have
> looked at some easy examples such as H2O molecule in order to
> familiarise myself with the protocols. I have used output from both
> Gaussian03 and CP2K (2.5.1). For the G03 output of a water molecule in
> gas phase I find pretty good agreement between TAMkin and Gaussian
> thermochemistry, and I attribute the small differences (~0.001 kJ/mol
> or J/mol*K depending on the quantity) to the use of perhaps slightly
> different conversion factors (ideally I would expect that there aren't
> any differences at all). I have attached my input file for the run,
> but I think this is fairly straightforward.
Well, this is exact reproduction of output from other codes is not as
easy as it seems. Physical constants and masses of elements are updated
every now and then to reflect results from recent more accurate
measurements. Different programs take these constants from different
sources with variable quality and age. Some codes even refuse to keep
their numbers up-to-date with latest publications just to maintain
backward compatibility. To solve this issue to some extent in TAMkin, we
try to read in atomic masses from the output files where possible. Even
that is not perfect as most codes don't bother to print them out in
sufficient precision.
> Now, with the CP2K output I have more trouble, and this is just meant
> to be the easy case. I struggle to make this work, and some of the
> output puzzles me. I am listing these problems/questions in the
> following. I have optimised the structure, performed a vibrational
> analysis and did a energy+force calculation as described in the manual
> (inputs and outputs are attached).
In general, vibrational calculations from periodic calculations (except
for the Crystal program) are always a little problematic. Nearly all
periodic codes suffer from the eggbox effect, which also results in
noise in the Hessian that is hard to mitigate. Also its impact on the
final results depend somewhat on how the vibrational analysis is done
exactly.
>
> (1) with nma = NMA(molecule, ConstrainExt()) tamkin complains about
> the rmsd of the gradient, so I reduced it to 0.01, which then works.
> How much error is introduced by relaxing the threshold? I would assume
> that the CP2K-optimized structure is perfectly fine to use, since I
> have used already somewhat tighter than default values (MAX_FORCE
> 1*10-4 Eh*bohr-1).
The threshold is just introduced for a sanity check, it does not really
affect the end result. This sanity check is introduced because the
removal of external degrees of freedom from a not-very-equilibrium
Hessian is not reliable. It is just a reminder that you have to do a
better job on the geometry optimization to get decent results. So, try
to further refine the geometry.
>
> (2) the TAMkin output from this run reports somewhat different wave
> numbers for the 3 normal modes than in the cp2k file.
> CP2K: 1604.378487 3657.348123 3760.361618 cm-1
> TAMkin 56.4 90.2 1604.3 3657.3 3760.3 cm-1 plus one
> imaginary frequency of i10.1 cm-1
>
> I don't know where these extra numbers come from, but I certainly
> don't think this is right.
CP2K removed also the rotational degrees of freedom from the Hessian,
while the TAMkin result still includes them. Note that these three extra
numbers should be zero. They aren't due to a mixture of probably the
following three reasons:
1) eggbox effect.
2) incomplete geometry optimization.
3) interactions between periodic images or box boundaries. (Your box is
big enough, so this is probably a minor effect.)
>
> (3) When I include ExtRot() in pf = PartFun(nma, [ExtTrans(),
> ExtRot()]) I get this error:
> ValueError: rotational: There is no external rotation in periodic systems.
>
> I have done the calculation with the molecule-in-a-box approach, hence
> the system shouldn't be periodical.
The current TAMkin version assumes that the systems read from CP2K
output are always periodic. You can manually override this, as you can
see in the code:
https://github.com/molmod/tamkin/blob/master/tamkin/io/cp2k.py#L49
It is possible to deduce from the CP2K output whether the system is
periodic. We should improve TAMkin to actually use that information.
Anyway, if you set is_periodic=True, you can remove the rotational
degrees of freedom from the Hessian in TAMkin. Still, you should also
get reasonable results without it (i.e. with 6 almost zero frequencies
for the external degrees of freedom). If not, the geometry and Hessian
are not of sufficient quality.
> (4) ultimately I am after some bigger systems (molecular crystals of
> an organometallic species, ~600 atoms in unit cell), for which I want
> to calculate a reaction profile and report Free Gibbs Energies. The
> reaction involves some species present in the crystal (a rhodium
> complex) and hydrogen gas. Initially free, hydrogen then binds to the
> Rh centre and everything from there is standard organometallic
> chemistry. So I would need to know how to treat this system in the
> appropriate manner with CP2K/Tamkin. Basically I have located most of
> the minima and transition states along the pathway, but what is needed
> at this stage are Free Energies for all species which I hope to obtain
> from TAMkin.
First, you have to double check if the harmonic approximation is
sensible for this system. Then make sure you have very good geometries
and also make sure your SCF convergence is good enough for both the
geometry and the Hessian calculations. A mediocre SCF convergence can
severely affect the results. The Hessian in CP2K is computed with finite
differences, which magnifies the errors due to a poorly converged SCF.
First, forces are more sensitive to SCF convergence than the energy.
Second, for the computation of the Hessian, the difference between two
very similar forces is computed and divided by a small number. You
really need to know and control these errors before doing production
calculations. Similarly, you should also be careful with the eggbox problem.
>
> If anyone could give me some advice how I can generate the correct
> CP2K output / TAMkin input for a solid state system (periodic) and
> Hydrogen gas I would be very grateful. Perhaps someone can comment on
> some of the special settings needed for CP2K, e.g. I run the CP2K
> frequencies with FULLY PERIODIC FALSE for non-periodic systems.
For isolated systems, it should be set to True in principle. However, it
does not affect the Hessian that is computed in CP2K and read by TAMkin.
So this setting does actually not affect results obtained with TAMkin
afterwards.
My main advice is to control numerical errors in CP2K. Make sure you
understand all the flags set in the input file. If some aspects are
unclear, please ask, or consider visiting our group in Ghent. I don't
have template input files for CP2K that will guarantee reliable results.
(I'm not even sure if such general templates can be made. The ideal
settings may be system dependent.)
>
> I am happy to provide more information if needed, I think at this
> stage I would need some better idea how to get started, since even
> such a simple system as water causes some problems. In the meantime I
> will continue to try for myself, but I want to avoid introducing some
> bad errors.
>
OK. Try to use my advise above for the water test case and see how much
that helps. If you have remaining problems, either for water or for your
system of interest, feel free to get back in touch. It would be nice if
you could share your tuned input for the water molecule.
Best Regards,
Toon