[Top][All Lists]

[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).


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?


JP Dr. Axel Arnold
ICP, Universit├Ąt Stuttgart
Allmandring 3
70569 Stuttgart, Germany
Email: address@hidden
Tel: +49 711 685 67609

reply via email to

[Prev in Thread] Current Thread [Next in Thread]