Re: [ESPResSo-devel] c question

[Ulf Schiller]

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
> 


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

Phone: +44 (0)20 7679 5300