Please note that the people responding here are volunteering their time and also are not familiar with your research, so if you want to get help you have to make it as easy as possible to help you. Unfortunately, your post is the exact opposite of that.
There are multiple issues here:
- LAMMPS does NOT stop prematurely without any error message. You probably have not looked in the right place. When running in parallel on a cluster, you may not find the error in the log file, but in the output to stderr. Thus you must not suppress that.
- You report that you are using a LAMMPS version that is neither the latest feature version not the latest stable version. So it is up to you to see if there is perhaps a problem that has since been fixed.
- You use an input deck that uses a directory hierarchy to collect its output. While this may be convenient to you, it is extremely annoying for testing. It would be better to have an input deck that can be run from a flat hierarchy like the LAMMPS examples and benchmark inputs
- You do not provide any information about how you compiled and run LAMMPS and what kind of platform you are running on with how many processors and whether this can be easily reproduced on a desktop machine with a few (say no more than 8) processors. Since this is what most people have available for testing and exploring which modifications to your input could resolve the issue you are seeing
- Your input deck is a complex multi-step calculation. That is wasting your and other people’s time trying to debug what is wrong. You can (and in parts you do) output suitable data files after each stage of your simulation, so you could have told a) at which stage the simulation fails and b) constructed an input file that started from the data file preceding the failure, so that the other steps do not have to be repeated by everybody.
- Your input deck is cluttered with lots of statements for collecting data for your analysis and creating output. This should be removed when they have no impact on the trajectory itself. This will either avoid the crash, and then you can easily narrow down which of those triggers the crash and then construct a minimal input deck with only that one set of commands that cause the trouble, or it will be easier to determine which features of LAMMPS could be failing on you.
- In general, the smaller your test system, the faster it can be run, the better the chances that somebody can help you narrow down the problem (please note my statement about not requiring a cluster to run the input). Some debugging tools slow down execution significantly so it can be very much worth to construct a new system that is very small (has as few atoms/molecules as possible to still reproduce the crash) and thus can be debugged more easily.
In summary, the more context you can provide and the more you can narrow down the issue to a minimal input deck that will reproduce the issue quickly, the better your chance to get help.
Your “here is an input deck that does not run to completion” type of post puts all the burden on the person that would potentially want to help you and thus your chances to get help are extremely low.