runaway Q_DOT_RAD

[drjfloyd]

Case in discussion #13434 wound up in a loop. This was caused by a warning on TMP_G_N < 0 which was caused by Q_DOT_RAD becomming a very large negative number. The current means of computing Q_DOT_RAD is:

Move Drops
Evaporate drops using QR_W to get Q_DOT_RAD based on AVG_DROP_AREA from before moving.
Compute A_D_A after evaporation
Do radiation getting QR_W using the A_D_A after evaporation

Had a paricle cross mesh boundaries and it had a slight non-zero QR_W but an essentially zero AVG_DROP_AREA. As a result in Q_DOT_RAD = QR_W / A_D_A * ADROP was ~ -1 / 1E-117 * * 1E-7 = -1 E110.

One option is to move evaporation to before particle movement. This however could mean issues with drag in cases where particles fully evaporate. One possible option to prevent that would be to store the old radius. Then assuming a constant mass loss rate can get r(t) over the time step and use that to get the average radius for drag by averaging r(t)^2 over the timestep .

[mcgratta]

I'm running the verification cases. I put the call to ENERGY_TRANSFER just before MOVE_PARTICLES in the same mesh loop. If you do this, does it solve the problem you first encountered?

[drjfloyd]

Compiling and testing now. Takes about an hour to get to the point of failure.

[mcgratta]

The verification cases ran without any out of bounds errors.

[drjfloyd]

It has gone out a ways past the prior failure point and not seeing any WARNING messages.

[drjfloyd]

should we push this change up and let firebot chew on it?

[mcgratta]

I'll commit the change for which I ran the verification cases. We'll see if firebot catches any change in images.

[mcgratta]

Actually, I just noticed that PARTICLE_MOMENTUM_TRANSFER should probably be moved as well to keep all the particle stuff in a consistent place. Since there has been some work lately on that, I'm going to run the verification cases again, and then I'll check the images too.

[mcgratta]

The verification cases were fine. I'll leave the issue open until we pass firebot tonight, where timings and images will be checked as well.

[drjfloyd]

Noticed another potential issue. In radi and in wall we were only entering droplet loops if NLP > 0; however, NLP could be zero and there could still be a large radiative or surface cooling effect if the last particle(s) had just been in a cell at a mesh boundary and then left. This was part of this issue as in radi we had the combination of basing radiation on the prior timestep particles plus not correctly updating QR_W if the last particle left a mesh. I will fix this by adding LIQUID_PARTICLES like we have SOLID_PARTICLES.