Skip to content
Permalink
Browse files

Merge #2781 #2835

2781: Add support for gdb in ipypresso r=jngrad a=hirschsn

Ipypresso's flag "--gdb" does not work on my system because ipypresso is just a wrapper script executing python with a bunch of parameters. Nevertheless, support of --gdb can be added to ipypresso by a slightly more complicated gdb setup.

This PR adds this support using gdb's exec-wrapper functionality. The implementation is quite hacky by inserting a check for ipython into pypresso.cmakein. Let me know if the functionality itself is something that you want to have upstream. If so, we also could figure out a less hacky solution.

Description of changes:
 - Use ipython as gdb's exec-wrapper, not directly as executable


PR Checklist
------------
 - [ ] Tests?
   - [ ] Interface
   - [ ] Core 
 - [ ] Docs?


2835: Fix some typos in constraints.py r=jngrad a=hirschsn

Fixes some typos in constraints.py.

PR Checklist
------------
 - [ ] Tests?
   - [ ] Interface
   - [ ] Core 
 - [ ] Docs?


Co-authored-by: Steffen Hirschmann <steffen.hirschmann@ipvs.uni-stuttgart.de>
Co-authored-by: Jean-Noel Grad <jgrad@icp.uni-stuttgart.de>
Co-authored-by: Jean-Noël Grad <jgrad@icp.uni-stuttgart.de>
  • Loading branch information...
3 people committed May 14, 2019
3 parents 304ddbe + 2642149 + 465872b commit 3e55eec148a038588c30027482860f85533c6997
60 NEWS
@@ -2,6 +2,66 @@
= ESPRESSO NEWS =
=================

ESPResSo 4.0.2
==============

This release provides a number of corrections for the Espresso 4.0 line.
We recommend that this release be used for all production simulations.
Please note that a sign error in tabulated interactions was fixed.
Simulation scripts which worked around this problem might have to be changed.
Below, please find the list of changes. The numbers in brackets refer to
ticket numbers on http://github.com/espressomd/espresso


Corrections for bugs that may harm simulation results:
* A sign error in tabulated interactions was corrected such that
the force equals the negative gradient of the potential. (#2519,2520)

* The flow field of the CPU lattice-Boltzmann implementation was deleted
when aspects of the molecular dynamics cell grid were changed; E.g., when
interactions, the skin or the parallelization setup were changed.
ESPResSo now terminates with an error, when this happens.
To avoid this, please setup the CPU lattice-Boltzmann after all
other aspects of the system. The GPU LB is not affected in the 4.0
release, but was affected in the current development branch. (#2728, #2736)

* Corrected the force acting on LB Boundaries for the case of
agrid and density not equal to 1 (#2624).

* Corrected the cutoff calculation for the soft sphere interaction. In the
previous implementation, the offset parameter was ignored. (#2505)

* The "three point coupling" of particles to the lattice-Boltzmann method
has been removed. While it works in most environments, for some compilers
the calculation gives wrong values. This is likely caused by undefined
behavior. A corrected implementation is available in
ESPResSo's development branch. It cannot be safely backported to 4.0.2,
because the code has diverged too far. (#2516, #2517)
Users who did not explicitly activate this coupling via couple="3pt" are
not affected.

* The velocity of existing particles was changed when setting or changing
the simulation time step (#2480)


Further changes:
* Fixed the electrokinetic Python interface (#2486)

* Correction to the installation instructions for mac (#2510)

* Corrected file permissions (#2470)

* Minor corrections and extensions to the test suite (#2477, #2552)

* Fixed a dead-lock in the dipolar Barnes Hutt method on the GPU for
recent NVIDIA cards such as RTX 2080 (#2719).

* Restored Mayavi visualizer's API-compatibility with OpenGL visualizer
(#2751)




ESPResSo 4.0.1
==============

@@ -449,7 +449,7 @@ The short ranged part is given by:

.. math :: p^\text{Coulomb, P3M, dir}_{(k,l)}= \frac{1}{4\pi \epsilon_0 \epsilon_r} \frac{1}{2V} \sum_{\vec{n}}^* \sum_{i,j=1}^N q_i q_j \left( \frac{ \mathrm{erfc}(\beta |\vec{r}_j-\vec{r}_i+\vec{n}|)}{|\vec{r}_j-\vec{r}_i+\vec{n}|^3} +\frac{2\beta \pi^{-1/2} \exp(-(\beta |\vec{r}_j-\vec{r}_i+\vec{n}|)^2)}{|\vec{r}_j-\vec{r}_i+\vec{n}|^2} \right) (\vec{r}_j-\vec{r}_i+\vec{n})_k (\vec{r}_j-\vec{r}_i+\vec{n})_l,
where :math:`\beta` is the P3M splitting parameter, :math:`\vec{n}` identifies the periodic images, the asterix denotes that terms with :math:`\vec{n}=\vec{0}` and i=j are omitted.
where :math:`\beta` is the P3M splitting parameter, :math:`\vec{n}` identifies the periodic images, the asterisk denotes that terms with :math:`\vec{n}=\vec{0}` and i=j are omitted.
The long ranged (k-space) part is given by:

.. math :: p^\text{Coulomb, P3M, rec}_{(k,l)}= \frac{1}{4\pi \epsilon_0 \epsilon_r} \frac{1}{2 \pi V^2} \sum_{\vec{k} \neq \vec{0}} \frac{\exp(-\pi^2 \vec{k}^2/\beta^2)}{\vec{k}^2} |S(\vec{k})|^2 \cdot (\delta_{k,l}-2\frac{1+\pi^2\vec{k}^2/\beta^2}{\vec{k}^2} \vec{k}_k \vec{k}_l),
@@ -474,10 +474,10 @@ To use the, e.g., ``ewald`` solver from SCAFACOS as electrostatics solver for y
cutoff to :math:`1.5` and tune the other parameters for an accuracy of
:math:`10^{-3}`, use::

from espressomd.electrostatics import Scafacos
scafacos = Scafacos(prefactor=1, method_name="ewald",
method_params={"ewald_r_cut": 1.5, "tolerance_field": 1e-3})
system.actors.add(scafacos)
from espressomd.electrostatics import Scafacos
scafacos = Scafacos(prefactor=1, method_name="ewald",
method_params={"ewald_r_cut": 1.5, "tolerance_field": 1e-3})
system.actors.add(scafacos)


For details of the various methods and their parameters please refer to
@@ -18,37 +18,35 @@
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
//

/** \file
ICCP3M is a method that allows to take into account the influence
of arbitrarily shaped dielectric interfaces. The dielectric
properties of a dielectric medium in the bulk of the simulation
box are taken into account by reproducing the jump in the electric
field at the inface with charge surface segments. The charge
density of the surface segments have to be determined
self-consistently using an iterative scheme. It can at presently
- despite its name - be used with P3M, ELCP3M, MMM2D and MMM1D.
For details see:<br> S. Tyagi, M. Suzen, M. Sega, C. Holm,
M. Barbosa: A linear-scaling method for computing induced charges
on arbitrary dielectric boundaries in large system simulations
(Preprint)
To set up ICCP3M first the dielectric boundary has to be modelled
by espresso particles 0..n where n has to be passed as a parameter
to ICCP3M. This is still a bit inconvenient, as it forces the user
to reserve the first n particle ids to wall charges, but as the
other parts of espresso do not suffer from a limitation like this,
it can be tolerated.
For the determination of the induced charges only the forces
acting on the induced charges has to be determined. As P3M and the
other Coulomb solvers calculate all mutual forces, the force
calculation was modified to avoid the calculation of the short
range part of the source-source force calculation. For different
particle data organisation schemes this is performed differently.
*/
*
* ICCP3M is a method that allows to take into account the influence
* of arbitrarily shaped dielectric interfaces. The dielectric
* properties of a dielectric medium in the bulk of the simulation
* box are taken into account by reproducing the jump in the electric
* field at the inface with charge surface segments. The charge
* density of the surface segments have to be determined
* self-consistently using an iterative scheme. It can at presently
* - despite its name - be used with P3M, ELCP3M, MMM2D and MMM1D. For
* details see: S. Tyagi, M. Suzen, M. Sega, M. Barbosa, S. S. Kantorovich,
* C. Holm: An iterative, fast, linear-scaling method for computing induced
* charges on arbitrary dielectric boundaries, J. Chem. Phys. 2010, 132,
* p. 154112, doi:10.1063/1.3376011
*
* To set up ICCP3M first the dielectric boundary has to be modelled
* by espresso particles 0..n where n has to be passed as a parameter
* to ICCP3M. This is still a bit inconvenient, as it forces the user
* to reserve the first n particle ids to wall charges, but as the
* other parts of espresso do not suffer from a limitation like this,
* it can be tolerated.
*
* For the determination of the induced charges only the forces
* acting on the induced charges has to be determined. As P3M and the
* other Coulomb solvers calculate all mutual forces, the force
* calculation was modified to avoid the calculation of the short
* range part of the source-source force calculation. For different
* particle data organisation schemes this is performed differently.
*/

#ifndef CORE_ICCP3M_HPP
#define CORE_ICCP3M_HPP
@@ -124,7 +124,7 @@ typedef struct {
int s_ur[6][3];
/** sizes for send buffers. */
int s_size[6];
/** dimensionof sub meshes to recv. */
/** dimension of sub meshes to recv. */
int r_dim[6][3];
/** left down corners of sub meshes to recv. */
int r_ld[6][3];
@@ -658,7 +658,7 @@ void assign_forces(const CUDA_particle_data *const pdata, const P3MGpuData p,
_cuda_check_errors(block, grid, "assign_forces", __FILE__, __LINE__);
}

/* Init the internal datastructures of the P3M GPU.
/* Init the internal data structures of the P3M GPU.
* Mainly allocation on the device and influence function calculation.
* Be advised: this needs mesh^3*5*sizeof(REAL_TYPE) of device memory.
* We use real to complex FFTs, so the size of the reciprocal mesh
@@ -117,7 +117,7 @@ inline void add_affinity_pair_force(Particle *p1, Particle *p2,
ia_params
->affinity_r0) { // Bond does not exist, we are inside
// of possible bond creation area,
// lets talk about creating a bond
// let's talk about creating a bond
// This implementation creates bond always
for (j = 0; j < 3; j++)
p1->p.bond_site[j] = unfolded_pos[j] - d[j];
@@ -231,7 +231,7 @@ inline void add_affinity_pair_force(Particle *p1, Particle *p2,
ia_params
->affinity_r0) { // Bond does not exist, we are inside
// of possible bond creation area,
// lets talk about creating a bond
// let's talk about creating a bond
double Pon = 1.0 - exp(-ia_params->affinity_Kon * time_step);
// The probability is given by function Pon(x)= 1 - e^(-x) where x is
// Kon*dt.
@@ -326,7 +326,7 @@ inline void add_affinity_pair_force(Particle *p1, Particle *p2,
ia_params
->affinity_r0) { // Bond does not exist, we are inside
// of possible bond creation area,
// lets talk about creating a bond
// let's talk about creating a bond
double Pon = 1.0 - exp(-ia_params->affinity_Kon * time_step);
// The probability is given by function Pon(x)= 1 - e^(-x) where x is
// Kon*dt.
@@ -440,7 +440,7 @@ inline void add_affinity_pair_force(Particle *p1, Particle *p2,
ia_params
->affinity_r0) { // Bond does not exist, we are inside
// of possible bond creation area,
// lets talk about creating a bond
// let's talk about creating a bond
double Pon = 1.0 - exp(-ia_params->affinity_Kon * time_step);
// The probability is given by function Pon(x)= 1 - e^(-x) where x is
// Kon*dt.
@@ -564,7 +564,7 @@ inline void add_affinity_pair_force(Particle *p1, Particle *p2,
ia_params
->affinity_r0) { // Bond does not exist, we are inside
// of possible bond creation area,
// lets talk about creating a bond
// let's talk about creating a bond
double Pon = 1.0 - exp(-ia_params->affinity_Kon * time_step);
// The probability is given by function Pon(x)= 1 - e^(-x) where x is
// Kon*dt.
@@ -688,7 +688,7 @@ inline void add_affinity_pair_force(Particle *p1, Particle *p2,
ia_params
->affinity_r0) { // Bond does not exist, we are inside
// of possible bond creation area,
// lets talk about creating a bond
// let's talk about creating a bond
double Pon = 1.0 - exp(-ia_params->affinity_Kon * time_step);
// The probability is given by function Pon(x)= 1 - e^(-x) where x is
// Kon*dt.
@@ -222,7 +222,7 @@ class _Interpolated(Constraint):
The data has to have one point of halo in each direction,
and is shifted by half a grid spacing in the +xyz direction,
so that the element (0,0,0) has coordinates -0.5 * grid_spacing.
The numer of points has to be such that the data spanc the whole
The number of points has to be such that the data spans the whole
box, e.g. the most up right back point has to be at least at
box + 0.5 * grid_spacing. There are convenience functions on this
class that can calculate the required grid dimensions and the coordinates.
@@ -508,7 +508,7 @@ class FlowField(_Interpolated):
F = -gamma * (u(r) - v)
wher v is the velocity of the particle.
where v is the velocity of the particle.
"""

@@ -528,7 +528,7 @@ class HomogeneousFlowField(Constraint):
F = -gamma * (u - v)
wher v is the velocity of the particle.
where v is the velocity of the particle.
Attributes
----------
@@ -243,7 +243,7 @@ cdef class ReactionAlgorithm(object):
if(self._params["check_for_electroneutrality"]):
charges = np.array(list(self._params["default_charges"].values()))
if(np.count_nonzero(charges) == 0):
# all partices have zero charge
# all particles have zero charge
# no need to check electroneutrality
return
total_charge_change = 0.0
@@ -54,6 +54,7 @@ fi
case $1 in
--gdb)
shift
[ "@PYTHON_FRONTEND@" = "@IPYTHON_EXECUTABLE@" ] && exec gdb -ex "set print thread-events off" -ex "set exec-wrapper sh -c 'exec \"@IPYTHON_EXECUTABLE@\" \"\$@\"'" --args "@PYTHON_EXECUTABLE@" $@
exec gdb --args @PYTHON_FRONTEND@ $@
;;
--lldb)
@@ -75,6 +76,7 @@ case $1 in
--gdb=*)
options="${1#*=}"
shift
[ "@PYTHON_FRONTEND@" = "@IPYTHON_EXECUTABLE@" ] && exec gdb -ex "set print thread-events off" -ex "set exec-wrapper sh -c 'exec \"@IPYTHON_EXECUTABLE@\" \"\$@\"'" ${options} --args "@PYTHON_EXECUTABLE@" $@
exec gdb ${options} --args @PYTHON_FRONTEND@ $@
;;
--lldb=*)

0 comments on commit 3e55eec

Please sign in to comment.
You can’t perform that action at this time.