Re: [Libmesh-users] problem with inverse_map()

2019-05-06 Thread Stogner, Roy H 


On Sat, 4 May 2019, Manav Bhatia wrote:

>     I am working on immersed boundary problems where I cut a FE based on a 
> level-set function. On each element obtained by the cut operation, I
> ask the FE to be initialized, either using a quadrature rule, or by specific 
> in the QP locations. 
> 
>     While this forward operation of QP -> compute shape functions, 
> derivatives and normals (on sides) should work out fine,

I'd be scared of the derivatives.  If dxi/dx is going off to infinity
(in some eigenvalues anyway) then our standard attempt to compute
dphi/dx as dphi/dxi*dxi/dx sounds perilous.

> the issue is showing
> up in  compute_face_map() ( 
> https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L224
>  ).
> 
>     It appears that compute_face_map() is using the xyz locations of the 
> quadrature points to figure out non-dimensional location of the
> quadrature points here:  
> https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L754
>  
> 
>      So, every once in a while the level-set based intersection leads to 
> sliver cut-cells, which case this inverse-map method to fail. 
> 
>      I am guessing there is a reason to do things this way, even though the 
> user may have explicitly provided the quadrature points to begin with.
> Do you know if there is a way to bypass the inverse_map for FE reinit? 

I'm actually not aware of any reason to do things this way.  It seems
like a bad idea in general, not just in your case!

There are cases where we do inverse_map() in AMR problems and for edge
and face reinits, because we're too lazy to do direct translation
function calculations for every single combination of parent<->child
element configuration, and it's easy to just do inverse_map() on one
of the xyz coordinates calculated from the other.  And that's
embarrassing, but at least we have an excuse.

But here I don't actually see an excuse.  Maybe we wrote the
compute_face_map API first, then we added the ability to get proper
tangents of 2D elements in 3D space later, and someone wanted to do
that without changing the API?  I'd say you should just change the
APIs for compute_face_map and compute_edge_map.  I'll bet nobody is
directly using them; they're technically public but they're basically
internal.

Hmm.. that fix will work for face reinits, and for edge reinits with
manually supplied quadrature points, but for edge reinits based on an
quadrature rule we're *also* using inverse_map(xyz) for some reason,
rather than using the refspace_nodes calculation we do for face
reinits.  That should probably be fixed one of these days.
---
Roy

___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

2019-05-03 Thread Manav Bhatia 
Roy, 

   This turned out to be unrelated to adaptivity. 

I am working on immersed boundary problems where I cut a FE based on a 
level-set function. On each element obtained by the cut operation, I ask the FE 
to be initialized, either using a quadrature rule, or by specific in the QP 
locations. 

While this forward operation of QP -> compute shape functions, derivatives 
and normals (on sides) should work out fine, the issue is showing up in  
compute_face_map() ( 
https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L224
 

 ).

It appears that compute_face_map() is using the xyz locations of the 
quadrature points to figure out non-dimensional location of the quadrature 
points here:  
https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L754
 

 

 So, every once in a while the level-set based intersection leads to sliver 
cut-cells, which case this inverse-map method to fail. 

 I am guessing there is a reason to do things this way, even though the 
user may have explicitly provided the quadrature points to begin with. Do you 
know if there is a way to bypass the inverse_map for FE reinit? 

Thanks,
Manav

   

> On May 2, 2019, at 8:10 AM, Stogner, Roy H  wrote:
> 
> 
> On Thu, 2 May 2019, Manav Bhatia wrote:
> 
>> I ran the debug version and this is where it crashed. 
> 
> Well, I'm afraid that's no more help.  Thanks anyway.
> 
> Could you loop through elem 16514's parent (672) and parent's parent
> and so on up to the top level and print them?  I'm not sure where to
> begin looking for the problem, unless you can set up a test case we
> can reproduce.
> ---
> Roy
> 
>> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
>> WARNING: Newton scheme has not converged in 11 iterations:
>>physical_point=(x,y,z)=(0.27,   0.2775,0)   
>> physical_guess=(x,y,z)=(0.27,   0.2775,0)   
>> dp=(x,y,z)=(-1.21944e-13,
>> -1.12163e-06,0)   p=(x,y,z)=(  -1, -0.57735,0)   
>> error=1.12163e-06   in element 16514
>>   Elem Information
>>id()=16514, processor_id()=2
>>type()=QUAD4
>>dim()=2
>>n_nodes()=4
>> 0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>> 1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,   
>>  0)
>> DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
>> (0/5/13475) (2/0/2245) (3/0/2245) 
>> 2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,  
>>  0.2775,0)
>> DoFs=
>> 3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>>n_sides()=4
>> neighbor(0)=nullptr
>> neighbor(1)=nullptr
>> neighbor(2)=nullptr
>> neighbor(3)=nullptr
>>hmin()=9.89829e-11, hmax()=0.001875
>>volume()=1.85593e-13
>>active()=1, ancestor()=0, subactive()=0, has_children()=0
>>parent()=672
>>level()=4, p_level()=0
>>refinement_flag()=DO_NOTHING
>>p_refinement_flag()=DO_NOTHING
>>DoFs=
>> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
>> WARNING: Newton scheme has not converged in 12 iterations:
>>physical_point=(x,y,z)=(0.27,   0.2775,0)   
>> physical_guess=(x,y,z)=(0.27,   0.2775,0)   
>> dp=(x,y,z)=(-1.21944e-13,
>> -1.12163e-06,0)   p=(x,y,z)=(  -1, -0.577351,0)   
>> error=1.12163e-06   in element 16514
>>   Elem Information
>>id()=16514, processor_id()=2
>>type()=QUAD4
>>dim()=2
>>n_nodes()=4
>> 0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>> 1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,   
>>  0)
>> DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
>> (0/5/13475) (2/0/2245) (3/0/2245) 
>> 2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,  
>>  0.2775,0)
>> DoFs=
>> 3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>>n_sides()=4
>> neighbor(0)=nullptr
>> neighbor(1)=nullptr
>> neighbor(2)=nullptr
>> neighbor(3)=nullptr
>>hmin()=9.89829e-11, hmax()=0.001875
>>volume()=1.85593e-13
>>active()=1, ancestor()=0, subactive()=0, has_children()=0
>>parent()=672
>>level()=4, p_level()=0
>>refinement_flag()=DO_NOTHING
>>p_refinement_flag()=DO_NOTHING
>>DoFs=
>> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
>> WARNING: Newton scheme has not converged in 13 iterations:
>>physical_point=(x,y,z)=(

Re: [Libmesh-users] problem with inverse_map()

2019-05-02 Thread Stogner, Roy H 


On Thu, 2 May 2019, Manav Bhatia wrote:

> I ran the debug version and this is where it crashed. 

Well, I'm afraid that's no more help.  Thanks anyway.

Could you loop through elem 16514's parent (672) and parent's parent
and so on up to the top level and print them?  I'm not sure where to
begin looking for the problem, unless you can set up a test case we
can reproduce.
---
Roy

> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
> WARNING: Newton scheme has not converged in 11 iterations:
>    physical_point=(x,y,z)=(    0.27,   0.2775,        0)   
> physical_guess=(x,y,z)=(    0.27,   0.2775,        0)   
> dp=(x,y,z)=(-1.21944e-13,
> -1.12163e-06,        0)   p=(x,y,z)=(      -1, -0.57735,        0)   
> error=1.12163e-06   in element 16514
>   Elem Information
>    id()=16514, processor_id()=2
>    type()=QUAD4
>    dim()=2
>    n_nodes()=4
>     0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(    0.27,   
> 0.2775,        0)
>     DoFs=
>     1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,    
>     0)
>     DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
> (0/5/13475) (2/0/2245) (3/0/2245) 
>     2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
> 0.2775,        0)
>     DoFs=
>     3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(    0.27,   
> 0.2775,        0)
>     DoFs=
>    n_sides()=4
>     neighbor(0)=nullptr
>     neighbor(1)=nullptr
>     neighbor(2)=nullptr
>     neighbor(3)=nullptr
>    hmin()=9.89829e-11, hmax()=0.001875
>    volume()=1.85593e-13
>    active()=1, ancestor()=0, subactive()=0, has_children()=0
>    parent()=672
>    level()=4, p_level()=0
>    refinement_flag()=DO_NOTHING
>    p_refinement_flag()=DO_NOTHING
>    DoFs=
> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
> WARNING: Newton scheme has not converged in 12 iterations:
>    physical_point=(x,y,z)=(    0.27,   0.2775,        0)   
> physical_guess=(x,y,z)=(    0.27,   0.2775,        0)   
> dp=(x,y,z)=(-1.21944e-13,
> -1.12163e-06,        0)   p=(x,y,z)=(      -1, -0.577351,        0)   
> error=1.12163e-06   in element 16514
>   Elem Information
>    id()=16514, processor_id()=2
>    type()=QUAD4
>    dim()=2
>    n_nodes()=4
>     0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(    0.27,   
> 0.2775,        0)
>     DoFs=
>     1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,    
>     0)
>     DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
> (0/5/13475) (2/0/2245) (3/0/2245) 
>     2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
> 0.2775,        0)
>     DoFs=
>     3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(    0.27,   
> 0.2775,        0)
>     DoFs=
>    n_sides()=4
>     neighbor(0)=nullptr
>     neighbor(1)=nullptr
>     neighbor(2)=nullptr
>     neighbor(3)=nullptr
>    hmin()=9.89829e-11, hmax()=0.001875
>    volume()=1.85593e-13
>    active()=1, ancestor()=0, subactive()=0, has_children()=0
>    parent()=672
>    level()=4, p_level()=0
>    refinement_flag()=DO_NOTHING
>    p_refinement_flag()=DO_NOTHING
>    DoFs=
> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
> WARNING: Newton scheme has not converged in 13 iterations:
>    physical_point=(x,y,z)=(    0.27,   0.2775,        0)   
> physical_guess=(x,y,z)=(    0.27,   0.2775,        0)   
> dp=(x,y,z)=(2.43888e-13,
> 2.24326e-06,        0)   p=(x,y,z)=(      -1, -0.577349,        0)   
> error=2.24326e-06   in element 16514
>   Elem Information
>    id()=16514, processor_id()=2
>    type()=QUAD4
>    dim()=2
>    n_nodes()=4
>     0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(    0.27,   
> 0.2775,        0)
>     DoFs=
>     1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,    
>     0)
>     DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
> (0/5/13475) (2/0/2245) (3/0/2245) 
>     2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
> 0.2775,        0)
>     DoFs=
>     3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(    0.27,   
> 0.2775,        0)
>     DoFs=
>    n_sides()=4
>     neighbor(0)=nullptr
>     neighbor(1)=nullptr
>     neighbor(2)=nullptr
>     neighbor(3)=nullptr
>    hmin()=9.89829e-11, hmax()=0.001875
>    volume()=1.85593e-13
>    active()=1, ancestor()=0, subactive()=0, has_children()=0
>    parent()=672
>    level()=4, p_level()=0
>    refinement_flag()=DO_NOTHING
>    p_refinement_flag()=DO_NOTHING
>    DoFs=
> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
> WARNING: Newton scheme has not converged in 14 iterations:
>    physical_point=(x,y,z)=(    0.27,   0.2775,        0)   
> physical_guess=(x,y,z)=(    0.27,   0.2775,        0)   
> dp=(x,y,z)=(-1.21944e-13,
> -1.12163e-06,        0)   p=(x,y,z)=(      -1, -0.57735,        0)   
> error=1.12163e-06   in element 16514
>  

Re: [Libmesh-users] problem with inverse_map()

2019-05-01 Thread Manav Bhatia 
I ran the debug version and this is where it crashed. 

[2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
WARNING: Newton scheme has not converged in 11 iterations:
   physical_point=(x,y,z)=(0.27,   0.2775,0)   
physical_guess=(x,y,z)=(0.27,   0.2775,0)   
dp=(x,y,z)=(-1.21944e-13, -1.12163e-06,0)   p=(x,y,z)=(  -1, 
-0.57735,0)   error=1.12163e-06   in element 16514
  Elem Information
   id()=16514, processor_id()=2
   type()=QUAD4
   dim()=2
   n_nodes()=4
0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,  
  0)
DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
   n_sides()=4
neighbor(0)=nullptr
neighbor(1)=nullptr
neighbor(2)=nullptr
neighbor(3)=nullptr
   hmin()=9.89829e-11, hmax()=0.001875
   volume()=1.85593e-13
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=672
   level()=4, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=
[2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
WARNING: Newton scheme has not converged in 12 iterations:
   physical_point=(x,y,z)=(0.27,   0.2775,0)   
physical_guess=(x,y,z)=(0.27,   0.2775,0)   
dp=(x,y,z)=(-1.21944e-13, -1.12163e-06,0)   p=(x,y,z)=(  -1, 
-0.577351,0)   error=1.12163e-06   in element 16514
  Elem Information
   id()=16514, processor_id()=2
   type()=QUAD4
   dim()=2
   n_nodes()=4
0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,  
  0)
DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
   n_sides()=4
neighbor(0)=nullptr
neighbor(1)=nullptr
neighbor(2)=nullptr
neighbor(3)=nullptr
   hmin()=9.89829e-11, hmax()=0.001875
   volume()=1.85593e-13
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=672
   level()=4, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=
[2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
WARNING: Newton scheme has not converged in 13 iterations:
   physical_point=(x,y,z)=(0.27,   0.2775,0)   
physical_guess=(x,y,z)=(0.27,   0.2775,0)   
dp=(x,y,z)=(2.43888e-13, 2.24326e-06,0)   p=(x,y,z)=(  -1, 
-0.577349,0)   error=2.24326e-06   in element 16514
  Elem Information
   id()=16514, processor_id()=2
   type()=QUAD4
   dim()=2
   n_nodes()=4
0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,  
  0)
DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
   n_sides()=4
neighbor(0)=nullptr
neighbor(1)=nullptr
neighbor(2)=nullptr
neighbor(3)=nullptr
   hmin()=9.89829e-11, hmax()=0.001875
   volume()=1.85593e-13
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=672
   level()=4, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=
[2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
WARNING: Newton scheme has not converged in 14 iterations:
   physical_point=(x,y,z)=(0.27,   0.2775,0)   
physical_guess=(x,y,z)=(0.27,   0.2775,0)   
dp=(x,y,z)=(-1.21944e-13, -1.12163e-06,0)   p=(x,y,z)=(  -1, 
-0.57735,0)   error=1.12163e-06   in element 16514
  Elem Information
   id()=16514, processor_id()=2
   type()=QUAD4
   dim()=2
   n_nodes()=4
0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,  
  0)
DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,

Re: [Libmesh-users] problem with inverse_map()

2019-05-01 Thread Stogner, Roy H 


On Wed, 1 May 2019, Manav Bhatia wrote:

>   I am using h-refinement in my analysis, which uses the mesh function 
> routines to compute the value of the function in the interior of an element.
>
>   All of my elements in the original mesh (before any refinements) are 
> squares (quad4).
>
>   For the most part everything works out fine without any issues.
>   Occasionally, however, I will get an error in the inverse_map()
>   like this. I am particularly perplexed by the hmin() size of
>   10^-11.
>
>   The size of my elements before refinement is hmin() = .015 and I
>   allow a max of 4 refinements in any element. Would there be any
>   reason to expect an hmin of order 10^-11 in this case?

Not even close, but there's definitely *something* going seriously
wrong here.

You have a degenerate element; points 0 and 3 and points 1 and 2
coincide.

You have three nodes with invalid processor ids.

You probably ought to

> Rerun in devel/dbg mode for more details.

(preferably dbg) and see whether it catches any problems earlier.
---
Roy


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

2019-05-01 Thread John Peterson 
On Wed, May 1, 2019 at 5:52 PM Manav Bhatia  wrote:

> Any reason to expect such a sliver element when refining from squares?
>

No... something else must be wrong, either with the original Mesh, or some
bug during the refinement process...

-- 
John

___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

2019-05-01 Thread Manav Bhatia 
Any reason to expect such a sliver element when refining from squares? 

> On May 1, 2019, at 5:50 PM, John Peterson  wrote:
> 
> 
> On Wed, May 1, 2019 at 5:40 PM Manav Bhatia  > wrote:
> As a followup, I have attached a screenshot of where the element in the error 
> message is pointing. It is intriguing that the coordinates of all 4 nodes 
> have virtually the same y-axis location (hence the hmin of 10^-11). I have 
> circled the respective edge that these coordinates define. 
> 
> I should also note that I am using a custom function for flagging elements 
> for refinement/coarsening. I have a scalar function define on the elements, 
> and based on the value of the function I mark them for refinement or 
> coarsening. So, this is a simple less-then/greater-than block. Not sure I am 
> supposed to check for more parameters before flagging. 
> 
> All four nodes have basically the same y and z coordinates? Sounds like it is 
> a sliver element, so I'd say the hmin value is probably correct...
> 
> -- 
> John


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

2019-05-01 Thread John Peterson 
On Wed, May 1, 2019 at 5:40 PM Manav Bhatia  wrote:

> As a followup, I have attached a screenshot of where the element in the
> error message is pointing. It is intriguing that the coordinates of all 4
> nodes have virtually the same y-axis location (hence the hmin of 10^-11). I
> have circled the respective edge that these coordinates define.
>
> I should also note that I am using a custom function for flagging elements
> for refinement/coarsening. I have a scalar function define on the elements,
> and based on the value of the function I mark them for refinement or
> coarsening. So, this is a simple less-then/greater-than block. Not sure I
> am supposed to check for more parameters before flagging.
>

All four nodes have basically the same y and z coordinates? Sounds like it
is a sliver element, so I'd say the hmin value is probably correct...

-- 
John

___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

2019-05-01 Thread Manav Bhatia 
As a followup, I have attached a screenshot of where the element in the error 
message is pointing. It is intriguing that the coordinates of all 4 nodes have 
virtually the same y-axis location (hence the hmin of 10^-11). I have circled 
the respective edge that these coordinates define. 

I should also note that I am using a custom function for flagging elements for 
refinement/coarsening. I have a scalar function define on the elements, and 
based on the value of the function I mark them for refinement or coarsening. 
So, this is a simple less-then/greater-than block. Not sure I am supposed to 
check for more parameters before flagging. 

Thanks,
Manav



> On May 1, 2019, at 5:25 PM, Manav Bhatia  wrote:
> 
> Hi, 
> 
>I am using h-refinement in my analysis, which uses the mesh function 
> routines to compute the value of the function in the interior of an element. 
> 
>All of my elements in the original mesh (before any refinements) are 
> squares (quad4). 
> 
>For the most part everything works out fine without any issues. 
> Occasionally, however, I will get an error in the inverse_map() like this. I 
> am particularly perplexed by the hmin() size of 10^-11. 
> 
>The size of my elements before refinement is hmin() = .015 and I allow a 
> max of 4 refinements in any element. Would there be any reason to expect an 
> hmin of order 10^-11 in this case? 
> 
> Thanks,
> Manav
> 
> 
> WARNING: At least one element took more than 10 iterations to converge in 
> inverse_map()...
> Rerun in devel/dbg mode for more details.
> ERROR: Newton scheme FAILED to converge in 21 iterations in element 16514 for 
> physical point = (x,y,z)=(0.27,   0.2775,0)
>   Elem Information
>id()=16514, processor_id()=2
>type()=QUAD4
>dim()=2
>n_nodes()=4
> 0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
> 0.2775,0)
> DoFs=
> 1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,
> 0)
> DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
> (0/5/13475) (2/0/2245) (3/0/2245) 
> 2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
> 0.2775,0)
> DoFs=
> 3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
> 0.2775,0)
> DoFs=
>n_sides()=4
> neighbor(0)=nullptr
> neighbor(1)=nullptr
> neighbor(2)=nullptr
> neighbor(3)=nullptr
>hmin()=9.89829e-11, hmax()=0.001875
>volume()=1.85593e-13
>active()=1, ancestor()=0, subactive()=0, has_children()=0
>parent()=672
>level()=4, p_level()=0
>refinement_flag()=DO_NOTHING
>p_refinement_flag()=DO_NOTHING
>DoFs=
> Exiting...
> [2] src/fe/fe_map.C, line 1905, compiled Apr 20 2019 at 20:02:41
> 


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] problem with inverse_map()

2019-05-01 Thread Manav Bhatia 
Hi, 

   I am using h-refinement in my analysis, which uses the mesh function 
routines to compute the value of the function in the interior of an element. 

   All of my elements in the original mesh (before any refinements) are squares 
(quad4). 

   For the most part everything works out fine without any issues. 
Occasionally, however, I will get an error in the inverse_map() like this. I am 
particularly perplexed by the hmin() size of 10^-11. 

   The size of my elements before refinement is hmin() = .015 and I allow a max 
of 4 refinements in any element. Would there be any reason to expect an hmin of 
order 10^-11 in this case? 

Thanks,
Manav


WARNING: At least one element took more than 10 iterations to converge in 
inverse_map()...
Rerun in devel/dbg mode for more details.
ERROR: Newton scheme FAILED to converge in 21 iterations in element 16514 for 
physical point = (x,y,z)=(0.27,   0.2775,0)
  Elem Information
   id()=16514, processor_id()=2
   type()=QUAD4
   dim()=2
   n_nodes()=4
0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,  
  0)
DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
   n_sides()=4
neighbor(0)=nullptr
neighbor(1)=nullptr
neighbor(2)=nullptr
neighbor(3)=nullptr
   hmin()=9.89829e-11, hmax()=0.001875
   volume()=1.85593e-13
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=672
   level()=4, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=
Exiting...
[2] src/fe/fe_map.C, line 1905, compiled Apr 20 2019 at 20:02:41


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users