Re: [ESPResSo-users] Force scaling wrong

[Ulf Schiller]

Hi,

good point, Owen, I forgot about the different points in the ESPResSo
code where momentum is applied to the particles and the fluid. I think
still there is no disagreement that one should not set the forces
deliberately by hand. In Owen's and Joost's case the forces are set to
what they are physically based on checkpoints - in order to avoid the
discrepancy that would result from a recalculation. That is in my view
perfectly in line with Stefan's argument.

The bottom line is, as things stand with the integrator, setting
particle forces is needed when reading checkpoints but is otherwise
potentially harmful. As always, ESPResSo does *not* do the physics for you.

Cheers,
Ulf

On 03/01/2015 11:11 AM, Owen Hickey wrote:
> Hey all,
> 
> There seems to be agreement among most of you that setting the forces
> isn't a good idea, but I beg to differ. The reason they are now
> settable in ESPResSo is that when I was doing electrophoresis
> simulations with Shervin she discovered that many of the trajectories
> had a large kink in the position versus time curves. These kinks
> turned out to correspond to checkpoints. The reason is that after a
> checkpoint the forces in the first step were recalculated and the LB
> coupling force was ignored, meaning that the particles lose 1/2 dt
> times the coupling force of momentum. Of course the LB fluid itself
> had already received the whole coupling force and hence the system
> acquires a center of mass velocity. This makes the measured velocity
> v_measured = v_center + v_electrophoresis. This problem would probably
> pop up in bulk measurements of diffusion or sedimentation too. Of
> course there are a wide variety of situations where confinement
> probably means that as long as this doesn't happen too often, it
> probably doesn't matter, and occasionally breaking momentum
> conservation and doing something a little wonky is okay, but that for
> me personally is not a statement I'd like to put in my papers. The
> same problem exists too with every thermostat except for Langevin,
> where a workaround was build into ESPResSo.
> 
> Owen
> 
> On Sun, Mar 1, 2015 at 11:29 AM, Joost de Graaf
> <address@hidden> wrote:
>> 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:
>>>
>>> Hi,
>>> 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.
>>> Cheers
>>> Stefan
>>>
>>> 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
>>>>>>
>>>>>>  https://github.com/espressomd/espresso/pull/213
>>>>>>
>>>>>> Kind regards,
>>>>>> Henri
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>        --
>>>>>        Institut für Computergestützte Biologische Chemie
>>>>>        University of Vienna
>>>>>        PGP public key on MIT server http://goo.gl/zlIZix
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    --
>>>>>    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
>>>
>>>
>>
> 


-- 
Ulf D. Schiller
Centre for Computational Science
University College London
20 Gordon Street
London WC1H 0AJ
United Kingdom

Phone: +44 (0)20 7679 5300