Dear lammps-users,
I am currently working on the fix bond/create routine. My aim is implement an
alternative partner picking algorithm for the polymerization process. If anyone
is interested in the details, my working version is here:
https://github.com/pdebuyl/lammps/blob/random_pick_fbc/src/MC/fix_bond_create.cpp
and a simulation can be run with the makefile from
https://github.com/pdebuyl/lammps_bond_create
and the command
make chain_growth LMP="mpirun -n 4 /path/to/lmp_mpi"
My question is about the reverse_comm_fix routine. I pack (and then unpack) the
partners for the reaction that are of type tagint.
Upon debugging my code, I found that on some occasions, the reverse_comm_fix
routine unpacks the buffer on a CPU for which the unpacked data is not "real"
(by checking that the index j of the particle is local "j<nlocal").
If anyone has an idea of why such a problem could occur, I would be grateful. I
understand that the problem may come from my code, indeed, but debugging does
not help me to get further, unfortunately.
Thanks for any pointer,
Pierre
Dear lammps-users,
I am currently working on the fix bond/create routine. My aim is implement an
alternative partner picking algorithm for the polymerization process. If anyone
is interested in the details, my working version is here:
https://github.com/pdebuyl/lammps/blob/random_pick_fbc/src/MC/fix_bond_create.cpp
and a simulation can be run with the makefile from
GitHub - pdebuyl/cg_md_polymerization: Polymerization algorithm in MD (lammps and ESPResSo++)
and the command
make chain_growth LMP="mpirun -n 4 /path/to/lmp_mpi"
My question is about the reverse_comm_fix routine. I pack (and then unpack) the
partners for the reaction that are of type tagint.
Upon debugging my code, I found that on some occasions, the reverse_comm_fix
routine unpacks the buffer on a CPU for which the unpacked data is not "real"
(by checking that the index j of the particle is local "j<nlocal").
could be either due to the encoding of exclusions for 1-2, 1-3 and 1-4
special bonds.
check out this code segment in most pairwise additive potentials that
extracts and removes this information, which is added to the top bits
of the index.
j = jlist[jj];
factor_lj = special_lj[sbmask(j)];
j &= NEIGHMASK;
you may just need to apply the last of those lines to remove that
information. this may be needed without communication as well.
or you would have such a large enough system where the index get into
issues with fitting a 64-bit integer into a double precision number.
that would happen once you need more than 52 bits to represent the
integer, but that is rather unlikely if you are doing development and
debugging. check out the use of the "ubuf" union in various places.
axel.
> My question is about the reverse_comm_fix routine. I pack (and then unpack) the
> partners for the reaction that are of type tagint.
>
> Upon debugging my code, I found that on some occasions, the reverse_comm_fix
> routine unpacks the buffer on a CPU for which the unpacked data is not "real"
> (by checking that the index j of the particle is local "j<nlocal").
could be either due to the encoding of exclusions for 1-2, 1-3 and 1-4
special bonds.
check out this code segment in most pairwise additive potentials that
extracts and removes this information, which is added to the top bits
of the index.
j = jlist[jj];
factor_lj = special_lj[sbmask(j)];
j &= NEIGHMASK;
you may just need to apply the last of those lines to remove that
information. this may be needed without communication as well.
or you would have such a large enough system where the index get into
issues with fitting a 64-bit integer into a double precision number.
that would happen once you need more than 52 bits to represent the
integer, but that is rather unlikely if you are doing development and
debugging. check out the use of the "ubuf" union in various places.
Thank you for the input. I wasn't masking j it is now done. The problem stays
though. I was already checking the tag of the particles, to follow the operation
of the algorithm and the tags correspond to what I expect.
I am testing with systems of a few thousands atoms at most and don't expect to
overflow that part.
Regards,
Pierre
Could it be that, as I am running small boxes (size about 10 x 10 x 10) with a
very large cutoff "comm_modify cutoff 3.5" or "comm_modify cutoff 4.0" the
neighoring is spurious?
I need the large cutoff to access special 1-2-3-4 bonds upon bond creation.
Thanks,
Pierre
I am currently working on the fix bond/create routine. My aim is implement an
alternative partner picking algorithm for the polymerization process. If anyone
is interested in the details, my working version is here:
https://github.com/pdebuyl/lammps/blob/random_pick_fbc/src/MC/fix_bond_create.cpp
and a simulation can be run with the makefile from
GitHub - pdebuyl/cg_md_polymerization: Polymerization algorithm in MD (lammps and ESPResSo++)
and the command
make chain_growth LMP="mpirun -n 4 /path/to/lmp_mpi"
My question is about the reverse_comm_fix routine. I pack (and then unpack) the
partners for the reaction that are of type tagint.
Upon debugging my code, I found that on some occasions, the reverse_comm_fix
routine unpacks the buffer on a CPU for which the unpacked data is not "real"
(by checking that the index j of the particle is local "j<nlocal").
Could it be that, as I am running small boxes (size about 10 x 10 x 10) with a
very large cutoff "comm_modify cutoff 3.5" or "comm_modify cutoff 4.0" the
neighoring is spurious?
no. i don't think so. i would suspect that some "magic" flag is set or
not set or set to the wrong value somewhere. this is difficult to
track down without looking over the code in detail or being steve
plimpton.
so i will defer to steve checking this out. mine was a guess based on
commonly occurring similar problems.
axel.
Thanks for the info anyway!
I will try to locate the problem with more precision before coming back to the
list.
Regards,
Pierre
Just for the information and in case other persons would encounter the same
issue: I was using a different array in the pack and unpack routine. The
information was thus only propagated to the 6 direct neighbors of a CPU and not
to all 26. This part of my problem is now solved 
Regards,
Pierre