Interactions

Work in progress!

Introduction

In physics, interactions are in general symmetric. However, the magnitude with which it affects the interaction partners can be very different. Also, the way the interactions have to be implemented can differ depending on the ‘‘direction’’ of the interaction.

Therefore, in Octopus interactions are broken down into their forward and their backward parts, which are treated seperately.

As we will see, in some approximations, only one of them (usually the forward interaction) are used.

The ‘‘partners’’ are instances of interaction_partner_t derived types. The interactions (from now on uni-directional) are implemented as derived types of the abstract interaction_t class.

An interaction ‘‘belongs’’ to partner A and acts on partner B.

Abstract classes

interaction_t

Definition of interaction_t

This is the minimal data structure for interactions, which only contains information relating to partner A, who owns the interacion. In particular, the interaction has a list of quantities, which partner A needs to expose, so that the interaction can be calculated. The IDs for the exposed quantities are defined in the section Exposed Quantities.

Furthermore, this abstract type already contains the clock for the interaction, and defines the interfaces for the deferred update() and calculate() routines.

interaction_with_partner_t

Curretly, all interactions are derived from interaction_with_partner_t, which extends interaction_t and adds the information about partner B, from here on only called ‘‘partner’’.

Definition of interaction_with_partner_t

This type adds a pointer to the interaction partner and a list of IDs of the quantities, the partner exposes to the interaction. Furthermore, at this level, we can implement the update() procedure.

force_interaction_t

The next level of specialization of interaction, are all interactions which create a force on the partner. Here we only add the actual force vector, acting on the partner system.

Definition of force_interaction_t


Specific classes:

Specific interaction classes extend the abstract ones. The most important element they add to the abstract classes is the information about the quantities, required to calculate the interaction. In case of the system. owning the interaction (system A), it is sufficient to keep pointers to the data, stored in the system itself. Thr reason is that the interaction is always updated by the propagator of the system A. For the partner system (system B), however, the interaction keeps a copy of the exposed quantities. This allows the partner system to continue the propagation beyond the time for which the quantities are requested, which might happen if the two systems are using different time steps.

Ghost interaction

Definition of ghost_interaction_t

Gravity

Definition of gravity_t

Coulomb force

Definition of coulomb_force_t

Lorentz force

Definition of lorentz_force_t

Interaction factory

Instances of interaction_t or derived types are, like systems, generated using a factory.

Definition of interactions_factory_abst_t
Definition of interactions_factory_t

The interactions_factory_create() function calls the constructor of the requested type and returns a pointer to the created instance.

Definition of interactions_factory_create()
Currently, the following interaction types are defined:


  integer, parameter, public :: &
    GRAVITY          = 1,       &
    LORENTZ_FORCE    = 2,       &
    COULOMB_FORCE    = 3,       &
    LINEAR_MEDIUM_EM_FIELD = 4

When using these system types, always use the parameters, and not their numerical values, as they might change over time.