Re: [ESPResSo-devel] Espressomd-devel Digest, Vol 52, Issue 7

[Josh Berryman]

Hello, I wrote the Lees Edwards stuff, just replying to confirm that yes I am still alive and willing to help or explain if needed.  It is a simple concept with a slightly fiddly implementation due to the requirement of rebuilding the ghost cell structure on every shift.  

The shearing is not really "time dependent" per se: you just send a command to set a new shear, and it is set.  For a constant shear rate you would of course do this once per timestep with linearly increasing shear displacement, I organised matters this way for maximum flexibility in case of e.g. oscillatory shear.  The code estimates the shear rate from behind the API by taking a delta.

Particles work fine under Leeds-Edwards pretty much as you describe.  LB I did not implement, hopefully you can get an idea of what has to happen here by looking at and extending the implementation that I made for particle interactions.  

Josh Berryman, Uni Luxembourg

On 28 May 2015 at 17:00, <address@hidden> wrote:

Send Espressomd-devel mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/espressomd-devel
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Espressomd-devel digest..."


Today's Topics:

   1. shifted periodicity (Ivan Cimrak)
   2. Re: c question (Ivan Cimrak)
   3. Re: shifted periodicity (Axel Arnold)


----------------------------------------------------------------------

Message: 1
Date: Wed, 27 May 2015 22:37:43 +0200
From: Ivan Cimrak <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [ESPResSo-devel] shifted periodicity
Message-ID:
        <CAEe=azY3KfU_1gvyNxQH_gKbU=hSekLoZaKmFCz-SbZs=t=address@hidden>
Content-Type: text/plain; charset=UTF-8

Dear all,


Periodicity of the simulation box is implemented in a way that, e.g.
for the lbfluid, the following periodic condition is valid:
v(x, y, z) = v(x+boxX, y, z), similarly in other directions.

I need to implement shifted periodicity, something like this:
Let shiftY be a number between 0 and boxY indicating the shift in y
direction. The shifted periodicity condition would then be
v(x,y,z) = v(x+boxX, y + shiftY, z)
It could of course be even more complicated, with simultaneous shift
also in z direction, but for brevity let us keep it simple like above.


This shifted periodicity must of course be implemented also for
particles. Currently, two particles with very short-range interaction
(with cut_off e.g. 3*delta) feel each other in case their positions
are  e.g. (x+delta, y, z) and (x+boxX-delta, y,z). In case with
shifted periodicity, particles with these positions would not feel
each other, however, particles with positions (x+delta, y, z) a
(x+boxX-delta, y + shiftY,z) would do.


Can anyone give a reasonable estimate on how difficult it is to
implement something like this? And also, where in the code to look:-)

Thank you,
Ivan




--
Ivan Cimrak
FRI Zilinska Univerzita v Ziline
personal web: http://www.kst.fri.uniza.sk/~icimrak/
cell-in-fluid group: http://cell-in-fluid.fri.uniza.sk



------------------------------

Message: 2
Date: Thu, 28 May 2015 08:26:13 +0200
From: Ivan Cimrak <address@hidden>
To: address@hidden
Subject: Re: [ESPResSo-devel] c question
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

Ulf, Florian,

Thanks for you opinion. If I understood it correctly, I will implement
new directive OIF_LOCAL_FORCES.

With best regards,
Ivan

D?a 18.5.2015 o 16:59 Ulf Schiller nap?sal(a):
> On 18/05/15 15:37, Florian Weik wrote:
>> Ulf,
>> I do not agree. From a code point of view the only relevant feature for
>> the bonded interactions are that the interaction partners are fixed (as
>> opposed to non-bonded interactions where we have to go to considerable
>> lengths to get the interaction partners). It does not matter what their
>> actual connectivity is, they are handled only by pointer lists. This is
>> reflected by the word 'bonded' which IMHO exactly captures that feature.
>
> Fair enough, if that's the definition.
>
> However, my concern is that actual potentials do depend on topology,
> hence all the switch/case to deal with the polymorphism. Apart from
> potentially interfering with CPU pipelines, this introduces a source of
> load imbalance that is not straightforward to address.
>
> Cheers,
> Ulf
>
>> On Mon, May 18, 2015 at 4:29 PM, Ulf Schiller <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>>      Ivan,
>>
>>      I reckon your 4 particles are the nodes of two triangles that share an
>>      edge. The cleanest way to implement forces for this topology is to
>>      introduce appropriate data structures and iterate over these; you will
>>      find that most interactions can actually be decomposed into
>>      contributions from 3 particles.
>>
>>      add_bonded_force, as far as I can tell, was originally intended for
>>      linear topologies and it may be cleaner not to squeeze in functionality
>>      with different semantics (dihedrals are already a borderline case imho).
>>
>>      As Florian pointed out it would be surprising if the interactions affect
>>      the performance much - it should be dominated by the fluid part. Hence I
>>      would be more concerned about load balancing.
>>
>>      Cheers,
>>      Ulf
>>
>>      On 18/05/15 12:28, Ivan Cimrak wrote:
>>      > Dear core developer(s),
>>      >
>>      >
>>      > I would like to add some functionality in our object-in-fluid
>>      framework.
>>      > We did some effort to speed up the computations. For this however we
>>      > needed to create new local interaction between 4 particles, called
>>      > oif_local_forces (this interaction replaces all other local
>>      interactions
>>      > from oif).
>>      >
>>      > Unlike the dihedral force, we need 4 different forces to be added to 4
>>      > particles involved in the interaction.
>>      >
>>      > Until now, the Espresso defines in function add_bonded_forces only 3
>>      > forces (force, force2 and force3). Only when TWIST_STACK is defined,
>>      > another forces are used.
>>      >
>>      > Here comes my question: How should I add the fourth force? There are
>>      > basically 2 options:
>>      > 1. I add force4 in the beginning  of add_bonded_force. The drawback of
>>      > this option is, that there will be always 4 forces compiled in
>>      > regardless whether our new local bonded interaction will be used
>>      or not.
>>      > 2. I will introduce new preprocessor directive OIF_LOCAL_FORCES that
>>      > will need to be set in myconfig.hpp in case I will use my new local
>>      > interaction. And the fourth force will be defined only if
>>      > OIF_LOCAL_FORCES is defined. I emphasize, that the directive
>>      > OIF_LOCAL_FORCES would be used only at this single place in the
>>      code. We
>>      > do not need it for anything else.
>>      >
>>      >
>>      > Thanks for your advice.
>>      >
>>      > Ivan
>>
>>      --
>>      Dr Ulf D Schiller
>>      Centre for Computational Science
>>      University College London
>>      20 Gordon Street
>>      London WC1H 0AJ
>>      United Kingdom
>>
>>
>>
>>
>>
>> --
>> Florian Weik, Dipl.-Phys.,
>> Institut f?r Computerphysik, Allmandring 3, D-70569 Stuttgart
>> Phone: +49-711-685-67703
>> Public Key 0x0562F11D Fingerprint 3294 6360 EC93 37A3 BD40  F597 0BAD
>> 3AF8 0562 F11D
>>
>
>

--
Ivan Cimrak
FRI Zilinska Univerzita v Ziline
personal web: http://www.kst.fri.uniza.sk/~icimrak/
cell-in-fluid group: http://cell-in-fluid.fri.uniza.sk



------------------------------

Message: 3
Date: Thu, 28 May 2015 08:36:14 +0200
From: Axel Arnold <address@hidden>
To: Ivan Cimrak <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [ESPResSo-devel] shifted periodicity
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"

Hi Ivan,

Take a look at the Lees-Edwards code in Espresso. That does time-dependent shifting, so is more complicated, but on the other hand has the necessary generalizations of parallel communication at least in one dimension. Is fairly tricky, though.

Best,
Axel

Axel Arnold
Martha-Schmidtmann-Str. 7
70374 Stuttgart, Germany
Email: address@hidden
Phone: +49 173 870 6659

> Am 27.05.2015 um 22:37 schrieb Ivan Cimrak <address@hidden>:
>
> Dear all,
>
>
> Periodicity of the simulation box is implemented in a way that, e.g.
> for the lbfluid, the following periodic condition is valid:
> v(x, y, z) = v(x+boxX, y, z), similarly in other directions.
>
> I need to implement shifted periodicity, something like this:
> Let shiftY be a number between 0 and boxY indicating the shift in y
> direction. The shifted periodicity condition would then be
> v(x,y,z) = v(x+boxX, y + shiftY, z)
> It could of course be even more complicated, with simultaneous shift
> also in z direction, but for brevity let us keep it simple like above.
>
>
> This shifted periodicity must of course be implemented also for
> particles. Currently, two particles with very short-range interaction
> (with cut_off e.g. 3*delta) feel each other in case their positions
> are  e.g. (x+delta, y, z) and (x+boxX-delta, y,z). In case with
> shifted periodicity, particles with these positions would not feel
> each other, however, particles with positions (x+delta, y, z) a
> (x+boxX-delta, y + shiftY,z) would do.
>
>
> Can anyone give a reasonable estimate on how difficult it is to
> implement something like this? And also, where in the code to look:-)
>
> Thank you,
> Ivan
>
>
>
>
> --
> Ivan Cimrak
> FRI Zilinska Univerzita v Ziline
> personal web: http://www.kst.fri.uniza.sk/~icimrak/
> cell-in-fluid group: http://cell-in-fluid.fri.uniza.sk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/espressomd-devel/attachments/20150528/221ad39f/attachment.html>

------------------------------

_______________________________________________
Espressomd-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/espressomd-devel


End of Espressomd-devel Digest, Vol 52, Issue 7
***********************************************