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.  >

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 locati

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

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

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). > > Fo

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 ___

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 >

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

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