Sie sind auf Seite 1von 7

REVERSE POISEUILLE FLOW

We have prepared a script for reverse poiseuille flow in LAMMPS. This kind of flow has been
chosen so that we are able to simulate a flow without having to worry about boundary interactions
(for now). The LAMMPS script is as follows.

log log.f_0p1 1) specifying the log file


echo both 2) 2D problem with periodic boundaries
dimension 2 3) LJ units through the simulation
units lj 4) atom style DPD
newton off
atom_style dpd
boundary ppp
region box block -20 20 1) defining the 40X60 box
-30 30 -0.1 0.1 units box 2) mass of atoms is set to 1
lattice sq 1.5
create_box 1 box
create_atoms 1 box
mass 1 1.0
region left block -20 0 1) Splitting the region in to two parts for
-30 30 -0.1 0.1 units box applying the force in two directions.
region right block 0 20
-30 30 -0.1 0.1 units box
group gleft dynamic all region
left every 1
group gright dynamic all
region right every 1
pair_style dpd 0.05 2.0 215355 1) Specifying the DPD parameters
pair_coeff * * 1 10.0 2.0
fix 1 all nve 1) Specifying the fixes
fix 2 all enforce2d 2) NVE for time stepping
fix 3 gleft addforce 0.0 0.1 3) ADDFORCE for applying external force
0.0 #region left
fix 4 gright addforce 0.0 -0.1
0.0 #region right
compute cc1 all chunk/atom bin/1d x 1) Collecting data while simulation is running
center 0.5 2) We collect particle velocities, mass and
fix chunkfix1 all ave/chunk 100 1 2000 number density
cc1 vy density/mass density/number temp file 3) The second chunk ‘cc2’ is for trial purposes.
veldata_f_0p1 It apparently gives time averaged values for all
compute cc2 all chunk/atom bin/1d x the specified variables.
center 0.5
fix chunkfix1 all ave/chunk 1 1
5000000 cc1 vy density/mass density/number
temp file veldata_f_0p1 ave running
dump 1 all xyz 5000 rs.xyz 1) Dump particle positions into an XYZ file
timestep 0.0001 2) Specifythe timestep, and number of iterations
thermo 1000
run 5000000
The first check is that the temperature of the system should eventually settle down to a constant
value. Does that happen? - Yes.
We check the temperature for different values of external forces applied.

How about the flow profile? - It is supposed to be parabolic.


This profile takes in values of velocities from every time step, and averages them successively. We
would like to start averaging from the time the temperature profile starts becoming steady. For that,
the script needs to change a bit
Run 2000000 1) The run command before the compute first
compute cc1 all chunk/atom bin/1d x center runs the simulation for 20 lakh time steps and
0.5 then starts savng data
fix chunkfix1 all ave/chunk 100 1 2000
cc1 vy density/mass density/number temp file
veldata_f_0p1
compute cc2 all chunk/atom bin/1d x center
0.5
fix chunkfix1 all ave/chunk 1 1 5000000
cc1 vy density/mass density/number temp file
veldata_f_0p1 ave running
dump 1 all xyz 5000 rs.xyz
timestep 0.0001
thermo 1000
run 5000000

Lets have a lok at the temperature profile now.


For the first 20 lakh time steps, the profile reads as the first graph below and the second is for the
next 50 lakh timesteps
Over here, we can raise the question about what tolerance limits can be taken under
consideration for a result to be accepted? It is 5% for engineering purposes.

We would like to check the profile of number density and temperature of particles through the
simulation box length. It should ideally be a straight line, meaning that there are no density
variations, but there will definitely be some. The point is to take note of how much variation is
allowed.

The variation is around 1.5, and fluctuates around that value. The temperature shows varation as a
parabola. We can say it is a parabola because the velocity variations are the same way, and
temperature is calculated from the sum of kinetic energies only.
BACKER. Et al (Poiseuille flow to measure the viscosity of particle model fluids, 2005)

We shall take up the parameters from the paper and simply substitute them in the script that we
have. Let us see how the result comes out. First of all, we want the temperature profile, as
calculated from LAMMPS, directly, and the velocity profile. The list of parameters in the paper are
listed in the table below:

A( conservative force coefficient) 0.0


Sigma (random force coefficient) 4.5
R_c (cutoff radius) 1.0
k_B T 0.5
External force 0.055
Time step 0.001

The changed lines in the script are as follows:

pair_style dpd 0.5 1.0 215355 1) The DPD parameters are fed in here
pair_coeff * * 0 20.25 1.0
fix 3 gleft addforce 0.0 0.055 2) The values of force are fed in here
0.0 #region left
fix 4 gright addforce 0.0
-0.055 0.0 #region right

The temperature profile for the given set of parameters is as follows:

The temperature shows steady increase even up till 70 lakh timesteps. Not very encouraging!
We shall implement some changes here. We can reduce the timestep value and run the simulation. It
shall be changed from 0.001 to 0.0001. This means that 50 lakh timesteps, now shall represent total
simulation time from 5000 seconds to 500 seconds.

Also, one computes are being introduced here. One is “compute ke”, to calculate the total
translational kinetic energy of the atoms. It shall be printed with every time step.
timestep 0.0001 1) reduce the timestep to one tenth of previous
value
compute cke all ke 1) Compute to calculate translational kinetic
energy
thermo_style custom step temp c_cke pe 1) Print total kinetic energy with time
etotal

Still doesn’t look any convinving.......

Let us try something else.


So, from the LAMMPS documentation, we see that there is a pair_style dpd/tstat invokes a DPD
thermostat on pairwise interactions, which is equivalent to the non-conservative portion of the DPD
force field.

So, we make a modification to one line of the code as follows:


pair_style dpd/tstat 0.5 1.0 215355 1) Trying to invoke a thermostat on the system
in an attempt to try and keep the temperature
under control...
Okay, there is something to note here....
We set up the simulation with the changes just mentioned. But, it has been mentioned that the
dpd/tstat pair style simply means that the conservative term in the original set of equations is
dropped. Thus, having a regular dpd pair style with a=0 is the same as having a dpd/tstat pair style.
Thus, putting a=0 should have acted as a thermostat but it still did not. We just wasted 5 hours for
no reason!

So, coming back to the temperature graph, it does not seem to be settling down even at low time
steps, and for 70 lakh runs. Also, the external force is much lower than required temperature. We
may argue that since there is an external force; acting on every particle at every time step, the
temperature must add up, and hence we should expect a graph like the one we have.

But two things come up here: the external force, in the problem acts in opposite directions in two
halves of the simulation box, so per time step, it all adds up to zero (and hence we should not get an
increasing value). Further, the variation of temperature isn’t steadily increasing. At certain times,
the other forces take over (dissipative, for instance), and the overall temperature dips to a certain
value before the external forces take control again.

We can do one thing. There is a pair_style dpd/fdt that sets up the relation between dissipative
force coefficient and random force, as per the Fluctuation Dissipation theorem. The code snippet
shall now become...
pair_style dpd/fdt 0.5 1.0 215355 1) Parameters for the dpd/fdt style. Note that in
pair_coeff * * 0 4.5 1.0 dpd pair style, gamma is specified. Here, its
sigma, in its place.

We must note, however, that there isn’t any actual difference between the two pair styles, as far as
the current problem is concerned because the FDT is kept in mind, in both pair styles, (as per the
documentation). We’ll try, nonetheless...

Das könnte Ihnen auch gefallen