Hoping someone can help because this is driving me nuts! [Maybe solved, see bottom of post]
Sometimes the indenter interacts with the particles as expected, and other times the indenter seems to pass through the particles with no effect. I've been having this problem for some time so I tried to narrow down the cause. I use a workstation running Ubuntu, and a large HPC cluster, and both run the executable compiled with 'make fedora'
I've attached two input scripts (plus associated stl file) in which I'm trying to move an indenter into a box of particles.
The only difference between the two is that one has particles 1.5mm diameter, and the other has particles 2mm in diameter.
The 2 mm input script works as expected on my workstation (2 cores). On my cluster, this 2mm input file works on upto 3 processors, but beyond that I get the mesh-ghosting effect described above.
At 1.5mm, I can't get the mesh to interact with the particles at all. I thought it might be a message passing issue when run in parallel, but 1.5mm does not work on a single core either, run both with and without mpirun.
Perhaps it's a memory issue, but I'm not getting any error messages in the log file, so I don't really know where to start. If anyone has any idea, I'd love to hear it.
Any suggestions on how to alter the input scripts would be most appreciated, because I've about exhausted what I can try.
Potentially related to this (or not!) is that on multiple cores I'm getting divisions between particles, see attached figure (particle size is visualised slightly smaller for clarity). Is this normal? Are there tips to avoid it?
[edit]
I think I've solved this issue by setting 'check no' in neigh_modify. I'll continue testing to see if this is correct.
| Attachment | Size |
|---|---|
 in.1_5particles.txt | 2.93 KB |
| in.2_0particles.txt | 2.93 KB |
| cyl.stl_.txt | 32.9 KB |
 Proc-Division_small.png | 282.25 KB |
ckloss | Thu, 06/28/2012 - 18:33
Seems you experimented quite
Seems you experimented quite a lot with the neigh settings - have you tried it with the standard values as given in the examples, i.e. neigh_modify delay 0 ?
EDIT: Could reproduce it, I'll have a look!
Cheers, Christoph
ckloss | Fri, 06/29/2012 - 09:08
Thanks, that was some
Thanks, that was some LIGGGHTS-internal issue...! Will be fixed in the next version 2.0.1!
Cheers, Christoph
pfalkingham | Fri, 06/29/2012 - 14:32
Glad it wasn't just me then!
Glad it wasn't just me then! Cheers Christoph
Peter.
ARPITA RAY | Fri, 06/23/2023 - 14:00
zero shear stresses on servo controlled mesh surface
Hello, I am a beginner in liggghts ad have been trying quite for sometime now to simulate a triaxial test but I am unable to detect the glitch in my code. I am trying to simulate a servo-controlled Triaxial compression test with particle insertion in periodic boundaries. During particle insertion, I set my timestep to 0.00001 and after unfixing insertion part I reset the dt using: "fix 5 all dt/reset 10 1.0e-8 1.0e-7 0.005"
For the compression and shearing part, my code goes like this:
"fix moveback all mesh/surface/stress/servo file backwall_new.stl type 2 stress on com -0.05 0.0 0.1 ctrlPV force axis 1.0 0.0 0.0 target_val 500 vel_max 0.01
fix moveright all mesh/surface/stress/servo file rightwall_new.stl type 2 stress on com 0.0 0.05 0.1 ctrlPV force axis 0.0 -1.0 0.0 target_val 500 vel_max 0.01
fix movefront all mesh/surface/stress/servo file frontwall_new.stl type 2 stress on com 0.05 0.0 0.1 ctrlPV force axis -1.0 0.0 0.0 target_val 500 vel_max 0.01
fix moveleft all mesh/surface/stress/servo file leftwall_new.stl type 2 stress on com 0.0 -0.05 0.1 ctrlPV force axis 0.0 1.0 0.0 target_val 500 vel_max 0.01
fix movetop all mesh/surface/stress/servo file topwall_new.stl type 2 stress on com 0.0 0.0 0.15 ctrlPV force axis 0.0 0.0 -1.0 target_val 500 vel_max 0.01
fix movebottom all mesh/surface/stress/servo file bottomwall_new.stl type 2 stress on com 0.0 0.0 0.05 ctrlPV force axis 0.0 0.0 1.0 target_val 500 vel_max 0.01
fix geometry2 all wall/gran model hooke tangential history mesh n_meshes 6 meshes moveleft moveright moveback movefront movetop movebottom
fix integ all nve/sphere
run 500000
unfix ins
unfix geometry2
fix movetop all mesh/surface/stress/servo file topwall_new.stl type 2 stress on com 0.0 0.0 0.15 ctrlPV force axis 0.0 0.0 -1.0 target_val 1000 vel_max 0.01
fix movebottom all mesh/surface/stress/servo file bottomwall_new.stl type 2 stress on com 0.0 0.0 0.05 ctrlPV force axis 0.0 0.0 1.0 target_val 1000 vel_max 0.01
fix geometry3 all wall/gran model hooke tangential history mesh n_meshes 6 meshes movetop movebottom moveleft moveright moveback movefront
#run
variable tri equal 500000
run ${tri}"
All my walls have been specified by wall/gran and stl files used for specifying the mesh surfaces. Also Hooke contact model is used.
But every time I try to display the average normal and shear stress in the dump file (using: "dump I_stl all mesh/vtk 1000 post/Stress_file-*.vtk stress vel area"), it shows zero in these two stages.
Can you please help me out?
Thanks
deepakpawar.2310 | Mon, 06/26/2023 - 11:40
Hi
Hi
It is displaying the zero stresses throughout the compression simulation or only for the few initial few step ?
Thank you and happy leaning !
ARPITA RAY | Wed, 06/28/2023 - 13:44
Thanks for responding
Hi, thanks for the response.
Yeah, it is displaying zero stresses throughout the compression and shearing process. it seems as though there is a perfectly permeable wall which is not capable of applying forces or moving even.
Waiting for some help in this regard.
deepakpawar.2310 | Thu, 07/06/2023 - 14:56
Hi
Hi
you need to modify the mesh/surface/stress/servo command a bit
I guess you sup[pose the provide the PID constants (such Kp, Ki and Kd with servo wall velocity) as well.
see the attached link for more into !
https://www.cfdem.com/media/DEM/docu/fix_mesh_surface_stress_servo.html
Thank you :)
ARPITA RAY | Wed, 07/12/2023 - 11:56
Tried with ratio and mode auto
Sorry for the late response.
I actually tried with ratio and mode auto at the ending of servo command. This way the walls are moving but there is lack of coordination between walls and particles. I mean, the walls are moving independently, not with the particles. Also, they are not achieving the required target force value. It would be of great help if you could suggest some way out.
Thankyou.