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 <jwpeter...@gmail.com> wrote: > > > On Mon, Jul 18, 2016 at 11:59 AM, Xujun Zhao <xzha...@gmail.com> 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 > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
