Unexpected Addtional Velocity in Uniaxial Extension Simulation

LAMMPS LAMMPS Beginners
,
1

Hi all,
Beginner ask for help: I am attempting to conduct uniaxial extension simulation in a polymer melt and nanoparticle system. However, it was observed that the nanoparticle was affected by an additional velocity during the extension process. This is a non-physical behavior. I would like to know how to remove the influence of the additional velocity. Any better approach is welcome. Thank you very much! :pray:

Below are the details

The Purpose
My goal is to extension the system for a long enough time to obtain the physical movement of the nanoparticle within it.
For this reason, I choose to use the commands in UEF package instead of using the “fix deform” and “fix nvt/sllod” commands, because the latter cannot achieve long-term extension. ref 1,2,3,4.

The Code
The “fix nvt/uef” and “dump cfg/uef” commands were used.

units lj
boundry p p p
change_box triclincic
...
group Polymer type 1
group NanoParticle type 2

fix 1 all nvt/uef temp 1.0 1.0 10 erate x y 0.001 -0.0005
fix 2 all momentum 100 linear 1 1 1
dump 1 NanoParticle cfg/uef 100 OUT.*.cfg mass type xs ys zs id mol
dump 2 NanoParticle custom 100 OUT.lammpstrj id mol type x y z
...
timesteps ${dt}
run ${Nsteps}

The Problem

When I perform extension using “nvt/uef”, the expected result is that the polymer and nanoparticle can maintain consistent movement, where the movement of the nanoparticle comes from the interaction with the polymer.

However, I found that the nanoparticle was affected by an additional velocity, specifically performed as the longest direction of the nanoparticle automatically pointing towards the extension direction. This directional phenomenon will occur even if only nanoparticle exist.

I guess that the reason of this additional influence is the SLLOD equations integrated in “fix nvt/uef”.

The fix nvt/uef command … integrates the SLLOD equations of motion, originally proposed by Hoover and Ladd.

The SLLOD equations of motion brings additional velocity to the particles.

\dot{r}_i = \mathbf{v}_i
\dot{\mathbf{v}}_i = \mathbf{F}_i / m_i - \mathbf{L} \cdot \mathbf{r}_i

Among them, r_i and v_i are the position and velocity of atom i respectively, F_i is the force acting on atom i, m_i is the mass of atom i, and L is the tensor related to flow.

Reference links: UEF package, nvt/uef, dump cfg/uef, fix nvt/sllod, fix rigid.

Key Point
The key is “how to remove the additional influence on nanoparticles while allowing them to be remapped by UEF package".

I had attempted to directly exclude nanoparticles from the nvt/uef command. The result was that nanoparticles could not be remapped like other particles, only the polymer were remapped. However, the remapping box is the basis of the UEF algorithm. Besides, I also attempted to set the nanoparticles as rigid bodies. However, the nanoparticles were not remapped for unknown reasons. So neither of the above two methods is acceptable.

I would like to know if it is possible to remove the additional influence on the nanoparticle, or to make the rigid nanoparticle capable of being remapped by UEF package. Any better approach is welcome!

Thanks for your reply! :pray: And my lammps version is “23 Jun 2022 - Update 1”

(There is no attachment becuase new users are not allowed to upload.)

2

Performing NEMD with extended nanoparticles is tricky for the reasons you say. The SLLOD equations assume all integrated particles will seek to follow the local streamlines, but this isn’t necessarily true for extended rigid bodies.

There are strategies that you can try to mitigate spurious effects. You could try integrating just the polymer with the SLLOD equations in UEF and integrate the nanoparticles with a regular NVE. Essentially, let the polymer fluid be the thermal resevoir that thermostats and advects the particles.

That strategy might help, but at the end of the day SLLOD assumes and enforces a homogeneous flow gradient which is never entirely true in any molecular or heterogeneous system, so you always have to check and see if its an appropriate approximation for your system.

2 Likes
3

Hi @toconnor,
Thanks for your reply!

Your explanation about the SLLOD equations and rigid bodies have helpd me understand the phenomenon of their incompatibility.

But I still have some problems now. The solution I understand is to control the polymer using nvt/uef commands and the nanoparticles through some kind of NVE, so that the former will be affected by SLLOD and the latter will not.

However, this means that the nanoparticles could not be remapped by the UEF package. The remapping box is the basis of the UEF algorithm. Only the nanoparticles are remapped to new positions and velocities at the specified time by the UEF algorithm, they are in continuous motion.

The above is the core contradiction I have encountered. I hope to use the remapping of the UEF algorithm but do not expect the additional impact caused by sllod. Or any better approach is acceptable.

I am not sure if my understanding is correct. Looking forward to your reply.

4

The idea would be that the remapped fluid particles can advect your nanoparticles and cause them to move with the flow via intermolecular interactions. You cant assume this will work; you have to check it for each composition and strain rate you want to study.

5

@qtang and @toconnor
I would like to add to this discussion that there is a pending pull request by @sjplimp with some corrections to the LAMMPS implementation. Please note the paper that is referenced. It should contain further information. Enhancements to enable more robust NEMD shear of rigid bodies by sjplimp ¡ Pull Request #4577 ¡ lammps/lammps ¡ GitHub

1 Like
6

Thanks for your reply! I will study the link you provided to improve my understanding.

7

Hi @toconnor,
Thank you for your reply! As you told me, one of the ideal situations is that the movement of nanoparticles is driven by the flow of fluid particles via intermolecular interactions.

But I think there might have been some misunderstandings. The meaning of the word “remap” I use here is not that fluid particles are controlled by algorithms to form uniaxial extension flow.

It has two meanings. One is the “remap v” of the particle crossing the boundary, and the other is the “huge change in the computer reference coordinate system” specific to the UEF algorithm, which is manifested as huge adjustments in the angles, positions and velocities of all particles (>30°, >20σ, >0.01σ/τ). The details of the adjustment for the latter are overly complex. Refer to ref.1 and fix nvt/uef.

The latter is the reason why it is difficult to control nanoparticles and fluid particles separately. I hope the nanoparticles can follow this huge adjustment (when the computer reference coordinate system changes), otherwise the angles, velocities and positions of the nanoparticles will have huge errors.

Thanks for your help!

8

Hi @toconnor,
Thank you again for your help. The additional velocity does not come from the presence of rigid particles but occurs under normal circumstances. The two situations in the second row of the table below are exactly the results that would be encountered in the way you mentioned. This stems from not being remapped.

Not rigid Use rigid
All apply the UEF algorithm Have additional velocity Similar to the result in the lower left corner(version23 Jun 2022)
Only nanoparticles have not applied the UEF algorithm Huge errors in the position, Angle, etc. of nanoparticles Similar to the result in the lower left corner

The upper left corner of the above table is exactly what I mentioned in my post, the lower left corner is about the results of separately processing nanoparticles and fluid particles, and the upper right corner is an attempt to solve the additional velocity, but it is very similar to the result in the lower left corner, that is, the nanoparticles were not remapped for unknown reasons (when the computer reference coordinate system changes).

Sorry, what I wrote was very messy. The calculation method of the UEF algorithm is overly complex and difficult to describe.

The key problem I need to solve is how to remap the nanoparticles like fluid particles (when the reference coordinate system changes significantly), without any additional velocity influence. But all attempts were unsuccessful.

The second problem is that nanoparticles with rigid commands applied do not seem to be remapped either. I’m not sure if it’s because “nvt/uef is time-integration fix”. ref links about rigid.

The above is the situation description. I would like to know any idea that might be helpful. Thanks!

9

Since the issue you describe sounds UEF-specific, I suggest you contact the author of the UEF package, David Nicholson - see his Gmail address in the src/UEF/README file.
If he reads this thread, maybe he will have ideas.

The changes in PR #4577, mentioned above by Axel, were for traditional NEMD via fix deform for rigid bodies, so are likely not applicable to isolated NPs in solution.

10

Another suggestion is to try modeling your system with simple continuous shear applied by fix deform (standard NEMD). You can use fix nvt/sllod and experiment with applying it to the entire system versus just the polymers (not the NPs). To see if you can get the desired result where the NPs flow with the polymers and the entire fluid deforms consistent with the box. If that doesn’t work, there is a more fundamental issue than UEF. If it does work, then there is likely something different about the way UEF is operating on this kind of hybrid system.

11

Hi @sjplimp,
Thanks for your suggestion! I will try to control the deformation of the simulated box through “fix deform” and apply “fix nvt/sllod” to all the atoms of non-nanoparticles. Although I have no clue about how to implement various operations of the UEF algorithm, I will try to solve it.

Thanks for your help again.

12

Sorry, it seems that I misunderstood your meaning. I’m not good at English. Later, I will compare the two cases of “nvt/sllod applied to all particles” and “only applied to polymers” to confirm whether the fluid flow can be consistent with the deformation of the box. Thank you for your help.