in order to generally implement the force fields I am using, I thought I would define all possible *_coeffs in separate file (i.e. enumarate all possible pair_coeff, bond_coeff etc.), which will be called from input script with include, and then I would only have to correspondingly label all types in data file. In that way, I wouldn’t have to care about potentials and only generate the data file, whilst keeping the scripts relatively “clean”.
The problem is the separate files with all coefficients is overdefined. It also includes the labels, which are not used in current job (e.g., for job with united-atom propane, the coefficients for sp2 carbons are not necessary), and LAMMPS sees it as error (ERROR: Atom type string (…) not found in labelmap.)
Is there a possiblity how either:
ignore *_coeffs with unused labels and use it directly for definition of coefficients, or
from the included file create a new file (possibly with write_coeff) which will only include the currently needed coefficient definiton?
That sounds like a neat idea, but there are a number of problems.
Generally, I would suggest you do the force field assignment with an external tool (e.g. written in python). You don’t need to put the coefficients into the data file, but can just generate a file with XXX_coeff commands and can be included. If you use the same base name for input, include, and data file, then should allow for a rather effective management of the files. This will allow you to use all kinds of labels and aliases in your scripts, but have the LAMMPS files just use the minimal numbers.
Otherwise, you would have to create the initial box with a create_box command reserving space for all possible types, even if you don’t use them. Define labelmaps that include all types for all kinds of interactions and so on. Particularly for the pair_coeff commands, that can become a lot. Having many types also has some performance limitations compared to having only the minimal set.
This kind of inflexible behavior has historic reasons, but also is a side effect of LAMMPS not being optimized for some specific kind of systems (like biopolymers) but rather for a large variety of systems with very different interactions. So the typical workflow is a bit different.
Since you label this as a beginner question, I have one more advice: do not try to “optimize” your workflow before you have sufficient experience. Rather just keep things simple and just follow some regular patterns and only when you have spend a significant amount of time running simulations you can re-evaluate whether these workflow optimizations are actually worth the effort. I have seen lots of people spending a lot of time on “premature optimization” only to find out that they had to make changes and redo everything multiple times and in the end lost time instead of saving it.
A practical problem is that a mega-parameter file is difficult to share and difficult to debug. The latter is especially tricky because all you need is to have one wrong “type” in your simulation and suddenly you will be getting nonphysical results.
You may be interested in Moltemplate, which has capabilities to specify the mega-parameter files you’re thinking of, automatically select relevant types, and prepare LAMMPS data and input files that only contain the relevant potential terms. That way your actual script inputs are “lean” (contain only relevant types) and are more easily shared and debugged.
Thank you kindly for your advices, I will then write another script to filter only those xxx_coeffs that are necessary. I thought and hoped it could be bypassed, but I understand the limitations.
I wouldn’t try to enhance the workflow if I were complete begginer, I’ve been using LAMMPS for the last two years and began to feel more comfortable with it. Yet I feel it is so complex (which is its enorm advantage), I will never be truly non-begginer.
That’s sadly not the case, since the error occured right after LAMMPS loaded the first of the overdefined pair_coeffs.
Maybe I could try experiment with it a bit more, if you say it should be possible, maybe it’s only some kind of formatting error, but I feel creating a script to filter only the needed coefficients would be faster, at least for now.
But thank you for your remark!
The file was not extraordinarly large, since I need only few interactions and they are partially covered using mixing rules. But for large and diverse system, I imagine it could become enormous quite quickly.
I don’t like to rely on external programs, I prefer to script my own (in order to understand what it is really doing) but I thank you for you tip, maybe I will use it at least for confronting my results.
we many be able to provide more precise suggestions if you provide a working example. However, I certainly agree with the advice of others on this thread to keep your coefficients input as simple as possible