Progress output

Dear all,

I'm somehow struggling with my simulation.
It starts to run but then is kind of stuck at:

Setting up Verlet run ...
  Unit style : real
  Current step : 0
  Time step : 0.0005

No further output is then produced and it runs
very long, so I'm curious if I can produce more
output during the calculation of the timestep.
(Or do I need to provide my input script that
you can make a better guess?)

Best,
Stephan

Dear all,

I'm somehow struggling with my simulation.
It starts to run but then is kind of stuck at:

Setting up Verlet run ...
  Unit style : real
  Current step : 0
  Time step : 0.0005

No further output is then produced and it runs
very long, so I'm curious if I can produce more
output during the calculation of the timestep.
(Or do I need to provide my input script that
you can make a better guess?)

​please check out:​

http://lammps.sandia.gov/doc/thermo.html

​and:​

http://lammps.sandia.gov/doc/thermo_style.html
http://lammps.sandia.gov/doc/thermo_modify.html

​axel.​

Thanks Axel,
I adjusted, however probably wrong, maybe
someone has time to check my Input Script:
http://nopaste.linux-dev.org/?1073261

If I run with this Input Script I gain
this output: http://nopaste.linux-dev.org/?1073269

After some hours I cancel the run.

I'm not sure what I'm doing wrong (tried serial and parallel).

Best,
S.

Thanks Axel,
I adjusted, however probably wrong, maybe
someone has time to check my Input Script:
http://nopaste.linux-dev.org/?1073261

If I run with this Input Script I gain
this output: http://nopaste.linux-dev.org/?1073269

After some hours I cancel the run.

I'm not sure what I'm doing wrong (tried serial and parallel).

​try with some of the LAMMPS examples.
i assume this is with a standard unmodified LAMMPS executable​, right?

if the regular inputs work, there has to be something wrong with your
configuration and/or parameters.
if not, then there is something with the executable or the machine or how
you run LAMMPS.

axel.

Dear Axel,

right I tried this already, thanks -
regular input works with both executables.

So I guess there should be something wrong
with my input, too!
I will take again a look at both files,
i.e. LAMMPS input and data file.
At least in my LAMMPS input script I posted
I can't see a blatantly wrong statement sadly. :confused:

Best,
S.

Dear Axel,

right I tried this already, thanks -
regular input works with both executables.

So I guess there should be something wrong
with my input, too!
I will take again a look at both files,
i.e. LAMMPS input and data file.
At least in my LAMMPS input script I posted
I can't see a blatantly wrong statement sadly. :confused:

​a simple way to figure out where the executable gets stuck​ is to look up
the process id, e.g. "ps x" or "pstree -p"
and then attach a debugger with "gdb -p <pid>" and then type "where" to get
a stack trace.

axel.

Good idea!
I'll try.

Best,
S.

Okay,

this give me the following stack trace:

(gdb) where
#0 0x00000000004345fe in grow<int> (this=0xa38da0, n=<value optimized

) at ../memory.h:166

#1 LAMMPS_NS::AtomVecFull::grow (this=0xa38da0, n=<value optimized

) at ../atom_vec_full.cpp:115

#2 0x000000000043103d in LAMMPS_NS::AtomVecFull::unpack_border
(this=0xa38da0, n=82601, first=991212, buf=0x2aaab07a5040)
    at ../atom_vec_full.cpp:537
#3 0x000000000046734c in LAMMPS_NS::CommBrick::borders (this=0xa23700)
at ../comm_brick.cpp:846
#4 0x000000000076b413 in LAMMPS_NS::Verlet::setup (this=0xa38490) at
../verlet.cpp:113
#5 0x0000000000741027 in LAMMPS_NS::Run::command (this=0x7fffffffde10,
narg=<value optimized out>, arg=0xa38d50) at ../run.cpp:177
#6 0x00000000005a7be3 in
LAMMPS_NS::Input::command_creator<LAMMPS_NS::Run> (lmp=<value optimized

, narg=1, arg=0xa38d50)

    at ../input.cpp:724
#7 0x00000000005a63ab in LAMMPS_NS::Input::execute_command
(this=0xa22a80) at ../input.cpp:707
#8 0x00000000005a768c in LAMMPS_NS::Input::file (this=0xa22a80) at
../input.cpp:243
#9 0x00000000005b55d6 in main (argc=3, argv=0x7fffffffe0c8) at
../main.cpp:31

I'm not sure if this will be helpful so much.
I looked into the lines in the corresponding files,
but could not find a hint for me.

I'm not sure, should I show you also my data file which
describes my geometry and my forcefield?

Best,
S.

Okay,

this give me the following stack trace:

(gdb) where
#0 0x00000000004345fe in grow<int> (this=0xa38da0, n=<value optimized
>) at ../memory.h:166
#1 LAMMPS_NS::AtomVecFull::grow (this=0xa38da0, n=<value optimized
>) at ../atom_vec_full.cpp:115
#2 0x000000000043103d in LAMMPS_NS::AtomVecFull::unpack_border
(this=0xa38da0, n=82601, first=991212, buf=0x2aaab07a5040)
    at ../atom_vec_full.cpp:537
#3 0x000000000046734c in LAMMPS_NS::CommBrick::borders (this=0xa23700)
at ../comm_brick.cpp:846
#4 0x000000000076b413 in LAMMPS_NS::Verlet::setup (this=0xa38490) at
../verlet.cpp:113
#5 0x0000000000741027 in LAMMPS_NS::Run::command (this=0x7fffffffde10,
narg=<value optimized out>, arg=0xa38d50) at ../run.cpp:177
#6 0x00000000005a7be3 in
LAMMPS_NS::Input::command_creator<LAMMPS_NS::Run> (lmp=<value optimized
>, narg=1, arg=0xa38d50)
    at ../input.cpp:724
#7 0x00000000005a63ab in LAMMPS_NS::Input::execute_command
(this=0xa22a80) at ../input.cpp:707
#8 0x00000000005a768c in LAMMPS_NS::Input::file (this=0xa22a80) at
../input.cpp:243
#9 0x00000000005b55d6 in main (argc=3, argv=0x7fffffffe0c8) at
../main.cpp:31

I'm not sure if this will be helpful so much.

​this means that your calculation is trying to allocate memory in order ​to
make room for some more ghost atoms.
how large is your system? what is your LAMMPS version and platform? is this
a shared machine or your desktop/laptop? how much available RAM do you have?

how large is your neighbor list and communication cutoff AKA master list
and ghost atom cutoff?

axel.

I looked into the lines in the corresponding files,

Hey Axel,

thank for interpreting the output!

I try to make it run on my Laptop first,
I've 16 GiB of RAM.

Neighbor list info ...
  1 neighbor list requests
  update every 1 steps, delay 2 steps, check yes
  max neighbors/atom: 2000, page size: 100000
  master list distance cutoff = 12
  ghost atom cutoff = 12

Is this the output you're asking for?

Best,
S.

Oh,
I missed the LAMMPS version and platform and system size:

LAMMPS (7 Apr 2016-ICMS)
Reading data file ...
  orthogonal box = (-0.5 -0.5 -0.5) to (0.5 0.5 0.5)

Mac OS X (tried also my Ubuntu 15.XX)

Atoms: ~3000

Best,
S.

Oh,
I missed the LAMMPS version and platform and system size:

LAMMPS (7 Apr 2016-ICMS)
Reading data file ...
  orthogonal box = (-0.5 -0.5 -0.5) to (0.5 0.5 0.5)

this looks bad.

​is your simulation cell really 1x1x1 angstrom in size?​ ​and you cram 3000
atoms into this?​
i would rather expect something in the order of magnitude of 30x30x30
angstrom for a typical atomic system with real units.

​with a communication cutoff ​of 12 angstrom that would need to create
about 15000 copies of the principal simulation cell containing a total of
about 50 billion ghost atoms, if my back-of-the-envelope estimate is
correct. that would explain that your simulation is stuck in ghost atom
creation and communication.

axel.

Oh wow!
50 Billioen sounds a lot :slight_smile:

Okay, I will check this,
I used topotools from VMD 1.9.2 for that.
I'll check why this gave me this bounding box.

Thank you Axel, YMMD.

Best,
S.

Oh wow!
50 Billioen sounds a lot :slight_smile:

Okay, I will check this,
I used topotools from VMD 1.9.2 for that.
I'll check why this gave me this bounding box.

​topotools can only use and output information that your feed it. there are
some heuristics that VMD applies if information is, but they may not always
work well and is usually only aimed at visualization.

you probably have read in a file​ that did not contain any box dimension
information. depending on the kind of molfile plugin, you may then just get
a 1x1x1 box.
please see the methane example on this page for an example that shows how
to guesstimate a suitable box from VMD/Tcl scripting with VMD's measure
command.

https://sites.google.com/site/akohlmey/software/topotools/topotools-tutorial---part-2

​axel.​

Dear Axel,

oh wow! I was not aware of that.
That's probably the reason!
Thanks in advance.

These values are the default values topotools provide
(looking at the TCL source code), so despite the fact
my LAMMPS data file I produced with VMD 1.9.2
(and probably Topotools 1.5) looked consistent, I
need to re-assure in any case every single brick.

I infered now the bounding box, and the simulation
runs due to your splendid help, thanks again.

I will look into this example!

Best,
S.