Confusion with pair_coeff...

Dear LAMMPS users,

I am used to the regular pair_coeff representation where first we have the pair coefficients in the following format:

 1 coeff1 coeff2 ...
  ...
  N coeff1 coeff2 ...              (N = # of atom types)

which is clear because you know which atom types are in question.

However, I came across an example in the peptide example folder, where there is pair coefficients listed without the coeff1 coeff2 notation. This is extremely confusing. How do I know what is going on and what the values actually represent?

This is an example from the pair coefficient part of the data file:
Pair Coeffs

1 0.110000 3.563595 0.110000 3.563595
2 0.080000 3.670503 0.010000 3.385415

Thank you for any input.

Anna

Dear LAMMPS users,

I am used to the regular pair_coeff representation where first we have the
pair coefficients in the following format:

1 coeff1 coeff2 ...
  ...
  N coeff1 coeff2 ... (N = # of atom types)

which is clear because you know which atom types are in question.

However, I came across an example in the peptide example folder, where there
is pair coefficients listed without the coeff1 coeff2 notation. This is

this notation is only true for lj/cut and lj/cut/coul/* and similar styles.

extremely confusing. How do I know what is going on and what the values
actually represent?

look at the pair_style. most pair styles require different number and
type of coefficients.

This is an example from the pair coefficient part of the data file:
Pair Coeffs

  1 0.110000 3.563595 0.110000 3.563595
  2 0.080000 3.670503 0.010000 3.385415

yes, as this input deck uses pair style lj/charmm/coul/long, which is
different from lj/cut/coul/long.

axel.

Thank you Axel. I am not sure I understand the particular example though, still have a mental block about it, sorry. So when we do not have a value for the atom types interacting, we assume it means * * in the other (straightforward) nomenclature. But this is not exactly what I need (and also seems awkward that all atom types would interact in the same way with other atom types)- Say I have C=1, N=2 and O=3. What I want to have is pair_coeff 1 1 (C-C interaction) with one set of parameters, 1 2 (C-N) with a different set of parameters, and so on (1-3, 2-2, 2-3, and 3-3) all with different set of parameters. I am not seeing something obvious conceptually, perhaps?

Thank you again

Anna

Thank you Axel. I am not sure I understand the particular example though,
still have a mental block about it, sorry. So when we do not have a value
for the atom types interacting, we assume it means * * in the other
(straightforward) nomenclature. But this is not exactly what I need (and

no.

also seems awkward that all atom types would interact in the same way with
other atom types)- Say I have C=1, N=2 and O=3. What I want to have is
pair_coeff 1 1 (C-C interaction) with one set of parameters, 1 2 (C-N) with
a different set of parameters, and so on (1-3, 2-2, 2-3, and 3-3) all with
different set of parameters. I am not seeing something obvious conceptually,
perhaps?

from the documentation of the Pair Coeffs section of the read_data command:

The number and meaning of the coefficients are specific to the defined
pair style. See the pair_style and pair_coeff commands for details.
Since pair coefficients for types I != J are not specified, these will
be generated automatically by the pair style’s mixing rule. See the
individual pair_style doc pages and the pair_modify mix command for
details. Pair coefficients can also be set via the pair_coeff command
in the input script.

for the CHARMM force field, the pair coefficients are usually only
provided for I, I pairs and the rest inferred from mixing. only pair
coefficients listed in NBFIX sections of the CHARMM parameter files
override those (and are currently ignored by the charmm2lammps
converter tools).

For pair styles that do not support mixing, one can also use a PairIJ
Coeffs section, which has a format that is equivalent to the
pair_coeff statement in the input.
personally, i avoid placing any Coeffs sections in data files and
rather using include files from the normal input script.

axel.