Reaxff ffield file handle exists after fclose

Hi,
I am confused why the handle of Reaxff ffield file ffield.reax still exists after then command “pair_coeff * * ffield.reax C H” have been carried out.
I write a call_lammps.cpp:
#define LAMMPS_LIB_MPI
#include
#include
#include
#include
#include
#include
#include

#include “mpi.h”

#include “lammps.h”
#include “input.h”
#include “atom.h”
#include “output.h”
#include “thermo.h”

using namespace std;

using namespace LAMMPS_NS;

int main(int argc, char *argv[])
{
int comm_size,rank;
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&comm_size);

    string cmd="";
    const char *lmpargv[] = { "liblammps","-screen", "none"};
    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.input");
    lmp->input->one("pair_style reaxff NULL safezone 10 mincap 100 minhbonds 100");

    cmd="pair_coeff * * ffield.reax C H";
     cout<<"a0 "<<endl;
    lmp->input->one(cmd);
     cout<<"a1 "<<endl;

    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 1.0e-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("fix             2 all nvt temp 300.0 300.0 100.0");
    lmp->input->one("run 1000000");
    cout<<"a2 "<<endl;

    delete lmp;
    cout<<"a3 "<<endl;

    MPI_Finalize();

    return 0;

}

and revise the text_file_reader.cpp:
TextFileReader::~TextFileReader()
{
std::cout<<textfilename<<" file1 “<<std::endl; // I have added “textfilename” in text_file_reader.h file
if (closefp)
{
std::cout<<textfilename<<” file2 “<<std::endl;
fclose(fp);
std::cout<<textfilename<<” file3 “<<std::endl;
}
std::cout<<textfilename<<” file4 "<<std::endl;
}

after I run ./a.out , it immediately print:
ffield.reax file1
ffield.reax file2
ffield.reax file3
ffield.reax file4
ffield.reax file1
ffield.reax file2
ffield.reax file3
ffield.reax file4
file1
file4
a1
This indicates that ffield.reax file has been closed. But I use lsof -p 143846 and found:
a.out 143846 hongchang 0u CHR 136,6 0t0 9 /dev/pts/6
a.out 143846 hongchang 1u CHR 136,6 0t0 9 /dev/pts/6
a.out 143846 hongchang 2u CHR 136,6 0t0 9 /dev/pts/6
a.out 143846 hongchang 3w REG 8,32 28270592 127143174 /home/hongchang/wangjie/ffopt/ts-search/lammps-29Sep2021-3/src/test/CH/log.lammps
a.out 143846 hongchang 4r REG 8,32 9057 127143177 /home/hongchang/wangjie/ffopt/ts-search/lammps-29Sep2021-3/src/test/CH/ffield.reax

The handle of ffield.reax file still exists!
So if I produce ffield.reax files many times according to different parameters and use these files in the cpp , the handles will exceed max number of files that can be opened (such as 65535) and then errors
like “ERROR: Cannot open file data.Rh_dc_bulk: Too many open files” occur.
How can I close the handle of ffield.reax indeed?

I cannot reproduce this. There must be something wrong with how you do your checking or how lsof works on your platform.

When I add the line shell lsof at the end of the examples/reaxff/in.reaxff.rdx example, and then use grep to find the relevant open files, I only see this:

lmp       621970                         akohlmey  cwd       DIR              259,5       4096    2629867 /home/akohlmey/compile/lammps/examples/reaxff
lmp       621970                         akohlmey  rtd       DIR              259,4       4096          2 /
lmp       621970                         akohlmey  txt       REG              259,5     299176    2634952 /home/akohlmey/compile/lammps/build-test/lmp
lmp       621970                         akohlmey    0u      CHR              136,5        0t0          8 /dev/pts/5
lmp       621970                         akohlmey    1w     FIFO               0,13        0t0    1447526 pipe
lmp       621970                         akohlmey    2u      CHR              136,5        0t0          8 /dev/pts/5
lmp       621970                         akohlmey    3u     IPv4            1444515        0t0        TCP *:56057 (LISTEN)
lmp       621970                         akohlmey    4w      REG              259,5       8879    2643163 /home/akohlmey/compile/lammps/examples/reaxff/log.lammps
lmp       621970                         akohlmey    5r      REG              259,5       1438    2643165 /home/akohlmey/compile/lammps/examples/reaxff/in.reaxff.rdx

Same with using strace with the command line: strace -v ../../build-test/lmp -in in.reaxff.rdx 2>&1 | egrep '^(open|close)'

[...]
openat(AT_FDCWD, "log.lammps", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
openat(AT_FDCWD, "in.reaxff.rdx", O_RDONLY) = 5
openat(AT_FDCWD, "data.rdx", O_RDONLY)  = 6
close(6)                                = 0
openat(AT_FDCWD, "data.rdx", O_RDONLY)  = 6
close(6)                                = 0
openat(AT_FDCWD, "control.reax_c.rdx", O_RDONLY) = 6
close(6)                                = 0
openat(AT_FDCWD, "ffield.reax", O_RDONLY) = 6
close(6)                                = 0
openat(AT_FDCWD, "ffield.reax", O_RDONLY) = 6
close(6)                                = 0
openat(AT_FDCWD, "ffield.reax", O_RDONLY) = 6
close(6)                                = 0
openat(AT_FDCWD, "ffield.reax", O_RDONLY) = 6
close(6)                                = 0
close(4)                                = 0
close(5)                                = 0

All the times the ffield.reax file is opened it gets assigned file descriptor 6 which is closed afterwards.

I change the machine and carry out the example in examples/reaxff/RDX by lmp_mpi < in.RDX & and
lsof -p 16261, I found the ffield.reax file:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
lmp_mpi 16261 wanggc cwd DIR 8,17 4096 32359 /home/wanggc/wangjie/Scripts/lammps/lammps-29Sep2021/examples/reaxff/RDX
lmp_mpi 16261 wanggc rtd DIR 8,3 4096 2 /
lmp_mpi 16261 wanggc txt REG 8,17 210330662 3222823666 /home/wanggc/wangjie/Scripts/lammps/lammps-29Sep2021/src/lmp_mpi
lmp_mpi 16261 wanggc mem REG 8,3 156928 20054561 /lib64/ld-2.12.so
lmp_mpi 16261 wanggc mem REG 8,3 599384 20054563 /lib64/libm-2.12.so
lmp_mpi 16261 wanggc mem REG 8,3 1926800 20054562 /lib64/libc-2.12.so
lmp_mpi 16261 wanggc mem REG 8,3 1043008 13900650 /usr/lib64/libfftw3.so.3.2.3
lmp_mpi 16261 wanggc mem REG 8,3 145896 20054089 /lib64/libpthread-2.12.so
lmp_mpi 16261 wanggc mem REG 8,3 91096 20054566 /lib64/libz.so.1.2.3
lmp_mpi 16261 wanggc mem REG 8,3 47064 20054575 /lib64/librt-2.12.so
lmp_mpi 16261 wanggc mem REG 8,3 157960 13895361 /usr/lib64/libpng12.so.0.49.0
lmp_mpi 16261 wanggc mem REG 8,3 93320 20054576 /lib64/libgcc_s-4.4.7-20120601.so.1
lmp_mpi 16261 wanggc mem REG 8,3 989840 13898407 /usr/lib64/libstdc++.so.6.0.13
lmp_mpi 16261 wanggc mem REG 8,3 17520 20054580 /lib64/libutil-2.12.so
lmp_mpi 16261 wanggc mem REG 8,3 1672576 13899929 /usr/lib64/libpython2.6.so.1.0
lmp_mpi 16261 wanggc mem REG 8,3 5332190 2228953 /opt/intel/impi/5.0.1.035/intel64/lib/release/libmpi.so.12.0
lmp_mpi 16261 wanggc mem REG 8,3 1240587 2228927 /opt/intel/impi/5.0.1.035/intel64/lib/libmpifort.so.12.0
lmp_mpi 16261 wanggc mem REG 8,3 174311 2228924 /opt/intel/impi/5.0.1.035/intel64/lib/libmpicxx.so.12.0
lmp_mpi 16261 wanggc mem REG 8,3 988032 13895327 /usr/lib64/libgfortran.so.3.0.0
lmp_mpi 16261 wanggc mem REG 8,3 22536 20054565 /lib64/libdl-2.12.so
lmp_mpi 16261 wanggc 0r REG 8,17 420 32363 /home/wanggc/wangjie/Scripts/lammps/lammps-29Sep2021/examples/reaxff/RDX/in.RDX
lmp_mpi 16261 wanggc 1u CHR 136,1 0t0 4 /dev/pts/1
lmp_mpi 16261 wanggc 2u CHR 136,1 0t0 4 /dev/pts/1
lmp_mpi 16261 wanggc 3w REG 8,17 0 179054 /home/wanggc/wangjie/Scripts/lammps/lammps-29Sep2021/examples/reaxff/RDX/log.lammps
lmp_mpi 16261 wanggc 4r REG 8,17 12745 32362 /home/wanggc/wangjie/Scripts/lammps/lammps-29Sep2021/examples/reaxff/RDX/ffield.reax.rdx

And I strace -v lmp_mpi < in.RDX 2>&1 | egrep ‘^(open|close)’ ,found:
open(“log.lammps”, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
open(“data.RDX”, O_RDONLY) = 4
close(4) = 0
open(“data.RDX”, O_RDONLY) = 4
close(4) = 0
open(“lmp_control”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
open(“param.qeq”, O_RDONLY) = 5
close(5) = 0
close(3) = 0

Here ffield.reax.rdx is not closed when opened last time.
Can you give me your in.* file?

It is unchanged in the LAMMPS distribution.
After looking more closely at your output, I see that you are using an older LAMMPS version. That is always a bad idea™ if you are tracking down unexpected behavior.

As it turns out, you have found a bug (again) that has been found and fixed already:

$ git log REAXFF/reaxff_ffield.cpp
commit 79a9829e9259fde03174e4d53adc2adc2451aaa5
Author: Richard Berger <[email protected]>
Date:   Sat Jan 22 09:56:01 2022 -0500

    Apply override to remaining classes

commit 1185591c768dc65fbedb2e14efa8ff1f2f429465
Author: Axel Kohlmeyer <[email protected]>
Date:   Thu Dec 23 08:20:47 2021 -0500

    add missing fclose()

commit 71a24580b8eadcff62d11c88630d4e173941dd19
Author: Axel Kohlmeyer <[email protected]>
Date:   Sat Oct 23 04:24:54 2021 -0400

    remove parser_error exception class ambiguity completely

[...]

Thanks for your reply. After installing lammps-23Jun2022, the ffield.reax file has been closed:
open(“data.RDX”, O_RDONLY) = 4
close(4) = 0
open(“data.RDX”, O_RDONLY) = 4
close(4) = 0
open(“lmp_control”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
close(4) = 0
open(“ffield.reax.rdx”, O_RDONLY) = 4
close(4) = 0
open(“param.qeq”, O_RDONLY) = 4
close(4) = 0
close(3) = 0