I posted this a couple of weeks ago about my jobs stopping early. I'm trying to fill up a "2D" hopper with particles, remove the piece at the bottom, and let the particles drain out, but I would get some sort of error and my job would end early (and it seems like it always ends on timestep 77000 of X). The only response I received was to update to the latest version. I am now running LIGGGHTS 2.1, and I'm getting the exact same issues. With the earlier version, the simulation would end early if I tried to insert "too many" particles (too many in quotes because I never discovered if there was an actual limit or not), and since I'm getting the same type of error with 2.1, I suspect it would happen again.
PLEASE take a look at my LIGGGHTS script (nano.save.2) and my output file. The output file is fairly verbose, but near the bottom you can see that a certain task has a segmentation fault. I'm hoping that means something to the programmers on the board, because I don't know what it means or how to debug/fix it.
Thanks again.
| Attachment | Size |
|---|---|
 nano.save_.2.txt | 2.09 KB |
| standard_out_file.1662705.repace.pace_.gatech.edu_.txt | 16.91 KB |
| hopper_open_2.txt | 10.8 KB |
| hopper_insert_2.txt | 580 bytes |
| valve.txt | 3.25 KB |
cstoltz | Thu, 09/06/2012 - 12:24
Could you also post the STL
Could you also post the STL files you used?
Thanks - Chris
msandli | Thu, 09/06/2012 - 16:51
See edited first post
Chris,
I edited my first post and added the stl files as txt files. As you can see by my script, my hopper and valve are 2 separate pieces. When I initially import them, the stl files overlap, making one piece. Then I simply unfix the valve. I haven't had any problems viewing my stl dumps, and they look correct, so I hope it's not somehow still a problem. I've also managed to get a few simulations to run long enough to start emptying out the hopper, although I haven't made it to completely empty yet.
Feel free to edit my script if it will be easier/faster to show me changes I need to make.
Anything else you want to know? I'm running this on a multi-core node, and I thought I saw a forum topic at one point that said people were getting errors if they used certain numbers of CPU's, but I could be mistaken.
Again, your help is greatly appreciated.
ckloss | Thu, 09/06/2012 - 17:07
Thanks for the report, I'll
Thanks for the report, I'll have a look!
Christoph
cstoltz | Thu, 09/06/2012 - 19:28
Christoph, I ran this on my
Christoph,
I ran this on my machine and it ran mostly fine in serial (had one particle show a sudden acceleration that led to it leaving the system). I did have to change the overlapcheck statement in the particle insertion to 'yes' however. Otherwise, the particles would immediately start blowing out. I'm assuming that new particles were generated on top of old particles and created extremely high forces.
When I ran it in parallel, however, the simulation goes awry immediately. It says that it inserts 200 particles on the first step, but then only retains some small number depending on the number of cores I use. No clue what is happening here, but for some reason, the particles aren't inserting correctly.
Regards,
Chris
msandli | Fri, 09/07/2012 - 02:19
update
I ran this with overlapcheck set to yes, and it seems to run fine! I was only running it with overlapcheck off because the manual said it scaled well in parallel.
If I need to run it with overlapcheck on, that's fine with me. Like I said, I'm interested in draining the particles, not really in how they behave when filling up the hopper.
If you come up with some sort of explanation, please let me know, I'm still curious about this. Until then, I will keep overlapcheck "yes" until I run into another snag....
Thanks again!
cstoltz | Fri, 09/07/2012 - 04:07
With regards to the
With regards to the overlapcheck, I would suggest setting it to 'on' any time you're going to simulate finite sized particles. Else you run the risk of generating a new particle on top of an existing particle and causing the system to blow up, or at the least cause a particle to go flying off into space.
Regards,
Chris
ckloss | Fri, 09/07/2012 - 17:08
Hi msandli,>>I ran this with
Hi msandli,
>>I ran this with overlapcheck set to yes, and it seems to run fine!
>I was only running it with overlapcheck off because the manual said it scaled well in parallel.
The manual also says you have to relax the system in some way, which you did not do. Typically, overlapcheck no makes more sense with fix insert/pack and letting the packing relax with fix nve/limit. I'll remove it from the list of options for the insert/stream command in order to avoid confusion...
Cheers, Christoph