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

[Jean-Noël Grad]

Hi,

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 
(https://doi.org/10.1063/1.168642), which is invalid for large angular 
momenta (the square root in equation 12 yields an imaginary number).

Best,
JN

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
> > follows:
> >
> > [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