Not a Number (nan) error with heat/gran

hunger's picture
Submitted by hunger on Thu, 12/10/2015 - 15:50

Hi all!

I have encountered the following problem with the energy equation in my simulation:

I am running the simulation with a constant particle temperature (for testing purposes). At a certain point, I get some "Not a Number" (nan) errors. The simulation goes on smoothly because the governing equations of movement are not affacted, it's just not possible to postprocess the temperature and heat transfer of the particles because the arrays are corrupted.

The thermo output looks like that when the error occurs:

Step Atoms KinEng rke ts[1] ts[2] heatCond Volume CPU
59000 13817 1816.8261 29.637494 0.20778338 0.10041859 7.2954075e+08 3.7790491 310.32842
60000 13817 1806.1169 26.993184 0.20778338 0.11191048 7.2954075e+08 3.7790491 320.54378
61000 13817 1838.9321 24.340526 0.20778338 0.12035869 7.2954075e+08 3.7790491 330.2177
62000 13817 1906.8327 39.709964 0.20778338 0.13885205 7.2954075e+08 3.7790491 341.76521
63000 13814 1779.3178 40.106091 0.20778338 0.14975786 -nan 3.7790491 356.23465
64000 13811 1724.4541 41.358488 0.20778338 0.090760015 -nan 3.7790491 372.47975
65000 13810 1664.0925 46.42712 0.20778338 0.090571159 -nan 3.7790491 383.07777

Between step 62000 and 63000, I do not take any actions in the simulation or the input file (e.g. inserting particles, changing material parameters or timestep, or unfix anything).

I have tried a lot of variations in my parameters and it looks like the problem is depending on the Youngs modulus somehow. I have also tried to change the time step and the outcome was that with a time step size half as big, the problem occurs at the double number of timesteps.
The only thing I could recognize in the output data is, that particles are lost. But this is not the first time particles leave the domain and usually this does not crash the energy equation.

In my opinion the problem could origin in the heat transfer or the particle temperature calculation, where first the NaN value occurs, which is then effecting the total thermal energy of the system. An interesting result is, that I have already conducted very similar simulations with a higher number of particles and timesteps.

Since I was not really able to locate and solve the problem after a lot of tries, I wanted to ask if somebody else has encountered a similar problem and was able to come up with a solution.

I have also enclosed the main part of my input file to this post. I appreciate any help!

*EDIT: I have changed the way of inserting particles, which means that the number of particles and the history of the particle movement is very different, but the error appears still at the very same time-step.
If I introduce an artificial, decreased Youngs Modulus of 1e08 (compared to the attached file) and I am using area_correction, the simulation seems to run without an error for a very high number of time-steps.
But still, I thing this does not solve the problem, but maybe just move it to a later time-step in the simulation which I was not able to reach yet.

Best regards
Harald

AttachmentSize
Plain text icon Liggghts input script4.84 KB
ckloss's picture

ckloss | Thu, 12/10/2015 - 23:14

Hi Harald,

NAN issues are unfortunately tricky to track down, and may not come from where they seem. I suggest you continue to systematically simplify the simulation to isolate the issue

Best wishes
Christoph

Evan.J | Wed, 07/17/2019 - 15:59

I realize this is years late, but for others who find this post in the future...

I have noticed similar issues recently, and in my case it seems to be directly related to the heat transfer calculated by heat/gran. If I set the thermal conductivity too high, or the specific heat of the particles too low, then I consistently get a NAN value for heat transfer. Without knowing exactly what's going on "under the hood" it seems that there could be a maximum value for particle-particle heat transfer, above which it fails to compute accurately.

Of course if the DCS guys have anything more concrete to say, please feel free to comment!

Thanks,

Evan