Hi,
I am trying to write a compute which uses a full neighbor list once per a while but with a larger cutoff distance from that, which was defined in the input file.
Is there any way to recalculate the neighbor list manually in a compute but for a larger cutoff distance (e.g. by changing skin parameter) during a simulation and at the end of the compute go back to the previous cutoff and recalculate the neighbor list again?
I was trying using
neighbor->skin = 5.0;
neighbor->build_one(list->index);
neighbor->skin = 2.0;
but it did not work. Probably it has to be changed in front of the neighbor->request command in the init() method. Unfortunately I get a many runtime errors by doing so.
Regards.
Hi,
I am trying to write a compute which uses a full neighbor list once per a
while but with a larger cutoff distance from that, which was defined in the
input file.
Is there any way to recalculate the neighbor list manually in a compute but
for a larger cutoff distance (e.g. by changing skin parameter) during a
simulation and at the end of the compute go back to the previous cutoff and
recalculate the neighbor list again?
I was trying using
neighbor->skin = 5.0;
neighbor->build_one(list->index);
neighbor->skin = 2.0;
but it did not work. Probably it has to be changed in front of the
neighbor->request command in the init() method. Unfortunately I get a many
runtime errors by doing so.
there is not a lot of detail that i can provide, steve would know much
better, but having neighbor list style "multi" is the only option i
know for lammps to do neighbor lists with different cutoffs. but those
are restricted to different lists of atom pairs, if i remember
correctly.
in case you don't really need the computed property right during the
simulation, you could just record your trajectory normally and then
post-process it with a suitable larger cutoff using the "rerun"
feature, which allows you to change all kinds of simulation
parameters, but will apply them to the exact same trajectory as it is
read from the previously dumped file(s).
axel.
From: Axel Kohlmeyer [mailto:[email protected]]
Sent: Saturday, July 27, 2013 08:52
To: Liedke, Bartosz
Cc: [email protected]
Subject: Re: [lammps-users] neighbor list recalculate manually for larger
cutoff
> Hi,
>
>
>
> I am trying to write a compute which uses a full neighbor list once
> per a while but with a larger cutoff distance from that, which was
> defined in the input file.
>
> Is there any way to recalculate the neighbor list manually in a
> compute but for a larger cutoff distance (e.g. by changing skin
> parameter) during a simulation and at the end of the compute go back
> to the previous cutoff and recalculate the neighbor list again?
>
> I was trying using
>
> neighbor->skin = 5.0;
>
> neighbor->build_one(list->index);
>
> neighbor->skin = 2.0;
>
> but it did not work. Probably it has to be changed in front of the
> neighbor->request command in the init() method. Unfortunately I get a
> neighbor->many
> runtime errors by doing so.
there is not a lot of detail that i can provide, steve would know much better,
but having neighbor list style "multi" is the only option i know for lammps to
do neighbor lists with different cutoffs. but those are restricted to different
lists of atom pairs, if i remember correctly.
Thank you for the reply. I did not know about the "multi" option for different cutoffs. I checked the manual and I do not think it will solve my problem, since I only have one atom type with a one type of binding. I know the rerun procedure and post-processing is unfortunately not the solution for me since I need this information during the simulation to modify the potential as the next step. I have checked the archive of the mailing list and I have found one suggestion from Steve about the code following the neighbor->decide() method. So I have put this into my compute:
neighbor->skin = 5.0;
if (modify->n_min_pre_exchange) modify->min_pre_exchange();
if (domain->triclinic) domain->x2lamda(atom->nlocal);
domain->pbc();
if (domain->box_change) {
domain->reset_box();
comm->setup();
if (neighbor->style) neighbor->setup_bins();
}
timer->stamp();
comm->exchange();
if (atom->sortfreq > 0 &&
update->ntimestep >= atom->nextsort) atom->sort();
comm->borders();
if (domain->triclinic) domain->lamda2x(atom->nlocal+atom->nghost);
timer->stamp(TIME_COMM);
neighbor->build();
timer->stamp(TIME_NEIGHBOR);
to recalculate the neighbor list and straight after to request the list:
int irequest = neighbor->request((void *) this);
neighbor->requests[irequest]->pair = 0;
neighbor->requests[irequest]->compute = 1;
neighbor->requests[irequest]->half = 0;
neighbor->requests[irequest]->full = 1;
neighbor->requests[irequest]->occasional = 1;
NeighList *list = neighbor->lists[irequest];
neighbor->build_one(list->index);
inum = list->inum;
ilist = list->ilist;
numneigh = list->numneigh;
firstneigh = list->firstneigh;
It compiled and run without runtime errors (I have only checked for serial compilation up to now). However, I did not realize any size increase of the neighbor lists. Maybe neighbor->skin is not the parameter I should change?
Regards,
Bartosz
Ok, I managed to have some progress in this topic.
The reason why it was not working with updating the attribute neighbor->skin is that it is only used during initialization of neighbor object, i.e. most of the time only at the beginning of simulation. Afterwards several different attributes are used as a some kind of cutoff distances, like **cutneighsq as total squared cutoff for regular atoms (or atomic pairs because it is an array of atom types), or **cutneighghostsq the same only for ghost atoms. The problem is cutneighsq is protected variable, so one cannot access it directly from a compute (or at least I do not know how to access it).
My solution, which is quite dirty, was to move cutneighsq to public attributes and increase it at the beginning of the compute, then change it back as it was before at the end of the compute.
My first tests show that it works.
I am quite sure there are much more elegant way to do it than to modify neighbor.h file. If you can tell me how I will be very thankful.
All the best,
Bartosz
Slightly more elegant would be making your compute class a friend of Neighbor.
What you describe below won’t work. There is no
current way in LAMMPS to have a compute use a neighbor
list with a longer cutoff than the pair style is using.
That would require different communication patterns
and new ghost atoms, etc. Effectively LAMMPS would
have to throw away its current info, build the new neighbor
list, perform communication, acquire different ghost atoms,
then when the compute is done, throw all of that away,
and re-generate its former data structures.
No one has ever requested such a thing and it wouldn’t
be very efficient.
What do you need a longer cutoff for?
Steve
Hi Steve,
thank you for your reply.
What you describe below won't work. There is no
current way in LAMMPS to have a compute use a neighbor
list with a longer cutoff than the pair style is using.
Now I know it cannot work, however, few emails below I was writing about manual recalculation of neighbor list and changing the attribute **cutneighsq. It was working for the first few ps, but later I unfortunately got a segmentation fault. I am not yet sure what is the reason of this error (probably some memory management).
That would require different communication patterns
and new ghost atoms, etc. Effectively LAMMPS would
have to throw away its current info, build the new neighbor
list, perform communication, acquire different ghost atoms,
then when the compute is done, throw all of that away,
and re-generate its former data structures.
No one has ever requested such a thing and it wouldn't
be very efficient.
It does not have to be efficient, since I need it only once per several ps. In between and most of the time I am using standard cutoff.
What do you need a longer cutoff for?
Finally the aim is to modify the potential, which will slightly change its parameters depending on the nearest configuration of atoms (I need 3rd nearest neighbor distance) and only for some of the atoms that fulfill the configuration condition. Therefore, to accelerate the computation, the most of the time the force calculation will be done for the standard cutoff. Every few ps the algorithm will check for which atoms the potential parameters have to be changed. The algorithm requires 3rd NN distance cutoff.
All the best,
Bartosz
Finally the aim is to modify the potential, which will slightly change its parameters depending on the nearest configuration of >atoms (I need 3rd nearest neighbor distance) and only for some of the atoms that fulfill the configuration condition. Therefore, to >accelerate the computation, the most of the time the force calculation will be done for the standard cutoff. Every few ps the >algorithm will check for which atoms the potential parameters have to be changed. The algorithm requires 3rd NN distance cutoff.
I’m not sure what it means to have a potential that has dynamic params
specific to a few of its atoms. But I would probably implement
this capability in the pair style itself. E.g. define a cutoff that
is the large one (3rd NN), and have the pair style create a
sub-list itself (or request a derived list from the Neighbor class)
that is with the shorter cutoff. Then the pair style could do
its param adjust every few ps using the longer list, and its calculation
every step with the shorter one.
Steve