Hi, Roy --
This happens when constructing a 2D disc using
MeshTools::Generation::build_sphere() using Intel 10.1 compilers with
debugging flags. My experience is that the Intel compilers are more
picky about this kind of stuff than GNU.
Here is a stack trace:
Program received signal SIGFPE, Arithmetic exception.
LocationMap<libMesh::Node>::key (this=0x7fffffffb390, p=...,
$?4=<value optimized out>, $?5=<value optimized out>)
at src/utils/location_maps.C:195
195 zscaled = (p(2) - _lower_bound[2])/
(gdb) where
#0 LocationMap<libMesh::Node>::key (this=0x7fffffffb390, p=...,
$?4=<value optimized out>, $?5=<value optimized out>)
at src/utils/location_maps.C:195
#1 0x00002aaaab980eba in LocationMap<libMesh::Node>::insert (
this=0x7fffffffb390, t=..., $?2=<value optimized out>,
$?3=<value optimized out>) at src/utils/location_maps.C:106
#2 0x00002aaaab981f27 in LocationMap<libMesh::Node>::fill (
this=0x7fffffffb390, mesh=..., $?5=<value optimized out>,
$?6=<value optimized out>) at src/utils/location_maps.C:217
#3 0x00002aaaab98045d in LocationMap<libMesh::Node>::init (
this=0x7fffffffb390, mesh=..., $?0=<value optimized out>,
$?1=<value optimized out>) at src/utils/location_maps.C:96
#4 0x00002aaaab5f3215 in MeshRefinement::update_nodes_map (
this=0x7fffffffb390, $?5=<value optimized out>)
at src/mesh/mesh_refinement.C:293
#5 0x00002aaaab5fed72 in MeshRefinement::_refine_elements (
this=0x7fffffffb390, $}4=<value optimized out>)
at src/mesh/mesh_refinement.C:1507
#6 0x00002aaaab5ffb20 in MeshRefinement::uniformly_refine (
this=0x7fffffffb390, n=1, $?3=<value optimized out>,
$?4=<value optimized out>) at src/mesh/mesh_refinement.C:1644
#7 0x00002aaaab5d711d in libMesh::MeshTools::Generation::build_sphere (
mesh=..., rad=0.20000000000000001, nr=4, type=QUAD4)
at src/mesh/mesh_generation.C:1786
#8 0x000000000067c6ba in main (argc=2, argv=0x7fffffffdfb8)
at ../../../../../IBAMR/examples/IBFE/explicit/ex4/main.C:351
-- Boyce
On 12/18/10 12:20 AM, Roy Stogner wrote:
> Under what conditions does this occur? I'm surprised if you're seeing
> it for 2D meshes (where IIRC we build quadtrees instead of octrees)
> and I'm surprised that I've never seen it for 1D meshes...
>
> Sounds like a straightforward solution, though; someone want to glance
> over and commit it?
> ---
> Roy
>
>
> On Fri, 17 Dec 2010, Boyce Griffith wrote:
>
>> Hi, Folks --
>>
>> We recently ran into a floating point exception coming from
>> location_maps.C. The problem is that when LIBMESH_DIM is 3 but the
>> mesh has DIM < 3, _lower_bound[i] == _upper_bound[i] for some
>> dimensions. Because LocationMap<T>::key() computes, e.g.,
>>
>> zscaled = (p(2) - _lower_bound[2])/
>> (_upper_bound[2] - _lower_bound[2]);
>>
>> if this happens, LocationMap<T>::key() results in a floating point
>> exception for some choices of compiler/compiler flags.
>>
>> An easy fix appears to be to offset the bounding box by machine
>> epsilon when computing the extents, e.g., in LocationMap<T>::init().
>> It looks like these values are only used in LocationMap<T>::key(), so
>> this change appears to be otherwise innocuous. Patch attached.
>>
>> -- Boyce
>>
>>
>
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
