[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ESPResSo-devel] Helfand moments
From: |
Axel Arnold |
Subject: |
Re: [ESPResSo-devel] Helfand moments |
Date: |
Wed, 28 Aug 2013 23:00:33 +0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 |
Hi Josh,
yes, that would be interesting to integrate (ifdef'd, of course).
Although, I want to add some warning: I encountered EH-fits in another
context (dielectric constant/conductivity). The fits look indeed much
better that the current-current autocorrelation. But it turns out that
in fact both approaches need equally loooooong trajectories, just that
EH-fits hide this fact much better. Therefore, I consider them a bit
dangerous (or misleading).
Axel
On 28.08.13 13:56, Josh Berryman wrote:
Hello everyone,
I've made a crude patch to the function add_nonbonded_pair_virials()
to calculate Helfand moments (sometimes called Einstein-Kubo-Helfand
moments).
This is basically a slight adition to the stress tensor which allows
direct calculation of shear viscosities in the form:
\eta \propto <G^2>
by analogy with the usual method for calculating diffusion constants
D \propto <x^2>. I've been working from Erpenbeck PRE 1995 for the
formula, and validating my answers against Meier et al. JCP 2004.
Espresso already provides a means to find the shear viscosity, of
course, using a Green-Kubo method starting from the stress-tensor
autocorrelation function, but this is quite a messy and difficult
calculation, given the tendency of the acf to quite often have a long
and noisy tail.
EKH doesn't seem to be any cheaper than GK, but it is simpler for the
user: there is less onus to e.g. fit something to the acf and
integrate the fitted function. (Or for that matter to notice in the
Espresso docs that online acfs are available).
The disadvantage is that it needs information from the verlet
nonbonded force calculation, including the *un-imaged* particle
coordinates, as well as the force and the imaged pairwise distance.
I've been using the function
get_particle_data(p1->p.identity, &pp1);
to retrieve the un-imaged coordinates, however this of course
introduces a performance and scaling penalty, meaning that the
functionality will have to be hash-deffed out by default if it is
integrated with the main build.
Is there any interest in having this? Shall I create a branch and add
it in?
Josh
--
JP Dr. Axel Arnold
ICP, Universität Stuttgart
Allmandring 3
70569 Stuttgart, Germany
Email: address@hidden
Tel: +49 711 685 67609