Project

General

Profile

Task #281801

Task #281799: stable API of Lua library

revise potential/force/truncation interface

Added by Felix Höfling about 3 years ago. Updated 5 months ago.

Status:
Approved
Priority:
Normal
Assignee:
-
Target version:
Start date:
2014-03-19
Due date:
% Done:

0%


Description

Move cutoff from potential to the force or truncation module. This makes the potentials re-usable for non-truncated force modules. One idea is to consider the truncation modules as potential adapters (they take a potential and return it in a modified form).

In a second step, the modules pair_full and pair_trunc can be unified on the Lua level. If a truncation/cutoff is specified, the latter module is used.


Related issues

Duplicated by HAL's MD package - Task #280674: Move cutoff from potential to pair_trunc Closed 2014-03-15

Associated revisions

Revision 6377 (diff)
Added by daniel.kirchner 7 months ago

potentials: move truncation to adapters

Moves the truncation completely to the potential adapter local_r4 and
the new adapter discontinuous; adjusts all dependencies and tests
accordingly.

This commit refs #281801

Revision 6378 (diff)
Added by daniel.kirchner 7 months ago

potential: rename local_r4 to smooth_r4 and discontinuous to shifted

Renames the potential adapter local_r4 to smooth_r4 and the potential
adapter discontinuous to shifted.

This commit refs #281801

Revision 6379 (diff)
Added by daniel.kirchner 7 months ago

potential: replace lennard_jones_linear with force_shifted potential adapter

Replaces the explicit implementation of lennard_jones_linear with a force_shifted
potential adapter that can be applied to any potential.

This commit refs #281801

Revision 6380 (diff)
Added by daniel.kirchner 7 months ago

potential adapters: add sharp potential adapter

Adds a "sharp" potential adapter cuts off at a cutoff radius without
further modifications.

This commit refs #281801

Revision 6381 (diff)
Added by daniel.kirchner 7 months ago

potential adapters: remove unneeded kernel interface, reduce texture size

Removes the unneeded r_cut(), rr_cut() interface from potential adapter
kernel implementations and reduces the number of parameters in the
textures passed to the potential adapter kernels where possible.

This commit refs #281801

Revision 6382 (diff)
Added by daniel.kirchner 7 months ago

potential adapters: add hard_core modification

Adds a hard_core potential adapter. Moves the truncate interface to a
new adapters.lua module shared by all potentials and adds a modify interface.

The hard_core adapter is only instantiated for variants of the power_law
potential for now and the power_law_with_core potential is retained
as it contains an optimized version if the modified potential.

This commit refs #281801

Revision 6383 (diff)
Added by daniel.kirchner 7 months ago

potential adapters: collect truncation adapters in single header file

Collects all truncation adapters in a single header file.
A template function is used to create the lua interfaces for
a given potential and macros are used for explicit instantiation
(unfortunately macros are the only solution here).

This commit refs #281801

Revision 6384 (diff)
Added by daniel.kirchner 7 months ago

potential adapters: replace power_law_with_core

Creates an optimized instantiation of hard_core<power_law>.
The old power_law_with_core implementation becomes obsolete and
is removed.
The tests for power_law_with_core are adjusted to test the new
optimized instantiation and renamed to power_law_hard_core.

This commit refs #281801

Revision 6385 (diff)
Added by daniel.kirchner 7 months ago

pair forces: add unified pair force in the lua interface

Adds a unified pair force interface that automatically
falls back to pair_full for untruncated potentials and
uses pair_trunc for truncated potentials.

This commit refs #281801

Revision 6387 (diff)
Added by daniel.kirchner 7 months ago

potential_adapters: move adapters into separate namespace

Moves the potential adapters into a separate namespace and a
separate subdirectory.

This commit refs #281801

Revision 6389 (diff)
Added by daniel.kirchner 7 months ago

potential adapters: move truncations to separate namespace; boost preprocessor for potential lists

Moves the potential truncations from the adapters namespace into the separate namespace truncations
and uses the boost preprocessor library to iterate over a list of truncations in truncations.cuh/hpp.
As a next step the list of truncations can be exposed as cmake variable.

This commit refs #281801

Revision 6390 (diff)
Added by daniel.kirchner 7 months ago

potential adapters: enabled truncations as cmake variable

Creates a CMake variable HALMD_PAIR_POTENTIAL_TRUNCATIONS containing a list of
potential truncations to be enabled.

This commit refs #281801

History

#1 Updated by Nicolas Höft about 3 years ago

  • Related to Task #280674: Move cutoff from potential to pair_trunc added

#2 Updated by Nicolas Höft about 3 years ago

  • Related to deleted (Task #280674: Move cutoff from potential to pair_trunc)

#3 Updated by Nicolas Höft about 3 years ago

  • Duplicated by Task #280674: Move cutoff from potential to pair_trunc added

#4 Updated by Felix Höfling about 3 years ago

Let me note the following thoughts:

The concept of potential adapters could become quite flexible. It could not even accomodate various truncation schemes (discontinuous, energy_shifted, force_shifted, smooth_r4), but it could also convert power_law into power_law_with_core.

We have to check whether such adapters are technically feasible, if the implementation becomes cumbersome or too complicated (e.g. concerning the parameter textures) we better forget the idea quickly.

#5 Updated by Felix Höfling about 3 years ago

For later reference, let me note how the new interface for the pair potentials could look like:

 
potential = lennard_jones({
           epsilon = 1, sigma = 1
         , modify = {"hard_core", radius = 1}
         , truncation = {"smooth_r4", cutoff = 2.5, smoothing = 0.01}
})

The modification is applied first (if present), the truncation comes afterwards.

possible modifications:
  • hard core: U(r) → U(r-r_hc), r < r_hc is not allowed (excluded volume)
possible truncations, U(r) = 0 for r > r_c always:
  • sharp: no extra modifications
  • shifted: U(r) → U(r) - U(r_c)
  • force_shifted: U(r) → U(r) - U(r_c) + (r-r_c) U'(r_c)
  • smooth_r4: U(r) → [U(r) - U(r_c)] * g((r - r_c)/h r_c)

#6 Updated by Felix Höfling about 3 years ago

An alternative interface which makes the order of application and the underlying modules a bit more explicit:

potential = lennard_jones({epsilon = 1, sigma = 1})
potential = potential:modify({"hard_core", radius = 1})
potential = potential:truncate({"smooth_r4", cutoff = 2.5, smoothing = 0.01})

Internally, this resolves to

potential = mdsim.potentials.modify.hard_core({potential = potential, radius = 1})
potential = mdsim.potentials.trunc.smooth_r4({potential = potential, cutoff = 2.5, smoothing = 0.01})

Before revising all the potential code, we could try to first implement the Lua interface which resorts to the existing C++ modules.

For example, the "trunc" parameter of the force would be inferred from the potential directly. The "hard_core" modification would drop the existing power_law potential and would instantiate power_law_with_core. Similarly for the "linear cutoff", i.e., shifted force: the potential would be re-instantiated (which results in some noise in the log file)

#7 Updated by Felix Höfling over 2 years ago

  • Target version set to 1.0

This needs to be addressed before the stable release 1.0.

#8 Updated by Felix Höfling 5 months ago

  • Status changed from New to Approved

This issue has been addressed in commits 06478be..8709a9b.

Also available in: Atom PDF