[Gfs-devel] uninitialised values in functions from variable_curvature_event

[Daniel Fuster]

Hi Stephane

I have been experiencing some random problems with function
fit_curvature getting errors like

[compute-7-0:24060] *** Process received signal ***
3371886 [compute-7-0:24060] Signal: Floating point exception (8)
3371887 [compute-7-0:24060] Signal code: (7)
3371888 [compute-7-0:24060] Failing at address: 0x2adb2761187e
3371889 [compute-7-0:24060] [ 0] /lib64/libpthread.so.0 [0x386540e4c0]
3371890 [compute-7-0:24060] [ 1]
/home/fuster/lib/libgfs3D-1.3.so.2(gfs_fit_curvature+0x9be)
[0x2adb2761187e]

Remarkably, this error is not reproducible. It appears in the middle
of simulations but if I restart them from my last gfs file, the
simulation continues running smoothly

I think I have a simplified example that points out the source of the
problem. The example is below. Even when it runs fine, I get several
errors when I run it with valgrind, all of them coming from the
curvature event

valgrind gerris2D -DLEVEL=2 example.gfs

For this particular example, the error does not appear if I use
GfsVariableTracerVOFHeight instead of GfsVariableTracerVOF

I looked in detail the error given by diffuse_kmax, checking that
there are uninitialized values in GFS_VALUE (cell, p->v). The problem
is that variable_curvature_from_fraction never fills the unitialized
values in the leaf level. To me, the difference with respect to
vofheight, which works fine, is that in vofheight you call the
function remaining_curvatures, which is not called in
variable_curvature_from_fraction

My problem is that remaining_curvatures seems to assume that the
variable is TRACER_VOF_HEIGHT, so I cannot call this function
directly. Do you have some suggestion about how I should initialize
the values in the leaf level in the case of the traditional VOF? Can
you confirm the problems of my simplified example with valgrind? I
tried it in two different machines with the same result

Best
Daniel



1 0 GfsSimulation GfsBox GfsGEdge {} {
Time { iend = 1 dtmax = 1.e-4 }
Refine LEVEL
GfsVariableTracerVOF T
VariableCurvature K T Kmax
SourceTension T 0.00003 K
Init {} {
U = (- cos (2.*M_PI*x)*sin (2.*M_PI*y))
V = (sin (2.*M_PI*x)*cos (2.*M_PI*y))
T = ( x > 0 )
}
}
GfsBox {}






--
www.danielfuster.com

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel

[Stephane Popinet]

Hi Daniel,

> I have been experiencing some random problems with function
> fit_curvature getting errors like
>
> [compute-7-0:24060] *** Process received signal ***
> 3371886 [compute-7-0:24060] Signal: Floating point exception (8)
> 3371887 [compute-7-0:24060] Signal code: (7)
> 3371888 [compute-7-0:24060] Failing at address: 0x2adb2761187e
> 3371889 [compute-7-0:24060] [ 0] /lib64/libpthread.so.0 [0x386540e4c0]
> 3371890 [compute-7-0:24060] [ 1]
> /home/fuster/lib/libgfs3D-1.3.so.2(gfs_fit_curvature+0x9be)

I am not sure about this one. It seems to be different from what
happens in your example below.

> valgrind gerris2D -DLEVEL=2 example.gfs
>
> For this particular example, the error does not appear if I use
> GfsVariableTracerVOFHeight instead of GfsVariableTracerVOF
>
> I looked in detail the error given by diffuse_kmax, checking that
> there are uninitialized values in GFS_VALUE (cell, p->v). The problem
> is that variable_curvature_from_fraction never fills the unitialized
> values in the leaf level.

Yes, I can reproduce the problem on my system.

If you look at variable_curvature_from_fraction(), you will see that
it calls height_curvature() for each leaf cell. In turn
height_curvature() fills in kmax and k for each leaf cell, so the
problem appears to be upstream. The only place where something can go
wrong is in gfs_height_curvature() which must not fill &k at some
point where it should. Going through gfs_height_curvature() and the
various functions it calls, one quickly identifies that this call:

if (independent_positions (interface, n) < 3*(FTT_DIMENSION - 1))
return GFS_NODATA;

returns an undefined curvature (GFS_NODATA) but does not fill kmax.
The obvious fix is thus:

if (independent_positions (interface, n) < 3*(FTT_DIMENSION - 1)) {
if (kmax)
*kmax = GFS_NODATA;
return GFS_NODATA;
}

The patch is attached and valgrind seems to be happy for your example.
Note however that the first bug you reported above (with
gfs_fit_curvature()) is probably a different one.

cheers

Stephane

[Daniel Fuster]

Thanks a lot. It also solves the problem in my system. I missed that
height_curvature was filling the kmax values.

2012/10/21 Stephane Popinet <s.po...@gmail.com>: