Charge Equilibration for relatively large MOFs leads to Segmentation Fault

[Lingxiao Qin]

Dear Prof. Dubbeldam and RASPA community,

I would like to report a problem that I encountered. When I used the 'charge-equilibration' method to compute the charges of some relatively large MOFs, the simulation crashed with a Segmentation Fault.

Take ZIF-20.cif as an example. This cif file is in the original 'structures' directory of RASPA (~/RASPA/simulations/share/raspa/structures/cif), whose cell length a, b and c are all equal to 45.4725 Å.

My simulation.input file is as

Code Select Expand


SimulationType                MonteCarlo
NumberOfCycles                0
NumberOfInitializationCycles  0
PrintEvery                    100
RestartFile                   no

Forcefield                    ExampleMOFsForceField
CutOff                        12.8

ChargeFromChargeEquilibration    yes
ChargeEquilibrationPeriodic      yes
ChargeEquilibrationEwald         yes
SymmetrizeFrameworkCharges       no

Framework             0
FrameworkName         ZIF-20
UnitCells             1 1 1
ExternalTemperature   298.0
ExternalPressure      0.0


The simulation terminated with a Segmentation Fault.

29555 Segmentation fault      (core dumped) ${RASPA_DIR}/bin/simulate $1

However, if I change the simulated MOF from ZIF-20 to Cu-BTC (simply modify the 'FrameworkName' in the above simulation.input file), whose cell length a, b and c are all equal to 26.343 Å, the simulation can run correctly.

In addition, if I run the simulation of Cu-BTC with 2*2*2 unit cells rather than 1*1*1 unit cell, the simulation will also crash with a Segmentation Fault.

A similar problem had been reported previously in this forum by neumannrf:

https://forums.iraspa.org/index.php?topic=1018.msg1252#msg1252


neumannrf simulated TER.cif (cell length a, b and c are 9.8070 Å,  23.6460 Å and 20.2420 Å, respectivly) with 3*2*2 unit cells and got a Segmentation Fault, but when he used 1*1*1 unit cell, the calculation ran correctly. This is similar to the case of Cu-BTC, but for ZIF-20, even running the simulation with 1*1*1 unit cell leads to a Segmentation Fault.

Following neumannrf's debug steps, I also recompiled RASPA (v2.0.47) with CFLAGS="-w -ggdb -O0" and executed (in the case of ZIF-20 with 1*1*1 unit cell)

Code Select Expand


gdb ~/RASPA/simulations/bin/simulate

(gdb) run
Starting program: ~/RASPA/simulations/bin/simulate
_cell_length_a: 45.472500
_cell_length_b: 45.472500
_cell_length_c: 45.472500
_cell_length_alpha: 90.000000
_cell_length_beta: 90.000000
_cell_length_gamma: 90.000000
_symmetry_space_group_name_Hall: P 1 found space group: 1
_symmetry_space_group_name_H-M: P 1 found space group: 1
_symmetry_Int_Tables_number: 1
space group found from symmetry elements: 1 (nr elements: 1)
End reading cif-file
'force_field.def' file not found and therefore not used

Program received signal SIGSEGV, Segmentation fault.
0x00007ffffe82d2f4 in PrecomputeFixedEwaldContributions () at ewald.c:1078
1078          Eikx[j*MaxNumberOfCoulombicSites+i].re=Eikx[(j-1)*MaxNumberOfCoulombicSites+i].re*Eikx[MaxNumberOfCoulombicSites+i].re-

(gdb) bt
#0  0x00007ffffe82d2f4 in PrecomputeFixedEwaldContributions () at ewald.c:1078
#1  0x00007ffffeb2b015 in ReadInput (
    input=0x8009b90 "SimulationType", ' ' <repeats 16 times>, "MonteCarlo\nNumberOfCycles", ' ' <repeats 16 times>, "0\nNumberOfInitializationCycles  0\nPrintEvery", ' ' <repeats 20 times>, "100\nRestartFile", ' ' <repeats 19 times>, "no\n\nForcefield", ' ' <repeats 17 times>...) at input.c:9030
#2  0x00007ffffeae35b0 in ReadInputFile (filename=0x8008910 "simulation.input") at input.c:208
#3  0x00007fffff117c7f in run (inputData=0x8008910 "simulation.input", inputCrystal=0x8008930 "",
    raspaDir=0x7ffffffee268 "~/RASPA/simulations/", stream=false) at run.c:97
#4  0x00000000080014ba in main (argc=1, argv=0x7ffffffedf28) at main.c:106

(gdb) frame 0
#0  0x00007ffffe82d2f4 in PrecomputeFixedEwaldContributions () at ewald.c:1078
1078          Eikx[j*MaxNumberOfCoulombicSites+i].re=Eikx[(j-1)*MaxNumberOfCoulombicSites+i].re*Eikx[MaxNumberOfCoulombicSites+i].re-

(gdb) p MaxNumberOfCoulombicSites
$1 = 1024
(gdb) p i
$2 = 4351
(gdb) p j
$3 = 9
(gdb) p  Eikx[j*MaxNumberOfCoulombicSites+i].re
Cannot access memory at address 0x7fff8c505000
(gdb) p Eikx[(j-1)*MaxNumberOfCoulombicSites+i].re
$4 = 0.99841316505325695


It seems the fault is due to the inaccessible memory, so I guess the charge equilibration method for relatively large MOFs might require a lot of memory. However, I observed that during the simulation, only abount 2 G memory was used whereas my computer has a total memory of 32 G. By the way, I ran the simulation in WSL (Windows Subsystem for Linux).

In a sum, my questions are: is the segmentation fault described above due to the implementation of the charge equilibration method in RASPA? Or is it because I do something wrong? How can I compute the charges of relatively large frameworks (such as ZIF-20) in RASPA?

Any suggestions would be greatly appreciated.

Best regards,
Lingxiao Qin