Unable to get Lammps to include MOLFILE package in installation

[chaitu]

Hi everyone,

Lammps Version: 29 August 2024, System OS: Ubuntu 22.04 LTS.

I dumped xtc trajectory files in a lammps simulation which I want to rerun using lammps.
The dump command was as follows:

dump TRAJ all xtc ${samplefreq} charge1.xtc
dump_modify TRAJ precision 1000000

And the rerun command looks like this:

rerun ../charge1.xtc dump x y z format molfile xtc

However, upon running the rerun script, I get the following error:

ERROR: Unrecognized reader style 'molfile' is part of the MOLFILE package which is not enabled in this LAMMPS binary. (src/read_dump.cpp:236)
Last command: rerun ../charge1.xtc dump x y z format molfile xtc

This tells me that my lammps binary was not built with MOLFILE package. Hence I rebuilt it to include MOLFILE package using the following sequence of commands:

1. cmake -C ../cmake/presets/basic.cmake -C ../cmake/presets/intel.cmake -D MOLFILE_INCLUDE_DIR=/home/chaitanya/softwares/vmd-1.9.3/plugins/include -D PKG_MOLFILE=yes -D BUILD_SHARED_LIBS=yes ../cmake
2. make -j 48

I did not do make install as I do not want to overwrite the existing lammps shared libraries. So I use the whole path of this binary while running the rerun script.

Even after building the new lammps binary with MOLFILE package, the same error occurs. I tried to check the installed packages in this new binary using the lmp -h command, but it does not show MOLFILE as one of the installed packages.

I have also put the gromacsplugin.so file in the directory where I am running the rerun script. But the same error persists. Can someone help me with this? I am unable to figure out what I am missing here.

Thanks, and regards,
Chaitanya

[akohlmey]

@chaitu

I am unable to figure out what I am missing here.

You should do two things with both LAMMPS executables in order to debug what is happening.

1. provide the output of lmp -h
2. provide the output of ldd lmp

[chaitu]

Hello Axel,

Thank you for your quick response. As per your suggestion, I am providing the outputs of lmp -h and ldd commands for both the lammps I have used.

The lmp -h output for the first lammps is in file lmp_help_1.txt and for the newly built lammps it is in lmp_help_2.txt. See my new comment.

The outputs of the ldd command for the first lammps is:

        linux-vdso.so.1 (0x00007ffc32ba3000)
        liblammps.so.0 => /home/chaitanya/.local/lib64/liblammps.so.0 (0x00007fe0ec6c5000)
        libmpicxx.so.12 => /opt/intel/oneapi/mpi/2021.14/lib/libmpicxx.so.12 (0x00007fe0ec400000)
        libmpi.so.12 => /opt/intel/oneapi/mpi/2021.14/lib/libmpi.so.12 (0x00007fe0e2400000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe0e21d4000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe0e20ed000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe0ec690000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0e1ec4000)
        libimf.so => /opt/intel/oneapi/compiler/2025.0/lib/libimf.so (0x00007fe0e1ab8000)
        libsvml.so => /opt/intel/oneapi/compiler/2025.0/lib/libsvml.so (0x00007fe0e0477000)
        libirng.so => /opt/intel/oneapi/compiler/2025.0/lib/libirng.so (0x00007fe0e037e000)
        libintlc.so.5 => /opt/intel/oneapi/compiler/2025.0/lib/libintlc.so.5 (0x00007fe0ec62c000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe0ec627000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe0ec622000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe0ed440000)

while that for the new lammps is:

        linux-vdso.so.1 (0x00007ffe86963000)
        liblammps.so.0 => /home/chaitanya/.local/lib64/liblammps.so.0 (0x00007f5b254cc000)
        libmpicxx.so.12 => /opt/intel/oneapi/mpi/2021.14/lib/libmpicxx.so.12 (0x00007f5b25200000)
        libmpi.so.12 => /opt/intel/oneapi/mpi/2021.14/lib/libmpi.so.12 (0x00007f5b1b200000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5b1afd4000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5b1aeed000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5b25497000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5b1acc4000)
        libimf.so => /opt/intel/oneapi/compiler/2025.0/lib/libimf.so (0x00007f5b1a8b8000)
        libsvml.so => /opt/intel/oneapi/compiler/2025.0/lib/libsvml.so (0x00007f5b19277000)
        libirng.so => /opt/intel/oneapi/compiler/2025.0/lib/libirng.so (0x00007f5b1917e000)
        libintlc.so.5 => /opt/intel/oneapi/compiler/2025.0/lib/libintlc.so.5 (0x00007f5b25433000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5b2542e000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5b25429000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5b26247000)

I hope this can help in debugging the issue.

Thanks, and regards,
Chaitanya

[chaitu]

PFA.

The output of the lmp-h command is big and hence I am providing it in files as an attachment.

Sorry I am attaching files in a new comment as there was some error in uploading the files.
This is the output for the first lammps used for running the simulations
lmp_help_1.txt (12.3 KB)

and this is the output for the newly build lammps with MOLFILE package.
lmp_help_2.txt (12.3 KB)

-Chaitanya

[srtee]

You may have linked the same file twice. Your second link leads to a file suffixed “1” which doesn’t show a MOLFILE package compiled.

[chaitu]

Hi Shern,

You are right. But I did upload two different files, one with suffix “1” and another with “2”. But the second file is getting renamed as the first one, even after multiple tries.

However, the output from lmp -h command for both the lammps is indeed exactly the same. So, I think it does not matter.

You are correct in pointing out that the lmp_help_2.txt does not contain MOLFILE package in the installed package list. But that is the issue I am facing as I have mentioned in my original post. That is why I am seeking help.

I hope you understand my problem.

Thanks,
Chaitanya

[akohlmey]

@chaitu

        liblammps.so.0 => /home/chaitanya/.local/lib64/liblammps.so.0 (0x00007fe0ec6c5000)

@chaitu

        liblammps.so.0 => /home/chaitanya/.local/lib64/liblammps.so.0 (0x00007f5b254cc000)

Both executables use the same shared library path. This is probably because you have set the LD_LIBRARY_PATH environment variable. The lmp executable does not much but load the LAMMPS library and then use its content. You can avoid such problems by setting -D BUILD_SHARED_LIBS=off.

@chaitu

I am providing it in files as an attachment.

Both links point to the same file.

[chaitu]

Dear Axel,

The files attached were two different files but while uploading the second file always gets renamed/changed to the file lmp_help_1.txt. I am not sure why this is happening.

However, the output for lmp -h command for both lammps is the exactly the same.

I did turn the option to build shared libraries because sometimes I use lammps as a library with a fortran code. Will turning off that flag sort the issue?

-Chaitanya

[akohlmey]

@chaitu

Will turning off that flag sort the issue?

I have new nothing to add to my previous response. You should know from previous exchanges how much I dislike it when people don’t read my responses carefully and ask questions that I have already answered.

@chaitu

I did turn the option to build shared libraries because sometimes I use lammps as a library with a fortran code.

You don’t have to do this for both executables. Please read up on shared libraries and understand what happens here. Also, you can link Fortran code to the static library as well. You need a shared library only for the Python module.

[chaitu]

Hi Axel,

Thank you for your help. I can now rerun with xtc trajectory files.

Thanks, and regards,
Chaitanya