[Top][All Lists]

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

Re: [ESPResSo-users] Force scaling wrong

From: Joost de Graaf
Subject: Re: [ESPResSo-users] Force scaling wrong
Date: Sun, 1 Mar 2015 11:29:39 +0100

Hi Stefan,

But that's exactly what I want. I am analyzing the trajectories of rod-shaped microswimmers in a channel with a quiescent LB fluid; to ensure low Reynolds number, the velocities of the rods can't be too high, which translates into long production runs. If I then want to run these with condor, I need to checkpoint them and ensure that restarting a run (say mid-way) does not mess up the trajectory I have obtained. Granted, it's a rather unusual situation, but I think having the possibility to set the forces correctly remains a nice feature.

Kind Regards, Joost

On 1 March 2015 at 10:17, Stefan Kesselheim <address@hidden> wrote:
just a brief comment:
My interpretation to the "force settable" question so far was:
Why would we need settable forces, if we have settable ext_forces? I can only think of prototyping situations, but not production situations where the actual forces have to be settable.

On Feb 28, 2015, at 6:06 PM, Ulf Schiller <address@hidden> wrote:

> On 02/28/2015 12:09 PM, Joost de Graaf wrote:
>> Dear Floh & Marcello,
>> I'm not sure if it's that good an idea to make the forces read-only. I
>> can assure you, they are definitely not that way in the current code and
>> for good reasons. If you want to reinitialize the LB fluid, you need the
>> reuse_forces command, to account for the fact that the LB use of forces
>> is half a time step off of that in the main integration loop. That's why
>> you want to keep them settable. (as I wrote this Henri's message came in).
> This is only needed if you desire exactly reproducible trajectories
> (which of course is helpful for debugging). The sampling would still be
> valid (and actually more accurate) if one just recalculates the forces
> (adjusting the noise amplitude appropriately). That is basically just
> another instance where velocity dependent forces reduce the accuracy of
> ESPResSo's integrator by an order anyways, same for the LB update.
> Cheers,
> Ulf
>> On 28 February 2015 at 12:23, Florian Weik <address@hidden
>> <mailto:address@hidden>> wrote:
>>    Hi,
>>    Marcello is right, these forces are never used. For technical
>>    reasons it is not that easy to make them read-only because a lot of
>>    the test cases rely on the fact that forces can be read via the
>>    blockfile mechanism which is in turn just an interface to the tcl
>>    part command. So unless somebody is volunteering for the busywork to
>>    change dozens of test cases, that situation is staying the way it
>>    is. I'm pretty sure the documentation reflects the fact that these
>>    forces are not used.
>>    Cheers,
>>    Florian
>>    On Sat, Feb 28, 2015 at 8:36 AM, Marcello Sega
>>    <address@hidden <mailto:address@hidden>> wrote:
>>        Hi,
>>        please correct me if I'm wrong: I think that forces are always
>>        overwritten by the integrator, so that setting them by hand does not
>>        have any effect at all.
>>        If this is right, then allowing to set forces could be just
>>        misleading
>>        (as the program would behave in a way unexpected by the user).
>>        Wouldn't it be better to make them read-only?
>>        Regards,
>>        Marcello
>>        On Fri, Feb 27, 2015 at 3:56 PM, Henri Menke
>>        <address@hidden <mailto:address@hidden>>
>>        wrote:
>>> Dear all,
>>> in the current master of ESPResSo the forces are scaled by the
>>        masses
>>> and the time step in the output, i.e. part 0 print f, but are
>>        not scaled
>>> by the mass in the input, i.e. part 0 f.  This leads to wrong
>>        forces
>>> when setting them by hand with a mass not equal to 1.
>>> This bug is fixed in the pull-request
>>> Kind regards,
>>> Henri
>>        --
>>        Institut für Computergestützte Biologische Chemie
>>        University of Vienna
>>        PGP public key on MIT server
>>    --
>>    Florian Weik, Dipl.-Phys.,
>>    Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
>>    Phone: +49-711-685-67703 <tel:%2B49-711-685-67703>
>>    Public Key 0x0562F11D Fingerprint 3294 6360 EC93 37A3 BD40  F597
>>    0BAD 3AF8 0562 F11D
> --
> Ulf D. Schiller
> Centre for Computational Science
> University College London
> 20 Gordon Street
> London WC1H 0AJ
> United Kingdom
> Phone: +44 (0)20 7679 5300

reply via email to

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