You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bug is reproducible on the python branch and with ESPResSo releases 4.2.1 and 4.1.4.
It is unclear to me, how to gracefully handle a box resize. One could fold the particle position onto the unit cell, apply the box resize via rescaling, and re-use the older image box counter. But then, a jump may become visible in trajectories in unfolded coordinates. One would also need to maintain the old and new value in the BoxGeometry object to apply the folding and then unfolding with the two box sizes. It is also unclear what should happen with Lees-Edwards boundary conditions, where particle positions gain an offset when going through one of the three periodic boundaries.
The easiest course of action is to prevent manually changing the box length if the box contains particles, and rely instead on the system.change_volume_and_rescale_particles(), which implements the correct behavior. Alternatively, one could make the box length setter call the rescale method under-the-hood, but this introduces a new problem: the on_boxl_change event would be called three times, causing long-range solvers to re-tune all solver parameters three times with a different box size. Since the box might no longer be cubic for the first two re-tunes, the tuning code may become extremely slow, have to sample more mesh sizes, and throw an exception if the accuracy cannot be reached.
Note: this bug doesn't affect the NpT integrator, which uses the rescale algorithm.
The text was updated successfully, but these errors were encountered:
Fixes#4834
Description of changes:
- Resizing the box via `system.box_l = new_box_l` now throws a runtime error if there are particles present, because particle position folding cannot be guaranteed to be correct; use `system.change_volume_and_rescale_particles()` instead, which properly rescales particle positions.
jngrad
pushed a commit
to jngrad/espresso
that referenced
this issue
Apr 25, 2024
Fixesespressomd#4834
Description of changes:
- Resizing the box via `system.box_l = new_box_l` now throws a runtime error if there are particles present, because particle position folding cannot be guaranteed to be correct; use `system.change_volume_and_rescale_particles()` instead, which properly rescales particle positions.
When manually modifying the box length, the new particle positions are recalculated with the wrong box size.
MWE:
Output:
This bug is reproducible on the python branch and with ESPResSo releases 4.2.1 and 4.1.4.
It is unclear to me, how to gracefully handle a box resize. One could fold the particle position onto the unit cell, apply the box resize via rescaling, and re-use the older image box counter. But then, a jump may become visible in trajectories in unfolded coordinates. One would also need to maintain the old and new value in the
BoxGeometry
object to apply the folding and then unfolding with the two box sizes. It is also unclear what should happen with Lees-Edwards boundary conditions, where particle positions gain an offset when going through one of the three periodic boundaries.The easiest course of action is to prevent manually changing the box length if the box contains particles, and rely instead on the
system.change_volume_and_rescale_particles()
, which implements the correct behavior. Alternatively, one could make the box length setter call the rescale method under-the-hood, but this introduces a new problem: theon_boxl_change
event would be called three times, causing long-range solvers to re-tune all solver parameters three times with a different box size. Since the box might no longer be cubic for the first two re-tunes, the tuning code may become extremely slow, have to sample more mesh sizes, and throw an exception if the accuracy cannot be reached.Note: this bug doesn't affect the NpT integrator, which uses the rescale algorithm.
The text was updated successfully, but these errors were encountered: