A question on the number of listed item in a DUMP

Hi everyone,
the following is my code, but LAMMPS returns error,

dump 1 all custom 1000 all_* id type x y z c_k c_s[1] c_s[2] c_s[3] c_s[4] c_s[5] c_s[6] c_v[1]
#the number of listed items is 13.

When I change it to

dump 1 all custom 1000 all_* type x y z c_k c_s[1] c_s[2] c_s[3] c_s[4] c_s[5] c_s[6] c_v[1]
#the number of listed items is 12.

it works.

I want to know that if LAMMPS has this limitation? Or Something is wrong?

Thanks in advance.

I don’t think anybody can answer with such limited information. Please attache the full input deck so people can look into it.

Ray

I don't think anybody can answer with such limited information. Please
attache the full input deck so people can look into it.

...and let us know what the error message is. most of the time, the
error message itself should give the necessary explanation.

axel.

2d indenter simulation

dimension 2
boundary p s p

atom_style atomic
neighbor 0.3 bin
neigh_modify delay 5

create geometry

lattice hex 0.9
region box block 0 20 0 10 -0.25 0.25
create_box 2 box
create_atoms 1 box

mass 1 1.0
mass 2 1.0

LJ potentials

pair_style lj/cut 2.5
pair_coeff * * 1.0 1.0 2.5

define groups

region 1 block INF INF INF 1.25 INF INF
group lower region 1
group mobile subtract all lower
set group lower type 2

initial velocities

compute new mobile temp
velocity mobile create 0.2 482748 temp new
fix 1 all nve
fix 2 lower setforce 0.0 0.0 0.0
fix 3 all temp/rescale 100 0.1 0.1 0.01 1.0

compute stress all stress/atom NULL
compute vol all voronoi/atom
compute ke all ke/atom

run with indenter

timestep 0.003
variable k equal 1000.0/xlat
variable y equal “13.0ylat - stepdt0.02ylat”

fix 4 all indent $k sphere 10 v_y 0 5.0
fix 5 all enforce2d

thermo 1000
thermo_modify temp new

dump 1 all custom 1000 all_* id type x y z c_ke c_stress[1] c_stress[2] c_stress[3] c_stress[4] c_stress[5] c_stress[6] c_vol[1]
dump_modify 1 format “%6d %2d %20.10f %20.10f %20.10f %20.10f %20.10f %20.10f %20.10f %20.10f %20.10f %20.10f %20.10f”

run 30000

ERROR:

*** Error in `/home/qi/lammps/src/lmp_g++’: free(): invalid pointer: 0x0000000001b2ac40 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7d1fd)[0x7f072a75e1fd]
/home/qi/lammps/src/lmp_g++(_ZN9LAMMPS_NS9PairLJCutD1Ev+0x142)[0x835c52]
/home/qi/lammps/src/lmp_g++(_ZN9LAMMPS_NS9PairLJCutD0Ev+0x9)[0x835cf9]
/home/qi/lammps/src/lmp_g++(_ZN9LAMMPS_NS5ForceD1Ev+0x88)[0x9515f8]

# 2d indenter simulation

[...]

run 30000

ERROR:

*** Error in `/home/qi/lammps/src/lmp_g++': free(): invalid pointer:
0x0000000001b2ac40 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7d1fd)[0x7f072a75e1fd]
/home/qi/lammps/src/lmp_g++(_ZN9LAMMPS_NS9PairLJCutD1Ev+0x142)[0x835c52]
/home/qi/lammps/src/lmp_g++(_ZN9LAMMPS_NS9PairLJCutD0Ev+0x9)[0x835cf9]
/home/qi/lammps/src/lmp_g++(_ZN9LAMMPS_NS5ForceD1Ev+0x88)[0x9515f8]

[...]

i cannot reproduce this. your input runs fine on my test machine with
the latest version of the code.

The LOG file has nothing important.

i disagree. it has something *very* important, that you don't mention:
version number of LAMMPS that you are using.

axel.

In fact, I do not know the reason, but I change the Makefile.g++

---------------------------------------------------------------------

LAMMPS-specific settings, all OPTIONAL

specify settings for LAMMPS features you will use

if you change any -D setting, do full re-compile after “make clean”

LAMMPS ifdef settings

see possible settings in Section 2.2 (step 4) of manual

LMP_INC = -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 DLAhttp://MMPS_BIGBIG

to

---------------------------------------------------------------------

LAMMPS-specific settings, all OPTIONAL

specify settings for LAMMPS features you will use

if you change any -D setting, do full re-compile after “make clean”

LAMMPS ifdef settings

see possible settings in Section 2.2 (step 4) of manual

LMP_INC = -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 #-DLAMMPS_BIGBIG

It works, Thank you.

Makefile.g++ (3.08 KB)

And until you tell us which version of LAMMPS you are using, nobody well know or want to check it out.

LAMMPS (8 Jul 2015)
I am Sorry, I often do “git pull”.

LAMMPS (8 Jul 2015)
I am Sorry, I often do "git pull".

ok. thanks. knowing that you use the latest version in combination
with the fact that you can make the problem go away with the fact that
it requires -DLAMMPS_BIGBIG to make the problem show up, helps to
track it down. there is a memory overflow for the custom format string
that you use, that will only happen, if you need support for 64-bit
long integers.

the following one-liner corrects this.

axel.

p.s.: compiling with -DLAMMPS_BIGBIG doesn't make much sense unless
your systems are insanely large.

[[email protected]... src]$ git diff dump_custom.cpp
diff --git a/src/dump_custom.cpp b/src/dump_custom.cpp
index 2aa7658..725f7ec 100644
--- a/src/dump_custom.cpp
+++ b/src/dump_custom.cpp
@@ -125,7 +125,7 @@ DumpCustom::DumpCustom(LAMMPS *lmp, int narg, char **arg) :

   vformat = new char*[size_one];

- format_default = new char[3*size_one+1];
+ format_default = new char[4*size_one+1];
   format_default[0] = '\0';

   for (int i = 0; i < size_one; i++) {

OK, Thanks, I will take your advice.
Best Regards.
Qitao

this correction will be in a patch later today

Thanks,

Steve