Message transféré : Re: [lammps-users] problems with command fix rigid (8.34 KB)
From: Gyorgy Hantal <[email protected]...>
To: Axel Kohlmeyer <[email protected]>
Cc:
Date: Tue, 14 Jun 2016 22:11:38 +0200
Subject: Re: [lammps-users] problems with command fix rigidThanks for the reply.
[...]
Sorry I didn't give you a detailed explanation of the project: the goal
is
not to totally immobilize the walls; in fact, they are meant to move in
the
x direction. There is a thin layer of fluid between the walls which
basically holds them together. The rest of the fluid particles constitute
a
bath. The confined fluid can exchange particles with the reservoir. We
want
to apply shear/compression to the walls and see how the confined fluid
reacts.you don't really need to use fix rigid for that. you can have the same
effect using a combination of fix setforce (to turn off forces in y,
and z) and fix aveforce (to have the same force act on all wall
particles in x). please see the flow example for a 2d-variant of that.Yes, I prepared input files using the combination of setforce and aveforce,
but I did not fully explore this option. I have just run some test
calculations on the my desktop machine replacing the problematic fix rigid
command with an appropriate combo of setforce and aveforce, and experienced
no problems!However I seemed to have another problem that I cannot reproduce now after
simplifying my input. I tried to run some simulations where one of the rigid
walls is kept fixed in the y and z directions while the other wall is pulled
in the z direction with a constant velocity. For the latter I use a
combination of fix setforce and fix aveforce +fix move, while the other wall
this doesn't make sense. fix move by itself is sufficient to move
atoms according to a prescribed rule. it will do the time integration
and ignore forces completely. because of the time integration, atoms
in the fix group of fix move must not be time integrated by any other
fix. the alternative for moving atoms with a constant velocity is to
use the velocity command to set the velocity, fix setforce to set all
forces to zero and fix nve to do plain time integration.
is held fixed with fix rigid (this runs still only on my laptop). The reason
for this is that I want to compute the force that acts on the center of mass
of the rigid wall. If I understood correctly this is computed by fix rigid.
why not simply use "compute reduce sum" on the force component of
interest for the group of wall atoms? using fix rigid for this is
overkill.
I had experienced that after some time the wall to which the fix rigid
command was applied started to rotate even though all torques were zeroed
with the fix rigid command.Fortunately this problem does not occur now, I am going to try to figure out
why.Anyway my desktop machine still seems to have problems running calculations
with fix rigid. I will try to do a clean reinstall (needed anyway for other
reasons) starting with the OS.
considering your overall approach, it is more likely, that you are not
using LAMMPS correctly.
[...]
I am using the same version of lammps (16Feb16) with open mpi. The
compilation of some libraries might be different, and the hardware is not
the same either...the most likely cause of such different behavior would be inconsistent
data initialization. as i mentioned, we are continuously improving the
code quality using a variety of tools and there are still issues been
found and fixed occasionally.How can such inconsistent data initialization be avoided? This issue has to
do basically with the particular compilation of lammps and the related
libraries on the particular hardware, right?
no. it is due to oversights in programming. with a software as
flexible and complex as LAMMPS, these issues can pop up whenever
somebody makes changes that have side effects, but does not thoroughly
look for them. since most people writing scientific software are not
trained programmers and often are under a lot of pressure to produce
results rather than high-quality and maintainable source code, this
happens regularly. that is why we have started systematically and
routinely applying various static code analysis tools. by now, we
should have addressed pretty much all easy to find and reproduce
issues. finding a new issue with inconsistent data initialization now
requires an input deck that reliably reproduces this with the latest
development sources. then one can apply various tools that instrument
the executable and track down data accesses at run time.
axel.
[…]
you don’t really need to use fix rigid for that. you can have the same
effect using a combination of fix setforce (to turn off forces in y,
and z) and fix aveforce (to have the same force act on all wall
particles in x). please see the flow example for a 2d-variant of that.Yes, I prepared input files using the combination of setforce and aveforce,
but I did not fully explore this option. I have just run some test
calculations on the my desktop machine replacing the problematic fix rigid
command with an appropriate combo of setforce and aveforce, and experienced
no problems!However I seemed to have another problem that I cannot reproduce now after
simplifying my input. I tried to run some simulations where one of the rigid
walls is kept fixed in the y and z directions while the other wall is pulled
in the z direction with a constant velocity. For the latter I use a
combination of fix setforce and fix aveforce +fix move, while the other wallthis doesn’t make sense. fix move by itself is sufficient to move
atoms according to a prescribed rule. it will do the time integration
and ignore forces completely. because of the time integration, atoms
in the fix group of fix move must not be time integrated by any other
fix. the alternative for moving atoms with a constant velocity is to
use the velocity command to set the velocity, fix setforce to set all
forces to zero and fix nve to do plain time integration.
Yes, I do not time integrate those atoms with another fix I just pull them with fix move.
is held fixed with fix rigid (this runs still only on my laptop). The reason
for this is that I want to compute the force that acts on the center of mass
of the rigid wall. If I understood correctly this is computed by fix rigid.why not simply use “compute reduce sum” on the force component of
interest for the group of wall atoms? using fix rigid for this is
overkill.
Cool, thanks, I will do like that then.
[…]
How can such inconsistent data initialization be avoided? This issue has to
do basically with the particular compilation of lammps and the related
libraries on the particular hardware, right?no. it is due to oversights in programming. with a software as
flexible and complex as LAMMPS, these issues can pop up whenever
somebody makes changes that have side effects, but does not thoroughly
look for them. since most people writing scientific software are not
trained programmers and often are under a lot of pressure to produce
results rather than high-quality and maintainable source code, this
happens regularly. that is why we have started systematically and
routinely applying various static code analysis tools. by now, we
should have addressed pretty much all easy to find and reproduce
issues. finding a new issue with inconsistent data initialization now
requires an input deck that reliably reproduces this with the latest
development sources. then one can apply various tools that instrument
the executable and track down data accesses at run time.
OK. I’ll do systematic tests and if I manage to reproduce the error I will provide you with the input deck for further testing.
What I understood is that in the previous version of my input file that was leading to unwanted rotation of the fixed wall I was doing two cycles of simulations that might have conflicted somehow. In the first one both walls were constrained by fix rigid (though I unfixed all respective fixes afterwards) while in the second one one wall was fixed with fix setforce + fix aveforce + fix move and the other one was still constrained by fix rigid. I removed the first cycle and the problem does not arise anymore. Anyway I will let you if it does again.
Thank you for your help
Gyorgy