libmesh-users — General information for libmesh users

[Libmesh-users] How to define Neuman Boundary Condition in libMesh

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

Dear All libMesh users

I am currently working with Example Fem_system example No2 titled 
"Nonlinear Elasticity with FEMSystem 
<http://libmesh.github.io/examples/fem_system_ex2.html>".

The boundary conditions used in the code are defined based on 
displacement(Drichlet Boundary condition).

How can I apply force boundary condition on one of the surfaces instead 
of displacement?

Which of the examples is suitable for learning how to define load(s) on 
different surfaces?

Thanks for your help and following!

[Libmesh-users] Error in Configure script

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

I am trying to configure libMesh 1.3. I get the following error in my
configure script:

configure: WARNING: boost/system/error_code.hpp: present but cannot be compiled
configure: WARNING: boost/system/error_code.hpp:     check for missing
prerequisite headers?
configure: WARNING: boost/system/error_code.hpp: see the Autoconf documentation
configure: WARNING: boost/system/error_code.hpp:     section "Present
But Cannot Be Compiled"
configure: WARNING: boost/system/error_code.hpp: proceeding with the
compiler's result
configure: WARNING:     ## --------------------------------------- ##
configure: WARNING:     ## Report this to roy...@ic... ##
configure: WARNING:     ## --------------------------------------- ##
checking for boost/system/error_code.hpp... no
configure: error: cannot find boost/system/error_code.hpp
configure: error: ../../../../contrib/metaphysicl/0.2.0/configure
failed for contrib/metaphysicl/0.2.0


The config.log file is also attached. What is going wrong?

Best,
Nikhil

Re: [Libmesh-users] Setting up BC for subdivision FE example

[Lee, J. H. <jae...@li...>]

Awesome! Thank you so much!

On Mar 28, 2019, at 12:11 PM, John Peterson <jwp...@gm...<mailto:jwp...@gm...>> wrote:



On Thu, Mar 28, 2019 at 11:02 AM Lee, Jae Ho <jae...@li...<mailto:jae...@li...>> wrote:
I was modifying the subdivision FE example code in miscellaneous/ex11 to handle large deformations and do a bending and inflation of a circular plate in Cirak and Ortiz 2001 (https://pdfs.semanticscholar.org/6fb5/bf884883eda23383e1502f62dd63d2b6b39e.pdf), and the way it currently handles its BCs is by penalty method. But by doing so, it’s also pinning some elements that are actually in the mesh body in addition to pinning the ghost elements. Is there particular reason that it does that? For example, if I just pin the ghost elements by imposing penalty term just for the three nodes associated with a ghost element, it “looks” like it’s doing the right thing.

for (unsigned int n = 1; n < 3; ++n) <——————— switched 4 to 3 to not pin the element that is in the actual mesh.
            {
                const dof_id_type u_dof = nodes[n]->dof_number(KL_system.number(), u_var, 0);
                const dof_id_type v_dof = nodes[n]->dof_number(KL_system.number(), v_var, 0);
                const dof_id_type w_dof = nodes[n]->dof_number(KL_system.number(), w_var, 0);
                KL_system.matrix->add(u_dof, u_dof, penalty);
                KL_system.matrix->add(v_dof, v_dof, penalty);
                KL_system.matrix->add(w_dof, w_dof, penalty);
            }

I am just not sure if doing so will cause any issues. Also, what would be the best approach if I want to impose boundary conditions other than pinning on the ghost elements (i.e. both displacement and rotation free)? Thank you for your help!

Unfortunately I don't really know the answer, but I replied off-list with some contact information for the original authors of the subdivision surfaces elements so you may try contacting them.

--
John

Re: [Libmesh-users] Setting up BC for subdivision FE example

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

On Thu, Mar 28, 2019 at 11:02 AM Lee, Jae Ho <jae...@li...> wrote:

> I was modifying the subdivision FE example code in miscellaneous/ex11 to
> handle large deformations and do a bending and inflation of a circular
> plate in Cirak and Ortiz 2001 (
> https://pdfs.semanticscholar.org/6fb5/bf884883eda23383e1502f62dd63d2b6b39e.pdf),
> and the way it currently handles its BCs is by penalty method. But by doing
> so, it’s also pinning some elements that are actually in the mesh body in
> addition to pinning the ghost elements. Is there particular reason that it
> does that? For example, if I just pin the ghost elements by imposing
> penalty term just for the three nodes associated with a ghost element, it
> “looks” like it’s doing the right thing.
>
> for (unsigned int n = 1; n < 3; ++n) <——————— switched 4 to 3 to not pin
> the element that is in the actual mesh.
>             {
>                 const dof_id_type u_dof =
> nodes[n]->dof_number(KL_system.number(), u_var, 0);
>                 const dof_id_type v_dof =
> nodes[n]->dof_number(KL_system.number(), v_var, 0);
>                 const dof_id_type w_dof =
> nodes[n]->dof_number(KL_system.number(), w_var, 0);
>                 KL_system.matrix->add(u_dof, u_dof, penalty);
>                 KL_system.matrix->add(v_dof, v_dof, penalty);
>                 KL_system.matrix->add(w_dof, w_dof, penalty);
>             }
>
> I am just not sure if doing so will cause any issues. Also, what would be
> the best approach if I want to impose boundary conditions other than
> pinning on the ghost elements (i.e. both displacement and rotation free)?
> Thank you for your help!
>

Unfortunately I don't really know the answer, but I replied off-list with
some contact information for the original authors of the subdivision
surfaces elements so you may try contacting them.

-- 
John

[Libmesh-users] Setting up BC for subdivision FE example

[Lee, J. H. <jae...@li...>]

I was modifying the subdivision FE example code in miscellaneous/ex11 to handle large deformations and do a bending and inflation of a circular plate in Cirak and Ortiz 2001 (https://pdfs.semanticscholar.org/6fb5/bf884883eda23383e1502f62dd63d2b6b39e.pdf), and the way it currently handles its BCs is by penalty method. But by doing so, it’s also pinning some elements that are actually in the mesh body in addition to pinning the ghost elements. Is there particular reason that it does that? For example, if I just pin the ghost elements by imposing penalty term just for the three nodes associated with a ghost element, it “looks” like it’s doing the right thing.

for (unsigned int n = 1; n < 3; ++n) <——————— switched 4 to 3 to not pin the element that is in the actual mesh.
            {
                const dof_id_type u_dof = nodes[n]->dof_number(KL_system.number(), u_var, 0);
                const dof_id_type v_dof = nodes[n]->dof_number(KL_system.number(), v_var, 0);
                const dof_id_type w_dof = nodes[n]->dof_number(KL_system.number(), w_var, 0);
                KL_system.matrix->add(u_dof, u_dof, penalty);
                KL_system.matrix->add(v_dof, v_dof, penalty);
                KL_system.matrix->add(w_dof, w_dof, penalty);
            }

I am just not sure if doing so will cause any issues. Also, what would be the best approach if I want to impose boundary conditions other than pinning on the ghost elements (i.e. both displacement and rotation free)? Thank you for your help!

Best,
Mike

Re: [Libmesh-users] problems with libmesh 1.4.0

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

Thank you.

Could you, please, tell when 1.4.1 is going to be released?

Thank you,

Michael.

On 3/27/2019 9:53 AM, John Peterson wrote:


On Tue, Mar 26, 2019 at 7:09 PM Povolotskyi, Mykhailo <mpo...@pu...<mailto:mpo...@pu...>> wrote:
Dear Libmesh developers,

I upgrarded from 1.2.1 to 1.4.0

My code stopped working.

The first error is as follows:

[0]PETSC ERROR: --------------------- Error Message
--------------------------------------------------------------
[0]PETSC ERROR: Object is in wrong state
[0]PETSC ERROR: Not for unassembled vector
[0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html
for trouble shooting.
[0]PETSC ERROR: Petsc Release Version 3.8.4, Mar, 24, 2018
[0]PETSC ERROR: /home/mpovolot/NEMO5/prototype/bug1/Bell/nemo on a linux
named brown-a302.rcac.purdue.edu<http://brown-a302.rcac.purdue.edu> by mpovolot Tue Mar 26 18:58:29 2019
[0]PETSC ERROR: Configure options --with-scalar-type=real --with-x=0
--with-hdf5 --download-hdf5=1 --with-single-library=1 --with-pic=1
--with-shared-libraries=0 --with-log=0 --with-clanguage=C++
--CXXFLAGS="-fopenmp -fPIC" --CFLAGS="-fopenmp -fPIC" --with-fortran=0
--FFLAGS="-fopenmp -fPIC" --with-debugging=0 --with-cc=mpicc
--with-fc=mpif90 --with-cxx=mpicxx COPTFLAGS= CXXOPTFLAGS= FOPTFLAGS=
--download-metis=1 --download-parmetis=1
--with-valgrind-dir=/apps/brown/valgrind/3.13.0_gcc-4.8.5
--download-mumps=1 --with-fortran-kernels=0 --download-superlu_dist=1
--with-blaslapack-lib="-L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
-lmkl_intel_lp64 -lmkl_gnu_thread -lmkl_core "
--with-blacs-lib=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.so
--with-blacs-include=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/include
--with-scalapack-lib="-Wl,-rpath,/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
-L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
-lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core  -lpthread
-L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
-lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64"
--with-scalapack-include=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/include
[0]PETSC ERROR: #1 VecCopy() line 1562 in
/depot/kildisha/apps/brown/nemo5/libs/petsc/build-real/src/vec/vec/interface/vector.c
terminate called after throwing an instance of
'libMesh::PetscSolverException'
   what():  Object is in wrong state

Program received signal SIGABRT, Aborted.
0x00002aaab14ea207 in raise () from /usr/lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-260.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
libicu-50.1.2-17.el7.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
librdmacm-41mlnx1-OFED.4.2.0.1.3.45101.x86_64
numactl-libs-2.0.9-7.el7.x86_64
opensm-libs-5.3.0.MLNX20181108.33944a2-0.1.45101.x86_64
python-libs-2.7.5-76.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) up
#1  0x00002aaab14eb8f8 in abort () from /usr/lib64/libc.so.6
(gdb)
#2  0x00002aaab087086d in __gnu_cxx::__verbose_terminate_handler () at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
95      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc: No such
file or directory.
(gdb)
#3  0x00002aaab086e8b6 in __cxxabiv1::__terminate (handler=<optimized
out>) at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
47      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc: No
such file or directory.
(gdb)
#4  0x00002aaab086e901 in std::terminate () at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
57      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc
(gdb)


#5  0x00002aaab086eb18 in __cxxabiv1::__cxa_throw (obj=0x5f95400,
tinfo=0x2aaab00a41e0 <typeinfo for libMesh::PetscSolverException>, dest=
     0x2aaaad2c0a42
<libMesh::PetscSolverException::~PetscSolverException()>) at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:87
87      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc: No such
file or directory.
(gdb)
#6  0x00002aaabe208304 in libMesh::PetscVector<double>::operator=
(this=0x373fc60, v=...) at src/numerics/petsc_vector.C:581
581           LIBMESH_CHKERR(ierr);
(gdb)
#7  0x00002aaabe208cb3 in libMesh::PetscVector<double>::operator=
(this=0x373fc60, v_in=...) at src/numerics/petsc_vector.C:552
552       *this = *v;
(gdb)
#8  0x00002aaabe20c6ae in libMesh::PetscVector<double>::localize
(this=0x373fba0, v_local_in=..., send_list=...) at
src/numerics/petsc_vector.C:723
723           v_local_in = *this;
(gdb)
#9  0x00002aaabe43f570 in libMesh::System::update (this=0x3734120) at
src/systems/system.C:424
424       solution->localize (*current_local_solution, send_list);
(gdb)
#10 0x00002aaabe3bbb33 in libMesh::libmesh_petsc_snes_residual_helper
(snes=0x58daf60, x=0x3628680, ctx=0x373fdb0) at
src/solvers/petsc_nonlinear_solver.C:98
98        sys.update();
(gdb)
#11 0x00002aaabe3bbe56 in libMesh::libmesh_petsc_snes_residual
(snes=0x58daf60, x=0x3628680, r=0x36b70d0, ctx=0x373fdb0) at
src/solvers/petsc_nonlinear_solver.C:152
152         ResidualContext rc =
libmesh_petsc_snes_residual_helper(snes, x, ctx);
(gdb)
#12 0x00002aaaaeae4dff in SNESComputeFunction () from
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#13 0x00002aaaaefd4fe6 in SNESSolve_NEWTONTR(_p_SNES*) () from
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#14 0x00002aaaaeaeed40 in SNESSolve () from
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#15 0x00002aaabe3bf889 in libMesh::PetscNonlinearSolver<double>::solve
(this=0x373fdb0, pre_in=..., x_in=..., r_in=...) at
src/solvers/petsc_nonlinear_solver.C:926
926       ierr = SNESSolve (_snes, PETSC_NULL, x->vec());
(gdb)
#16 0x00002aaabe4367ad in libMesh::NonlinearImplicitSystem::solve
(this=0x3734120) at src/systems/nonlinear_implicit_system.C:183
183 nonlinear_solver->max_linear_iterations);
(gdb)
#17 0x00002aaaadb45bb2 in NonlinearPoisson::execute_for_single_replica
(this=0x2cbaa90, my_system=0x3734120) at NonlinearPoisson.cpp:1359
1359        system->solve();
(gdb)
#18 0x00002aaaadb66dc4 in NonlinearPoisson::execute_solver
(this=0x2cbaa90) at NonlinearPoisson.cpp:1247
1247          execute_for_single_replica(my_system);
(gdb)


In order to solve it, I had to compile with disable-ghosted

After that, I have got another similar error:

#1  0x00002aaab14eb8f8 in abort () from /usr/lib64/libc.so.6
(gdb)
#2  0x00002aaab087086d in __gnu_cxx::__verbose_terminate_handler () at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
95      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc
(gdb)
#3  0x00002aaab086e8b6 in __cxxabiv1::__terminate (handler=<optimized
out>) at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
47      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc: No
such file or directory.
(gdb)
#4  0x00002aaab086e901 in std::terminate () at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
57      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc
(gdb)
#5  0x00002aaab086eb18 in __cxxabiv1::__cxa_throw (obj=0x5fe1060,
tinfo=0x2aaab0059a20 <typeinfo for libMesh::LogicError>,
dest=0x2aaaacc4de4a <libMesh::LogicError::~LogicError()>)
     at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:87
87      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc: No such
file or directory.
(gdb)
#6  0x00002aaabda5c5b4 in libMesh::DofMap::enforce_constraints_exactly
(this=0x382c3e0, system=..., v=0x382ab70, homogeneous=false) at
src/base/dof_map_constraints.C:2108
2108          libmesh_assert (v_local->closed());
(gdb)
#7  0x00002aaabe3bbb0b in libMesh::libmesh_petsc_snes_residual_helper
(snes=0x58f21f0, x=0x3713590, ctx=0x382ac80) at
src/solvers/petsc_nonlinear_solver.C:105
105       sys.get_dof_map().enforce_constraints_exactly(sys,
sys.current_local_solution.get());
(gdb)
#8  0x00002aaabe3bbde2 in libMesh::libmesh_petsc_snes_residual
(snes=0x58f21f0, x=0x3713590, r=0x37a0560, ctx=0x382ac80) at
src/solvers/petsc_nonlinear_solver.C:152
152         ResidualContext rc =
libmesh_petsc_snes_residual_helper(snes, x, ctx);
(gdb)
#9  0x00002aaaaeae4dff in SNESComputeFunction () from
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#10 0x00002aaaaefd4fe6 in SNESSolve_NEWTONTR(_p_SNES*) () from
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#11 0x00002aaaaeaeed40 in SNESSolve () from
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#12 0x00002aaabe3bf815 in libMesh::PetscNonlinearSolver<double>::solve
(this=0x382ac80, pre_in=..., x_in=..., r_in=...) at
src/solvers/petsc_nonlinear_solver.C:926
926       ierr = SNESSolve (_snes, PETSC_NULL, x->vec());
(gdb)
#13 0x00002aaabe4365bd in libMesh::NonlinearImplicitSystem::solve
(this=0x381f030) at src/systems/nonlinear_implicit_system.C:183
183 nonlinear_solver->max_linear_iterations);


Please advise.

This could be related to the bug that was fixed in

3d86f9946 Close residual/vector before applying constraints

Unfortunately that fix did not make it into the 1.4.0 release because it came out after it was tagged, but it will be in an eventual 1.4.1 bugfix release. If your code works with 1.4.0, it shouldn't be too hard to also try it with master or the "v1.4.1_branch" from the upstream repository to see if the problem goes away.

Re: compiling with --disable-ghosted I'm not sure why one would need to do this, it probably masks a real bug/issue with your code but that would require some investigation to determine.

--
John

Re: [Libmesh-users] problems with libmesh 1.4.0

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

On Wed, Mar 27, 2019 at 8:57 AM Povolotskyi, Mykhailo <mpo...@pu...>
wrote:

> Thank you.
>
> Could you, please, tell when 1.4.1 is going to be released?
>
There's no set date for this, but if the fix is needed for your code
there's a good chance that it will also be needed for others, and this
would make us want to get something out there quickly...

If you prefer to work with tarballs, just choose v1.4.1_branch in the left
drop down menu and then choose "Download zip" in the right drop down menu
(see linked screenshot).

https://drive.google.com/file/d/1S28RnOzCTvKfCK4sn-tqyYG-yChWzlkz/view?usp=sharing

This is basically the same as what you'd get if we tagged the 1.4.1 release
and manually made tarballs for it today.

-- 
John

Re: [Libmesh-users] problems with libmesh 1.4.0

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

On Tue, Mar 26, 2019 at 7:09 PM Povolotskyi, Mykhailo <mpo...@pu...>
wrote:

> Dear Libmesh developers,
>
> I upgrarded from 1.2.1 to 1.4.0
>
> My code stopped working.
>
> The first error is as follows:
>
> [0]PETSC ERROR: --------------------- Error Message
> --------------------------------------------------------------
> [0]PETSC ERROR: Object is in wrong state
> [0]PETSC ERROR: Not for unassembled vector
> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html
> for trouble shooting.
> [0]PETSC ERROR: Petsc Release Version 3.8.4, Mar, 24, 2018
> [0]PETSC ERROR: /home/mpovolot/NEMO5/prototype/bug1/Bell/nemo on a linux
> named brown-a302.rcac.purdue.edu by mpovolot Tue Mar 26 18:58:29 2019
> [0]PETSC ERROR: Configure options --with-scalar-type=real --with-x=0
> --with-hdf5 --download-hdf5=1 --with-single-library=1 --with-pic=1
> --with-shared-libraries=0 --with-log=0 --with-clanguage=C++
> --CXXFLAGS="-fopenmp -fPIC" --CFLAGS="-fopenmp -fPIC" --with-fortran=0
> --FFLAGS="-fopenmp -fPIC" --with-debugging=0 --with-cc=mpicc
> --with-fc=mpif90 --with-cxx=mpicxx COPTFLAGS= CXXOPTFLAGS= FOPTFLAGS=
> --download-metis=1 --download-parmetis=1
> --with-valgrind-dir=/apps/brown/valgrind/3.13.0_gcc-4.8.5
> --download-mumps=1 --with-fortran-kernels=0 --download-superlu_dist=1
> --with-blaslapack-lib="-L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
>
> -lmkl_intel_lp64 -lmkl_gnu_thread -lmkl_core "
> --with-blacs-lib=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.so
>
> --with-blacs-include=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/include
>
> --with-scalapack-lib="-Wl,-rpath,/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
>
> -L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
>
> -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core  -lpthread
> -L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64
>
> -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64"
>
> --with-scalapack-include=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/include
> [0]PETSC ERROR: #1 VecCopy() line 1562 in
>
> /depot/kildisha/apps/brown/nemo5/libs/petsc/build-real/src/vec/vec/interface/vector.c
> terminate called after throwing an instance of
> 'libMesh::PetscSolverException'
>    what():  Object is in wrong state
>
> Program received signal SIGABRT, Aborted.
> 0x00002aaab14ea207 in raise () from /usr/lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.17-260.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
> libicu-50.1.2-17.el7.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
> librdmacm-41mlnx1-OFED.4.2.0.1.3.45101.x86_64
> numactl-libs-2.0.9-7.el7.x86_64
> opensm-libs-5.3.0.MLNX20181108.33944a2-0.1.45101.x86_64
> python-libs-2.7.5-76.el7.x86_64 zlib-1.2.7-18.el7.x86_64
> (gdb) up
> #1  0x00002aaab14eb8f8 in abort () from /usr/lib64/libc.so.6
> (gdb)
> #2  0x00002aaab087086d in __gnu_cxx::__verbose_terminate_handler () at
> /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
> 95      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc: No such
> file or directory.
> (gdb)
> #3  0x00002aaab086e8b6 in __cxxabiv1::__terminate (handler=<optimized
> out>) at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
> 47      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc: No
> such file or directory.
> (gdb)
> #4  0x00002aaab086e901 in std::terminate () at
> /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
> 57      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc
> (gdb)
>
>
> #5  0x00002aaab086eb18 in __cxxabiv1::__cxa_throw (obj=0x5f95400,
> tinfo=0x2aaab00a41e0 <typeinfo for libMesh::PetscSolverException>, dest=
>      0x2aaaad2c0a42
> <libMesh::PetscSolverException::~PetscSolverException()>) at
> /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:87
> 87      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc: No such
> file or directory.
> (gdb)
> #6  0x00002aaabe208304 in libMesh::PetscVector<double>::operator=
> (this=0x373fc60, v=...) at src/numerics/petsc_vector.C:581
> 581           LIBMESH_CHKERR(ierr);
> (gdb)
> #7  0x00002aaabe208cb3 in libMesh::PetscVector<double>::operator=
> (this=0x373fc60, v_in=...) at src/numerics/petsc_vector.C:552
> 552       *this = *v;
> (gdb)
> #8  0x00002aaabe20c6ae in libMesh::PetscVector<double>::localize
> (this=0x373fba0, v_local_in=..., send_list=...) at
> src/numerics/petsc_vector.C:723
> 723           v_local_in = *this;
> (gdb)
> #9  0x00002aaabe43f570 in libMesh::System::update (this=0x3734120) at
> src/systems/system.C:424
> 424       solution->localize (*current_local_solution, send_list);
> (gdb)
> #10 0x00002aaabe3bbb33 in libMesh::libmesh_petsc_snes_residual_helper
> (snes=0x58daf60, x=0x3628680, ctx=0x373fdb0) at
> src/solvers/petsc_nonlinear_solver.C:98
> 98        sys.update();
> (gdb)
> #11 0x00002aaabe3bbe56 in libMesh::libmesh_petsc_snes_residual
> (snes=0x58daf60, x=0x3628680, r=0x36b70d0, ctx=0x373fdb0) at
> src/solvers/petsc_nonlinear_solver.C:152
> 152         ResidualContext rc =
> libmesh_petsc_snes_residual_helper(snes, x, ctx);
> (gdb)
> #12 0x00002aaaaeae4dff in SNESComputeFunction () from
> /home/mpovolot/NEMO5/prototype/lib/libnemo.so
> (gdb)
> #13 0x00002aaaaefd4fe6 in SNESSolve_NEWTONTR(_p_SNES*) () from
> /home/mpovolot/NEMO5/prototype/lib/libnemo.so
> (gdb)
> #14 0x00002aaaaeaeed40 in SNESSolve () from
> /home/mpovolot/NEMO5/prototype/lib/libnemo.so
> (gdb)
> #15 0x00002aaabe3bf889 in libMesh::PetscNonlinearSolver<double>::solve
> (this=0x373fdb0, pre_in=..., x_in=..., r_in=...) at
> src/solvers/petsc_nonlinear_solver.C:926
> 926       ierr = SNESSolve (_snes, PETSC_NULL, x->vec());
> (gdb)
> #16 0x00002aaabe4367ad in libMesh::NonlinearImplicitSystem::solve
> (this=0x3734120) at src/systems/nonlinear_implicit_system.C:183
> 183 nonlinear_solver->max_linear_iterations);
> (gdb)
> #17 0x00002aaaadb45bb2 in NonlinearPoisson::execute_for_single_replica
> (this=0x2cbaa90, my_system=0x3734120) at NonlinearPoisson.cpp:1359
> 1359        system->solve();
> (gdb)
> #18 0x00002aaaadb66dc4 in NonlinearPoisson::execute_solver
> (this=0x2cbaa90) at NonlinearPoisson.cpp:1247
> 1247          execute_for_single_replica(my_system);
> (gdb)
>
>
> In order to solve it, I had to compile with disable-ghosted
>
> After that, I have got another similar error:
>
> #1  0x00002aaab14eb8f8 in abort () from /usr/lib64/libc.so.6
> (gdb)
> #2  0x00002aaab087086d in __gnu_cxx::__verbose_terminate_handler () at
> /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
> 95      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc
> (gdb)
> #3  0x00002aaab086e8b6 in __cxxabiv1::__terminate (handler=<optimized
> out>) at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
> 47      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc: No
> such file or directory.
> (gdb)
> #4  0x00002aaab086e901 in std::terminate () at
> /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
> 57      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc
> (gdb)
> #5  0x00002aaab086eb18 in __cxxabiv1::__cxa_throw (obj=0x5fe1060,
> tinfo=0x2aaab0059a20 <typeinfo for libMesh::LogicError>,
> dest=0x2aaaacc4de4a <libMesh::LogicError::~LogicError()>)
>      at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:87
> 87      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc: No such
> file or directory.
> (gdb)
> #6  0x00002aaabda5c5b4 in libMesh::DofMap::enforce_constraints_exactly
> (this=0x382c3e0, system=..., v=0x382ab70, homogeneous=false) at
> src/base/dof_map_constraints.C:2108
> 2108          libmesh_assert (v_local->closed());
> (gdb)
> #7  0x00002aaabe3bbb0b in libMesh::libmesh_petsc_snes_residual_helper
> (snes=0x58f21f0, x=0x3713590, ctx=0x382ac80) at
> src/solvers/petsc_nonlinear_solver.C:105
> 105       sys.get_dof_map().enforce_constraints_exactly(sys,
> sys.current_local_solution.get());
> (gdb)
> #8  0x00002aaabe3bbde2 in libMesh::libmesh_petsc_snes_residual
> (snes=0x58f21f0, x=0x3713590, r=0x37a0560, ctx=0x382ac80) at
> src/solvers/petsc_nonlinear_solver.C:152
> 152         ResidualContext rc =
> libmesh_petsc_snes_residual_helper(snes, x, ctx);
> (gdb)
> #9  0x00002aaaaeae4dff in SNESComputeFunction () from
> /home/mpovolot/NEMO5/prototype/lib/libnemo.so
> (gdb)
> #10 0x00002aaaaefd4fe6 in SNESSolve_NEWTONTR(_p_SNES*) () from
> /home/mpovolot/NEMO5/prototype/lib/libnemo.so
> (gdb)
> #11 0x00002aaaaeaeed40 in SNESSolve () from
> /home/mpovolot/NEMO5/prototype/lib/libnemo.so
> (gdb)
> #12 0x00002aaabe3bf815 in libMesh::PetscNonlinearSolver<double>::solve
> (this=0x382ac80, pre_in=..., x_in=..., r_in=...) at
> src/solvers/petsc_nonlinear_solver.C:926
> 926       ierr = SNESSolve (_snes, PETSC_NULL, x->vec());
> (gdb)
> #13 0x00002aaabe4365bd in libMesh::NonlinearImplicitSystem::solve
> (this=0x381f030) at src/systems/nonlinear_implicit_system.C:183
> 183 nonlinear_solver->max_linear_iterations);
>
>
> Please advise.
>

This could be related to the bug that was fixed in

3d86f9946 Close residual/vector before applying constraints

Unfortunately that fix did not make it into the 1.4.0 release because it
came out after it was tagged, but it will be in an eventual 1.4.1 bugfix
release. If your code works with 1.4.0, it shouldn't be too hard to also
try it with master or the "v1.4.1_branch" from the upstream repository to
see if the problem goes away.

Re: compiling with --disable-ghosted I'm not sure why one would need to do
this, it probably masks a real bug/issue with your code but that would
require some investigation to determine.

--
John

[Libmesh-users] problems with libmesh 1.4.0

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

Dear Libmesh developers,

I upgrarded from 1.2.1 to 1.4.0

My code stopped working.

The first error is as follows:

[0]PETSC ERROR: --------------------- Error Message 
--------------------------------------------------------------
[0]PETSC ERROR: Object is in wrong state
[0]PETSC ERROR: Not for unassembled vector
[0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html 
for trouble shooting.
[0]PETSC ERROR: Petsc Release Version 3.8.4, Mar, 24, 2018
[0]PETSC ERROR: /home/mpovolot/NEMO5/prototype/bug1/Bell/nemo on a linux 
named brown-a302.rcac.purdue.edu by mpovolot Tue Mar 26 18:58:29 2019
[0]PETSC ERROR: Configure options --with-scalar-type=real --with-x=0 
--with-hdf5 --download-hdf5=1 --with-single-library=1 --with-pic=1 
--with-shared-libraries=0 --with-log=0 --with-clanguage=C++ 
--CXXFLAGS="-fopenmp -fPIC" --CFLAGS="-fopenmp -fPIC" --with-fortran=0 
--FFLAGS="-fopenmp -fPIC" --with-debugging=0 --with-cc=mpicc 
--with-fc=mpif90 --with-cxx=mpicxx COPTFLAGS= CXXOPTFLAGS= FOPTFLAGS= 
--download-metis=1 --download-parmetis=1 
--with-valgrind-dir=/apps/brown/valgrind/3.13.0_gcc-4.8.5 
--download-mumps=1 --with-fortran-kernels=0 --download-superlu_dist=1 
--with-blaslapack-lib="-L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64 
-lmkl_intel_lp64 -lmkl_gnu_thread -lmkl_core " 
--with-blacs-lib=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.so 
--with-blacs-include=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/include 
--with-scalapack-lib="-Wl,-rpath,/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64 
-L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64 
-lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core  -lpthread 
-L/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64 
-lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64" 
--with-scalapack-include=/apps/cent7/intel/compilers_and_libraries_2017.1.132/linux/mkl/include
[0]PETSC ERROR: #1 VecCopy() line 1562 in 
/depot/kildisha/apps/brown/nemo5/libs/petsc/build-real/src/vec/vec/interface/vector.c
terminate called after throwing an instance of 
'libMesh::PetscSolverException'
   what():  Object is in wrong state

Program received signal SIGABRT, Aborted.
0x00002aaab14ea207 in raise () from /usr/lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-260.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 
libicu-50.1.2-17.el7.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 
librdmacm-41mlnx1-OFED.4.2.0.1.3.45101.x86_64 
numactl-libs-2.0.9-7.el7.x86_64 
opensm-libs-5.3.0.MLNX20181108.33944a2-0.1.45101.x86_64 
python-libs-2.7.5-76.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) up
#1  0x00002aaab14eb8f8 in abort () from /usr/lib64/libc.so.6
(gdb)
#2  0x00002aaab087086d in __gnu_cxx::__verbose_terminate_handler () at 
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
95      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc: No such 
file or directory.
(gdb)
#3  0x00002aaab086e8b6 in __cxxabiv1::__terminate (handler=<optimized 
out>) at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
47      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc: No 
such file or directory.
(gdb)
#4  0x00002aaab086e901 in std::terminate () at 
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
57      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc
(gdb)


#5  0x00002aaab086eb18 in __cxxabiv1::__cxa_throw (obj=0x5f95400, 
tinfo=0x2aaab00a41e0 <typeinfo for libMesh::PetscSolverException>, dest=
     0x2aaaad2c0a42 
<libMesh::PetscSolverException::~PetscSolverException()>) at 
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:87
87      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc: No such 
file or directory.
(gdb)
#6  0x00002aaabe208304 in libMesh::PetscVector<double>::operator= 
(this=0x373fc60, v=...) at src/numerics/petsc_vector.C:581
581           LIBMESH_CHKERR(ierr);
(gdb)
#7  0x00002aaabe208cb3 in libMesh::PetscVector<double>::operator= 
(this=0x373fc60, v_in=...) at src/numerics/petsc_vector.C:552
552       *this = *v;
(gdb)
#8  0x00002aaabe20c6ae in libMesh::PetscVector<double>::localize 
(this=0x373fba0, v_local_in=..., send_list=...) at 
src/numerics/petsc_vector.C:723
723           v_local_in = *this;
(gdb)
#9  0x00002aaabe43f570 in libMesh::System::update (this=0x3734120) at 
src/systems/system.C:424
424       solution->localize (*current_local_solution, send_list);
(gdb)
#10 0x00002aaabe3bbb33 in libMesh::libmesh_petsc_snes_residual_helper 
(snes=0x58daf60, x=0x3628680, ctx=0x373fdb0) at 
src/solvers/petsc_nonlinear_solver.C:98
98        sys.update();
(gdb)
#11 0x00002aaabe3bbe56 in libMesh::libmesh_petsc_snes_residual 
(snes=0x58daf60, x=0x3628680, r=0x36b70d0, ctx=0x373fdb0) at 
src/solvers/petsc_nonlinear_solver.C:152
152         ResidualContext rc = 
libmesh_petsc_snes_residual_helper(snes, x, ctx);
(gdb)
#12 0x00002aaaaeae4dff in SNESComputeFunction () from 
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#13 0x00002aaaaefd4fe6 in SNESSolve_NEWTONTR(_p_SNES*) () from 
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#14 0x00002aaaaeaeed40 in SNESSolve () from 
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#15 0x00002aaabe3bf889 in libMesh::PetscNonlinearSolver<double>::solve 
(this=0x373fdb0, pre_in=..., x_in=..., r_in=...) at 
src/solvers/petsc_nonlinear_solver.C:926
926       ierr = SNESSolve (_snes, PETSC_NULL, x->vec());
(gdb)
#16 0x00002aaabe4367ad in libMesh::NonlinearImplicitSystem::solve 
(this=0x3734120) at src/systems/nonlinear_implicit_system.C:183
183 nonlinear_solver->max_linear_iterations);
(gdb)
#17 0x00002aaaadb45bb2 in NonlinearPoisson::execute_for_single_replica 
(this=0x2cbaa90, my_system=0x3734120) at NonlinearPoisson.cpp:1359
1359        system->solve();
(gdb)
#18 0x00002aaaadb66dc4 in NonlinearPoisson::execute_solver 
(this=0x2cbaa90) at NonlinearPoisson.cpp:1247
1247          execute_for_single_replica(my_system);
(gdb)


In order to solve it, I had to compile with disable-ghosted

After that, I have got another similar error:

#1  0x00002aaab14eb8f8 in abort () from /usr/lib64/libc.so.6
(gdb)
#2  0x00002aaab087086d in __gnu_cxx::__verbose_terminate_handler () at 
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
95      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc
(gdb)
#3  0x00002aaab086e8b6 in __cxxabiv1::__terminate (handler=<optimized 
out>) at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
47      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc: No 
such file or directory.
(gdb)
#4  0x00002aaab086e901 in std::terminate () at 
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
57      in /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc
(gdb)
#5  0x00002aaab086eb18 in __cxxabiv1::__cxa_throw (obj=0x5fe1060, 
tinfo=0x2aaab0059a20 <typeinfo for libMesh::LogicError>, 
dest=0x2aaaacc4de4a <libMesh::LogicError::~LogicError()>)
     at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:87
87      /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc: No such 
file or directory.
(gdb)
#6  0x00002aaabda5c5b4 in libMesh::DofMap::enforce_constraints_exactly 
(this=0x382c3e0, system=..., v=0x382ab70, homogeneous=false) at 
src/base/dof_map_constraints.C:2108
2108          libmesh_assert (v_local->closed());
(gdb)
#7  0x00002aaabe3bbb0b in libMesh::libmesh_petsc_snes_residual_helper 
(snes=0x58f21f0, x=0x3713590, ctx=0x382ac80) at 
src/solvers/petsc_nonlinear_solver.C:105
105       sys.get_dof_map().enforce_constraints_exactly(sys, 
sys.current_local_solution.get());
(gdb)
#8  0x00002aaabe3bbde2 in libMesh::libmesh_petsc_snes_residual 
(snes=0x58f21f0, x=0x3713590, r=0x37a0560, ctx=0x382ac80) at 
src/solvers/petsc_nonlinear_solver.C:152
152         ResidualContext rc = 
libmesh_petsc_snes_residual_helper(snes, x, ctx);
(gdb)
#9  0x00002aaaaeae4dff in SNESComputeFunction () from 
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#10 0x00002aaaaefd4fe6 in SNESSolve_NEWTONTR(_p_SNES*) () from 
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#11 0x00002aaaaeaeed40 in SNESSolve () from 
/home/mpovolot/NEMO5/prototype/lib/libnemo.so
(gdb)
#12 0x00002aaabe3bf815 in libMesh::PetscNonlinearSolver<double>::solve 
(this=0x382ac80, pre_in=..., x_in=..., r_in=...) at 
src/solvers/petsc_nonlinear_solver.C:926
926       ierr = SNESSolve (_snes, PETSC_NULL, x->vec());
(gdb)
#13 0x00002aaabe4365bd in libMesh::NonlinearImplicitSystem::solve 
(this=0x381f030) at src/systems/nonlinear_implicit_system.C:183
183 nonlinear_solver->max_linear_iterations);


Please advise.

Michael.

Re: [Libmesh-users] ‘VecScatterCreateWithData’ was not declared in this scope

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

On Tue, Mar 26, 2019 at 8:22 AM Charlie Talbot <cha...@gm...> wrote:

> Thanks!
>

FYI: https://github.com/libMesh/libmesh/issues/2084

-- 
John

Re: [Libmesh-users] ‘VecScatterCreateWithData’ was not declared in this scope

[Charlie T. <cha...@gm...>]

Thanks!

On Tue, Mar 26, 2019 at 9:21 AM John Peterson <jwp...@gm...> wrote:

>
>
> On Tue, Mar 26, 2019 at 7:59 AM Charlie Talbot <cha...@gm...>
> wrote:
>
>> Hi, I recently configured petsc after pulling from the master branch,
>> configuring using the
>>
>> arch-linux-pkgs-64idx.py
>>
>> script provided, and specified this when trying to install libmesh-1.4.0,
>> which failed with error message:
>> ...
>>   CXX      src/numerics/libmesh_dbg_la-sparse_matrix.lo
>>   CXX      src/numerics/libmesh_dbg_la-sparse_shell_matrix.lo
>>   CXX      src/numerics/libmesh_dbg_la-sum_shell_matrix.lo
>>   CXX      src/numerics/libmesh_dbg_la-tensor_shell_matrix.lo
>> In file included from ./include/libmesh/petsc_vector.h:31,
>>                  from ../src/numerics/petsc_vector.C:24:
>> ../src/numerics/petsc_vector.C: In member function ‘virtual void
>> libMesh::PetscVector<T>::localize(libMesh::NumericVector<T>&) const’:
>> ./include/libmesh/petsc_macro.h:94:58: error: there are no arguments to
>> ‘VecScatterCreateWithData’ that depend on a template parameter, so a
>> declaration of ‘VecScatterCreateWithData’ must be available [-fpermissive]
>>  #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
>> VecScatterCreateWithData(xin,ix,yin,iy,newctx)
>>
>
>
> The code in question is this:
>
> // Once PETSc-3.11.0 is released, "&& PETSC_VERSION_RELEASE" should be
> removed
> #if PETSC_VERSION_LESS_THAN(3,11,0) && PETSC_VERSION_RELEASE
> #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
> VecScatterCreate(xin,ix,yin,iy,newctx)
> #else
> #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
> VecScatterCreateWithData(xin,ix,yin,iy,newctx)
> #endif
>
> Since you are using PETSc master, you are getting into the #else case
> since master == !PETSC_VERSION_RELEASE. But somehow your version of master
> doesn't have VecScatterCreateWithData, so it may have been in master for a
> while and then they took it back out...
>
>
>
> Any idea how to work around this? Should I stick to petsc-3.9._?
>>
>
> Yes. At this point we probably don't have a version of libmesh that works
> with PETSc master, it is a bit of a moving target as you can see..
>
> --
> John
>

Re: [Libmesh-users] ‘VecScatterCreateWithData’ was not declared in this scope

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

On Tue, Mar 26, 2019 at 7:59 AM Charlie Talbot <cha...@gm...> wrote:

> Hi, I recently configured petsc after pulling from the master branch,
> configuring using the
>
> arch-linux-pkgs-64idx.py
>
> script provided, and specified this when trying to install libmesh-1.4.0,
> which failed with error message:
> ...
>   CXX      src/numerics/libmesh_dbg_la-sparse_matrix.lo
>   CXX      src/numerics/libmesh_dbg_la-sparse_shell_matrix.lo
>   CXX      src/numerics/libmesh_dbg_la-sum_shell_matrix.lo
>   CXX      src/numerics/libmesh_dbg_la-tensor_shell_matrix.lo
> In file included from ./include/libmesh/petsc_vector.h:31,
>                  from ../src/numerics/petsc_vector.C:24:
> ../src/numerics/petsc_vector.C: In member function ‘virtual void
> libMesh::PetscVector<T>::localize(libMesh::NumericVector<T>&) const’:
> ./include/libmesh/petsc_macro.h:94:58: error: there are no arguments to
> ‘VecScatterCreateWithData’ that depend on a template parameter, so a
> declaration of ‘VecScatterCreateWithData’ must be available [-fpermissive]
>  #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
> VecScatterCreateWithData(xin,ix,yin,iy,newctx)
>


The code in question is this:

// Once PETSc-3.11.0 is released, "&& PETSC_VERSION_RELEASE" should be
removed
#if PETSC_VERSION_LESS_THAN(3,11,0) && PETSC_VERSION_RELEASE
#  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreate(xin,ix,yin,iy,newctx)
#else
#  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)
#endif

Since you are using PETSc master, you are getting into the #else case since
master == !PETSC_VERSION_RELEASE. But somehow your version of master
doesn't have VecScatterCreateWithData, so it may have been in master for a
while and then they took it back out...



Any idea how to work around this? Should I stick to petsc-3.9._?
>

Yes. At this point we probably don't have a version of libmesh that works
with PETSc master, it is a bit of a moving target as you can see..

-- 
John

[Libmesh-users] ‘VecScatterCreateWithData’ was not declared in this scope

[Charlie T. <cha...@gm...>]

Hi, I recently configured petsc after pulling from the master branch,
configuring using the

arch-linux-pkgs-64idx.py

script provided, and specified this when trying to install libmesh-1.4.0,
which failed with error message:
...
  CXX      src/numerics/libmesh_dbg_la-sparse_matrix.lo
  CXX      src/numerics/libmesh_dbg_la-sparse_shell_matrix.lo
  CXX      src/numerics/libmesh_dbg_la-sum_shell_matrix.lo
  CXX      src/numerics/libmesh_dbg_la-tensor_shell_matrix.lo
In file included from ./include/libmesh/petsc_vector.h:31,
                 from ../src/numerics/petsc_vector.C:24:
../src/numerics/petsc_vector.C: In member function ‘virtual void
libMesh::PetscVector<T>::localize(libMesh::NumericVector<T>&) const’:
./include/libmesh/petsc_macro.h:94:58: error: there are no arguments to
‘VecScatterCreateWithData’ that depend on a template parameter, so a
declaration of ‘VecScatterCreateWithData’ must be available [-fpermissive]
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

^~~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:685:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,          is,
          ^~~~~~~~~~~~~~~~~~~~~~~
./include/libmesh/petsc_macro.h:94:58: note: (if you use ‘-fpermissive’,
G++ will accept your code, but allowing the use of an undeclared name is
deprecated)
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

^~~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:685:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,          is,
          ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In member function ‘virtual void
libMesh::PetscVector<T>::localize(libMesh::NumericVector<T>&, const
std::__debug::vector<long unsigned int>&) const’:
./include/libmesh/petsc_macro.h:94:58: error: there are no arguments to
‘VecScatterCreateWithData’ that depend on a template parameter, so a
declaration of ‘VecScatterCreateWithData’ must be available [-fpermissive]
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

^~~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:758:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,          is,
          ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In member function ‘virtual void
libMesh::PetscVector<T>::localize(std::__debug::vector<T>&, const
std::__debug::vector<long unsigned int>&) const’:
./include/libmesh/petsc_macro.h:94:58: error: there are no arguments to
‘VecScatterCreateWithData’ that depend on a template parameter, so a
declaration of ‘VecScatterCreateWithData’ must be available [-fpermissive]
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

^~~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:811:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,
          ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In member function ‘virtual void
libMesh::PetscVector<T>::localize(libMesh::numeric_index_type,
libMesh::numeric_index_type, const std::__debug::vector<long unsigned
int>&)’:
./include/libmesh/petsc_macro.h:94:58: error: there are no arguments to
‘VecScatterCreateWithData’ that depend on a template parameter, so a
declaration of ‘VecScatterCreateWithData’ must be available [-fpermissive]
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

^~~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:897:12: note: in expansion of macro
‘LibMeshVecScatterCreate’
     ierr = LibMeshVecScatterCreate(_vec,              is,
            ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In member function ‘virtual void
libMesh::PetscVector<T>::create_subvector(libMesh::NumericVector<T>&, const
std::__debug::vector<long unsigned int>&) const’:
./include/libmesh/petsc_macro.h:94:58: error: there are no arguments to
‘VecScatterCreateWithData’ that depend on a template parameter, so a
declaration of ‘VecScatterCreateWithData’ must be available [-fpermissive]
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

^~~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:1321:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(this->_vec,
          ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In instantiation of ‘void
libMesh::PetscVector<T>::localize(libMesh::NumericVector<T>&) const [with T
= double]’:
../src/numerics/petsc_vector.C:1526:16:   required from here
./include/libmesh/petsc_macro.h:94:82: error: ‘VecScatterCreateWithData’
was not declared in this scope
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:685:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,          is,
          ^~~~~~~~~~~~~~~~~~~~~~~
./include/libmesh/petsc_macro.h:94:82: note: suggested alternative:
‘VecScatterCreateToZero’
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:685:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,          is,
          ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In instantiation of ‘void
libMesh::PetscVector<T>::localize(libMesh::NumericVector<T>&, const
std::__debug::vector<long unsigned int>&) const [with T = double]’:
../src/numerics/petsc_vector.C:1526:16:   required from here
./include/libmesh/petsc_macro.h:94:82: error: ‘VecScatterCreateWithData’
was not declared in this scope
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:758:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,          is,
          ^~~~~~~~~~~~~~~~~~~~~~~
  CXX      src/numerics/libmesh_dbg_la-tensor_tools.lo
./include/libmesh/petsc_macro.h:94:82: note: suggested alternative:
‘VecScatterCreateToZero’
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:758:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,          is,
          ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In instantiation of ‘void
libMesh::PetscVector<T>::localize(std::__debug::vector<T>&, const
std::__debug::vector<long unsigned int>&) const [with T = double]’:
../src/numerics/petsc_vector.C:1526:16:   required from here
./include/libmesh/petsc_macro.h:94:82: error: ‘VecScatterCreateWithData’
was not declared in this scope
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:811:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,
          ^~~~~~~~~~~~~~~~~~~~~~~
./include/libmesh/petsc_macro.h:94:82: note: suggested alternative:
‘VecScatterCreateToZero’
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:811:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(_vec,
          ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In instantiation of ‘void
libMesh::PetscVector<T>::localize(libMesh::numeric_index_type,
libMesh::numeric_index_type, const std::__debug::vector<long unsigned
int>&) [with T = double; libMesh::numeric_index_type = long unsigned int]’:
../src/numerics/petsc_vector.C:1526:16:   required from here
./include/libmesh/petsc_macro.h:94:82: error: ‘VecScatterCreateWithData’
was not declared in this scope
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:897:12: note: in expansion of macro
‘LibMeshVecScatterCreate’
     ierr = LibMeshVecScatterCreate(_vec,              is,
            ^~~~~~~~~~~~~~~~~~~~~~~
  CXX      src/numerics/libmesh_dbg_la-trilinos_epetra_matrix.lo
./include/libmesh/petsc_macro.h:94:82: note: suggested alternative:
‘VecScatterCreateToZero’
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:897:12: note: in expansion of macro
‘LibMeshVecScatterCreate’
     ierr = LibMeshVecScatterCreate(_vec,              is,
            ^~~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C: In instantiation of ‘void
libMesh::PetscVector<T>::create_subvector(libMesh::NumericVector<T>&, const
std::__debug::vector<long unsigned int>&) const [with T = double]’:
../src/numerics/petsc_vector.C:1526:16:   required from here
./include/libmesh/petsc_macro.h:94:82: error: ‘VecScatterCreateWithData’
was not declared in this scope
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:1321:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(this->_vec,
          ^~~~~~~~~~~~~~~~~~~~~~~
  CXX      src/numerics/libmesh_dbg_la-trilinos_epetra_vector.lo
./include/libmesh/petsc_macro.h:94:82: note: suggested alternative:
‘VecScatterCreateToZero’
 #  define LibMeshVecScatterCreate(xin,ix,yin,iy,newctx)
VecScatterCreateWithData(xin,ix,yin,iy,newctx)

~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../src/numerics/petsc_vector.C:1321:10: note: in expansion of macro
‘LibMeshVecScatterCreate’
   ierr = LibMeshVecScatterCreate(this->_vec,
          ^~~~~~~~~~~~~~~~~~~~~~~
  CXX      src/numerics/libmesh_dbg_la-trilinos_preconditioner.lo
  CXX      src/numerics/libmesh_dbg_la-type_tensor.lo
Makefile:17265: recipe for target
'src/numerics/libmesh_dbg_la-petsc_vector.lo' failed
make[2]: *** [src/numerics/libmesh_dbg_la-petsc_vector.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
'/home/chaztikov/src/libmesh-1.4.0/arch-linux-pkgs-64idx'
Makefile:8551: recipe for target '../libmesh_dbg.la' failed
make[1]: *** [../libmesh_dbg.la] Error 2
make[1]: Leaving directory
'/home/chaztikov/src/libmesh-1.4.0/arch-linux-pkgs-64idx/tests'
Makefile:31077: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Any idea how to work around this? Should I stick to petsc-3.9._?

Thanks!

Re: [Libmesh-users] Problem in linking vtk libraries

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

THANKS!

It works now!

On 2019-03-23 8:24 p.m., Simone Rossi wrote:
> Usually adding the VTK library folder to the shared library path 
> (LD_LIBRARY_PATH or DYLD_LIBRARY_PATH depending on your system) would 
> solve this kind problem.
>
>
> On Sat, Mar 23, 2019, 5:56 PM Nikrouz <nik...@gm... 
> <mailto:nik...@gm...>> wrote:
>
>     Dear all,
>
>     I have configured libMesh for running unsteady cases.
>
>     I can compile the code of the example by make command but when I
>     run the
>     code I faced with an error:
>
>
>     ./example-opt: error while loading shared libraries:
>     libvtksys-8.2.so.1:
>     cannot open shared object file: No such file or directory
>
>     How can I solve the issue?
>
>     Thanks,
>
>
>
>     _______________________________________________
>     Libmesh-users mailing list
>     Lib...@li...
>     <mailto:Lib...@li...>
>     https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] Problem in linking vtk libraries

[Simone R. <sim...@gm...>]

Usually adding the VTK library folder to the shared library path
(LD_LIBRARY_PATH or DYLD_LIBRARY_PATH depending on your system) would solve
this kind problem.


On Sat, Mar 23, 2019, 5:56 PM Nikrouz <nik...@gm...> wrote:

> Dear all,
>
> I have configured libMesh for running unsteady cases.
>
> I can compile the code of the example by make command but when I run the
> code I faced with an error:
>
>
> ./example-opt: error while loading shared libraries: libvtksys-8.2.so.1:
> cannot open shared object file: No such file or directory
>
> How can I solve the issue?
>
> Thanks,
>
>
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

[Libmesh-users] Problem in linking vtk libraries

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

Dear all,

I have configured libMesh for running unsteady cases.

I can compile the code of the example by make command but when I run the 
code I faced with an error:


./example-opt: error while loading shared libraries: libvtksys-8.2.so.1: 
cannot open shared object file: No such file or directory

How can I solve the issue?

Thanks,

[Libmesh-users] Question about Newmark system

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

Dear LibMesh developers,

there is an example transient_ex2/transient_ex2.C where a wave equation 
is solved.

Could you, please, tell me how to modify this example if I need to have 
force that explicitly depends on time?

Thank you,

Michael.

[Libmesh-users] Question about nedelec elements

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

Dear Libmesh developers,

let me ask you a question about nedelec elements.

I'm solving a 2D problem. As far as I understand the nedelec elements 
are define for each edge of the finite element cell. Is it so?

If yes, is it possible to get the DOF number for a given edge?

Thank you,

Michael.

Re: [Libmesh-users] Syncing ghosting between two meshes

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

On Wed, 20 Mar 2019, Alexander Lindsay wrote:

> In MOOSE we often have two meshes, a reference (un-displaced) and a
> displaced mesh. We want to be able to sync ghosting between the two meshes.
> Currently I am running into issues when I am running a displaced problem
> with AMR.

IIRC I worked on something only slightly harder than this once, with
OversampleOutput.C, and gave up to work on more low-hanging fruit
first, which can't be a good sign.

> I first call the reference EquationSystems::reinit which coarsens,
> constricts the mesh, and then refines. Now when I call the displaced
> EquationSystems::reinit, during coarsening we call DofMap::distribute_dofs
> which calls through to our ghosting functors. We set up a proxy ghosting
> functor which essentially loops over the ghosting functors and elements of
> the reference mesh, determining what elements were ghosted on the reference
> mesh **and then** ghosts the corresponding element IDs on the displaced
> mesh. This works great except when we have AMR. The problem is that the
> mesh constriction of the reference mesh has deleted its inactive elements
> and then renumbered. We are calling distribute dofs on the displaced mesh
> **before** we've done the same constriction, so we have an out-of-sync
> correspondence between the reference and displaced element numbering.
>
> Does anyone have a suggestion for a good solution here? What's the best way
> to sync_ghosting()?

I'm not sure what the best way is, but let me think...

Doesn't MOOSE already require unique_id support enabled?  If so then
it wouldn't cost anything extra to keep your corresponding elements
mapped to each other by unique_id() and forget about shifting id()
numbers.

Even without unique_id support you can always (locally) use Elem* to
uniquely identify an element... but the trouble here is that element
deletion (including through coarsening) invalidates any such map.
Perhaps you could do a trick we use when syncing mid-refinement data,
and identify elements via a pointer to the *parent* element plus a
short int for which child of that parent they are?

Except that would *only* work for the removal of elements remoted by
AMR, not repartitioning ... and it would even leave dangling pointers
in some AMR cases, just not in the case where elements were
disappeared by coarsening.  If you refine an element and you only own
its child(ren) on one side then you can end up remoting *all* elements
adjacent to the other side, straight up the hierarchy.  I guess you'll
never be *asked* for a map lookup leading the elements that have been
remoted, but having dangling pointers floating around still terrifies
me.

Would it make sense to combine the parent+child_number lookup with a
delayed delete_remote_elements() behavior?  You could always turn off
automatic deletion of remote elements, then call it manually, on the
displaced mesh *before* the original mesh, after mesh modification
operations.
---
Roy

Re: [Libmesh-users] Syncing ghosting between two meshes

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

One blue-sky idea is this:

We currently have different EquationSystems corresponding to the different
meshes. These EquationSystems object typically contain two Systems, a
non-linear and an auxiliary. Conceptually the reference and displaced
Systems should have the same data in their vectors...we currently do work
to make sure they are synced over the course of our computation. Perhaps we
should just have a single EquationSystems object...and then we wouldn't
have to worry about maintaining consistent ghosting between reference and
displaced vectors because we would just have the one set of vectors.

This is attractive to me conceptually, but this would require an overhaul
of the MOOSE code base.


On Wed, Mar 20, 2019 at 5:45 PM Alexander Lindsay <ale...@gm...>
wrote:

> In MOOSE we often have two meshes, a reference (un-displaced) and a
> displaced mesh. We want to be able to sync ghosting between the two meshes.
> Currently I am running into issues when I am running a displaced problem
> with AMR.
>
> I first call the reference EquationSystems::reinit which coarsens,
> constricts the mesh, and then refines. Now when I call the displaced
> EquationSystems::reinit, during coarsening we call DofMap::distribute_dofs
> which calls through to our ghosting functors. We set up a proxy ghosting
> functor which essentially loops over the ghosting functors and elements of
> the reference mesh, determining what elements were ghosted on the reference
> mesh **and then** ghosts the corresponding element IDs on the displaced
> mesh. This works great except when we have AMR. The problem is that the
> mesh constriction of the reference mesh has deleted its inactive elements
> and then renumbered. We are calling distribute dofs on the displaced mesh
> **before** we've done the same constriction, so we have an out-of-sync
> correspondence between the reference and displaced element numbering.
>
> Does anyone have a suggestion for a good solution here? What's the best
> way to sync_ghosting()?
>

Re: [Libmesh-users] question about FEMContext

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

Thank you, John,

at least now we are on the same page.

Let me tell you what I'm doing, and hopefully you can suggest an effective way without using protected methods.

I'm solving a Newmark system with vector finite elements (Nedelec elements).

I need to compute solution, curl of the solution and derivative over time of the solution at a specific set of points for every time step.

To do so I pre-compute local coordinates of the points, then I do something like this:

 FEGenericBase<RealGradient>* fe_new = fecontext.cached_fe<RealGradient>(elem->dim(), fe_type);
 fe_new->reinit (elem, &(local_points));

After this I have access to fe_new->get_phi() and can compute all what I need.

What would you suggest?

Thank you,

Michael.

On 3/21/2019 9:08 AM, John Peterson wrote:


On Thu, Mar 21, 2019 at 7:59 AM John Peterson <jwp...@gm...<mailto:jwp...@gm...>> wrote:


On Wed, Mar 20, 2019 at 11:47 PM Povolotskyi, Mykhailo <mpo...@pu...<mailto:mpo...@pu...>> wrote:
Dear LibMesh developers,

in the documentation http://libmesh.github.io/doxygen/classlibMesh_1_1FEMContext.html#ab308f0ea12c91d002e896e0217d3c3c9


the method cached_fe is public.

In the release 1.4.0 it is protected.

Your link doesn't go to the cached_fe() implementation for me, and as far as I can tell, the cached_fe() interface was added as a protected member function in this commit:

commit 6a9f9060f5596085b9801c5caeafc4d19d1fc54a
Author: Roy H. Stogner <roy...@ic...<mailto:roy...@ic...>>
Date:   Mon Oct 2 12:59:34 2017 -0500

    Cache FEMContext::point_value() FE Objects

    This really ought to be redone entirely, but hopefully we can get a
    little performance improvement right away by just avoiding de and
    reallocations.

and it's never been public.

OK, after scrolling up, it looks like cached_fe does show up among the other public APIs in doxygen:

https://drive.google.com/file/d/1JqJCROKxhsU084JPgShsIY6haCKUzP2G/view?usp=sharing

but I'd chalk that up to a bug in Doxygen... this function has always been protected AFAICT.

--
John

Re: [Libmesh-users] question about FEMContext

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

On Thu, Mar 21, 2019 at 8:17 AM Povolotskyi, Mykhailo <mpo...@pu...>
wrote:

> Thank you, John,
>
> at least now we are on the same page.
>
> Let me tell you what I'm doing, and hopefully you can suggest an effective
> way without using protected methods.
>
> I'm solving a Newmark system with vector finite elements (Nedelec
> elements).
>
> I need to compute solution, curl of the solution and derivative over time
> of the solution at a specific set of points for every time step.
>
> To do so I pre-compute local coordinates of the points, then I do
> something like this:
>
>  FEGenericBase<RealGradient>* fe_new =
> fecontext.cached_fe<RealGradient>(elem->dim(), fe_type);
>  fe_new->reinit (elem, &(local_points));
>
> After this I have access to fe_new->get_phi() and can compute all what I
> need.
>
> What would you suggest?
>

Would one of the various public get_element_fe() APIs in FEMContext not
work for your case?

-- 
John

Re: [Libmesh-users] question about FEMContext

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

On Thu, Mar 21, 2019 at 7:59 AM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Mar 20, 2019 at 11:47 PM Povolotskyi, Mykhailo <
> mpo...@pu...> wrote:
>
>> Dear LibMesh developers,
>>
>> in the documentation
>> http://libmesh.github.io/doxygen/classlibMesh_1_1FEMContext.html#ab308f0ea12c91d002e896e0217d3c3c9
>>
>>
>> the method cached_fe is public.
>>
>> In the release 1.4.0 it is protected.
>>
>
> Your link doesn't go to the cached_fe() implementation for me, and as far
> as I can tell, the cached_fe() interface was added as a protected member
> function in this commit:
>
> commit 6a9f9060f5596085b9801c5caeafc4d19d1fc54a
> Author: Roy H. Stogner <roy...@ic...>
> Date:   Mon Oct 2 12:59:34 2017 -0500
>
>     Cache FEMContext::point_value() FE Objects
>
>     This really ought to be redone entirely, but hopefully we can get a
>     little performance improvement right away by just avoiding de and
>     reallocations.
>
> and it's never been public.
>

OK, after scrolling up, it looks like cached_fe does show up among the
other public APIs in doxygen:

https://drive.google.com/file/d/1JqJCROKxhsU084JPgShsIY6haCKUzP2G/view?usp=sharing

but I'd chalk that up to a bug in Doxygen... this function has always been
protected AFAICT.

-- 
John

Re: [Libmesh-users] question about FEMContext

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

On Wed, Mar 20, 2019 at 11:47 PM Povolotskyi, Mykhailo <mpo...@pu...>
wrote:

> Dear LibMesh developers,
>
> in the documentation
> http://libmesh.github.io/doxygen/classlibMesh_1_1FEMContext.html#ab308f0ea12c91d002e896e0217d3c3c9
>
>
> the method cached_fe is public.
>
> In the release 1.4.0 it is protected.
>

Your link doesn't go to the cached_fe() implementation for me, and as far
as I can tell, the cached_fe() interface was added as a protected member
function in this commit:

commit 6a9f9060f5596085b9801c5caeafc4d19d1fc54a
Author: Roy H. Stogner <roy...@ic...>
Date:   Mon Oct 2 12:59:34 2017 -0500

    Cache FEMContext::point_value() FE Objects

    This really ought to be redone entirely, but hopefully we can get a
    little performance improvement right away by just avoiding de and
    reallocations.

and it's never been public.

-- 
John

[Libmesh-users] question about FEMContext

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

Dear LibMesh developers,

in the documentation http://libmesh.github.io/doxygen/classlibMesh_1_1FEMContext.html#ab308f0ea12c91d002e896e0217d3c3c9


the method cached_fe is public.

In the release 1.4.0 it is protected.

What are you plans: are you going to keep it public or protected?


Currently I use it as public by manually editing the header file.

So I would prefer to have it public.

Thank you,

Michael.