espressomd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ESPResSo-devel] CONFIGTEMP feature


From: Florian Weik
Subject: Re: [ESPResSo-devel] CONFIGTEMP feature
Date: Mon, 4 Jul 2016 08:59:42 -0600

Hi Tristan,
thank you for your quick response and for the doc. I agree that it makes sense to implement this in the core. I still think that we should maybe find an less intrusive way to do this (e.g. not inside the pair potential as it is done for LJ).

Cheers,
Florian

On Jul 4, 2016 05:43, "Tristan Bereau" <address@hidden> wrote:
I've sent a pull request that includes documentation and a testcase
for CONFIGTEMP. I've also removed the deprecation warning.

https://github.com/espressomd/espresso/pull/725

Best,
Tristan

On Mon, Jul 4, 2016 at 8:43 AM, Tristan Bereau <address@hidden> wrote:
> Hi Rudolf,
>
> The configurational temperature was used to better identify deviations
> from sampling a proper canonical ensemble for DPD simulations with a
> too-large time step, as compared to the kinetic temperature:
>
> http://pubs.acs.org/doi/abs/10.1021/jp055119e
>
> I've used it to calibrate integration timesteps with a multimestepping
> algorithm.
>
> I'll work on the documentation.
>
> Best,
> Tristan
>
>
>
> On Mon, Jul 4, 2016 at 8:36 AM, Rudolf Weeber
> <address@hidden> wrote:
>> Hi,
>> On Mon, Jul 04, 2016 at 08:04:14AM +0200, Tristan Bereau wrote:
>>> CONFIGTEMP computes the configurational temperature of a (sub)system.
>>> It estimates the temperature from the interaction potential, rather
>>> than the more usual definition based on the kinetic energy.
>> Under what circumstances is this measure preferable to the one based on kinetic energy?
>>
>>>I've so
>>> far only implemented it for a few interaction potentials. Whether you
>>> want to have this feature in ESPResSo is something I let you decide,
>>> but I don't think it would be easy to implement without accessing the
>>> core, since it relies on force derivatives. If you wish to keep it in,
>>> I'm happy to provide documentation, otherwise we can remove the 1 or 2
>>> relevant git commits. Let me know.
>> I don't see an urgent reason for removal.
>> As the code has to be run in the loop over all particle pairs, separating it from the force calculation would at this point result in much more code, as the pair generation loop would have to be replicated.
>> This would be different if/once the pair generation loops are templated.
>>
>> Regards, Rudolf


reply via email to

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