I use C H O Ti and P which have parameters in the reaxff for the model I am using. There is no separate indication of O or H which are used for both the surface, solvents and solutes, Reax must make that distinction.
The issue I have is in visualizing in vmd . I would like to hide the solvent, but I do not know how to group the molecules in lammps while using the reaxff
Since the reaxff /charge requires 5 columns in the data file, the mol ID column is deleted. I tried using reax/species for grouping but have not been successful.
The atom_ style is * * TiOCHF.ff C H O P TI. So how would one the visualize TIO2, C2H5OH and a phosphate as separate entities in vmd ?
vmd is not much help since only the atom numbers are listed as ‘names’ and O and H appear on both organics and the Ti surface
Please note that the VMD part of your question is effectively off-topic for this category and better asked on the VMD mailing list. That said, VMD is not automatically a good choice for studying reactive force field simulations, since VMD being originally conceived to visualize CHARMM force field simulations implicitly assumes that the bonds don’t change. There is a “Dynamic Bonds” representation that can recompute bonds based on distance.
ReaxFF makes no use of molecule IDs hence the use of atom style “charge”. But there are multiple ways to include them. The atom style “charge” only includes atomic parameters with the charge property added, but you could just use atom style “full” which is a superset of “charge”. Also atom style “hybrid charge bond” would include charges and molecule IDs. And finally, molecule IDs can be added to a system via fix property/atom (check out the documentation). I all cases, the format of the data file will be different though.
It is not “deleted” but just wasn’t added.
Fix reaxff/species is the way to query the ReaxFF pair style for how it “sees” the system as molecules (based on the computed bond order). Mind you, as a reactive force field, it may determine that there are bonds where you don’t desire them, but where the bond order is large enough for reaxff/species to say there is one.
There are some special hacks in the VMD molfile plugin reader to obtain information that is otherwise not readily available via the molfile plugin API. Those can be set via environment variables, e.g. LAMMPSREMAPFIELDS can be used to pick a different column in an output file as molecule ID. Homepage of Axel Kohlmeyer - LAMMPS VMD plugin
However, those are still limited by the “one topology per simulation data set” approach.
Using an alternate visualizer that was designed with LAMMPS in mind, like OVITO, may be an alternative.
Another alternative would be assigning atom IDs in the data file following a pattern that would also allow to group atoms based on the atom ID ranges.
Thank you very much for the prompt and thoughtful response.
Regarding the ‘deletion’ : the model was created in Samson which writes the data file in full format, hence, I must remove column 2 but it also writes out a column of #-atom names . Following your suggestion, perhaps merging/moving col 2 behind the # can lead to a solution. that could provide atom-mol in the input. Convincing lammps to keep track of that for the output needs some thought.
I am reasonably good friends with vmd and use the dynamic bonds mode. In fact one must use it and alter bond length to the measured values to make sense of the visual result. I will look closer at the species command and give ovito a try as well
You can use “full” directly. Almost anything following a “#” character is considered a comment in the data file reader in LAMMPS. This is a convention introduced by TopoTools in VMD to pass (optional) alphanumeric info from data files to VMD. TopoTools will only look for it, if there is a CGCMM keyword in the (otherwise ignored) title line of a data file. LAMMPS only uses it for verifying intended atom/pair/bond/angle/etc styles.
There is some limited support for symbolic types in LAMMPS now with the “typelabel” facility (8.2.2. Type labels — LAMMPS documentation). It is more geared to classical force fields, though. There is a forthcoming publication on that including some use cases for fix bond/react and the OpenKIM interface in VMD.
There must have been a mistake on your side. There is no principal problem with using an atom style that is a superset of another. The biggest challenge is usually to avoid writing out a bond topology. In TopoTools/VMD this is easily removed. It is also easily removed with a text editor (much easier than columns from the Atoms section), since it requires the removal of entire sections.
Please provide an example where using atom style full fails and we can have a look.