ave/atom positions with PBC

Hi all,

I was wondering if the fix ave/atom as given by, e.g., ‘fix AV all ave/atom 1 2 100 x y z’ deals with periodic boundary conditions properly?

If I look at the code in fix_ave_atom.cpp, then it seems that the coordinates as given in atom->x are averaged, which, if I am correct, are boxed? If an atom crosses the boundary, it makes a jump, and this jump would be averaged, and this can not be unwrapped any more in the post-processing phase.

However, in a file such as compute_msd.cpp some modifications are carried out to unwrap the coordinates. Wouldn’t it make sense to use something similar with ‘ave/atom’, or am I missing something?

Thanks,
Bart

you're correct, but you can use fix ave/atom with compute property/atom
and specify the latter for xu,yu,zu, which lets you use unwrapped coords.

I'll add a note to the doc page to this effect.

Steve

Hi all,

I’ve been having some problems with using fix langevin. Consider the following partial script

fix 1 all langevin 1.0 1.0 1 699483
fix 2 all nve
run 0
run 2500

If I execute this script in Lammps, then everything works fine. However, if I change the last line to

run 2500 pre no

then a segmentation fault will occur in LAMMPS_NS::Neighbor::bin_atoms(). Disabling the langevin fix will prevent the crash. I need the ‘pre no’ as I’m intending to use it via the library interface.

Another issue is that in FixLangevin::memory_usage() the variable bytes is declared twice, and the values of ‘bytes’ are not added together.

Finally, am I right in assuming that lammps_file() is only intended to be used once during a Lammps session (I.e., no multiple input files can be read in, at least not via this function call)?

Thanks for any help,

Bart

hi bart,

Hi all,

I've been having some problems with using fix langevin. Consider the
following partial script

fix 1 all langevin 1.0 1.0 1 699483
fix 2 all nve
run 0
run 2500

If I execute this script in Lammps, then everything works fine. However, if
I change the last line to

run 2500 pre no

then a segmentation fault will occur in LAMMPS_NS::Neighbor::bin_atoms().
Disabling the langevin fix will prevent the crash. I need the 'pre no' as
I'm intending to use it via the library interface.

the problem is, that run 0 doesn't do a full timestep
and thus some of the preparations that are required
for using "run" with "pre no" are not done.
if you replace that with a "run 1", it works.

Another issue is that in FixLangevin::memory_usage() the variable bytes is
declared twice, and the values of 'bytes' are not added together.

Finally, am I right in assuming that lammps_file() is only intended to be
used once during a Lammps session (I.e., no multiple input files can be read
in, at least not via this function call)?

you could simply do:

lammps_command(LMP, "include newfile.in");

another option would be to redirect input from a pipe.

axel.

There was a logic bug in fix langevin for the run 0 case, will
be fixed in next patch.

Steve

Thank you both for the quick replies. The patch solves it and the include
statement is indeed an easy workaround.

I encountered one more problem. Occasionally a dead-lock in Lammps occurs
when running an MPI job with multiple processes. In this case most of the
processes are in Neighbor::check_distance, while one is in Comm::exchange.
It looks like it is caused by an uninitialised variable and that it can be
resolved by adding the following line in the constructor of Fix (in
fix.cpp)

next_reneighbor = 0;

Kind regards,
Bart

Next_reneighbor is only used if a fix forces reneighboring,
so the fix itself sets it (no need to initialize in fix.h).

I only see one fix where the logic
for this is suspect, which is fix npt in the case of large tilts.
Are you running a problem with fix npt or fix nh with
a triclinic geometry?

Steve

Hi Steve,

I'm indeed running fix nph tri. I'm also using Lammps as a library and
LAMMPS objects are created frequently in my program.

Valgrind reports that a conditional jump occurs due to an uninitialised
value in a line that contains next_reneighbor:
"
Conditional jump or move depends on uninitialised value(s)
at 0x53016C: LAMMPS_NS::Neighbor::decide() (neighbor.cpp:1191)
"

hence my suggested fix.

Kind regards,
Bart

we just fixed the bug, in the fix_nh.cpp file,
will be in the next patch.

Steve