Problem with restart file in gran/hook/history

LAMMPS LAMMPS Mailing List Mirror
1

Dear Lammps developers,

I am running granular potential hook with box deformation to

mimic the Lees-Edwards boundary conditions.

My simulations are done in 2 steps:

  1. I run a simulation for box deformation rate gd1 and at the end I

write down the final configuration in a restart file

  1. I read restart of gd1 and apply gd2 which is smaller than gd1.

At each step I use 32 processors.

For pair_style gran/hooke this works fine and I get good

results. However, when I use gran/hooke/history to simulate

frictional particles, in step 2, I get simulations with artifacts where

particles fly over each other which is a typical artifact of MD

simulations.

I stress out that this happens when the history dependent

frictional force gran/hooke/history is switched on and it only

happens in step 2.

Apparently details for the history of the forces are not written

into the restart file and when I read the restart file in the 2nd

step the simulations does not work properly.

Is there any way to fix this problem?

Below is the summary of my code:

2

three comments:
- *ALWAYS* report which LAMMPS version you are using and what platform
you are running on.
- the neighborlist history *is* written into the restart files, you
can find the code for it in fix_neigh_history.cpp, which is used by
the history dependent granular styles
- if you want confirm, that there is an issue with restarting of the
gran/xxx/history pair styles, you should construct a minimal (size and
commands) input deck, that confirms the issue and is small and simple
enough, so that developers can help you track it down.

in conclusion, it is impossible to give a recommendation for a
workaround or instructions how to solve a problem, before the cause of
the problem is confirmed and it is also proven that this issue still
exists in the latest development version of LAMMPS.

axel.

3

To add to Axel’s comment. In all my time using Gran/hooke/history, I’ve never seen particle configurations suddenly explode on restart. I’ve never seen them explode without something else in my input deck being an issue.

Eric Murphy, PhD
Mechanical Engineer
murphyericjames@…24…

4

Dear Eric,
Dear Axel,

Thanks a lot for your kind replies.

I think I have solved the problem.

Let me go the way Axel asked:

  1. I am using

LAMMPS (6 Jul 2017)

with a modified version of lammps which excludes artificial attractive forces due to the gran/hook model.

I used to do frictionless disk simulations with gran/hook.

I prepared my initial packing by box compression with frictionless particles and wrote the final packing into a restart file by

write_data restart_file

Then I have read that initial packing to perform shearing experiments with frictionless particles.

Until this step, everything was fine.

Then I used these frictionless initial packings and changed my force to gran/hooke/history in my reader code. The reader code is the one which reads the initial packing and performs shearing simulation. There the problem showed up and I ran into trouble.

Finally I realized that I have to go to my packing maker code and prepare my packings with frictional particles by gran/hooke/history then the problem disappeared.

This was apparently the reason for wrong results.

And another thing when using frictional particles one must use write_restart and write_data does produces artifacts.

I do not know whether these are bugs or just inconsistency of my procedure to read frictionless packings in order to simulate frictional particles.

I have one more question:

In gran/hooke/history I need to dump the angular coordinate of each particle \theta. Apparently this is not supported by dump class? Is there any trick I can use to print them out?

Yours
Habib.

5

In gran/hooke/history I need to dump the angular coordinate of each particle \theta. Apparently this is not supported by dump class? Is there any trick I can use to print them out?

For a sphere (or a disc in 2d), there is no need to keep track of an ang coord like theta.
All the eqs of motion need is omega (ang velocity). So that is all LAMMPS stores
and updates. If something in your modified pair style needs theta then you will
have to add it to the code. E.g. by using fix property/atom.

Steve

6

Dear Eric,
Dear Axel,

Thanks a lot for your kind replies.

I think I have solved the problem.

Let me go the way Axel asked:

1) I am using
LAMMPS (6 Jul 2017)

with a modified version of lammps which excludes artificial attractive forces due to the gran/hook model.

[...]

I do not know whether these are bugs or just inconsistency of my procedure to read frictionless packings in order to simulate frictional particles.

without a simple, minimal, and complete (i.e. easy to debug) example
input deck, that reproduces the unexpected behavior with an
*unmodified* LAMMPS code, there is not much that can be said here.
your description of the procedure is too vague and it is not possible
to tell, whether there are any mistakes in the process (e.g.
inconsistent order of command) or whether the modifications to LAMMPS
have an impact.

I have one more question:

In gran/hooke/history I need to dump the angular coordinate of each particle \theta. Apparently this is not supported by dump class? Is there any trick I can use to print them out?

this is not an issue with dump. dump can output quaternions, which is
how LAMMPS would store orientation information. but LAMMPS simply does
not track orientations in granular simulations; it is not needed for
time integration or force/torque computations and you cannot output
information that is not there. only simulations requiring atom styles
body, ellipsoid, or tri store and maintain this information, but they
also require, e.g. different integrator fixes for that purpose.

axel.