particles are not shown moving in dump file

Submitted by sajjadjeeven on Wed, 07/21/2010 - 05:05

Hi all!
i created a box and divided it into two parts(regions).The particles are poured in one region and are made to move into the other region and the particles can be seen moving in paraview.But when i see the dump file(region), all the particles are shown in the same region and they do not change their region with the passage of time.As the region is a static command, Is there any solution of this ? Actually i want to know the number of particles in each region after some specific time intervals.
If anybody knows please help.Thanks
sajjad

Forums:

sajjadjeeven | Sun, 08/01/2010 - 10:48

Dear Christoph!
First of all i am sorry that i could not make my problem so clear to you that you can understand it. i write it again in detail...
I created a box and divided it into two parts (regions) with the help of an imported STL wall. The two regions are grouped as grp1 and grp2 . The imported wall has a window at its center. After that I poured Two type of particles i.e. small and big particles into region1(grouped as grp1). Then i applied wiggle command on the base of my box. I obtained the two dump files for the two regions(grp1 and grp2). When i see the vtk files by using paraview then i can see that the particles are moving from one region of box to the other region of box through the window and the number of particles are varying in these two regions. But when i see the dump file of these regions(grp1 and grp2), the number of particles are constant in both regions. Actually i want to find the number of particles which move from one region to the other region though the window after some time intervals. So my problem is to find the number of particles in these two regions at differrent instants of time, so that i can find the flux of particles through the window.
With best of regards
sajjad

ckloss's picture

ckloss | Mon, 08/02/2010 - 08:41

Hi sajjad,

I guess you are dumping a specific group's data if you want

Assume mygroup is the group of particles in region 1. What I would suggest is to do the following:

...
dump mygroup dmp 5000 ....
...

run 100000 every 5000 group mygroup region region1

Alternatively, you can also evaluate the flux of particles in paraview e.g. if you make a histogram of the data over time with the x (y,z) pos as data input.

best,
Christoph

sajjadjeeven | Tue, 10/19/2010 - 08:55

Dear Christoph!
According to your's advice i assumed that the 'sm' is the group of particles in region1. Then i applied the following command
dump sm every 5000 id type type x y z ix iy iz vx vy vz fx fy fz ........
run 30000 every 5000 group sm region reg1
but there is always error message 'ERROR: Could not find dump group ID
i have tried many times but could not succeeded.
please help me.
sajjad

raguelmoon's picture

raguelmoon | Mon, 10/25/2010 - 19:09

Hi,
The easiest way for counting specific numbers of particles in specific region is as follow : -
1. dump the file like: dump dpm all custom ... .. ...
2. convert into vtk by pizza
3. open in paraview
4. select particles and click "clip" in the menu
5. choose "x" axis and "plane" and then "apply"
6. in "filters" menu, select "integrate variables" under "data analysis" sub-menu and then apply
7. New data window will appear, choose "clips" from drop down menu in the window.

Now it will show number of particles in specific region you chose from "clip" command. You can see that the number of particles are changing as time is changing. You can also export it for excel/origin etc for further analysis.
Best
Ram

Ram

paulbrumby | Thu, 12/09/2010 - 12:11

Sorry to highjack this thread, but I have a similar problem so thought it would be best to ask about it here rather than start a new thread.

My particle coordinates are not changing between input and output but I think this may be because the particle positions are only output to 6 significant figures whereas I need to have them to be accurate to double precision. Is there any way to have my output to a greater degree of accuracy? My input file (modified from the cohesion example) is shown below, if anyone has some advice on what I am doing wrong I would greatly appreciate it! And yes I know my system is very small, but I really want to keep everything in SI units if at all possible.

atom_style granular
atom_modify map array
boundary p p f
newton off
communicate single vel yes
units si

read_data system_state_old.txt

region reg block -4.99999999999999956E-006 4.99999999999999956E-006 -4.99999999999999956E-006 4.99999999999999956E-006 -4.99999999999999956E-006 4.99999999999999956E-006 units box

neighbor 9.99999999999999955E-007 bin

neigh_modify delay 0

#Material properties required for new pair styles
fix m1 all property/global youngsModulus peratomtype 9764855.27
fix m2 all property/global poissonsRatio peratomtype 0.45
fix m3 all property/global coefficientRestitution peratomtypepair 1 0.85
fix m4 all property/global coefficientFriction peratomtypepair 1 0.20
fix m5 all property/global characteristicVelocity scalar 2.
fix m6 all property/global cohesionEnergyDensity peratomtypepair 1 20000

#New pair style.
pair_style gran/hertz/history 1 1 #hertzian with cohesion
pair_coeff * *

timestep 3.70370370370370200E-010 #for 10 DEM timesteps per cycle.

#Enable this to switch on gravity.
#fix gravi all gravity 9.81 vector 0.0 0.0 -1.0

#Walls at upper and lower z boundaries.
fix zwalls all wall/gran/hertz/history 1 0 zplane -4.99999999999999956E-006 4.99999999999999956E-006 1

#Define all particles in the system as being part of the nve_group group.
group nve_group region reg

#Apply nve integration to all particles.
fix integr nve_group nve/sphere

#Output settings, include total thermal energy
compute 1 all erotate/sphere
thermo_style custom step atoms ke c_1 vol
thermo 1000
thermo_modify lost ignore norm no
compute_modify thermo_temp dynamic yes

#Insert the first particles so that dump is not empty
run 1
dump dmp all custom 10 system_state_dem.txt xs ys zs vx vy vz omegax omegay omegaz radius

#Run DEM
run 2000 upto

ckloss's picture

ckloss | Thu, 12/09/2010 - 12:28

Hi Paul,

firstly, are there any initial overlaps in the system you are reading in? If not, it is natural that nothing will happen, because you do not have external forces acting (such as gravity)

Secondly, if your system extent is in the range of -1e-6 to 1e-6, you should consider another unit system, not SI.
This is because many code operations involve calculations like x^2, which are almost guaranteed to fail if x is as low as in your case.

Cheers,
Christoph

paulbrumby | Thu, 12/09/2010 - 12:54

Hi Christoph,

Thank you for you speedy reply! My particles are read in with initial velocities, which works well at larger length scales. From your reply I now see what I must do. Should I have any problems if I change all these values into Real units?

Best regards,

Paul

ckloss's picture

ckloss | Thu, 12/09/2010 - 13:00

I would recommend LJ (if that is a viable solution for you), real (or metal) will not work, since nobody has yet done the work to include the conversion factors (which are all 1 for LJ) at various positions in the code

Christoph

paulbrumby | Thu, 12/09/2010 - 13:27

That's good to know. I will try to use LJ. Although I am a little confused as to how I will go about converting meters into sigma and seconds into tau etc. I cannot seem to find any conversion tables for this.

Paul

paulbrumby | Thu, 12/09/2010 - 14:21

Ah sorry about that, I think I see. Correct me if I am wrong, but with the LJ system I set the conversion ratios for mass, length and time myself? So I could set my system length to be one and keep everything relative to that and likewise with time and mass?

Or have I gotten even more confused? :)

Cheers,

Paul

ckloss's picture

ckloss | Thu, 12/09/2010 - 15:01

From the units command doc: mass, sigma, epsilon, and the Boltzmann constant = 1, and everything else evolves out of that.
I must admit that I (we) have not validated LJ units, since we did not have the need for that yet.

Best,
Christoph

paulbrumby | Fri, 12/10/2010 - 02:28

Thanks for your replies Christoph.

Just to be absolutely clear about this. If I set my system box to be say 10 sigma long in each Cartesian axis, since the “real” length of my system 10 micrometers I should now convert all other variables (particle diameters, Young Modulus, cohesive energy density, etc) to be expressed in units of sigma (which is now in micrometers rather than meters as I had with the SI unit system). This is just an example, I may need to use sigma = nanometres instead in order to see the change in particle positions during the simulation to a high enough degree of accuracy in the output files.

Likewise, my timestep will be something of the order of 1.0E-010 seconds, so if I take this to be 1 epsilon, I must again convert my velocities, and other functions of time, to be in terms of epsilon rather than seconds.

The same with mass, I may set mass = 1 microgram or smaller depending on how big my variables have become with the new time and length scales.

Am I on the right track here? If so I will let you know how I get on!

Cheers,

Paul

paulbrumby | Thu, 12/16/2010 - 06:52

Dear Christoph,

I am still having some difficulties with this I am afraid. I have things more or less working with LJ units now, but I still have a problem with particle positions. It seems that the dump command outputs the particle coordinates accurate to 6 significant figures but my input data is in accurate to 16 s.f.. So even though my system is now 1e+9 sigma from one end to the other, the particle positions are given to the nearest 10,000 units of sigma. This is not enough to capture the moment of the particles, as I require very small time-steps. Do you have any suggestions for how I can obtain the particle positions to a higher degree of accuracy? I read that the precision keyword can be used with the dump_modify command when using the XTC unit system but was hoping that it may be possible to do something similar with either LJ or SI units as well.

Best regards,

Paul

ckloss's picture

ckloss | Thu, 12/16/2010 - 14:28

Hi Paul,

As I am not an expert on this, I would suggest you post this to the lammps-users board on sourceforge.

Cheers,
Christoph

paulbrumby | Wed, 09/14/2011 - 09:20

Dear Christoph.

Sorry for the delay but I thought better late than never. Your advice was spot on and the people over at lammps were able to help me out. I have included my fixed input file below in case it is useful for anyone and it seems to work okay with SI units for now, but I will keep an eye on things in case I have problems like you mentioned.

I also found that liggghts works really well when coupled with other codes as there is almost no initialisation delay, even when exchanging particle positions by reading from and writing to files.

atom_style granular
atom_modify map array
boundary p p f
newton off
communicate single vel yes
units si

read_data old_system_state.txt

region reg block -0.0000025000000000 0.0000025000000000 -0.0000025000000000 0.0000025000000000 -0.0000025000000000 0.0000025000000000 units box

neighbor 0.0000002500000000 bin

neigh_modify delay 0

fix m1 all property/global youngsModulus peratomtype 9764855.2699999995529652
fix m2 all property/global poissonsRatio peratomtype 0.4500000000000000
fix m3 all property/global coefficientRestitution peratomtypepair 1 0.0500000000000000
fix m4 all property/global coefficientFriction peratomtypepair 1 0.2000000000000000
fix m5 all property/global characteristicVelocity scalar 2.
fix m6 all property/global cohesionEnergyDensity peratomtypepair 1 20000.0000000000000000

pair_style gran/hertz/history 1 1 #Hertzian with cohesion
pair_coeff * *

timestep 0.000000000810185185185

fix zwalls all wall/gran/hertz/history 1 1 zplane -0.0000024583333333 0.0000024583333333 1

group nve_group region reg

fix integr nve_group nve/sphere

compute 1 all erotate/sphere
thermo_style custom step atoms ke c_1 vol
thermo 1000
thermo_modify lost ignore norm no
compute_modify thermo_temp dynamic yes

run 1
dump dmp all custom 1 system_state_dem.txt x y z vx vy vz omegax omegay omegaz radius
dump_modify dmp format "%32.21f %32.21f %32.21f %32.21f %32.21f %32.21f %32.21f %32.21f %32.21f %32.21f"

run 2000 upto

ckloss's picture

ckloss | Wed, 07/28/2010 - 19:34

Hi sajjad,

I am not sure if I exactly understand what you want to do, but yes - the group region command is static.
What you can do is to re-execute it periodically, e.g.

...
dump mygroup dmp 5000 ....
...

run 100000 every 5000 group mygroup region myregion