Re: [Libmesh-users] contains_point() error

[Xujun Z. <xz...@gm...>]

I also tried. You are right. It looks like this element and point don't
have the zero det problem. I also tried other mesh and points. They crashed
down and led to the same error messages:

Assertion `my_det != static_cast<T>(0.)' failed.
my_det = 0
static_cast<T>(0.) = 0

But when I extract the nodal information and construct a one-element mesh,
the function contains_point() works well again. I can't understand why this
happen.

Btw, I use mesh.read() to read a mesh file created by CUBIT, then let it
all_second_order(). Will this cause problems?

-Xujun

On Wed, Jul 20, 2016 at 11:21 AM, John Peterson <jwp...@gm...>
wrote:

>
>
> On Mon, Jul 18, 2016 at 11:59 AM, Xujun Zhao <xz...@gm...> wrote:
>
>> Yes, the points are not quad-points but arbitrary points, which are
>> moving particles in the domain. It mainly happened when the points are out
>> of the element. One case it failed is as follows:
>>
>> pt[186] = (-11.545647,22.442960,12.336682)
>>
>> Elem id = 449, and volume is 383.684010
>>
>>          Element Nodes are :
>>
>>             node 0 = (-18.750000,7.911975,7.911975)
>>
>>             node 1 = (-18.750000,3.750062,7.806584)
>>
>>             node 2 = (-18.750000,3.834322,12.613942)
>>
>>             node 3 = (-18.750000,8.099410,12.760054)
>>
>>             node 4 = (-30.163472,12.728141,12.728141)
>>
>>             node 5 = (-31.084410,6.216985,12.942030)
>>
>>             node 6 = (-29.400453,6.012310,19.778966)
>>
>>             node 7 = (-28.660566,12.380462,19.504553)
>>
>>             node 8 = (-18.750000,5.831019,7.859280)
>>
>>             node 9 = (-18.750000,3.792192,10.210263)
>>
>>             node 10 = (-18.750000,5.966866,12.686998)
>>
>>             node 11 = (-18.750000,8.005692,10.336015)
>>
>>             node 12 = (-24.456736,10.320058,10.320058)
>>
>>             node 13 = (-24.917205,4.983523,10.374307)
>>
>>             node 14 = (-24.075226,4.923316,16.196454)
>>
>>             node 15 = (-23.705283,10.239936,16.132304)
>>
>>             node 16 = (-30.623941,9.472563,12.835085)
>>
>>             node 17 = (-30.242432,6.114647,16.360498)
>>
>>             node 18 = (-29.030509,9.196386,19.641760)
>>
>>             node 19 = (-29.412019,12.554301,16.116347)
>>
>>             node 20 = (-18.750000,5.898942,10.273139)
>>
>>             node 21 = (-24.686971,7.651791,10.347183)
>>
>>             node 22 = (-24.496216,4.953420,13.285381)
>>
>>             node 23 = (-23.890255,7.581626,16.164379)
>>
>>             node 24 = (-24.081009,10.279997,13.226181)
>>
>>             node 25 = (-29.827225,9.334474,16.238423)
>>
>>             node 26 = (-24.288613,7.616708,13.255781)
>>
>
> BTW, I coded up this element [0], and it does not produce a floating point
> zero determinant calculation even though the point is outside the element...
>
> I really don't see how that's possible except in truly degenerate (0.0
> volume element) cases which this example is not (see attached figure),
> however, I'm glad your issue led us to fix this corner case.
>
> [0]: https://gist.github.com/jwpeterson/f695b7783a76d74a790dacba5989ddc4
>
> --
> John
>