[SDEM] CalculateElementalVolume threshold modified

[jgonzalezusua]

Description The problem came from the modification of the CalculateVolume function in the script SwimmingDEMApplication/custom_functions.h. The threshold to consider the element volume bigger enough to be calculated has been changed making imposible to use meshes with small element sizes (for example, the ones located in the boundary layer). My questions are: Can we change again this threshold? and why are we using this epsilon and not other value?

Scope

• SwimmingDEMApplication/custom_functions.h line 631

Expected behavior Kratos should not throw any error when meshes with boundary layers are used.

Environment

• OS: Ubuntu 18.04
• Branch: master
• Python 3.7

[maceligueta]

Is the error triggered by this if? https://github.com/KratosMultiphysics/Kratos/blob/284902a7f196d4c19df9fda53d7bf273f9914016/applications/SwimmingDEMApplication/custom_utilities/custom_functions.h#L630 It's weird that the volume is below that epsilon, though. Anyways, I have two comments:

• better use geom.Volume() than an independent method CalculateVolume(geom). I thought about it when I saw the warning but did not remember to mention it to you
• when checking the volume of an element, I would consider comparing the resulting volume to the size of the edges (cubic power), not just its absolute value

[jgonzalezusua]

I didn't aware about these changes in that script until now. Yes, it is in that line. I don't know why it was decided to use independent functions, but it should be considered to remove that threshold. For example, in the mesh I am using, the element has a volume of 1.8e-16 while the threshold is 2.21e-16. Before that change, I ran that mesh without any problem in the solution, so I do not think that it is necessary to use this check.

[maceligueta]

Maybe that check was put there to avoid a division by zero. In that case, the check should be outside the function, right before the division.

[jgonzalezusua]

So it is enough to be different from zero, or at least much smaller than the one introduced

[maceligueta]

I don't really know. Maybe @GuillermoCasas remembers something about it.

[GuillermoCasas]

I do not think it is correct to invoke the stad epsilon here. First, it is a length scale cubed (so lenght scales of the order of the micrometer would already trigger the error), second, there is no mathematical/numerical problem with calculating the volume wth such small values. I would leave it at <=0, since it is non-(strictly)positive numbers that are wrong strickly speaking. Thus, it is necessary to change the error message as well.