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