dump_modify every + dump custom + variable equal logfreq

Hello,

I have been searching in the internet for some answers to my problems but I have not found anything, so there it is:

I am trying to dump the positions of all my atoms in a logarithmic frequency. I want to calculate mean squared displacements and non-gaussian parameters using these data. Please, note that I am aware of the commands msd and msd/nongauss which I have used many times, but what I am trying to do goes beyond the versatility of those commands. To compute these quantities I need the positions with atoms not being put back into the box. That is why I use “dump custom”

The problem appears when I try to modify the frequency using the “dump_modify every” command with a logfreq variable. The code is the following:

variable s equal logfreq(1,9,10)
dump msddump all custom 5000 fort.101 id x y z
dump_modify msddump sort id every v_s first yes

It works fine when I comment the final part of the last line:
dump_modify msddump sort id # every v_s first yes

But when I try to use dump_modify every, it will return a Segmentation fault error. I am using the latest version (May’15) which is, I believe, the first one to allow the use of variables with “dump_modify every”.

Has anybody else had this problem? Am I doing it wrong?

Kind regards
Javier

I don’t know if this is a bug or not. You can always work around this by doing something like

dump msddump all custom 1 …

run 100

dump msddump all custom 10 …
run 1000

dump msddump all custom 100 …
run 10000

dump msddump all custom 1000 …
run 100000

Something like the above can be generated easily with e.g. bash.

Hello,

I have been searching in the internet for some answers to my problems but
I have not found anything, so there it is:

I am trying to dump the positions of all my atoms in a logarithmic
frequency. I want to calculate mean squared displacements and non-gaussian
parameters using these data. Please, note that I am aware of the commands
msd and msd/nongauss which I have used many times, but what I am trying to
do goes beyond the versatility of those commands. To compute these
quantities I need the positions with atoms not being put back into the box.
That is why I use "dump custom"

The problem appears when I try to modify the frequency using the
"dump_modify every" command with a logfreq variable. The code is the
following:

​​
variable s equal logfreq(1,9,10)
dump msddump all custom 5000 fort.101 id x y z
dump_modify msddump sort id every v_s first yes

It works fine when I comment the final part of the last line:
dump_modify msddump sort id # every v_s first yes

But when I try to use dump_modify every, it will return a Segmentation
fault error. I am using the latest version (May'15) which is, I believe,
the first one to allow the use of variables with "dump_modify every".

​FYI, the *latest* version of LAMMPS is currently the 5 Oct​ 2015 version.
the latest stable version is 10 Aug 2015.

if i add your three lines of LAMMPS input script to the melt example in the
LAMMPS distribution and run with my current LAMMPS-ICMS git binary, there
is no segfault. so please try the same example to make certain that it is
not something else in your input causing the segfault and then also try a
newer LAMMPS version.

​axel.​

And there are no valgrind errors (for memory issues),

so I think the current version works with the 3 lines

you posted.

Steve

Hello for your help!

After trying these lines in the melt example, and see they worked perfectly fine, I tried to change something in my code again and I found that the problem was the location in the code of these lines. I don’t know why, but I changed the structure:

timestep
variable s equal logfreq(1,9,10)
thermo v_s
dump
dump_modify
reset_timestep
fix NVT
thermo_style
run

for this other one:

timestep
variable s equal logfreq(1,9,10)
thermo v_s
reset_timestep
fix NVT
thermo_style
dump
dump_modify
run

I don’t know why the order of these lines had the effect that I commented and only when I used the “every v_s” function, but it now works fine. I haven’t changed anything else, only moved the lines containing the “dump” and “dump_modify” commands just before the run command.

Thank you all for your suggestions and your time.

Javier

​the problem is caused by using "reset_timestep" *after* defining the dump
and *before* certain internal data structures are properly initialized at
the beginning of a run or minimize command. thus by resetting the time step
number, you are reading uninitialized data and that can cause all kinds of
funny things, depending on what random bytes are stored in that location.

the changes listed in the patch below, make certain that data is
consistently initialized when assigned to a dump and thus can trigger a
necessary action when reset_timestep is called unexpectedly.

axel.

​diff --git a/src/output.cpp b/src/output.cpp
index ce561e3..4daca80 100644
--- a/src/output.cpp
+++ b/src/output.cpp
@@ -456,6 +456,14 @@ void Output::reset_timestep(bigint ntimestep)
       next_dump[idump] = (ntimestep/every_dump[idump])*every_dump[idump];
       if (next_dump[idump] < ntimestep) next_dump[idump] +=
every_dump[idump];
     } else {
+ // ivar_dump may not be initialized.
+ if (var_dump[idump] < 0) {
+ ivar_dump[idump] = input->variable->find(var_dump[idump]);
+ if (ivar_dump[idump] < 0)
+ error->all(FLERR,"Variable name for dump every does not exist");
+ if (!input->variable->equalstyle(ivar_dump[idump]))
+ error->all(FLERR,"Variable for dump every is invalid style");
+ }
       modify->clearstep_compute();
       update->ntimestep--;
       bigint nextdump = static_cast<bigint>
@@ -561,6 +569,13 @@ void Output::add_dump(int narg, char **arg)
     memory->grow(ivar_dump,max_dump,"output:ivar_dump");
   }

+ // make certain that per-dump data is properly initialized to suitable
default values

a quick update. there was a small typo in the patch. the correct version is:

diff --git a/src/output.cpp b/src/output.cpp
index ce561e3…8c16cbf 100644
— a/src/output.cpp
+++ b/src/output.cpp
@@ -456,6 +456,14 @@ void Output::reset_timestep(bigint ntimestep)
next_dump[idump] = (ntimestep/every_dump[idump])*every_dump[idump];
if (next_dump[idump] < ntimestep) next_dump[idump] += every_dump[idump];
} else {

  • // ivar_dump may not be initialized.

  • if (ivar_dump[idump] < 0) {

  • ivar_dump[idump] = input->variable->find(var_dump[idump]);

  • if (ivar_dump[idump] < 0)

  • error->all(FLERR,“Variable name for dump every does not exist”);

  • if (!input->variable->equalstyle(ivar_dump[idump]))

  • error->all(FLERR,“Variable for dump every is invalid style”);

  • }
    modify->clearstep_compute();
    update->ntimestep–;
    bigint nextdump = static_cast
    @@ -561,6 +569,13 @@ void Output::add_dump(int narg, char **arg)
    memory->grow(ivar_dump,max_dump,“output:ivar_dump”);
    }

  • // make certain that per-dump data is properly initialized to suitable default values

this will be in the next patch - thanks again Axel

Steve