On Wed, Jul 20, 2016 at 12:57 PM, Xujun Zhao wrote:
> 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(0.)' failed.
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(0.)' failed.
my_det = 0
static_cast(0.) = 0
But when I extract the nodal in
On Mon, Jul 18, 2016 at 11:59 AM, Xujun Zhao 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)
Thank you very much, John.
On Tue, Jul 19, 2016 at 4:58 PM, John Peterson wrote:
>
>
> On Tue, Jul 19, 2016 at 2:41 PM, Xujun Zhao wrote:
>
>> Hi John,
>> Please let me know when this is fixed. I will pull the updated version.
>> Thank you very much
>>
>
> It's testing now in https://github.com
On Tue, Jul 19, 2016 at 2:41 PM, Xujun Zhao wrote:
> Hi John,
> Please let me know when this is fixed. I will pull the updated version.
> Thank you very much
>
It's testing now in https://github.com/libMesh/libmesh/pull/1030
If you want to pull that branch and let me know if it works, that woul
Hi John,
Please let me know when this is fixed. I will pull the updated version.
Thank you very much
-Xujun
On Mon, Jul 18, 2016 at 2:21 PM, Roy Stogner
wrote:
>
> On Mon, 18 Jul 2016, John Peterson wrote:
>
> The lower order ones (TRI3 and TET4) have contains_point()
>> specializations, but I
OK. I see. Thanks, John.
On Mon, Jul 18, 2016 at 1:55 PM, John Peterson wrote:
>
>
> On Mon, Jul 18, 2016 at 12:42 PM, Xujun Zhao wrote:
>
>> It sounds like this is an inherent problem of the present algorithm for
>> determining if a point is in an element??? especially for complex elements
>>
On Mon, 18 Jul 2016, John Peterson wrote:
> The lower order ones (TRI3 and TET4) have contains_point()
> specializations, but I see that the Tet4 one also needs a similar
> try/catch block fix since it uses TypeTensor::solve().
I guess, but it's not nearly as urgent. Tet4 maps are affine, so th
On Mon, Jul 18, 2016 at 12:42 PM, Xujun Zhao wrote:
> It sounds like this is an inherent problem of the present algorithm for
> determining if a point is in an element??? especially for complex elements
> such as HEX27.
>
It's only a problem because we aren't properly handling the failure
case..
Also, how about the tri/tet elements? Will they cause zero determinant
problems?
On Mon, Jul 18, 2016 at 1:42 PM, Xujun Zhao wrote:
> It sounds like this is an inherent problem of the present algorithm for
> determining if a point is in an element??? especially for complex elements
> such as HEX
It sounds like this is an inherent problem of the present algorithm for
determining if a point is in an element??? especially for complex elements
such as HEX27. Is there any other more robust solution in computational
geometry?
I also tried to use the 1st order element, it passed the test for thi
On Mon, 18 Jul 2016, John Peterson wrote:
I can fix this. The zero determinant asserts could be changed to
libmesh_error()'s (or explicit exception throws)
libmesh_assert and kin do throw an exception, but yeah, we probably
need to change this just to get rid of the text that gets spewed to
On Mon, Jul 18, 2016 at 12:13 PM, Roy Stogner
wrote:
>
> On Mon, 18 Jul 2016, Xujun Zhao 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.
>>
>
> Oh, yes, looking for poin
On Mon, 18 Jul 2016, Xujun Zhao 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.
Oh, yes, looking for points far outside an element can give you
inverse map failures. If yo
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 Nod
On Mon, Jul 18, 2016 at 9:42 AM, Xujun Zhao wrote:
> Guys,
>
> I met this error when I try to determine if a point is inside an element
> using the function constains_point(). I tracked the code using the
> dbg version and found that this happened when computing the
> FE::inverse_map(), in which
Guys,
I met this error when I try to determine if a point is inside an element
using the function constains_point(). I tracked the code using the
dbg version and found that this happened when computing the
FE::inverse_map(), in which it calls TypeTensor::inverse() and leads to
Jacobian = 0. Here a
17 matches
Mail list logo
