Re: [ESPResSo-devel] c question

[Ulf Schiller]

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