(no subject)

Dear all,

I am simulating the bending test of a nanotube with AIREBO potential.
With one end fixed, I apply a vertical force to the other end. Then I
dump the current force for atoms.

My load-apply script is “fix 2 top_move aveforce 1.0e-5 0.0 0.0”
My force-dump script is “dump 12 all custom 10000 force.profile id
type fx fy fz”

However, I have tried “setforce”, “addforce” and “aveforce”, the
deformations are reasonable. The dumped force is always “1e-5”for the
loaded end.

I think the force should be initial_force+load_force, thus, it can not
be a constant value if I use “addforce” or “aveforce”. And is there
any way to retrieve the current force for the specified atoms?

Any comments and suggestions?

Thx very much

Best

Ming

Dear all,

I am simulating the bending test of a nanotube with AIREBO potential.
With one end fixed, I apply a vertical force to the other end. Then I
dump the current force for atoms.

My load-apply script is “fix 2 top_move aveforce 1.0e-5 0.0 0.0”
My force-dump script is “dump 12 all custom 10000 force.profile id
type fx fy fz”

However, I have tried “setforce”, “addforce” and “aveforce”, the
deformations are reasonable. The dumped force is always “1e-5”for the
loaded end.

I think the force should be initial_force+load_force, thus, it can not
be a constant value if I use “addforce” or “aveforce”. And is there
any way to retrieve the current force for the specified atoms?

​the force you output in the dump *is* the actual force that the atoms
experiencing and reacting to.​

axel.

Dear Alex,

Thanks for your comments.

I believe that the dumped force should be the actual force, this is
explained in manual.

I doubted that this is caused by the ignorable force I used, the
"dump" command is not effective to reflect the relative change. Thus,
I use the "addforce" method and increase the applied force to "1" even
the atoms flee away. but the dumped force is still what I applied.

I attach my script here.

atom_style atomic
units metal
boundary s s s

read_data data.dat
mass * 12.1017

#define group to fix the boundary
lattice sc 1
region 1 block INF INF INF INF 999 10000 #top
movable region of nanotube
region 2 block INF INF INF INF -10 0 #bottom movable
region of nanotube
region 3 block INF INF -0.2 0.2 INF INF
#central plane of nanotube
group top_move region 1
group bottom_move region 2
group central_plane region 3
group boundary union top_move bottom_move
group mobile subtract all boundary

#initial the velocity environment and ignore the thermal effect

velocity mobile create 0.001 234567
velocity boundary set 0.0 0.0 0.0

#define the used potential

pair_style airebo 3.0 1 0
pair_coeff * * CH.airebo C C C C C

neighbor 3 bin
timestep 0.001

#define NVT ensemble

fix fix_y central_plane setforce NULL 0.0 NULL

fix freeze boundary setforce 0.0 0.0 0.0
fix 1 mobile nvt temp 0.001 0.001 0.001 drag 0.2
fix 3 boundary nve

thermo_style custom step temp etotal pe ke ebond evdwl pzz
thermo 1000

#central_line

dump 12 all custom 10000 force.profile id type x y z fx fy fz

fix 2 top_move addforce 1.0e-6 0.0 0.0

run 50000

###final minimization
unfix 2

velocity top_move set 0.0 0.0 0.0

run 1000000

Dear Alex,

Thanks for your comments.

I believe that the dumped force should be the actual force, this is
explained in manual.

I doubted that this is caused by the ignorable force I used, the
"dump" command is not effective to reflect the relative change. Thus,
I use the "addforce" method and increase the applied force to "1" even
the atoms flee away. but the dumped force is still what I applied.

​is there some kind of question here?​

Dear Alex,

Thanks for your comments.

I believe that the dumped force should be the actual force, this is
explained in manual.

I doubted that this is caused by the ignorable force I used, the
"dump" command is not effective to reflect the relative change. Thus,
I use the "addforce" method and increase the applied force to "1" even
the atoms flee away. but the dumped force is still what I applied.

​is there some kind of question here?​

for "addforce", the dumped force should be
initial_force+addforce*step. but what I dumped is only the added
force.

​that doesn't ​make sense. you have to show conclusive proof.

axel.

>
>> Dear Alex,
>>
>> Thanks for your comments.
>>
>> I believe that the dumped force should be the actual force, this is
>> explained in manual.
>>
>> I doubted that this is caused by the ignorable force I used, the
>> "dump" command is not effective to reflect the relative change. Thus,
>> I use the "addforce" method and increase the applied force to "1" even
>> the atoms flee away. but the dumped force is still what I applied.
>>
>>
> ​is there some kind of question here?​
>
>

for "addforce", the dumped force should be
initial_force+addforce*step. but what I dumped is only the added
force.

​that doesn't ​make sense. you have to show conclusive proof.

this is what I use

dump 12 all custom 10000 force.profile id type x y z fx fy fz

fix 2 top_move addforce 1 0.0 0.0

this is what I get

8128 4 32354.4 -3.52946 993.817 1 0 0 , while "1" is for fx

atom 8128 belongs to the top_move group.

this is also the case for "addforce 1e-6 0.0 0.0"

>
>> >
>> >> Dear Alex,
>> >>
>> >> Thanks for your comments.
>> >>
>> >> I believe that the dumped force should be the actual force, this is
>> >> explained in manual.
>> >>
>> >> I doubted that this is caused by the ignorable force I used, the
>> >> "dump" command is not effective to reflect the relative change. Thus,
>> >> I use the "addforce" method and increase the applied force to "1"
even
>> >> the atoms flee away. but the dumped force is still what I applied.
>> >>
>> >>
>> > ​is there some kind of question here?​
>> >
>> >
>>
>> for "addforce", the dumped force should be
>> initial_force+addforce*step. but what I dumped is only the added
>> force.
>>
>>
> ​that doesn't ​make sense. you have to show conclusive proof.

this is what I use

dump 12 all custom 10000 force.profile id type x y z fx fy fz

fix 2 top_move addforce 1 0.0 0.0

​this is no proof. you also have to show that fx *before* fix addforce is
applies is larger than 1.0e-6​

this is what I get

8128 4 32354.4 -3.52946 993.817 1 0 0 , while "1" is for fx

atom 8128 belongs to the top_move group.

this is also the case for "addforce 1e-6 0.0 0.0"


what you get fx = 1 in this case?​ that is extremely hard to believe. many
people, including me, have used fix addforce over a long time, and it
always did what it was supposed to do.
​you must be doing something that is different from what you think you do.

you have to provide the two different (complete) input decks that prove
this, so it can be reproduced independently. also, you have to prove that
this happens with the latest version of LAMMPS.

axel.​

>
>> >
>> >> Dear Alex,
>> >>
>> >> Thanks for your comments.
>> >>
>> >> I believe that the dumped force should be the actual force, this is
>> >> explained in manual.
>> >>
>> >> I doubted that this is caused by the ignorable force I used, the
>> >> "dump" command is not effective to reflect the relative change.
>> >> Thus,
>> >> I use the "addforce" method and increase the applied force to "1"
even
>> >> the atoms flee away. but the dumped force is still what I applied.
>> >>
>> >>
>> > ​is there some kind of question here?​
>> >
>> >
>>
>> for "addforce", the dumped force should be
>> initial_force+addforce*step. but what I dumped is only the added
>> force.
>>
>>
> ​that doesn't ​make sense. you have to show conclusive proof.

this is what I use

dump 12 all custom 10000 force.profile id type x y z fx fy fz

fix 2 top_move addforce 1 0.0 0.0

​this is no proof. you also have to show that fx *before* fix addforce is
applies is larger than 1.0e-6​

this is what I get

8128 4 32354.4 -3.52946 993.817 1 0 0 , while "1" is for fx

atom 8128 belongs to the top_move group.

this is also the case for "addforce 1e-6 0.0 0.0"


what you get fx = 1 in this case?​ that is extremely hard to believe. many
people, including me, have used fix addforce over a long time, and it
always did what it was supposed to do.
​you must be doing something that is different from what you think you do.

you have to provide the two different (complete) input decks that prove
this, so it can be reproduced independently. also, you have to prove that
this happens with the latest version of LAMMPS.

Thank you for your comments. the version of Lammps is released in
2015, this may be the cause. I will try the latest version. Thanks
very much.