search

schrummy14 / LIGGGHTS_Flexible_Fibers

This is a modified version of LIGGGHTS that includes granular bond formulations. The original version of LIGGGHTS produced by CFDEM can be found here: https://github.com/CFDEMproject/LIGGGHTS-PUBLIC
GNU General Public License v2.0
45 stars 34 forks source link

Segmentation fault. #2

Closed DanielBorgesOliveira closed 4 years ago

DanielBorgesOliveira commented 5 years ago

I am running a test case create by me and in some part of the program I receive segmentation fault.

The simulation crash when some bonds are broken.

The execution command: $ mpiexec -n 2 liggghts -in in.insert_particles

The problem seems to be caused by the method unpack_exchange of the class AtomVecBondGraN. The file backtrace.txt shows the backtrace reported by gbd 8.2.1 running in debian 10, kernel 4.19.0-6-amd64.

The problem occur when the program execute the instruction:

bond_hist[nlocal][k][l] = buf[m++];

I think the program is trying to write a value outside array bond_hist.

I see that the method grow of the class AtomVecBondGran make the memory allocation for the array bond_hist. Can this method be allocating less memory than is necessary by the program?

The file study.tar.gz has the backtrace.txt and the simulation files.

study.tar.gz

Thank you.

schrummy14 commented 4 years ago

Hello, Sorry for the late reply. I am finishing up my PhD and just now took a look. I was not able to recreate your segmentation fault. I also needed to edit your input file to get it to work.

Also, I noticed that you did not turn off bond formation after bonds were declared, fix bondcr all bond/create/gran 1 1 1 ${bond_skin} 1 6 #every itype jtype cutoff btype newperts run 1 fix_modify bondcr every 0 #do not create new bonds after this line run 1

Was this on purpose? I would recommend not trying to form bonds every step if you would like new bonds to form after some break (although I did not see any bonds break upto 8.5 seconds).

Upon running your simulation I did notice that the simulation is very unstable at the time step you are working with. I know that I gave a formula that I have been using but that formula was created for flexible fiber simulations of wheat straw so I do not know if they apply here. I also calculated the ray and hertz time steps and it was about 20% ray and 10% hertz.

I also found that your stl files take most of the simulation time. I would highly suggest reducing the complexity of the mesh. (140 seconds of simulation time had 120 seconds of file output)

Setting the time step to 0.0001 seems to work just fine for me on a single processor.

I also did not write the geometry to file as writing the geometry to file was taking a very long time.

DanielBorgesOliveira commented 4 years ago

Hi, thank you for your reply. I made the modifications you suggested and the problem has gone. But was needed to decrease the timestep more than the value suggested by the formula. I divided the outputted value by the formula by 2 and the problem was gone.

Looks like the problem was the large timestep this time this time too.

Thank you very much.

schrummy14 commented 4 years ago

No problem.