Bug/instability related to variable TotalVelocityWater on LagrangianPhase.FOR

[albuquerqueraniel]

Hello everyone!

I would like to report a bug/instability that I'm suffering when I try to simulate some problems with 2 phases. My model consists of a rigid body penetrating a saturated soil (fully coupled). When I run the code I receive the following error:

This error is caused when ocurr an operation with a NaN. I checked my model several times looking for inconsistencies and didn't find them, so I debbuged the model in Visual Studio. I find out that this error appered in subroutines ApplyDampingForceWater (when homogeneous local damping is defined) and MapWaterDampingFromParticles (when homogeneous local damping is deactivated on CPS file).

This issue is related to TotalVelocityWater. At some point during the execution of the 2 phase calculation on LagrangianPhase.FOR, a component of TotalVelocityWater takes a NaN value.

I tried to track were this NaN was assigned, so I asked Anura to write on the MLG file the value of TotalVelocityWater(I, J) (were "I" and "J" are the index of the specific component with the NaN that triggered the invalid floating). I've write the value of TotalVelocityWater before and after subroutines that call or read this vector.

I noticed that extremely small values (on the order of E-360) were being assigned to this variable. NaN values may be generated by operations between small numbers.

When I finished entering the commands to write the TotalVelocityWater values to the MLG in the code and ran the simulation, I no longer got the Floating invalid error.

Somehow, the fact that I asked in several parts of the code to write the value of TotalVelocityWater to the MLG prevented the NaNs from being generated. I suspect that because this vector has extremely small values, at some point the computer loses information from the values stored in it, and so the NaNs are generated. And the fact that I asked the computer to access this array at several points in the code helped save the original values in its temporary memory. But this is just a guess.

My model is running now, but it is writing values of TotalVelocityWater to the MLG file in every load step. The solution that I found is a "go horse" way, so I'm sharing this issue with you people, that has far move knowledge about the code, to know if you can find a more formal solution.

Best regards,
Raniel

[murphy-john]

Thanks for the discussion. I haven't come across this issue. Were you able to find where the extremely small values came from? Why were they assigned that small in the first place? I think this might be caused by the rigid body.

It was very interesting to see how it resolved itself. It was also cool to learn the new (to me) coding term "go horse".

[albuquerqueraniel]

Hello!

I found the source of this issue. Indeed it was associated with the rigid body. The small values were generated at the subroutine CorrectWaterForPrescribedVelocity, which is only accessed if the flag CalParams%ApplyContactAlgorithm is true. There is a print of the subroutine:

The variable which had very small values was PrescribedValues(J). PrescrVelocity(nn,JJ) receive values from PrescribedVelocityNodes, which is generated in the subroutine GetNodePrescribedVelocity.

As you can see in the next picture, the subroutine just assigns values to PrescribedVelocityNodes if the flag IsPrescribedVelocity is true.

But, if I dont prescribe velocities to the model, the values of PrescribedVelocityNodes aren't defined. So I just added this line (next picture) to the beggining of the subroutine GetNodePrescribedVelocity and no extremelly small values were generated anymore.

With that modification, I could remove the temporary solution that I was using and had no more issues with invalid floating operation errors.

Best regards,
Raniel