Hi, Christoph, Tapan and Philippe,
here another case that seemingly represents a similar problem as the one Tapan found in his case.
The figure frameA.jpg shows the geometry used in my simulation (run with LIGGGHTS 2.0.6).
The particle that explodes is identified in the figure, whereas a zoom at that particle possibly shows what is causing the explosion (see frameB.jpg): the particle is ignoring the CAD walls and penetrating into it.
It is interesting to note that I had this problem once and it was apparently solved after LIGGGHTS 2.0.5 - at least the case I showed at that time now runs correctly. I wonder if there is still some connection between that problem and the error we find now though.
Hope this further help to identify the problem in the code.
All the best
Eric
| Attachment | Size |
|---|---|
 frameA.jpg | 180.27 KB |
| frameB.jpg | 133.02 KB |
 DEVICE.tar_.gz | 7.33 KB |
| DEVICE2.tar_.gz | 7.34 KB |
Philippe | Tue, 08/28/2012 - 12:29
Hello Eric, it seems that we
Hello Eric,
it seems that we have tracked down the bug - could you maybe post the mesh and input script for the case shown in your picture to make sure that we found it?
best,
Philippe
ericparteli | Tue, 08/28/2012 - 13:59
input script & stl files
Hi, Philippe,
oh, great news! Thanks so much for your feedback to my post.
I attached the case for you in my original message (please see above).It contains both .stl surfaces and the input script. The error occurs close to timestep ~1530000, and the input script saves files every 30000 iterations.
I run this case using LIGGGHTS 2.0.6 with mpirun -np 3 (processors choice is currently specified in the input script). I didn't test yet with other processor choices. Because the last time the bug was present when running LIGGGHTS in parallel for specific processor choices, maybe it might be interesting for testing your improved version to make a try running also with other choices (4 1 1; 2 2 1, etc.), what do you think?
Please definitely let me know if you need some more explanation about the files or about the simulation.
Best
Eric
Philippe | Tue, 08/28/2012 - 14:20
Case
Hello Eric,
Thank you for the case! Unfortunately, without your in-house pair style I am unable to reproduce the issue as the system behaves differently with gran/hertz/history. However, the issue seems similar to the one reported in Tapan's case in the other thread, so I hope we have found it, and it should be fixed in the next release.
best
Philippe
ericparteli | Tue, 08/28/2012 - 15:39
example using stiffness pair style
Hi, Philippe,
that is right, sorry for not having noted that my input script was using a different pair style.
I have found another case using gran/hertz/history/stiffness, please see attachment "DEVICE2.tar.gz" to the original thread (my first message above). Again, I used LIGGGHTS 2.0.6 with mpirun -np 3.
I think it would be useful to make some tests using atom style hybrid molecular granular, if I find some case showing a similar problem I will let you know, OK?
Thanks so much again!
Best
Eric
P.S. By the way the pair style I implemented is the one from this paper, which allows us to analytically calculate the damping constant for the normal restitution coefficient indirectly from the expressions for the restitution coefficient presented in the paper (if you have interest to look at, here the link):
http://pre.aps.org/abstract/PRE/v84/i2/e021302.