check/timestep/gran + wall/gran bug (?)

msbentley's picture
Submitted by msbentley on Wed, 10/12/2011 - 15:15

I just came across this, and assume it's a bug: if you have more than one check/timestep/gran fix in a simulation (with the same fix ID, or different) and one call is before a wall/mesh/gran fix, and the other after, the sim crashes.

In my case when I try to pour particles:

[comp-l08:07286] *** Process received signal ***
[comp-l08:07286] Signal: Segmentation fault (11)
[comp-l08:07286] Signal code: Address not mapped (1)
[comp-l08:07286] Failing at address: (nil)
[comp-l08:07286] [ 0] /lib/libpthread.so.0(+0xf8f0) [0x7f52735598f0]
[comp-l08:07286] [ 1] /home/mab/bin/lmp_openmpi(_ZN9LAMMPS_NS15FixTriNeighlist10set_arraysEi+0xa) [0x6678fa]
[comp-l08:07286] [ 2] /home/mab/bin/lmp_openmpi(_ZN9LAMMPS_NS7FixPour12pre_exchangeEv+0xdd7) [0x60a8b7]
[comp-l08:07286] [ 3] /home/mab/bin/lmp_openmpi(_ZN9LAMMPS_NS6Modify12pre_exchangeEv+0x43) [0x6c6813]
[comp-l08:07286] [ 4] /home/mab/bin/lmp_openmpi(_ZN9LAMMPS_NS6Verlet3runEi+0x47c) [0x7cb41c]
[comp-l08:07286] [ 5] /home/mab/bin/lmp_openmpi(_ZN9LAMMPS_NS3Run7commandEiPPc+0x26a) [0x79f53a]
[comp-l08:07286] [ 6] /home/mab/bin/lmp_openmpi(_ZN9LAMMPS_NS5Input15execute_commandEv+0x9ae) [0x6a3ade]
[comp-l08:07286] [ 7] /home/mab/bin/lmp_openmpi(_ZN9LAMMPS_NS5Input4fileEv+0x3c8) [0x6a4338]
[comp-l08:07286] [ 8] /home/mab/bin/lmp_openmpi(main+0x49) [0x6ad5a9]
[comp-l08:07286] [ 9] /lib/libc.so.6(__libc_start_main+0xfd) [0x7f52731e5c4d]
[comp-l08:07286] [10] /home/mab/bin/lmp_openmpi() [0x47a059]
[comp-l08:07286] *** End of error message ***
[comp-l08:07288] *** Process received signal ***
[comp-l08:07288] Signal: Segmentation fault (11)
[comp-l08:07288] Signal code: Address not mapped (1)
[comp-l08:07288] Failing at address: (nil)

In fact I only meant to use one timestep check, but accidentally put it in twice, and couldn't figure out why things were going wrong :) It's quite a specific problem, but if I hit it, I guess someone else will ;-) If I unfix the timestep check before the second call, it works fine - but I believe calling a fix with the same ID should by default delete and over-write the old one?

Cheers, Mark

AttachmentSize
Plain text icon in.bug_test.txt3.06 KB