[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ESPResSo-users] Force scaling wrong
From: |
Owen Hickey |
Subject: |
Re: [ESPResSo-users] Force scaling wrong |
Date: |
Sun, 1 Mar 2015 12:11:53 +0100 |
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
>>
>>
>