Completed design discussions

From espressopp

This page lists the finished discussions concerning the design of ESPResSo++. Look here for open discussions.

Contents 1 Finished discussions 1.1 Inner loop 1.2 Identifying a particle in the script 2 Discussion pages

Finished discussions

• Efficient loops

Inner loop

The simplest implementation can be visualized as follows, where every solid arrow indicates a virtual function call, and the comments indicates the transferred information. The boxes represent involved instances of different classes, which represent different runtime degrees of freedom, which therefore require the virtual calls:

In this image, virtual function calls should be avoided as much as possible, and some optimization may be possible by avoiding some of the runtime degrees of freedom. For example, the computer is not really independent of the interaction: it can only accumulate what the interaction actually is able to compute. The current implementation therefore avoids this degree of freedom by making a combined object from the computer and interaction, i.e. an object representing the energy calculation for a potential. However, this combined object is generated by the potential, which means that adding new such combined objects is difficult.

Identifying a particle in the script

A script author has to be able to create and modify specific particles. To do that, he must be able to select a particle/a set of particles according to some criteria. How can/should this be done in the Python script?

Note that is not necessarily the same as the global ID that we require for every particle so that it an be identified over different processors. It might be the same, though.

In the old ESPResSo, we used numeric, continuous, user-assigned particle IDs:

• When a particle is created, a numerical particle id has to be provided.
• Later in the script, this particle id is used to refer to that particle.
• When a particle gets automatically created by the system, it gets a particle ID that is greater than the greatest particle ID used so far.

This system is simple and fits to the way physicists think about a system. From the implementation point of view, this ID could simply be used as the global ID required by the parallelization anyway.

However, it also has some disadvantages. In ESPResSo a number of functions are implemented such, that assumptions were made as to the ordering of the particle ids. For example, many polymer analysis functions assumed that the polymer chains were of the same length and their particle ids were continuous. This should be avoided in ESPResSo++! Is there any way to prevent this from happening?

We concluded that the only way to make module developers not to make assumptions on the particle ID ordering is to make it comfortable to do otherwise, e.g. by introducing topologies like polymers etc.

Discussion pages

• Open design discussions: Discussions concerning the system design (Completed design discussions)
• Open development discussions: Discussions concerning the development (code layout etc.) (Completed development discussions)
• Technologies discussions: Discussions about the technologies