Failed to delete lmp pointer

Hi,
I want to delete lmp pointer in try catch as follows:
#include <map>
#include <string>
#include <vector>
#include <fstream>
#include <iostream>
#include <cstdio>
#include <cstdlib>
#include <cmath>
#include “mpi.h”

#include “lammps.h”
#include “input.h”
#include

using namespace std;
using namespace LAMMPS_NS;

int main(int argc,char **argv)
{
MPI_Init(&argc,&argv);
string cmd=“”;
int index=0;
const char *lmpargv[] = { “liblammps”};

int lmpargc = sizeof(lmpargv)/sizeof(const char *);
LAMMPS *lmp = new  LAMMPS(lmpargc, (char **)lmpargv, MPI_COMM_WORLD);
lmp->input->one("units           real");
lmp->input->one("atom_style      charge");
lmp->input->one("box tilt large");
lmp->input->one("read_data       data.Rh111_surface");
lmp->input->one("pair_style      reaxff NULL safezone 10 mincap 100 minhbonds 100");
lmp->input->one("pair_coeff      * * ffield.reax    Rh");
lmp->input->one("neighbor        2 bin");
lmp->input->one("neigh_modify    every 10 delay 0 check no");
lmp->input->one("timestep        0.25");
lmp->input->one("fix             1 all qeq/reaxff 1 0.0 10.0 1e-6 reaxff");
lmp->input->one("thermo_style    custom step elapsed elaplong dt time temp epair ke pe etotal press");
lmp->input->one("thermo          1");
lmp->input->one("dump            1 all custom 1 dump.custom id element x y z");
lmp->input->one("dump_modify     1 sort id element Rh format float %8.8f");
lmp->input->one("min_style       cg");
try{
lmp->input->one("minimize 0.0 1.0e-4 10000 10000");}
catch(...)
{

cout<<"err"<<endl;
delete lmp;
throw 0;
}
cout<<"err2 "<<endl;
delete lmp;

MPI_Finalize();

return 0;

}

But failed:
ERROR on proc 0: step 36: ran out of space on angle_list: top=1905, max=1000 (…/reaxff_valence_angles.cpp:381)
err
*** Error in `./a.out’: free(): invalid next size (normal): 0x0000000002c3c1f0 ***

I don’t know why I can’t delete lmp when ran out space. How to solve it?

The problem is a limitation of the ReaxFF code. When the error message is printed, your memory is already corrupted since you have exceeded the reserved memory buffers.
From that state there is no recovery. This is usually caused by starting from a geometry that undergoes too many changes. ReaxFF has some heuristic memory management approach for its many dynamic buffers that assumes you are starting from a geometry that is already close to its equilibrium state. Obviously, that is not the case for your system.

You cannot use ReaxFF for this calculation. You need to look for some other force field.

I’m trying to optimize the ReaxFF parameters to fit DFT data with GA, so it is very likely to undergo too many changes for a geometry using an individual. My thoughts are that I catch an exception when lammps calculations fail and produce a new individual to calculate again. if I do not delete lmp pointer before throw, I found that the new calculation gives “Segmentation fault” when carrying out:
LAMMPS *lmp = new LAMMPS(lmpargc, (char **)lmpargv, MPI_COMM_WORLD);

Can I interrupt the calculation just before exceeding the reserved memory buffers and delete lmp normally?

That will not work with the ReaxFF implementation in LAMMPS. Not like this. As I already wrote, it can detect memory corruption only after the fact. So the only way to start over is to let the executable exit and start new.

No. I already explained that.

You say, " let the executable exit and start new".
But why the new calculation gives “Segmentation fault” when carrying out:
void call_lammps(string ffieldfile , string name, int index, const MPI_Comm &comm, double *res)
{ …
LAMMPS *lmp = new LAMMPS(lmpargc, (char **)lmpargv, MPI_COMM_WORLD); ? //Segmentation fault

}
Does it mean I need to compile the function as an executable or a static library instead of only recalling the function?

For the last time: once you have corrupted memory, you must abort. There is no way to recover from that. So you cannot do what you are trying to do the way you are doing it. Changing that way how you compile or link with LAMMPS makes no difference.

If you don’t understand this, then I cannot help you.

The KOKKOS package version of ReaxFF is much more memory robust and should never error out with these types of memory issues, unless you truly exhaust all available memory on the system. You can run Kokkos in MPI-only mode which is similar to the original CPU version of the code. So I would try using the KOKKOS version of ReaxFF.