I would agree with Steve, combining systems in-house can be a powerful
(clean and quick) tool.
This more obviously diverges from 'building the system' when at least one of
the systems is to be run in lammps separately first. In this case, the
'read_data add' option would become more relevant if it could be used after
a read_restart command. This would require being able to previously tell
lammps to reserve space for extra atom types the same way you can tell it to
reserve space for a certain number of bonds per atom. Axel, did you suggest
this was already possible?
not with restarts. here is the basic rundown of the available options
and facilities:
- restarts should only be used for continuing simulations. at best you
can switch fixes or force field parameters.
- everything else should be done with data files via read_data, and/or
create_box, create_atoms.
- restart files can be converted into data files with the -r command
line flag, or with read_restart followed by write_data. or you can
simply also do write_data directly at the end of your preparatory
simulations. data files are by far more portable and backwards
compatible than restarts, too.
those data files will contain velocities, so there isn't anything
important lost.
- with create_box you can reserve sufficient extra space for all kinds
of topology data. please see the manual.
- so create_box followed by multiple read_data add is pretty much the
only option to combine topologies that does not require changing the
individual files, provided you set the corresponding offsets
accordingly. if you want that step to be done automatically, you
*have* to do it with an external tool.
Ignorant of the coding issues, it would also be great to be able to
automatically add any read_data to any read_data or restart file (which
would be essentially assuming that all incoming atom types, etc. are new to
the system).
that is not desirable for the technical reasons i already outlined. it
also won't work in the generality of force fields that LAMMPS supports
as it implicitly assumes that all mixed force field parameters between
the different atom types can be inferred from mixing rules. for a
large number of simulations that people run with LAMMPS, this is not
given, so this kind of feature would require a very complex operation
to be implemented and would still only benefit a few users. there are
many things that would be nice to have, but here is a limitation that
is due to the basic design of LAMMPS that cannot be easily removed
without massively impacting the performance. since the same operation
is rather easy to do externally, there is no good argument to do it
from inside LAMMPS.
in fact, merging multiple topologies from data files under the
assumption that you have a class 1 force field with global mixing for
LJ parameters and need to check atom/bond/angle/dihedral/improper
types for overlap is pretty straightforward to program in a scripting
language like perl, python or Tcl. while features in LAMMPS should
work for many different cases, you can write that script to only
support your special use case and that would eliminate almost all of
the complications.
here is some pseudo code for it.
program takes multiple data files as arguments.
open all files and parse the header part. record the total number of
entities (atoms, bonds etc.) and types and the offsets for each file.
open the output file and write out a suitable combined header
now process each section, again looping over each file and apply the
predetermined offsets for types and ids, while writing the augmented
data to the new file. that requires some familiarity with list
manipulations in the scripting language of choice, but either perl,
python or tcl are well suited for that.
to summarize.
- type counts and other topology related parameters in LAMMPS are
locked in when the box is created; either directly or when a restart
or data file is read. nobody will change that, as that is at the very
core of how LAMMPS works and needed to run efficiently.
- automated combining of topologies only works with additional
constraints in place (e.g. the kind of force field). that is often
very project specific and then really easy to program as an external
tool for that particular use case. trying to shoehorn this into LAMMPS
itself is not a good idea and would be a massive effort.
when looking at the how lammps is implemented. the only way how i
could imagine to make this works would be to implement a variant of
the "clear" command, lets call it "suspend", that would create a new
instance of the LAMMPS class, but not delete the old instance of the
LAMMPS class, instead it keeps a pointer to it available and assign it
a label. then you would basically do the same thing as with setting up
(and running) multiple independent consecutive simulations, but rather
than using clear to wipe out the old version, you keep it and then you
could have a "combine" command to build yet another new instance of
the LAMMPS class with the combined data from multiple suspended
instances, or possible also a "switch" command that would cycle
between those suspended instances. as you probably see from this
description, this doesn't sound as easy as writing a (small) script to
combine data files.
axel.