libmesh-users — General information for libmesh users

Re: [Libmesh-users] Quick question - bandwidth minimization?

[Jed B. <je...@je...>]

John Peterson <jwp...@gm...> writes:

> On Thu, May 2, 2019 at 12:35 PM Yuxiang Wang <yw...@vi...> wrote:
>
>> Dear all,
>>
>> A quick question - when using libmesh, should I consciously do bandwidth
>> minimization when I number my node IDs? Or, are those taken care of at
>> pre-processing stage of PETSc and other solvers?
>>
>
> I wouldn't try and do anything manually since PETSc has a number of
> renumbering algorithms that I think you can play around with pretty easily
> to see if they make any difference...

You can run factorizations in a different ordering, but low-bandwidth
orderings make a difference for cache reuse in MatMult.  PETSc can't
reorder that without making a copy.  But don't put too much effort into
it.

Re: [Libmesh-users] Quick question - bandwidth minimization?

[John P. <jwp...@gm...>]

On Thu, May 2, 2019 at 12:35 PM Yuxiang Wang <yw...@vi...> wrote:

> Dear all,
>
> A quick question - when using libmesh, should I consciously do bandwidth
> minimization when I number my node IDs? Or, are those taken care of at
> pre-processing stage of PETSc and other solvers?
>

I wouldn't try and do anything manually since PETSc has a number of
renumbering algorithms that I think you can play around with pretty easily
to see if they make any difference...

-- 
John

[Libmesh-users] Quick question - bandwidth minimization?

[Yuxiang W. <yw...@vi...>]

Dear all,

A quick question - when using libmesh, should I consciously do bandwidth
minimization when I number my node IDs? Or, are those taken care of at
pre-processing stage of PETSc and other solvers?

Best,
Shawn

-- 
Yuxiang "Shawn" Wang, PhD
yw...@vi...
+1 (434) 284-0836

Re: [Libmesh-users] about point locator

[Povolotskyi, M. <mpo...@pu...>]

Just sent a short example to your personal e-mail.

Thank you,

Michael.


On 05/02/2019 10:55 AM, Stogner, Roy H wrote:
> On Thu, 2 May 2019, Povolotskyi, Mykhailo wrote:
>
>> Yes, I'm happy to  do that.
>>
>> How can I send you the mesh file? Attachments are not allowed here.
> What's worked best in the past for me is for you to create a Github
> fork with a new branch that I can then check out; then the test case
> and its data files are all naturally together.
>
>> Can I sent it to your personal address?
> Yeah, that'll be fine.
> ---
> Roy

Re: [Libmesh-users] about point locator

[Stogner, R. H <roy...@ic...>]

On Thu, 2 May 2019, Povolotskyi, Mykhailo wrote:

> Yes, I'm happy to  do that.
>
> How can I send you the mesh file? Attachments are not allowed here.

What's worked best in the past for me is for you to create a Github
fork with a new branch that I can then check out; then the test case
and its data files are all naturally together.

> Can I sent it to your personal address?

Yeah, that'll be fine.
---
Roy

Re: [Libmesh-users] about point locator

[Povolotskyi, M. <mpo...@pu...>]

Hi Roy,

Yes, I'm happy to  do that.

How can I send you the mesh file? Attachments are not allowed here. Can 
I sent it to your personal address?

Meanwhile, I found a workaround by setting a tolerance. I learned from 
the documentation that setting a tolerance is changing the algorithm, so 
it helped.

Michael.

On 5/2/2019 9:30 AM, Stogner, Roy H wrote:
> On Thu, 2 May 2019, Povolotskyi, Mykhailo wrote:
>
>> Dear Libmesh developers,
>>
>> yesterday I reported about problems with the point locator.
>>
>> Today I updated libmesh to 1.4.1 version.
>>
>> The problem still exist, but when looking for a different point.
>>
>> Please, advise, how can I tweak the point locator?
> Can you set up a test case we can use to reproduce the problem?
>
> Thanks,
> ---
> Roy

Re: [Libmesh-users] about point locator

[Stogner, R. H <roy...@ic...>]

On Thu, 2 May 2019, Povolotskyi, Mykhailo wrote:

> Dear Libmesh developers,
>
> yesterday I reported about problems with the point locator.
>
> Today I updated libmesh to 1.4.1 version.
>
> The problem still exist, but when looking for a different point.
>
> Please, advise, how can I tweak the point locator?

Can you set up a test case we can use to reproduce the problem?

Thanks,
---
Roy

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

[Stogner, R. H <roy...@ic...>]

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
>   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 15 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 16 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 17 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=
> WARNING: Newton scheme has not converged in 21 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=
> 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 29 2019 at 13:59:12
> 
> 
> 
>
>       On May 1, 2019, at 9:29 PM, Stogner, Roy H <roy...@ic...> wrote:
> 
> 
> 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
> 
> 
> 
>

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

[Manav B. <bha...@gm...>]

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,   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 15 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 16 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 17 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=
WARNING: Newton scheme has not converged in 21 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=
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 29 2019 at 13:59:12




> On May 1, 2019, at 9:29 PM, Stogner, Roy H <roy...@ic...> wrote:
> 
> 
> 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] about point locator

[Povolotskyi, M. <mpo...@pu...>]

Dear Libmesh developers,

yesterday I reported about problems with the point locator.

Today I updated libmesh to 1.4.1 version.

The problem still exist, but when looking for a different point.

Please, advise, how can I tweak the point locator?

Thank you,

Michael.

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

[Stogner, R. H <roy...@ic...>]

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

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

[John P. <jwp...@gm...>]

On Wed, May 1, 2019 at 5:52 PM Manav Bhatia <bha...@gm...> 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()

[Manav B. <bha...@gm...>]

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

> On May 1, 2019, at 5:50 PM, John Peterson <jwp...@gm...> wrote:
> 
> 
> On Wed, May 1, 2019 at 5:40 PM Manav Bhatia <bha...@gm... <mailto:bha...@gm...>> 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

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

[John P. <jwp...@gm...>]

On Wed, May 1, 2019 at 5:40 PM Manav Bhatia <bha...@gm...> 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

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

[Manav B. <bha...@gm...>]

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 <bha...@gm...> 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] problem with inverse_map()

[Manav B. <bha...@gm...>]

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

Re: [Libmesh-users] hp-EIM

[David K. <dav...@ak...>]

>
> I would like to have your guidance on another point. I see that the system
> matrices and vectors required for the reduced basis and EIM computations
> are managed by unique pointers in the rb and eim construction classes. For
> hp EIM, multiple copies of these are required. This means that there will
> have to be multiple copies (in memory) of these matrices and vectors. From
> your experience, do you feel that this could cause memory shortage issues
> for large problems?
>

I think it could be a problem if you have, say, 100 hp regions and a
separate RBConstruction associated with each region, since you would
duplicate the matrices 100 times. This would only be a problem during
training, though, not when evaluating a trained model, since you don't need
the RBConstructions to evaluate.

I can think of two approaches that would avoid this issue:
1. train each RBConstruction one at a time (i.e. sample in its hp region
then move to the next region), and clear each RBConstruction once it is
trained
2. create multiple RBConstructions and train them at the same time, but
share data (like the system matrices) between them

I think option 1 would be easier to implement.

Best regards,
David



> On Wed, May 1, 2019 at 4:10 PM David Knezevic <dav...@ak...>
> wrote:
>
>> Hi Nikhil,
>>
>>
>>> I have started to implement hp-EIM. I have a question about combining hp
>>> EIM with the reduced basis method. In standard EIM, the theta objects from
>>> the eim evaluation object are attached to the rb theta expansion of the rb
>>> evaluation object. In hp EIM there are multiple eim evaluation objects.
>>>
>>
>> OK, that's good to hear!
>>
>>
>>> My question is this:
>>>
>>> Is it possible to attach different eim theta objects to the rb theta
>>> expansion depending on which EIM evaluation objects corresponds to the
>>> parameter values in question? Consider the greedy procedure of the rb
>>> construction object. Is it possible to attach different eim theta objects
>>> to the rb theta expansion during different iterations of the greedy
>>> procedure?
>>>
>>
>> I think you would have to make a separate set of rb objects for each
>> region of the hp EIM. It doesn't make sense to me to combine them into one
>> overall expansion, since each hp region may have a different number of
>> terms and hence the training needs to be performed separately for each
>> case. If you do it that way, then the code should look mostly like the
>> current EIM code, except you have one rb expansion for each hp region. At
>> least that's how I would approach it, I think.
>>
>> Best regards,
>> David
>>
>>
>>
>>
>>
>> On Tue, Apr 2, 2019 at 4:48 PM David Knezevic <dav...@ak...>
>> wrote:
>>
>>> On Tue, Apr 2, 2019 at 10:39 AM Nikhil Vaidya <nik...@gm...>
>>> wrote:
>>>
>>>> Hi David,
>>>>
>>>> Thanks for your reply. Could you give me some tips for extending the
>>>> current EIM code?
>>>>
>>>
>>> You'd have to read through the EIM code and familiarize yourself with
>>> it... I don't see any blockers to supporting hp-EIM, but it would take some
>>> work to make sure you're managing all the data correctly. I don't have any
>>> specific suggestions I'm afraid, other than to make sure you understand the
>>> current code (I can answer questions on that if needed) and then you should
>>> be able to see how it could be extended to do what you need (via
>>> subclassing the relevant parts, for example).
>>>
>>> Best,
>>> David
>>>
>>>>

Re: [Libmesh-users] hp-EIM

[Nikhil V. <nik...@gm...>]

OK! Noted.

I would like to have your guidance on another point. I see that the system
matrices and vectors required for the reduced basis and EIM computations
are managed by unique pointers in the rb and eim construction classes. For
hp EIM, multiple copies of these are required. This means that there will
have to be multiple copies (in memory) of these matrices and vectors. From
your experience, do you feel that this could cause memory shortage issues
for large problems?

Best regards,
Nikhil

On Wed, May 1, 2019 at 4:10 PM David Knezevic <dav...@ak...>
wrote:

> Hi Nikhil,
>
>
>> I have started to implement hp-EIM. I have a question about combining hp
>> EIM with the reduced basis method. In standard EIM, the theta objects from
>> the eim evaluation object are attached to the rb theta expansion of the rb
>> evaluation object. In hp EIM there are multiple eim evaluation objects.
>>
>
> OK, that's good to hear!
>
>
>> My question is this:
>>
>> Is it possible to attach different eim theta objects to the rb theta
>> expansion depending on which EIM evaluation objects corresponds to the
>> parameter values in question? Consider the greedy procedure of the rb
>> construction object. Is it possible to attach different eim theta objects
>> to the rb theta expansion during different iterations of the greedy
>> procedure?
>>
>
> I think you would have to make a separate set of rb objects for each
> region of the hp EIM. It doesn't make sense to me to combine them into one
> overall expansion, since each hp region may have a different number of
> terms and hence the training needs to be performed separately for each
> case. If you do it that way, then the code should look mostly like the
> current EIM code, except you have one rb expansion for each hp region. At
> least that's how I would approach it, I think.
>
> Best regards,
> David
>
>
>
>
>
> On Tue, Apr 2, 2019 at 4:48 PM David Knezevic <dav...@ak...>
> wrote:
>
>> On Tue, Apr 2, 2019 at 10:39 AM Nikhil Vaidya <nik...@gm...>
>> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for your reply. Could you give me some tips for extending the
>>> current EIM code?
>>>
>>
>> You'd have to read through the EIM code and familiarize yourself with
>> it... I don't see any blockers to supporting hp-EIM, but it would take some
>> work to make sure you're managing all the data correctly. I don't have any
>> specific suggestions I'm afraid, other than to make sure you understand the
>> current code (I can answer questions on that if needed) and then you should
>> be able to see how it could be extended to do what you need (via
>> subclassing the relevant parts, for example).
>>
>> Best,
>> David
>>
>>>

Re: [Libmesh-users] hp-EIM

[David K. <dav...@ak...>]

Hi Nikhil,


> I have started to implement hp-EIM. I have a question about combining hp
> EIM with the reduced basis method. In standard EIM, the theta objects from
> the eim evaluation object are attached to the rb theta expansion of the rb
> evaluation object. In hp EIM there are multiple eim evaluation objects.
>

OK, that's good to hear!


> My question is this:
>
> Is it possible to attach different eim theta objects to the rb theta
> expansion depending on which EIM evaluation objects corresponds to the
> parameter values in question? Consider the greedy procedure of the rb
> construction object. Is it possible to attach different eim theta objects
> to the rb theta expansion during different iterations of the greedy
> procedure?
>

I think you would have to make a separate set of rb objects for each region
of the hp EIM. It doesn't make sense to me to combine them into one overall
expansion, since each hp region may have a different number of terms and
hence the training needs to be performed separately for each case. If you
do it that way, then the code should look mostly like the current EIM code,
except you have one rb expansion for each hp region. At least that's how I
would approach it, I think.

Best regards,
David





On Tue, Apr 2, 2019 at 4:48 PM David Knezevic <dav...@ak...>
wrote:

> On Tue, Apr 2, 2019 at 10:39 AM Nikhil Vaidya <nik...@gm...>
> wrote:
>
>> Hi David,
>>
>> Thanks for your reply. Could you give me some tips for extending the
>> current EIM code?
>>
>
> You'd have to read through the EIM code and familiarize yourself with
> it... I don't see any blockers to supporting hp-EIM, but it would take some
> work to make sure you're managing all the data correctly. I don't have any
> specific suggestions I'm afraid, other than to make sure you understand the
> current code (I can answer questions on that if needed) and then you should
> be able to see how it could be extended to do what you need (via
> subclassing the relevant parts, for example).
>
> Best,
> David
>
>>

Re: [Libmesh-users] hp-EIM

[Nikhil V. <nik...@gm...>]

Hi David,

I have started to implement hp-EIM. I have a question about combining hp
EIM with the reduced basis method. In standard EIM, the theta objects from
the eim evaluation object are attached to the rb theta expansion of the rb
evaluation object. In hp EIM there are multiple eim evaluation objects. My
question is this:

Is it possible to attach different eim theta objects to the rb theta
expansion depending on which EIM evaluation objects corresponds to the
parameter values in question? Consider the greedy procedure of the rb
construction object. Is it possible to attach different eim theta objects
to the rb theta expansion during different iterations of the greedy
procedure?

Best regards,
Nikhil

On Tue, Apr 2, 2019 at 4:48 PM David Knezevic <dav...@ak...>
wrote:

> On Tue, Apr 2, 2019 at 10:39 AM Nikhil Vaidya <nik...@gm...>
> wrote:
>
>> Hi David,
>>
>> Thanks for your reply. Could you give me some tips for extending the
>> current EIM code?
>>
>
> You'd have to read through the EIM code and familiarize yourself with
> it... I don't see any blockers to supporting hp-EIM, but it would take some
> work to make sure you're managing all the data correctly. I don't have any
> specific suggestions I'm afraid, other than to make sure you understand the
> current code (I can answer questions on that if needed) and then you should
> be able to see how it could be extended to do what you need (via
> subclassing the relevant parts, for example).
>
> Best,
> David
>
>>

[Libmesh-users] a bug related to the point locator

[Povolotskyi, M. <mpo...@pu...>]

Dear developers,

I think I found a problem in the PointLocator.

I run the following simple code:

#include "libmesh/mesh.h"
#include "libmesh/gmsh_io.h"
#include "libmesh/libmesh.h"
#include "libmesh/point.h"
#include "libmesh/point_locator_tree.h"
#include "libmesh/elem.h"
int main (int argc, char ** argv)
{
   MPI_Init(&argc, &argv);
   {
     libMesh::LibMeshInit init(argc, argv,MPI_COMM_WORLD);
     libMesh::Parallel::Communicator comm;
     libMesh::Mesh mesh(comm);
     std::string mesh_file("domain.msh");
     libMesh::GmshIO(mesh).read(mesh_file);
     libMesh::PointLocatorTree locator(mesh);
     libMesh::Point p(771.091,   999.52,        0);

     if (locator(p) == NULL)
       std::cout << "not found\n";
     else
       std::cout << "found\n";
   }
   MPI_Finalize();
   return 0;
}

The mesh is generated in gmsh. If I produce the 1st order mesh, the 
element is found. If I produce the 2nd order mesh of the same geometry, 
the element is not found, which is incorrect.

Since the list does not allow to add attachments, I post here the gmsh 
script. If you would like the actual mesh file, just give the e-mail 
address. Thank you!

length = 6000;
height = 8000;
dL = 800;
film_thickness = 50;
film_height = 4000;

absorber_width = 1500;
r1 = 300;
r2 = 40;

Point(1) = {0, 0, 0, r1};
Point(2) = {0, height, 0, r1};
Point(3) = {length, height, 0, r1};
Point(4) = {length, 0, 0, r1};
Point(5) = {0+absorber_width, 0, 0, r1};
Point(6) = {0+absorber_width, height-absorber_width, 0, r1};
Point(7) = {length-absorber_width, height-absorber_width, 0, r1};
Point(8) = {length-absorber_width, 0, 0, r1};
Point(9) = {0+absorber_width+400, film_height, 0, r2};
lineX[] = Extrude{length - 2*absorber_width - dL, length - 
2*absorber_width- dL, 0} { Point{9}; Layers{100}; };
fi[] = Extrude{-film_thickness, film_thickness, 0} { Line{lineX[1]}; 
Layers{10}; };
//+
Line(5) = {1, 2};
//+
Line(6) = {2, 3};
//+
Line(7) = {3, 4};
//+
Line(8) = {8, 4};
//+
Line(9) = {8, 7};
//+
Line(10) = {7, 6};
//+
Line(11) = {6, 5};
//+
Line(12) = {5, 1};
//+
Line(13) = {5, 8};
//+
Curve Loop(1) = {11, 12, 5, 6, 7, -8, 9, 10};
//+
Plane Surface(6) = {1};
//+
Curve Loop(2) = {13, 9, 10, 11};
//+
Curve Loop(3) = {2, -4, -1, 3};
//+
Plane Surface(7) = {2, 3};
Physical Surface("film") = {5};
Physical Surface("PML") = {6};
Physical Surface("air") = {7};

[Libmesh-users] problem with mesh locator

[Povolotskyi, M. <mpo...@pu...>]

Dear Libmesh developers,

I found a problem with the mesh locator.

I created a 2nd order 2D mesh with gmesh software.

When I run my code using this mesh, I'm getting an error with the PointLocator.

Does PointLocator support QUAD9 elements?

Bellow you can find output from my debugger.

If you need the mesh to reproduce the problem, I can provide it.

Thank you,

Michael.

Program received signal SIGFPE, Arithmetic exception.
0x00002aaab87a575c in libMesh::FE<2u, (libMesh::FEFamily)0>::inverse_map (elem=0x1f42750, physical_point=...,
    tolerance=9.9999999999999995e-08, secure=false) at src/fe/fe_map.C:1726
1726                dp(0) = (Ginv11*dxidelta + Ginv12*detadelta);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7.x86_64 hwloc-libs-1.11.8-4.el7.x86_64 hwloc-plugins-1.11.8-4.el7.x86_64 libfabric-1.7.0-1.el7.x86_64 libibumad-43.1.1.MLNX20180612.87b4d9b-0.1.45101.x86_64 libibverbs-41mlnx1-OFED.4.5.0.1.0.45101.x86_64 libmlx4-41mlnx1-OFED.4.5.0.0.3.45101.x86_64 libmlx5-41mlnx1-OFED.4.5.0.3.8.45101.x86_64 libnl3-3.2.28-4.el7.x86_64 libpciaccess-0.14-1.el7.x86_64 librdmacm-41mlnx1-OFED.4.2.0.1.3.45101.x86_64 libtool-ltdl-2.4.2-22.el7_3.x86_64 libxml2-2.9.1-6.el7_2.3.x86_64 numactl-libs-2.0.9-7.el7.x86_64 opensm-libs-5.3.0.MLNX20181108.33944a2-0.1.45101.x86_64 xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) p dxidelta
$1 = -2.0365205457321792e+22
(gdb) p Ginv11
$2 = inf
(gdb) p Ginv12
$3 = inf
(gdb) p detadelta
$4 = 1.0182602728660896e+22
(gdb) up
#1  0x00002aaab8721e1b in libMesh::FEInterface::inverse_map (dim=2, fe_t=..., elem=0x1f42750, p=...,
    tolerance=9.9999999999999995e-08, secure=false) at src/fe/fe_interface.C:570
570      fe_with_vec_switch(inverse_map(elem, p, tolerance, secure));
(gdb) p p
$5 = (const libMesh::Point &) @0x5131998: {<libMesh::TypeVector<double>> = {_coords = {1140, 1216,
      0}}, <No data fields>}
(gdb) p elem->type()
$6 = libMesh::QUAD9
(gdb) p elem->point(0)
$7 = (const libMesh::Point &) @0xbe79d0: {<libMesh::TypeVector<double>> = {_coords = {1073.919607848597,
      1053.6736755206391, 0}}, <No data fields>}
(gdb) p elem->point(1)
$8 = (const libMesh::Point &) @0xd7c550: {<libMesh::TypeVector<double>> = {_coords = {1118.8895049213079,
      1069.0910114055571, 0}}, <No data fields>}
(gdb) p elem->point(2)
$9 = (const libMesh::Point &) @0xc440d0: {<libMesh::TypeVector<double>> = {_coords = {1136.2480098839389,
      1025.636099727888, 0}}, <No data fields>}
(gdb) p elem->point(3)
$10 = (const libMesh::Point &) @0xc57a50: {<libMesh::TypeVector<double>> = {_coords = {1091.286513287763,
      998.03909901903012, 0}}, <No data fields>}
(gdb) p elem->point(4)
$11 = (const libMesh::Point &) @0xe34510: {<libMesh::TypeVector<double>> = {_coords = {1096.404556384952,
      1061.3823434630981, 0}}, <No data fields>}
(gdb) p elem->point(5)
$12 = (const libMesh::Point &) @0xe345d0: {<libMesh::TypeVector<double>> = {_coords = {1127.5687574026231,
      1047.3635555667231, 0}}, <No data fields>}
(gdb) p elem->point(6)
$13 = (const libMesh::Point &) @0xe34690: {<libMesh::TypeVector<double>> = {_coords = {1113.767261585851,
      1011.8375993734591, 0}}, <No data fields>}
(gdb) p elem->point(7)
$14 = (const libMesh::Point &) @0xe34750: {<libMesh::TypeVector<double>> = {_coords = {1082.6030605681799,
      1025.8563872698351, 0}}, <No data fields>}
(gdb) p elem->point(8)
$15 = (const libMesh::Point &) @0xe34810: {<libMesh::TypeVector<double>> = {_coords = {1105.0859089854021,
      1036.609971418279, 0}}, <No data fields>}
(gdb)
(gdb) up
#2  0x00002aaab889f5cf in libMesh::Elem::point_test (this=0x1f42750, p=..., box_tol=9.9999999999999995e-07,
    map_tol=9.9999999999999995e-07) at src/geom/elem.C:2406
2406                                                          /*secure=*/ false);
(gdb)
#3  0x00002aaab889eec6 in libMesh::Elem::contains_point (this=0x1f42750, p=..., tol=9.9999999999999995e-07)
    at src/geom/elem.C:2321
2321        return this->point_test(p, TOLERANCE, tol);
(gdb)
#4  0x00002aaab8de5cc6 in libMesh::TreeNode<4u>::find_element (this=0x318a930, p=..., allowed_subdomains=0x0,
    relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:484
484                if ((*pos)->active() && (*pos)->contains_point(p, relative_tol))
(gdb)
#5  0x00002aaab8de5eee in libMesh::TreeNode<4u>::find_element_in_children (this=0x31890c0, p=...,
    allowed_subdomains=0x0, relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:517
517                                        relative_tol);
(gdb)
#6  0x00002aaab8de5d27 in libMesh::TreeNode<4u>::find_element (this=0x31890c0, p=..., allowed_subdomains=0x0,
    relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:492
492                                              relative_tol);
(gdb)
#7  0x00002aaab8de5eee in libMesh::TreeNode<4u>::find_element_in_children (this=0x314d730, p=...,
    allowed_subdomains=0x0, relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:517
517                                        relative_tol);
(gdb)
#8  0x00002aaab8de5d27 in libMesh::TreeNode<4u>::find_element (this=0x314d730, p=..., allowed_subdomains=0x0,
    relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:492
492                                              relative_tol);
(gdb)
#9  0x00002aaab8de5eee in libMesh::TreeNode<4u>::find_element_in_children (this=0x313d2c0, p=...,
    allowed_subdomains=0x0, relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:517
517                                        relative_tol);
(gdb)
#10 0x00002aaab8de5d27 in libMesh::TreeNode<4u>::find_element (this=0x313d2c0, p=..., allowed_subdomains=0x0,
    relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:492
492                                              relative_tol);
(gdb)
#11 0x00002aaab8de5eee in libMesh::TreeNode<4u>::find_element_in_children (this=0x3132c20, p=...,
    allowed_subdomains=0x0, relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:517
517                                        relative_tol);
(gdb)
#12 0x00002aaab8de5d27 in libMesh::TreeNode<4u>::find_element (this=0x3132c20, p=..., allowed_subdomains=0x0,
    relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:492
492                                              relative_tol);
(gdb)
#13 0x00002aaab8de5eee in libMesh::TreeNode<4u>::find_element_in_children (this=0x3132df0, p=...,
    allowed_subdomains=0x0, relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:517
517                                        relative_tol);
(gdb)
#14 0x00002aaab8de5d27 in libMesh::TreeNode<4u>::find_element (this=0x3132df0, p=..., allowed_subdomains=0x0,
    relative_tol=9.9999999999999995e-07) at src/utils/tree_node.C:492
492                                              relative_tol);
(gdb)
#15 0x00002aaab8ddd67e in libMesh::Tree<4u>::find_element (this=0x3132de0, p=..., allowed_subdomains=0x0,
    relative_tol=9.9999999999999995e-07) at src/utils/tree.C:152
152      return root.find_element(p, allowed_subdomains, relative_tol);
(gdb)
#16 0x00002aaab8d81ac7 in libMesh::PointLocatorTree::operator() (this=0x3132af0, p=..., allowed_subdomains=0x0)
    at src/utils/point_locator_tree.C:207
207          this->_element = this->_tree->find_element (p,allowed_subdomains);
(gdb)

Re: [Libmesh-users] Face ids in gmesh and libMesh

[John P. <jwp...@gm...>]

On Mon, Apr 29, 2019 at 6:02 PM Nikrouz <nik...@gm...> wrote:

> Dear all libMesh users,
>
> I have produced a 3D msh file by Gmesh but I do not define any group
> surface in Gmesh.
>
> In order to identify different faces, is there any class or method in
> libMesh or it is neccsary to define id for msh file in gmesh?
>
> The mentioned faces will be used for boundary conditions.
>

Boundary conditions are specified by "Physical" groups in the gmsh input
file. libMesh reads sections like the following:

$PhysicalNames
5
1 2 "left"
1 3 "right"
1 4 "top"
1 5 "bottom"
$EndPhysicalNames

and converts them into named sidesets with the ids specified.

You might also find this tutorial helpful:
https://albertsk.files.wordpress.com/2012/12/gmsh_tutorial.pdf

-- 
John

[Libmesh-users] Face ids in gmesh and libMesh

[Nikrouz <nik...@gm...>]

Dear all libMesh users,

I have produced a 3D msh file by Gmesh but I do not define any group 
surface in Gmesh.

In order to identify different faces, is there any class or method in 
libMesh or it is neccsary to define id for msh file in gmesh?

The mentioned faces will be used for boundary conditions.

Thanks everybody for your help and guidance,

Re: [Libmesh-users] Fwd: Suitable version of slepc

[Alexander L. <ale...@gm...>]

The SLEPc developers try to keep their versions in sync with PETSc, so the
v3.10 tag of SLEPc should work with your version of PETSc

On Wed, Apr 24, 2019 at 2:49 PM Nikrouz <nik...@gm...> wrote:

>
> Dear All libMesh users
>
> For some examples, it is necessary to configure libMesh with slepc.
>
> Currently, I have PetSC version 3.10.0 which is not compatible with the
> new version of slepc.
>
> How can I find a slepc version suitable for my case?
>
> Thanks you again!
>
>
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>