comm_modify - combine mode multi with cutoff option

LAMMPS LAMMPS Mailing List Mirror
1

Dear all,

I am wondering what happens when I combine the keywords "mode multi" and
"cutoff value" in the comm_modify command.

In my simulations, I am using a fluid with short interactions, for which
the mode multi is very beneficial, as it is combined with colloids with
longer cutoffs. I'd like to introduce longer bonds between the colloids,
for which I will need some extra communication distance.

The Manual states that when using multi, there will be a specific
communication distance cutoff for each species. When using cutoff, there
will be a ghost cutoff distance equal to what I specify in the command.
This could mean that the "cutoff" option overwrites all the different
cutoffs from "mode multi" with the value given.

I tried to infer what happens from the source code in comm_brick.cpp .
If I got it right, the specified extra ghost cutoff "cutghostuser" is
considered in the "cutghost" array, while "cutghostmulti" stores the
different cutoffs for all the species. (see l.165 ff.)
For the multi mode, the "boundaries for slab of atoms to send at each
swap" (l.315) are multilo/multihi , and they get assigned

multihi[iswap][i] = sublo[dim] + cutghostmulti[i][dim]; (l.348)
multilo[iswap][i] = subhi[dim] - cutghostmulti[i][dim]; (l.369)

from which I would assume that "cutghostuser" is not considered in the
communication, as "cutghostmulti" does not store information about it ?
So is the "cutoff value" option ignored when using "mode multi" in
comm_modify ?

Thank you very much for any hints!

Best wishes,

Martin Wagner

2

dear martin,

i think your review of the code is correct. i am not certain what is
the right way to address this issue directly by manipulating per
specific communication cutoffs.
what you may want to check out, is the pair_style "list" that can add
very long "bonds" between particles without requiring both particles
to be available on the same subdomain.
it can be added via using hybrid/overlay.

perhaps steve has some comments as well and an idea for an alternate solution.

HTH,
    axel.

3

Dear Axel, dear all,

Thank you very much for having a look at this.

I have tested the issue in the simplest way I had available, by starting a simulation with long bonds, specifying a proper user cutoff and changing from comm_modify mode single (which works) to multi and waiting for one dimer to cross a boundary. It leads, as expected, to
ERROR on proc 5: Bond atoms 1 2 missing on proc 5 at step 81200 (../neigh_bond.cpp:76)
from which I would deduce that the assumption of the user cutoff not being considered in the comm multi mode is correct. I would like to suggest adding this information to the Manual.

I have added some quick modifications to comm.h / comm.cpp and comm_brick.cpp that fixed the issue for me. With these, a user-cutoff can be specified type-dependent, while for the rest the standard values are used.
As it is just a few lines of code, I'll post the diffs here in case anyone else is interested. No guarantees on that it's really working though ...

Best wishes,

Martin

diff ../backup/comm/comm.h comm.h
31a32
> double *cutghostuser_multi; // extra user-specified ghost cutoff for single type

diff ../backup/comm/comm.cpp comm.cpp
13a14,21
> /* ----------------------------------------------------------------------
> Modified Aug 18 2015:
> Extra cutoff_multi option to specify a user cutoff for a specific type
> Usage: comm_modify cutoff/multi type cutoff
> where "type" is the atom type the user specified cutoff should be applied to
> and "cutoff" is ... this cutoff
> ------------------------------------------------------------------------- */
>
74a83,89
> cutghostuser_multi = NULL;
> int ntypes = atom->ntypes;
> memory->create(cutghostuser_multi, ntypes, "comm: cutghostuser_multi");
> for (int i = 0; i < ntypes; i++) {
> cutghostuser_multi[i] = -1.0;
> }
>
255a271,278
> } else if (strcmp(arg[iarg],"cutoff/multi") == 0) {
> if (iarg+3 > narg) error->all(FLERR,"Illegal comm_modify command");
> int type = force->numeric(FLERR,arg[iarg+1]);
> double cut = force->numeric(FLERR,arg[iarg+2]);
> if (cut < 0.0)
> error->all(FLERR,"Invalid cutoff in comm_modify command");
> cutghostuser_multi[type] = cut;
> iarg += 3;

diff ../backup/comm/comm_brick.cpp comm_brick.cpp
175,176c175,179
< for (i = 1; i <= ntypes; i++)
< cutghostmulti[i][0] = cutghostmulti[i][1] = cutghostmulti[i][2] =

4

Dear Axel, dear all,

Thank you very much for having a look at this.

I have tested the issue in the simplest way I had available, by starting
a simulation with long bonds, specifying a proper user cutoff and
changing from comm_modify mode single (which works) to multi and waiting
for one dimer to cross a boundary. It leads, as expected, to
ERROR on proc 5: Bond atoms 1 2 missing on proc 5 at step 81200
(../neigh_bond.cpp:76)
from which I would deduce that the assumption of the user cutoff not
being considered in the comm multi mode is correct. I would like to
suggest adding this information to the Manual.

I have added some quick modifications to comm.h / comm.cpp and
comm_brick.cpp that fixed the issue for me. With these, a user-cutoff
can be specified type-dependent, while for the rest the standard values
are used.
As it is just a few lines of code, I'll post the diffs here in case
anyone else is interested. No guarantees on that it's really working
though ...

would you mind trying a little experiment with this?

at and after the recent LAMMPS users workshop we discussed different
ways to improve the process of managing and keeping track of
contributed code changes, bug fixes and new features.

the "old" way was to e-mail one (or more) developer(s), but that has
the high risk of getting lost in a flood of e-mail or not getting
noticed by other developers, that may have the time to work on
including the change. this is still supported, but we want to see, if
the alternatives work better.

here are two new options:
- if you are using a git fork you could just create a branch with this
change and then file a pull request at
https://github.com/lammps/lammps/pulls

- if you are not familiar with this or don't use git, you can recreate
the diffs, but use the -u flag or -c flag, so that the resulting diff
file contains not only the changes, but also context information.
also, please state which version of LAMMPS exactly the diff is
relative to. alternatively, you can submit the original and the
unchanged files (again, with the date from version.h) so that we can
create the diffs ourselves. then create a compressed tar or zip
archive and upload it at: https://github.com/lammps/lammps/issues

since your change also alters/extend the syntax of the comm_modify
command, it would be extremely nice, if you also make a suitable
change to the doc/comm_modify.txt file, so that the changes are
documented (the html files are automatically generated from this).

if you have any problems with the process, let me know. that will
hopefully help to document the procedure well enough.

thanks in advance,
       axel.