[lammps-users] Simulating impact of a rigid nanoparticle using the fix rigid command

Please post to the mail list, not to me personally.
I would first try your problem without fix rigid. In
other words send the nanoparticle into the substrate and
see if it does the right thing upon impact, even if it
breaks apart. Once you are confident you can
model that with the right velocity, timestep, dynamics
etc, then turn on fix rigid.

Steve

Yes, that’s what I did.

It works fine if the nanoparticle is not rigid. Of course, it sticks to the substrate after the initial impact in that case, as there are interactions between atoms in the particle and in the substrate.

If the particle is made rigid, I would have thought that it could bounce back after the impact, since in that case there is no reason why the atoms would interact with the substrate?

Thanks,
Thomas

thomas,

Yes, that's what I did.

It works fine if the nanoparticle is not rigid. Of course, it sticks to the
substrate after the initial impact in that case, as there are interactions
between atoms in the particle and in the substrate.

If the particle is made rigid, I would have thought that it could bounce
back after the impact, since in that case there is no reason why the atoms
would interact with the substrate?

why should that be? that doesn't make any sense.
the particle interactions remain the same, rigid or not.
the only difference is that your nano-particle will not
deform or break, and you have to ask yourself, if that
actually is a good model, if you are looking at an
atomic scale model.

if you want to deform your surface, but have the nanoparticle
not stick, you have to change the interactions so that they are
only repulsive, e.g. by placing the cutoff where the minimum of
the potential is.

cheers,
    axel.

If it works fine in non-rigid mode, then you use fix rigid on
just the nanoparticle (and turn off other time integration on it),
then you should be fine. There is no conceptual way that
fix rigid can "break" up a rigid particle. Every timestep it
resets the coordinate of every atom in the rigid body so
that it is the same rigid body, albeit at a new position
and orientation. The only way I can see this failing
is if you impose some huge force on the rigid body and
blow it out of the box in a single timestep. But the non-rigid
results indicate you are not doing that. You might monitor
the center-of-mass and vel c-o-m and force c-o-m of the rigid body
by printing the fix rigid output with your thermo output.

Steve

thomas,

i may have mentioned this before, but one thing to note here is,
that if you smash a rigid particle with a single atom at the tip into
a surface, that is effectively the same for the atom at the tip as if
it had the mass of the whole rigid particle. that would also mean
that you will "climb up" on the repulsive part of the potential much
higher, than for the non-rigid particle. at that point, you have to use
a _much_ smaller time-step for being able to accurately integrate
the equations of motion. otherwise you will get excessive forces
that will lead to some atom(s) being "shot" through the simulation
cell followed by a crash of lammps.

i think you need to consider very carefully, what is the actual model
that you need to simulate and what is the useful information
that you can extract from running with a rigid or non-rigid nanoparticle.

cheers,
    axel.

thomas,

Yes, that’s what I did.

It works fine if the nanoparticle is not rigid. Of course, it sticks to the
substrate after the initial impact in that case, as there are interactions
between atoms in the particle and in the substrate.

If the particle is made rigid, I would have thought that it could bounce
back after the impact, since in that case there is no reason why the atoms
would interact with the substrate?

why should that be? that doesn’t make any sense.
the particle interactions remain the same, rigid or not.
the only difference is that your nano-particle will not
deform or break, and you have to ask yourself, if that
actually is a good model, if you are looking at an
atomic scale model.

Axel,

So what does the following command do then?

neigh_modify exclude group particle particle

I thought it was used to turn off interactions within the rigid body?

Of course, that would not make the particle bounce back, but conceptually I would think that this command could also be used to turn off interactions between the particle and the deformable body?

However, as I said before, when this line is included, the calculation crashes.

Thanks for your help.

Thomas

Axel,

So what does the following command do then?

neigh_modify exclude group particle particle

I thought it was used to turn off interactions within the rigid body?

yes. there is no need to compute them. for large rigid particles,
that can result in a speedup of the calculation. it should otherwise
have no impact on the simulation of the rigid body.

Of course, that would not make the particle bounce back, but conceptually I
would think that this command could also be used to turn off interactions
between the particle and the deformable body?

if you turn off interactions between the nanoparticle and the deformable body,
then both won't see each other and thus no deformation would happen.

However, as I said before, when this line is included, the calculation
crashes.

included in which case? rigid or non-rigid?
crashes when? right away or on impact?

the issue that i was raising has little to do with the technical realization.
i was simply asking, whether it would be a good model to simulate
a perfectly rigid body on the atomic scale, as i would expect it to behave
significantly different from a real nanoparticle. i also know from experimenting
with rigid particles that have a "perfect tip" how easy it is to crash
a simulation
due to the excessive forces generated at the tip atom on impact, even
if the nanoparticle is build from unphysically light particles (to be able to
move it with interactive MD).

cheers,
    axel.

Axel,

I think I get your point with respect to the conceptual aspect of the model itself.

Having said that, I still do not understand why my simulation crashes when I include the neigh_modify command. More specifically, please find below (next to your comments) more details on the simulations I am doing.

Thanks,
Thomas

Axel,

So what does the following command do then?

neigh_modify exclude group particle particle

I thought it was used to turn off interactions within the rigid body?

yes. there is no need to compute them. for large rigid particles,
that can result in a speedup of the calculation. it should otherwise
have no impact on the simulation of the rigid body.

But it does! (see more details below, answering your couple of questions)

Of course, that would not make the particle bounce back, but conceptually I
would think that this command could also be used to turn off interactions
between the particle and the deformable body?

if you turn off interactions between the nanoparticle and the deformable body,
then both won’t see each other and thus no deformation would happen.

OK, that’s in fact what is happening (ie no deformation happens in this case)

However, as I said before, when this line is included, the calculation
crashes.

included in which case? rigid or non-rigid?
crashes when? right away or on impact?

Included in the rigid case. It crashes shortly after impact. Atoms get ejected and some atoms are lost since they are ejected outside the box.

If not included (also in the rigid case), then the simulation runs normally, the particle moves rigidly and the substrate deforms upon impact, without any atom being ejected.

If you built your rigid body with many highly overlapped
particles, then if LAMMPS computes the interactions
between those particles (within the rigid body) it
will get huge values. In principle they should cancel,
but in practice they will not due to round-off. More
importantly those value will swamp the small values
you care about, which the interactions with
other particles outside the rigid body. So in
that scenario it's important to exclude the interactions
within the rigid body, else you can often get
different (bad) dynamics.

Steve

thomas,

Axel,

I think I get your point with respect to the conceptual aspect of the model
itself.

Having said that, I still do not understand why my simulation crashes when I
include the neigh_modify command. More specifically, please find below (next
to your comments) more details on the simulations I am doing.

i don't think anybody will be able to give a definite answer without
having access to the exact input files that you are running and being
able to reproduce what you are seeing.

words to describe what you are doing can be easily misleading,
as there is always a chance that what is in your input does something
that is different from what you think that it is doing.

Thanks,
Thomas

[...]

> However, as I said before, when this line is included, the calculation
> crashes.

included in which case? rigid or non-rigid?
crashes when? right away or on impact?

Included in the rigid case. It crashes shortly after impact. Atoms get
ejected and some atoms are lost since they are ejected outside the box.

so what atoms get ejected? my guess would be, those are not atoms
from the rigid particle, but atoms in the surface that it is hitting.
if your rigid particle hits a single atom at the surface perfectly
in the center, there would be a significant transfer of momentum.

the typical MD settings, are not able to handle this kind of
scenario well. they are optimized for maximum MD speed
and the stability of the integrator will break down, if you deviate
too far from it.

cheers,
    axel.