[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Seg error trying to combine Gay-Berne and dipoles

From: Jean-Noël Grad
Subject: Re: Seg error trying to combine Gay-Berne and dipoles
Date: Thu, 1 Apr 2021 17:54:14 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.12.0


I was about to make the same suggestion. The kinetic part of the energy calculation contains the linear kinetic + rotational kinetic energy, and this quantity fluctuates wildly if you print it every 100 time steps. I tried again with a system.time_step value that was smaller by a factor of 10, and it looked stable in the first 4000 time steps, but then the kinetic energy jumped from 410 to 165000.

The assertion `assert(square > 0)` was introduced to stop the simulation when a particle angular momentum is so large that it almost does a full rotation in one time step. ESPResSo uses the solution to the equations of rotational motion derived at the fourth order in Omelyan 1998 (, which is invalid for large angular momenta (the square root in equation 12 yields an imaginary number).


On 4/1/21 5:22 PM, Rudolf Weeber wrote:
Hi Margaret,
On Thu, Apr 01, 2021 at 04:13:26PM +0200, Margaret Rosenberg wrote:
I'm attempting to reproduce a simple Gay-Berne ferrofluid and getting some
odd segmentation errors. I've attached an attempt at a minimal working
example* below: any advice would be appreciated. The error message reads as

[cpk01:64078] *** Process received signal ***
[cpk01:64078] Signal: Segmentation fault: 11 (11)
[cpk01:64078] Signal code: Address not mapped (1)
[cpk01:64078] Failing at address: 0x7f85d9bd5000
[cpk01:64078] [ 0] 0   libsystem_platform.dylib
0x00007fff718535fd _sigtramp + 29
[cpk01:64078] [ 1] 0   ???
0x00007f89d7c30220 0x0 + 140230007128608
[cpk01:64078] [ 2] 0   EspressoCore.dylib
0x0000000109d691b6 _Z18dp3m_dipole_assignRK13ParticleRange + 326
A segfautl in the p3m dipole assignment (map dipoles onto the p3m gird) 
strongly sugges a particle position outside the domain.

Unfortunately, I can't check that, becaus I can only reproduce the segfault, if 
I run your sample outside a debugger. When running in the debugger (and build 
type=Debug set in cmake), the simulation eventually fails due to an assertion 
checking the stability of the rotational integrator
``` assert(square > 0) ``` in propagate_omega_quat_particle() in rotation.cpp.
to mittigate this, you can try to slow the rotational time scale of your 
simulation, e.g., by increasing the rotational inertia of the Gay-Berne 
particles or the rotational friction coefficient in the Langevin thermostat.
Probably it is also a good ide to run minimum distance analysis on your dipoles 
during the simulation to make sure there are no surprises, there.

Hope that helps!
Regards, Rudolf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]