In ESyS-Particle, when you wanna use periodic (circular) boundary conditions along one (or more) direction(s), you MUST choose to divide the spatial domain of the model into AT LEAST 2 sub-domains along that/those) direction(s). Meaning, you MUST run the simulation in parallel with AT LEAST 2 sub-domains along that(those) direction(s).
That's a really important feature of ESyS-Particle cited in the following post on ESyS-Particlelaunchpad User's Forum .
I was distracted several times by strange results by the simulations and did not run them properly. I looked for the problem and suddenly realized that I forgot to run it in parallel, at least with 3 threads (i.e., processors), one as master and the other two as slaves (the real computational threads).
Do not loose your time in making stupid errors ...
If you want to run a simulation with circular boundary condition, always check about this detail first.
------------------------------------------------------------------------------
Disclaimer
This post is based on the author's personal experience in using the ESyS-Particle Discrete Element Method code.
This post should not be considered as an official document about the code itself.
This post does not come with any warranty about the correctness of its content.
If you find any error in the content, please write to the author.
------------------------------------------------------------------------------
Wednesday, August 19, 2009
Monday, August 17, 2009
ESyS-Particle: RotBondPrms interaction group 's parameters
Since version 2.0, for 3D simulations, RotBondPrms interaction group's parameters identifying elastic spring constants have been redefined in order to take into account the effect of the particle size distribution.
The parameters, members of the class RotBondPrms, are the following ones:
Then, for example, normalK must be expressed as a Young modulus and the corresponding breaking threshold normalBrkForce as a yield stress.
Again, this is valid only for 3D simulations and for ESyS-Particle version 2.0 on.
The same principle applies for the corresponding members of two other classes implementing other different interaction groups: RotFrictionPrms and NRotElasticWallPrms.
-------------------------------------------------------------------------------------------------
Disclaimer
This post is based on the author's personal experience in using the ESyS-Particle Discrete Element Method code.
This post should not be considered as an official document about the code itself.
This post does not come with any warranty about the correctness of its content.
If you find any error in the content, please write to the author.
-------------------------------------------------------------------------------------------------
The parameters, members of the class RotBondPrms, are the following ones:
- normalK
- shearK
- torsionK
- bendingK
- normalBrkForce
- shearBrkForce
- torsionBrkForce
- bendingBrkForce
Then, for example, normalK must be expressed as a Young modulus and the corresponding breaking threshold normalBrkForce as a yield stress.
Again, this is valid only for 3D simulations and for ESyS-Particle version 2.0 on.
The same principle applies for the corresponding members of two other classes implementing other different interaction groups: RotFrictionPrms and NRotElasticWallPrms.
-------------------------------------------------------------------------------------------------
Disclaimer
This post is based on the author's personal experience in using the ESyS-Particle Discrete Element Method code.
This post should not be considered as an official document about the code itself.
This post does not come with any warranty about the correctness of its content.
If you find any error in the content, please write to the author.
-------------------------------------------------------------------------------------------------
Thursday, July 30, 2009
dump2vtk: tips & tricks
dump2vtk is a very useful additional tool in ESyS-Particle.
It can be found in the folder ESyS-Particle root folder>/Tools/dump2vtk (for ESyS-Particle version 2.0 and not compiled with a custom folder for binaries, otherwise it'll be in the directory of all the binaries).
It can be used for creating VTK data files out of the files produced by CheckPointer.
What it does is essentially the following.
where ID = 0 for the format file and = 1,2,3, .... for the different processes the simulations is
divided into, ???? stands for the number of the recording time step (in a series).
dump2vtk -i -o _ -t tini numsnap deltat [-list] [-bkrlist] [-t0] [-sz] [-rxb] [-single_tag] [-rot] [-unwrap]
Options and their arguments:
-i : setup the CheckPointer fileNamePrefix, which should be equal to the fileNamePrefix defined in the CheckPointPrms class.
-o: setup the VTK output fileNamePrefix
-t: define the initial recording time step (tini), the total number of snapshots that you want to produce (numsnap) and the gap between two recording time steps, i.e., the interval (in time steps) between two CheckPointer files (deltat), such that dump2vtk knows which CheckPointer file to convert next.
-list: instead of constructing the list of input files starting from the CheckPointer fileNamePrefix and from the arguments of the option -t, it takes as input a list of files
-brklist: not yet analyzed
-t0: not yet analyzed
-sz: take only a slice Z = constant
-rxb: not yet analyzed
-single_tag: not yet analyzed
-rot: flag for indicating that the particles are rotational
-unwrap: not yet analyzed
N.B. #1: the VTK output files produced by dump2vtk are numbered according to an increasing sequence. This sequence does not have any relation to the sequence of time steps the different CheckPointer files refer to. Example: suppose that, during an ESyS-Particle simulation, you recorded CheckPointer files every deltat = 100 time steps. You want to convert into VTK snapshots the CheckPointer files from time tini = 1000 to tfin = 5000. That means that you want to convert a total number of numsnap = 51 CheckPointer datasets into corresponding VTK snapshots. You can do that running the command
dump2vtk -i <CheckPointer filename prefix> -o < VTK unstructure grid filename prefix>_ -t 1000 51 100 [...]
The correspondingly generated VTK file names will be indexed from 0 to 50, being their index not related to the actual simulation time step the snapshot refers to.
N.B. #2: there could be a problem when your ESyS-Particle script is not writing CheckPointer
output files in the same directory where it's located. In order to get that, you have to define the CheckPointer fileNamePrefix with the full path, as in the following example:
ckptr_for_ParaView = CheckPointPrms(
fileNamePrefix = "/pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt",
beginTimeStep = 0,
endTimeStep = nt,
timeStepIncr = 100
)
In such a case, the format file for each CheckPointer (the one whose name terminates with index 0) will point to the CheckPointer sub-domains files via their full paths. Example: for a simulation domain divided in 2 subdomains and for the CheckPointer at time t = 0, the file /pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt_t=0_0.txt will point to the files /pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt_t=0_1.txt and /pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt_t=0_2.txt.
If you move the the CheckPointer files into a different directory where they were created or onto a different machine and then try to run dump2vtk, it won't find the sub-domain Checkpointer files, unless the same path is recreated, in the new machine case.
Suggestion: if you are using full path CheckPointer fileNamePrefix in your ESyS-Particle script, leave the CheckPointer files in the same directory and machine before running dump2vtk. If you need to move the CheckPointer files on a different machine, write the CheckPointer files in the same directory the ESyS-Particle script runs in.
-------------------------------------------------------------------------------------------------
Disclaimer
This post is based on the author's personal experience in using the ESyS-Particle Discrete Element Method code.
This post should not be considered as an official document about the code itself.
This post does not come with any warranty about the correctness of its content.
If you find any error in the content, please write to the author.
-------------------------------------------------------------------------------------------------
It can be found in the folder ESyS-Particle root folder>/Tools/dump2vtk (for ESyS-Particle version 2.0 and not compiled with a custom folder for binaries, otherwise it'll be in the directory of all the binaries).
It can be used for creating VTK data files out of the files produced by CheckPointer.
What it does is essentially the following.
- Take as input the different files produced by the CheckPointer (one file for each recording time step); these files are usually called
where ID = 0 for the format file and = 1,2,3, .... for the different processes the simulations is
divided into, ???? stands for the number of the recording time step (in a series).
- For each recording time step, a corresponding VTK unstructured grid (.vtu) file is created. In case of parallel simulations, dump2vtk takes care of putting together the different CheckPointer files and respective datasets stored by the different processes.
dump2vtk -i
Options and their arguments:
-i : setup the CheckPointer fileNamePrefix, which should be equal to the fileNamePrefix defined in the CheckPointPrms class.
-o: setup the VTK output fileNamePrefix
-t: define the initial recording time step (tini), the total number of snapshots that you want to produce (numsnap) and the gap between two recording time steps, i.e., the interval (in time steps) between two CheckPointer files (deltat), such that dump2vtk knows which CheckPointer file to convert next.
-list: instead of constructing the list of input files starting from the CheckPointer fileNamePrefix and from the arguments of the option -t, it takes as input a list of files
-brklist: not yet analyzed
-t0: not yet analyzed
-sz: take only a slice Z = constant
-rxb: not yet analyzed
-single_tag: not yet analyzed
-rot: flag for indicating that the particles are rotational
-unwrap: not yet analyzed
N.B. #1: the VTK output files produced by dump2vtk are numbered according to an increasing sequence. This sequence does not have any relation to the sequence of time steps the different CheckPointer files refer to. Example: suppose that, during an ESyS-Particle simulation, you recorded CheckPointer files every deltat = 100 time steps. You want to convert into VTK snapshots the CheckPointer files from time tini = 1000 to tfin = 5000. That means that you want to convert a total number of numsnap = 51 CheckPointer datasets into corresponding VTK snapshots. You can do that running the command
dump2vtk -i <CheckPointer filename prefix>
The correspondingly generated VTK file names will be indexed from 0 to 50, being their index not related to the actual simulation time step the snapshot refers to.
N.B. #2: there could be a problem when your ESyS-Particle script is not writing CheckPointer
output files in the same directory where it's located. In order to get that, you have to define the CheckPointer fileNamePrefix with the full path, as in the following example:
ckptr_for_ParaView = CheckPointPrms(
fileNamePrefix = "/pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt",
beginTimeStep = 0,
endTimeStep = nt,
timeStepIncr = 100
)
In such a case, the format file for each CheckPointer (the one whose name terminates with index 0) will point to the CheckPointer sub-domains files via their full paths. Example: for a simulation domain divided in 2 subdomains and for the CheckPointer at time t = 0, the file /pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt_t=0_0.txt will point to the files /pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt_t=0_1.txt and /pool2/grm118/ShearFaultGouge2DEx3_31/2Dfg_test3_31_ckpt_t=0_2.txt.
If you move the the CheckPointer files into a different directory where they were created or onto a different machine and then try to run dump2vtk, it won't find the sub-domain Checkpointer files, unless the same path is recreated, in the new machine case.
Suggestion: if you are using full path CheckPointer fileNamePrefix in your ESyS-Particle script, leave the CheckPointer files in the same directory and machine before running dump2vtk. If you need to move the CheckPointer files on a different machine, write the CheckPointer files in the same directory the ESyS-Particle script runs in.
-------------------------------------------------------------------------------------------------
Disclaimer
This post is based on the author's personal experience in using the ESyS-Particle Discrete Element Method code.
This post should not be considered as an official document about the code itself.
This post does not come with any warranty about the correctness of its content.
If you find any error in the content, please write to the author.
-------------------------------------------------------------------------------------------------
Friday, May 29, 2009
Create animations with ImageMagick
A frequent task in post-processing scientific numerical simulations consists of creating a movie of simulation runs.
If your simulation codes saves on files graphical snapshots (plots, images, etc. ...) regarding your system, you can create a corresponding movie at the end of the simulation run.
A simple way to create a movie is to put together in a sequence the single snapshots.
ImageMagick is a software suite providing lots of commands for image processing.
Using its command convert you can also stack together in a sequence your simulation snapshots.
Simple example of its use:
convert -adjoin -delay X file_snapshot1 file_snapshot2 ... file_snapshotN file_movie.format
While convert is routinely used for converting an image file from one format into another, it can be used also for stacking together image files into a movie file passing to it the option -adjoin.
-delay X indicates the (real) time delay (X) between one snapshot and the following one. The delay is expressed in a default unit: one 100th of second. This default value can be changed.
After delay put the list of image files being your snapshots. If the files are numbered and ordered incrementally, you can just use wildcards (''*'' character in Linux/Unix) for indicating the changing index. Finally you have to indicate the name of the movie file followed by the format extension. ImageMagick will use the right encoder according to the format extension it finds in the movie filename.
If your simulation codes saves on files graphical snapshots (plots, images, etc. ...) regarding your system, you can create a corresponding movie at the end of the simulation run.
A simple way to create a movie is to put together in a sequence the single snapshots.
ImageMagick is a software suite providing lots of commands for image processing.
Using its command convert you can also stack together in a sequence your simulation snapshots.
Simple example of its use:
convert -adjoin -delay X file_snapshot1 file_snapshot2 ... file_snapshotN file_movie.format
While convert is routinely used for converting an image file from one format into another, it can be used also for stacking together image files into a movie file passing to it the option -adjoin.
-delay X indicates the (real) time delay (X) between one snapshot and the following one. The delay is expressed in a default unit: one 100th of second. This default value can be changed.
After delay put the list of image files being your snapshots. If the files are numbered and ordered incrementally, you can just use wildcards (''*'' character in Linux/Unix) for indicating the changing index. Finally you have to indicate the name of the movie file followed by the format extension. ImageMagick will use the right encoder according to the format extension it finds in the movie filename.
Subscribe to:
Posts (Atom)
