Re: [ESPResSo-users] Force scaling wrong

[Owen Hickey]

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
>>
>>
>