libmesh-users — General information for libmesh users

Re: [Libmesh-users] Question about using NodeElems with GhostingFunctor

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

On Tue, 4 Dec 2018, David Knezevic wrote:

> I use NodeElems with GhostingFunctor to couple unconnected nodes (i.e. I
> attach NodeElems to the nodes that I want to couple), and this works well.
> However, I realized that this approach requires me to set the processor_id
> in the NodeElem to match the processor_id of the Node that it points to, as
> per the code below:
>
>  for (const auto & elem : mesh.active_element_ptr_range())
>  {
>    if(elem->type() == NODEELEM)
>    {
>      elem->processor_id() = elem->node_ref(0).processor_id();
>    }
>  }
>
> This seems reasonable to me, but I just wanted to check if this is an
> expected requirement?

Huh.  I need to think about that.

For a mesh to be consistent, each Node is required to have the same
processor id as at least *one* of the elements which use it, but
presumably you're tacking NodeElems onto an existing mesh which
already satisfies that requirement, in which case the processor id of
the NodeElems can be anything and still be valid.

For geometric ghosting to work, the processor id of the NodeElem
determines which processor can also see its ghosted elements.  But
you're just using NodeElem as a hack to get just the right amount of
coupling working, so geometry is irrelevant here I assume, in which
case we still have no restrictions on NodeElem pid.

For algebraic ghosting to work... we loop over active_local_elements
when building the send_list... and that might be a problem for you,
huh?!  It seems like not only would you need a NodeElem to have the
right pid for that, but on domain boundaries where two processors'
elements share a Node, you could need a NodeElem with *each* pid?!

Well, either that or you'd need to use higher-dimensional boundary
elements.  So then NodeElem would be the way to go for boundary
coupling only on a 1-D mesh; you'd need Edge2/Edge3 elements on a 2D
mesh, and quads or tris on a 3D mesh.  And each boundary element
would need to match pid with its interior_parent() - it sounds like
BoundaryInfo::add_elements() may be the safe way to work on these
sorts of problems.
---
Roy

[Libmesh-users] Question about using NodeElems with GhostingFunctor

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

I use NodeElems with GhostingFunctor to couple unconnected nodes (i.e. I
attach NodeElems to the nodes that I want to couple), and this works well.
However, I realized that this approach requires me to set the processor_id
in the NodeElem to match the processor_id of the Node that it points to, as
per the code below:

  for (const auto & elem : mesh.active_element_ptr_range())
  {
    if(elem->type() == NODEELEM)
    {
      elem->processor_id() = elem->node_ref(0).processor_id();
    }
  }

This seems reasonable to me, but I just wanted to check if this is an
expected requirement?

Best,
David

Re: [Libmesh-users] Error with GMSH file

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

On Tue, Dec 4, 2018 at 1:15 PM Amneet Bhalla <mai...@gm...> wrote:

> Ok, I just copied the original .msh file to a file with a different name
> and it works. Maybe it was a strange OS thing.
>

Yeah, the file you shared worked OK for me as well FWIW.

-- 
John

Re: [Libmesh-users] Error with GMSH file

[Amneet B. <mai...@gm...>]

Ok, I just copied the original .msh file to a file with a different name
and it works. Maybe it was a strange OS thing.

On Mon, Dec 3, 2018 at 10:29 PM Amneet Bhalla <mai...@gm...> wrote:

> Hi Folks,
>
> I am trying to read a simple GMSH file with libMesh, but I get the
> following error:
>
> Assertion `in.good()' failed.
>
>
> Stack frames: 10
>
> 0: 0   libmesh_dbg.0.dylib                 0x000000010e1a5516
> libMesh::print_trace(std::__1::basic_ostream<char,
> std::__1::char_traits<char> >&) + 2406
>
> 1: 1   libmesh_dbg.0.dylib                 0x000000010e190e20
> libMesh::MacroFunctions::report_error(char const*, int, char const*, char
> const*) + 688
>
> 2: 2   libmesh_dbg.0.dylib                 0x000000010e82af54
> libMesh::GmshIO::read_mesh(std::__1::basic_istream<char,
> std::__1::char_traits<char> >&) + 612
>
> 3: 3   libmesh_dbg.0.dylib                 0x000000010e82ac57
> libMesh::GmshIO::read(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 1079
>
> 4: 4   libmesh_dbg.0.dylib                 0x000000010eb14ddc
> libMesh::NameBasedIO::read(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 45116
>
> 5: 5   libmesh_dbg.0.dylib                 0x000000010ebd8b90
> libMesh::UnstructuredMesh::read(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*,
> bool, bool) + 1424
>
> 6: 6   main2d                              0x000000010b4e32c9
> run_example(int, char**, std::__1::vector<double,
> std::__1::allocator<double> >&) + 12985
>
> 7: 7   main2d                              0x000000010b50bc3d main + 205
>
> 8: 8   libdyld.dylib                       0x00007fff6bf9a015 start + 1
>
> 9: 9   ???                                 0x0000000000000002 0x0 + 2
>
> [0] ../libMesh/src/mesh/gmsh_io.C, line 159, compiled Nov 25 2018 at
> 13:55:48
>
> libc++abi.dylib: terminate_handler unexpectedly returned
>
> Abort trap: 6
>
> Any hints?
>
> The mesh file is attached here. The geometry is a triangle, with element
> size of 0.005.
>
> FWIW, The MATLAB code to create .geo file is here :
> https://paste.ofcode.org/Ts4MZnRicVsJhTpSDaWh4X
>
>
> Thanks,
> --
> --Amneet
>
>
>
>

-- 
--Amneet

[Libmesh-users] Error with GMSH file

[Amneet B. <mai...@gm...>]

Hi Folks,

I am trying to read a simple GMSH file with libMesh, but I get the
following error:

Assertion `in.good()' failed.


Stack frames: 10

0: 0   libmesh_dbg.0.dylib                 0x000000010e1a5516
libMesh::print_trace(std::__1::basic_ostream<char,
std::__1::char_traits<char> >&) + 2406

1: 1   libmesh_dbg.0.dylib                 0x000000010e190e20
libMesh::MacroFunctions::report_error(char const*, int, char const*, char
const*) + 688

2: 2   libmesh_dbg.0.dylib                 0x000000010e82af54
libMesh::GmshIO::read_mesh(std::__1::basic_istream<char,
std::__1::char_traits<char> >&) + 612

3: 3   libmesh_dbg.0.dylib                 0x000000010e82ac57
libMesh::GmshIO::read(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 1079

4: 4   libmesh_dbg.0.dylib                 0x000000010eb14ddc
libMesh::NameBasedIO::read(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 45116

5: 5   libmesh_dbg.0.dylib                 0x000000010ebd8b90
libMesh::UnstructuredMesh::read(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*,
bool, bool) + 1424

6: 6   main2d                              0x000000010b4e32c9
run_example(int, char**, std::__1::vector<double,
std::__1::allocator<double> >&) + 12985

7: 7   main2d                              0x000000010b50bc3d main + 205

8: 8   libdyld.dylib                       0x00007fff6bf9a015 start + 1

9: 9   ???                                 0x0000000000000002 0x0 + 2

[0] ../libMesh/src/mesh/gmsh_io.C, line 159, compiled Nov 25 2018 at
13:55:48

libc++abi.dylib: terminate_handler unexpectedly returned

Abort trap: 6

Any hints?

The mesh file is attached here. The geometry is a triangle, with element
size of 0.005.

FWIW, The MATLAB code to create .geo file is here :
https://paste.ofcode.org/Ts4MZnRicVsJhTpSDaWh4X


Thanks,
-- 
--Amneet

Re: [Libmesh-users] linking vtk with mpi on osx

[Griffith, B. E. <bo...@em...>]

FWIW, you now can use libMesh master -- and, for better or worse, we also now require C++11.

> On Nov 30, 2018, at 1:12 PM, Alex Kaiser <adk...@gm...> wrote:
> 
> I'm on version 1.2.1, which, like the flag, was selected from IBAMR
> examples, https://ibamr.github.io/mac#libmesh. I have no particular reason
> for using that version, other than trying to find a combination in which
> everything works together happily.
> 
> Thanks again,
> Alex
> 
> 
> On Thu, Nov 29, 2018 at 9:17 PM John Peterson <jwp...@gm...> wrote:
> 
>> 
>> 
>> On Nov 29, 2018, at 9:35 PM, Alex Kaiser <adk...@gm...> wrote:
>> 
>> Hi all,
>> 
>> This appears to be working. From IBAMR example build scripts I had "
>> --disable-cxx11" set in libmesh configure. The error appears to be that
>> something in this version of VTK that requires cxx11, because the crash was
>> on loading a vtk header. I appreciate the advice to look in that log more
>> carefully. The error itself was very confusing, but it was followed by so
>> many warnings about cxx11 that it seemed, correctly, like that was the
>> issue.
>> 
>> 
>> You must be using an old version of libmesh?disable-cxx is ignored/no
>> longer an option in recent versions...
>> 
>> —
>> John
>> 
>> 
> 
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] linking vtk with mpi on osx

[Alex K. <adk...@gm...>]

Awesome, glad to know!

On Fri, Nov 30, 2018 at 10:18 AM Griffith, Boyce Eugene <
bo...@em...> wrote:

> FWIW, you now can use libMesh master -- and, for better or worse, we also
> now require C++11.
>
> > On Nov 30, 2018, at 1:12 PM, Alex Kaiser <adk...@gm...> wrote:
> >
> > I'm on version 1.2.1, which, like the flag, was selected from IBAMR
> > examples, https://ibamr.github.io/mac#libmesh. I have no particular
> reason
> > for using that version, other than trying to find a combination in which
> > everything works together happily.
> >
> > Thanks again,
> > Alex
> >
> >
> > On Thu, Nov 29, 2018 at 9:17 PM John Peterson <jwp...@gm...>
> wrote:
> >
> >>
> >>
> >> On Nov 29, 2018, at 9:35 PM, Alex Kaiser <adk...@gm...> wrote:
> >>
> >> Hi all,
> >>
> >> This appears to be working. From IBAMR example build scripts I had "
> >> --disable-cxx11" set in libmesh configure. The error appears to be that
> >> something in this version of VTK that requires cxx11, because the crash
> was
> >> on loading a vtk header. I appreciate the advice to look in that log
> more
> >> carefully. The error itself was very confusing, but it was followed by
> so
> >> many warnings about cxx11 that it seemed, correctly, like that was the
> >> issue.
> >>
> >>
> >> You must be using an old version of libmesh?disable-cxx is ignored/no
> >> longer an option in recent versions...
> >>
> >> —
> >> John
> >>
> >>
> >
> > _______________________________________________
> > Libmesh-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>

Re: [Libmesh-users] linking vtk with mpi on osx

[Alex K. <adk...@gm...>]

I'm on version 1.2.1, which, like the flag, was selected from IBAMR
examples, https://ibamr.github.io/mac#libmesh. I have no particular reason
for using that version, other than trying to find a combination in which
everything works together happily.

Thanks again,
Alex


On Thu, Nov 29, 2018 at 9:17 PM John Peterson <jwp...@gm...> wrote:

>
>
> On Nov 29, 2018, at 9:35 PM, Alex Kaiser <adk...@gm...> wrote:
>
> Hi all,
>
> This appears to be working. From IBAMR example build scripts I had "
> --disable-cxx11" set in libmesh configure. The error appears to be that
> something in this version of VTK that requires cxx11, because the crash was
> on loading a vtk header. I appreciate the advice to look in that log more
> carefully. The error itself was very confusing, but it was followed by so
> many warnings about cxx11 that it seemed, correctly, like that was the
> issue.
>
>
> You must be using an old version of libmesh?disable-cxx is ignored/no
> longer an option in recent versions...
>
> —
> John
>
>

Re: [Libmesh-users] linking vtk with mpi on osx

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

> On Nov 29, 2018, at 9:35 PM, Alex Kaiser <adk...@gm...> wrote:
> 
> Hi all, 
> 
> This appears to be working. From IBAMR example build scripts I had "--disable-cxx11" set in libmesh configure. The error appears to be that something in this version of VTK that requires cxx11, because the crash was on loading a vtk header. I appreciate the advice to look in that log more carefully. The error itself was very confusing, but it was followed by so many warnings about cxx11 that it seemed, correctly, like that was the issue. 

You must be using an old version of libmesh?disable-cxx is ignored/no longer an option in recent versions...

—
John

Re: [Libmesh-users] linking vtk with mpi on osx

[Alex K. <adk...@gm...>]

Hi all,

This appears to be working. From IBAMR example build scripts I had "
--disable-cxx11" set in libmesh configure. The error appears to be that
something in this version of VTK that requires cxx11, because the crash was
on loading a vtk header. I appreciate the advice to look in that log more
carefully. The error itself was very confusing, but it was followed by so
many warnings about cxx11 that it seemed, correctly, like that was the
issue.

Thanks again,
Alex




On Mon, Nov 26, 2018 at 7:25 AM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Mon, 26 Nov 2018, John Peterson wrote:
>
> > It's possible that you built VTK correctly (i.e. with the correct MPI
> > settings), but linking failed for some other reason. Off the top of my
> > head, I'd suspect that it's because you are using VTK 8.x and we haven't
> > tested building libmesh with this version yet...
>
> I've been using VTK 8.0.1 for a while; haven't tried 8.1 yet though.
> ---
> Roy
>

Re: [Libmesh-users] PetscDMWrapper functionality (Salazar De Troya, Miguel)

[Boris B. <bor...@bu...>]

Hi Miguel,

Sorry, I should have responded to you earlier - you are correct, as it
currently stands the DMWrapper is incomplete in libMesh master, and for now
only serves as a placeholder for the rest of the implementation.

I have recently been working on finalizing details regarding some
fieldsplit capabilities in conjunction with the implementation, details
which we wish to iron out before the rest of the infrastructure is merged
into master. If you are interested in trying out the 'alpha' version and
have no need for the fieldsplit capabilities, you can check out my branch
which admittedly needs cleanup at this point, but should have the required
components. You can find it at :
https://github.com/bboutkov/libmesh/tree/gmg_master

If you do decide to try it, please note that it currently requires the user
to supply a pre-refined mesh hierarchy, and might change around a bit in
the near future.

Best of luck,
- Boris


Message: 1
> Date: Tue, 27 Nov 2018 17:58:35 +0000
> From: "Salazar De Troya, Miguel" <sal...@ll...>
> To: "Lib...@li..."
>         <Lib...@li...>
> Subject: [Libmesh-users] PetscDMWrapper functionality
> Message-ID: <40A...@co...>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> I just wanted to ask if this capability (geometric multigrid in libMesh)
> is working properly before I dig deeper in the possible parameters for the
> PETSc mg. I?m trying to solve a linear elasticity problem with the settings:
>
> -ksp_type cg
> -pc_type mg
> -pc_mg_levels 3
> -pc_mg_galerkin
> -pc_mg_type full
>
> But I get a lof of iterations (>1000) in the linear solver. I do pass the
> options ?use_petsc_dm and ?node_major_dofs. I noticed this capability is
> still very new and that the number of levels seems to be limited to 1. Does
> that mean that I should not use it at all?
>
> Thanks
> Miguel
>
>
> Miguel A. Salazar de Troya
> Graduate Scholar, Lawrence Livermore National Laboratory
> Ph.D. Candidate, University of Illinois at Urbana-Champaign
> B141
> Rm: 1085-5
> Ph: 1(925) 422-6411
>
> ------------------------------
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>
> ------------------------------
>
> End of Libmesh-users Digest, Vol 150, Issue 19
> **********************************************
>

Re: [Libmesh-users] Working with 1D mesh in 2D simulation

[Amneet B. <mai...@gm...>]

Yeah, that's what I ended up doing: computing it myself.

On Thu, Nov 29, 2018 at 9:17 AM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Nov 28, 2018 at 3:58 PM Amneet Bhalla <mai...@gm...>
> wrote:
>
>> Hi Folks,
>>
>> I have a question about using 1D mesh (of an immersed structure) in 2D
>> (fluid domain) simulation.
>> I am importing GMSH file to read linear elements (EDGE2) making the
>> surface
>> of a circle, such that I get
>>
>>         mesh.read_mesh(gmsh_filename);
>>             and
>>        int dim =  mesh.mesh_dimension; // dim == 1
>>
>> In my simulation I want to enquire the orientation of the normal vector of
>> the edge elements.
>
>
> In libMesh, the "normals" are always relative to the "face" of the element
> (i.e. are computed by FE::reinit(elem, side), so in 1D the normals are
> (perhaps paradoxically) tangential to the element itself.
>
> If you are after a vector which is perpendicular to a given 1D element
> (assuming it's not the side of a 2D parent element) you may be best of just
> calculating it yourself as I don't think there's currently anything in the
> library that does this.
>
> --
> John
>
>

-- 
--Amneet

Re: [Libmesh-users] Working with 1D mesh in 2D simulation

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

On Wed, Nov 28, 2018 at 3:58 PM Amneet Bhalla <mai...@gm...> wrote:

> Hi Folks,
>
> I have a question about using 1D mesh (of an immersed structure) in 2D
> (fluid domain) simulation.
> I am importing GMSH file to read linear elements (EDGE2) making the surface
> of a circle, such that I get
>
>         mesh.read_mesh(gmsh_filename);
>             and
>        int dim =  mesh.mesh_dimension; // dim == 1
>
> In my simulation I want to enquire the orientation of the normal vector of
> the edge elements.


In libMesh, the "normals" are always relative to the "face" of the element
(i.e. are computed by FE::reinit(elem, side), so in 1D the normals are
(perhaps paradoxically) tangential to the element itself.

If you are after a vector which is perpendicular to a given 1D element
(assuming it's not the side of a 2D parent element) you may be best of just
calculating it yourself as I don't think there's currently anything in the
library that does this.

--
John

[Libmesh-users] Working with 1D mesh in 2D simulation

[Amneet B. <mai...@gm...>]

Hi Folks,

I have a question about using 1D mesh (of an immersed structure) in 2D
(fluid domain) simulation.
I am importing GMSH file to read linear elements (EDGE2) making the surface
of a circle, such that I get

        mesh.read_mesh(gmsh_filename);
            and
       int dim =  mesh.mesh_dimension; // dim == 1

In my simulation I want to enquire the orientation of the normal vector of
the edge elements. What would be the correct FEBase and QRule to construct
to get normal vector in 2D. I am doing the following:

    const int bdry_mesh_dim = 1;

    libMesh::UniquePtr<FEBase> fe_bdry(FEBase::build(2, fe_type));



    libMesh::UniquePtr<QBase> qrule_bdry = QBase::build(QGAUSS,
bdry_mesh_dim, CONSTANT);

    fe_bdry->attach_quadrature_rule(qrule_bdry.get());



/// Loop over bdry_mesh_elems


      fe_bdry->reinit(elem);

      const std::vector<libMesh::Point>& bdry_normals = fe_bdry->get_normals
();


I get error with fe_bdry->reinit(elem) saying that EDGE2 is not supported.

If I build fe_bdry with dim of 1 it proceeds, but bdry_normals is just of
dimension 1.

What should I be doing instead?

Thanks,
-- 
--Amneet

[Libmesh-users] PetscDMWrapper functionality

[Salazar De T. M. <sal...@ll...>]

Hello,

I just wanted to ask if this capability (geometric multigrid in libMesh) is working properly before I dig deeper in the possible parameters for the PETSc mg. I’m trying to solve a linear elasticity problem with the settings:

-ksp_type cg
-pc_type mg
-pc_mg_levels 3
-pc_mg_galerkin
-pc_mg_type full

But I get a lof of iterations (>1000) in the linear solver. I do pass the options –use_petsc_dm and –node_major_dofs. I noticed this capability is still very new and that the number of levels seems to be limited to 1. Does that mean that I should not use it at all?

Thanks
Miguel


Miguel A. Salazar de Troya
Graduate Scholar, Lawrence Livermore National Laboratory
Ph.D. Candidate, University of Illinois at Urbana-Champaign
B141
Rm: 1085-5
Ph: 1(925) 422-6411

Re: [Libmesh-users] linking vtk with mpi on osx

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

On Mon, 26 Nov 2018, John Peterson wrote:

> It's possible that you built VTK correctly (i.e. with the correct MPI
> settings), but linking failed for some other reason. Off the top of my
> head, I'd suspect that it's because you are using VTK 8.x and we haven't
> tested building libmesh with this version yet...

I've been using VTK 8.0.1 for a while; haven't tried 8.1 yet though.
---
Roy

Re: [Libmesh-users] linking vtk with mpi on osx

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

On Tue, Nov 20, 2018 at 3:32 PM Alex Kaiser <adk...@gm...> wrote:

> Hello,
>
> I am trying link libmesh to vtk on osx. What is the best way to install vtk
> so that this will work?
>
> The versions of vtk that come with brew and miniconda seem to fail to
> include MPI and give the error
>
> <<< libMesh requires VTK to be configured with -DVTK_Group_MPI:BOOL=ON >>>.
>
>
> I tried building vtk from source with that flag set, but it did not work.
> The line passed to cmake is
>
> ccmake ../VTK-8.1.2 \
>      -DCMAKE_BUILD_TYPE=RELEASE \
>      -DVTK_Group_MPI:BOOL=ON \
>      -DQT_QMAKE_EXECUTABLE=/opt/Qt5.4.2/5.4/clang_64/bin/qmake
>
> When running configure on libmesh I get:
>
> checking /usr/local/include/vtk-8.1/vtkConfigure.h usability... yes
>
> checking /usr/local/include/vtk-8.1/vtkConfigure.h presence... yes
>
> checking for /usr/local/include/vtk-8.1/vtkConfigure.h... yes
>
> <<< Linking a test program against the VTK libraries failed >>>
>

It's possible that you built VTK correctly (i.e. with the correct MPI
settings), but linking failed for some other reason. Off the top of my
head, I'd suspect that it's because you are using VTK 8.x and we haven't
tested building libmesh with this version yet...  If you look through the
config.log file that gets written, you should be able to find the VTK test
program which fails to link, and the error diagnostic from the
compiler/linker, which would give us a better idea of what went wrong.

-- 
John

Re: [Libmesh-users] [Libmesh]: In parallel error :Segmentation Violation, probably memory access out of range

[Fatemeh C. S. <che...@gm...>]

Dear All,

I don't know for some reason my email is rejected again.
However, I've already registered the email.

Could you please let me know if you receive my email?

best regards,
Fatemeh



On Thu, Nov 22, 2018 at 6:28 PM Fatemeh Chegini Salzmann <
che...@gm...> wrote:

> Dear All,
>
> Did someone perhaps get a chance to look into the issue I submitted?
> We would really appreciate any support.
>
> Best regards,
> Fatemeh
>
> On Wed, Nov 14, 2018 at 3:31 PM <lib...@li...>
> wrote:
>
>> Your message has been rejected, probably because you are not
>> subscribed to the mailing list and the list's policy is to prohibit
>> non-members from posting to it.  If you think that your messages are
>> being rejected in error, contact the mailing list owner at
>> lib...@li....
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Fatemeh Chegini Salzmann <che...@gm...>
>> To: lib...@li...
>> Cc:
>> Bcc:
>> Date: Wed, 14 Nov 2018 15:31:15 +0100
>> Subject: Fwd: [Libmesh]: In parallel error :Segmentation Violation,
>> probably memory access out of range
>>
>> Dear All,
>>
>> I just created a public git repository for some section of the code which
>> causes the problem,
>>
>> https://bitbucket.org/FatemehChe/reaction_diffusion/src/master/
>>
>> Shortly speaking, this code is part of a PDE-Constrained optimization
>> problem, and this function is called at each iteration of an iterative
>> solver.
>> As I mentioned before it randomly gives us this error  "*Segmentation
>> Violation, probably memory access out of range*".
>> That's why I run it this function 10k times to show you the error, you
>> can see the error in the file called *result/mono *
>> Although, I am able to run it on my local machine (Mac/OS, CPU 2.5 GHz
>> Intel Core i7) with 4 cores, without any problem,
>> whenever I run the project on the cluster with more cores it gives me
>> that error after some iterations.
>>
>> To run the project on the cluster,
>> - *make*
>> - *sh benchmark*
>>
>> Thanks in advance.
>>
>> Best regards,
>> Fatemeh
>>
>> ---------- Forwarded message ---------
>> From: John Peterson <jwp...@gm...>
>> Date: Tue, Nov 13, 2018 at 4:07 PM
>> Subject: Re: [Libmesh]: In parallel error :Segmentation Violation,
>> probably memory access out of range
>> To: Fatemeh Chegini Salzmann <che...@gm...>
>>
>>
>> Hi Fatemeh,
>>
>> Two requests:
>>
>> 1.) please provide your entire application code if possible, we can't
>> debug code snippets
>> 2.) please send help requests like this to lib...@li... or
>> open an issue on GitHub. That way you will be more likely to get help
>> people with more time and/or insight than me.
>>
>> --
>> John
>>
>>
>> On Tue, Nov 13, 2018 at 3:38 AM Fatemeh Chegini Salzmann <
>> che...@gm...> wrote:
>>
>>> Dear John,
>>>
>>> I have couple of transient PDEs  that need to be solved at each time
>>> iteration, where the solution of one PDE is used to solve the next PDE.
>>> As you can see shortly here:
>>> //
>>> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>     system_gateVariable.time  = 0;
>>>     system_diffusion.time        = 0;
>>>     system_reaction.time        = 0
>>>   unsigned int t_step;
>>>   for (t_step=1; t_step<(T); t_step++)
>>>   {
>>>
>>>     system_gateVariable.time += dt_T;
>>>     system_diffusion.time    += dt_T;
>>>     system_reaction.time     += dt_T;
>>>
>>>     *system_gateVariable.old_local_solution =
>>> *system_gateVariable.current_local_solution;
>>>     *system_reaction.old_local_solution =
>>> *system_reaction.current_local_solution;
>>>     *system_diffusion.old_local_solution =
>>> *system_diffusion.current_local_solution;
>>>
>>>     equation_systems.get_system("gateVariable").solve();
>>>     equation_systems.get_system("reaction").solve();
>>>
>>>   *system_diffusion.old_local_solution =
>>> *system_reaction.current_local_solution;
>>>    equation_systems.get_system("diffusion").solve();
>>> }
>>> //
>>> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>>  and in the assembly function, I called the *old_solution* whenever i
>>> need to read the solution of each PDE. as follows:
>>> system.*old_solution*(dof_indices[l]);,
>>>
>>> I have this error when I run the project in parallel mode "*Caught
>>> signal number 11 SEGV: Segmentation Violation, probably memory access out
>>> of range*"
>>> I even tried to use *close()*  after solving each equation, e.g.*
>>> equation_systems.get_system("reaction").solution.close();* which didn't
>>> help.
>>> I don't know how to deal with this problem.
>>>
>>> I would appreciate any help/suggetion.
>>>
>>> Thank in advance,
>>> Fatemeh
>>>
>>> *FYI:*
>>>
>>> [1]PETSC ERROR: ------------------------------------------------
>>> ------------------------
>>>
>>> [1]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation,
>>> probably memory access out of range
>>>
>>> [1]PETSC ERROR: Try option -start_in_debugger or
>>> -on_error_attach_debugger
>>>
>>> [1]PETSC ERROR: or see
>>> http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
>>>
>>> [1]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac
>>> OS X to find memory corruption errors
>>>
>>> [1]PETSC ERROR: configure using --with-debugging=yes, recompile, link,
>>> and run
>>>
>>> [1]PETSC ERROR: to get more information on the crash.
>>>
>>> [1]PETSC ERROR: --------------------- Error Message
>>> --------------------------------------------------------------
>>>
>>> [1]PETSC ERROR: Signal received
>>>
>>> [1]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html
>>> for trouble shooting.
>>>
>>> [1]PETSC ERROR: Petsc Release Version 3.8.3, Dec, 09, 2017
>>>
>>> [1]PETSC ERROR:
>>> /home/chegini/inverseProblem/LibmeshCode_InParallel_Cluster/./assemble on a
>>> arch-linux2-c-opt named icsnode17 by chegini Tue Nov 13 10:56:57 2018
>>>
>>> [1]PETSC ERROR: Configure options --prefix=/apps/petsc/3.8.3
>>> --download-hypre=1 --with-ssl=0 --with-debugging=no --with-pic=1
>>> --with-shared-libraries=1 --with-cc=mpicc --with-cxx=mpicxx
>>> --with-fc=mpif90 --download-fblaslapack=1 --download-metis=1
>>> --download-parmetis=1 --download-superlu_dist=1 --download-mumps=1
>>> --download-scalapack=1 --CC=mpicc --CXX=mpicxx --FC=mpif90 --F77=mpif77
>>> --F90=mpif90 --CFLAGS="-fPIC -fopenmp" --CXXFLAGS="-fPIC -fopenmp"
>>> --FFLAGS="-fPIC -fopenmp" --FCFLAGS="-fPIC -fopenmp" --F90FLAGS="-fPIC
>>> -fopenmp" --F77FLAGS="-fPIC -fopenmp"
>>> PETSC_DIR=/apps/petsc/3.8.3/src/petsc-3.8.3
>>>
>>> [1]PETSC ERROR: #1 User provided function() line 0 in  unknown file
>>>
>>> ------------------------------------------------
>>> --------------------------
>>>
>>> MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
>>>
>>> with errorcode 59.
>>>
>>>
>>> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
>>>
>>> You may or may not see output from other processes, depending on
>>>
>>> exactly when Open MPI kills them.
>>>
>>> ------------------------------------------------
>>> --------------------------
>>>
>>> In: PMI_Abort(59, N/A)
>>>
>>> srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
>>>
>>> slurmstepd: *** STEP 924595.0 ON icsnode17 CANCELLED AT
>>> 2018-11-13T11:00:55 ***
>>>
>>> srun: error: icsnode17: tasks 0,3,5-16,18-19: Killed
>>>
>>> srun: error: icsnode17: task 1: Exited with exit code 59
>>>
>>> srun: error: icsnode17: tasks 2,4,17: Killed
>>>
>>
>>
>>

Re: [Libmesh-users] question about surface elements

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

On Tue, 20 Nov 2018, Michael Povolotskyi wrote:

> Dear Libmesh developers,
> I see from the examples that the surface element is constructed as follows:
>
> // Declare a special finite element object for
> // boundary integration.
> std:: unique_ptr<FEBase> fe_face (FEBase::build(dim, fe_type));
>
> Question: why the dimension is equal to the dimension of the mesh instead of 
> dim - 1, as you use in the quadrature rule?

It's still a dim-dimensional element, even if you do some
initialization for a dim-1-dimensional side.  Consider the HERMITE
case.  With p=3 on an edge, HERMITE gives you 4 DoFs: u and du/dx on
each of left/right nodes.  But with p=3 on a quad, HERMITE gives you
16 DoFs, and *8* of those are on any given edge: the above four, plus
du/dy and d^2u/dy^2 on left/right nodes.  If you were integrating
fluxes across the edge, say, then you'd need all 8 of those DoFs to
get the right result.
---
Roy

[Libmesh-users] linking vtk with mpi on osx

[Alex K. <adk...@gm...>]

Hello,

I am trying link libmesh to vtk on osx. What is the best way to install vtk
so that this will work?

The versions of vtk that come with brew and miniconda seem to fail to
include MPI and give the error

<<< libMesh requires VTK to be configured with -DVTK_Group_MPI:BOOL=ON >>>.


I tried building vtk from source with that flag set, but it did not work.
The line passed to cmake is

ccmake ../VTK-8.1.2 \
     -DCMAKE_BUILD_TYPE=RELEASE \
     -DVTK_Group_MPI:BOOL=ON \
     -DQT_QMAKE_EXECUTABLE=/opt/Qt5.4.2/5.4/clang_64/bin/qmake

When running configure on libmesh I get:

checking /usr/local/include/vtk-8.1/vtkConfigure.h usability... yes

checking /usr/local/include/vtk-8.1/vtkConfigure.h presence... yes

checking for /usr/local/include/vtk-8.1/vtkConfigure.h... yes

<<< Linking a test program against the VTK libraries failed >>>

<<< libMesh requires VTK to be configured with -DVTK_Group_MPI:BOOL=ON >>>


Please let me know what I could try to fix this. I looked at this thread,
https://sourceforge.net/p/libmesh/mailman/message/36419977/ , and have run
make install. I am passing the following to configure when trying to build
libmesh:
    --enable-vtk  --with-vtk-include=/usr/local/include/vtk-8.1
--with-vtk-lib=/usr/local/lib \
Those directories have vtk headers and vtk-related dylibs as expected.

Thank you,
Alex

[Libmesh-users] question about surface elements

[Michael P. <mpo...@pu...>]

Dear Libmesh developers,
I see from the examples that the surface element is constructed as follows:

// Declare a special finite element object for
// boundary integration.
std::unique_ptr<FEBase> fe_face (FEBase::build(dim, fe_type));

Question: why the dimension is equal to the dimension of the mesh 
instead of dim - 1, as you use in the quadrature rule?
Thank you.

Re: [Libmesh-users] Is JxGradW Available??

[Brandon D. <bld...@bu...>]

Good Morning John,

Will do. Thanks for the help.

Have a great holiday.
-Brandon



On Tue, Nov 20, 2018, 10:44 AM John Peterson <jwp...@gm... wrote:

>
>
> On Mon, Nov 19, 2018 at 11:10 PM Brandon Denton <bld...@bu...>
> wrote:
>
>> Good evening.
>>
>> No. I'm trying to solve compressible navier-stokes in conservative form.
>>
>> dU/dt + (Ai + Bi)dU/dxi + d/dxi(cij*dU/dxj) = 0
>>
>> After taking the inner product of the weighting functions (W) and the
>> residual, integrated over the domain and apply the divergence theorem, I
>> get the integrand for the domain as
>>
>> W*(Ai + Bi)dU/dxi + dW/dxi*(cij*dU/dxj)
>>
>> With the surface integrand as
>>
>> -W*(cij*dU/dxj)
>>
>> To do the domain integral via quadrature, I would need dW/dxi at the
>> quadrature point. I know I can get JxW and calculate all components of Ai,
>> Bi, cij and dU/dxi using context.interior_value and
>> context.interior_gradient (after proper reorganization).
>>
>> I just can't seem to figure out dW/dxi. Since I still need the geometric
>> jacobian J, I was wondering if JxdW/dxi was available or some way I could
>> calculate it.
>>
>
> The "W" in your context is a test function while the W in "JxW" is the
> quadrature weight.
>
> The FE::get_phi() and FE::get_dphi() functions provide access to the test
> function values and shape derivatives, respectively. Have a look at the
> various examples and you should be able to figure out what's going on.
>
> --
> John
>

Re: [Libmesh-users] Is JxGradW Available??

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

On Mon, Nov 19, 2018 at 11:10 PM Brandon Denton <bld...@bu...>
wrote:

> Good evening.
>
> No. I'm trying to solve compressible navier-stokes in conservative form.
>
> dU/dt + (Ai + Bi)dU/dxi + d/dxi(cij*dU/dxj) = 0
>
> After taking the inner product of the weighting functions (W) and the
> residual, integrated over the domain and apply the divergence theorem, I
> get the integrand for the domain as
>
> W*(Ai + Bi)dU/dxi + dW/dxi*(cij*dU/dxj)
>
> With the surface integrand as
>
> -W*(cij*dU/dxj)
>
> To do the domain integral via quadrature, I would need dW/dxi at the
> quadrature point. I know I can get JxW and calculate all components of Ai,
> Bi, cij and dU/dxi using context.interior_value and
> context.interior_gradient (after proper reorganization).
>
> I just can't seem to figure out dW/dxi. Since I still need the geometric
> jacobian J, I was wondering if JxdW/dxi was available or some way I could
> calculate it.
>

The "W" in your context is a test function while the W in "JxW" is the
quadrature weight.

The FE::get_phi() and FE::get_dphi() functions provide access to the test
function values and shape derivatives, respectively. Have a look at the
various examples and you should be able to figure out what's going on.

-- 
John

Re: [Libmesh-users] Is JxGradW Available??

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

> On Nov 19, 2018, at 7:33 PM, Brandon Denton <bld...@bu...> wrote:
> 
> Good Evening,
> 
> I am currently working on a FEM formulation which calls for the JxGrad(W).
> I know that JxW is available from libmesh but is JxGrad(W)? if so, how to I
> access it? If not, is there a work around?

W in this context is the quadrature weight... I’m not sure what is meant by its gradient? Are you by chance referring to changes in the element Jacobian due to mesh displacements?

—
John

[Libmesh-users] Is JxGradW Available??

[Brandon D. <bld...@bu...>]

Good Evening,

I am currently working on a FEM formulation which calls for the JxGrad(W).
I know that JxW is available from libmesh but is JxGrad(W)? if so, how to I
access it? If not, is there a work around?

Thank you in advance.
-Brandon Denton