libmesh-users — General information for libmesh users

Re: [Libmesh-users] Are there QBC, non-homogeneous BC, essential BC by modifying equations?

[edgar <edg...@cr...>]

On 2021-05-05 20:02, John Peterson wrote:
> Hi Edgar,
> 
> Sorry for not responding, your email got kind of lost in my inbox.

Not at all. Thank you very much. I can only imagine how busy you are :) 
.

> 
> LibMesh does support penalty BCs, some examples which use penalty BCs
> are: adjoints_ex1,2,4; adaptivity_ex1,2,4. It sounds like you may be
> interested in DirichletBoundary objects, which impose the BCs as
> user-defined constraints. Examples using DirichletBoundary objects are:
> adaptivity_ex3; adjoints_ex5,6,7; fem_system_ex1,3,4. The 
> implementation of
> DirichletBoundary objects corresponds to the description you gave in 
> your
> original email about modifying the matrix and rhs.
> 

This is super useful. Thanks!

Re: [Libmesh-users] Are there QBC, non-homogeneous BC, essential BC by modifying equations?

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

Hi Edgar,

Sorry for not responding, your email got kind of lost in my inbox.

LibMesh does support penalty BCs, some examples which use penalty BCs
are: adjoints_ex1,2,4; adaptivity_ex1,2,4. It sounds like you may be
interested in DirichletBoundary objects, which impose the BCs as
user-defined constraints. Examples using DirichletBoundary objects are:
adaptivity_ex3; adjoints_ex5,6,7; fem_system_ex1,3,4. The implementation of
DirichletBoundary objects corresponds to the description you gave in your
original email about modifying the matrix and rhs.

--
John


On Wed, May 5, 2021 at 2:50 PM edgar <edg...@cr...> wrote:

> Nevermind. I found this [1]:
>
>      - Cons of this approach :
>        - Works for an interpolary finite element basis but not in
> general.
>        - May be inefficient to change individual entries once the global
> matrix is assembled.
>      - Need to enforce boundary conditions for a generic finite element
> basis at the element stiffness matrix level.
>
> [1]
>
> https://users.oden.utexas.edu/~roystgnr/libmeshpdfs/roystgnr/sandia_libmesh.pdf
>
> On 2021-04-24 05:14, edgar wrote:
> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >                       ARE THERE QBC, NON-HOMOGENEOUS
> >                 BC, ESSENTIAL BC BY MODIFYING EQUATIONS?
> >            ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >
> >
> > Hello busy developers and scientists! I’ll try to make it short.
> >
> > [Logan12] calls them /nonhomogeneous boundary conditions/ (BC),
> > [Ashgar05] refers to them as /essential boundary conditions by
> > modifying
> > equations/ and I am sure that some people call them qualifying boundary
> > conditions (who?).
> >
> > The procedure consists, for example, from a 1D system like this (2
> > elements, 3 nodes), where nodes 1 (n1) and 3 (n3) have an imposed value
> > of f and node 2 (n2) has essential (Dirichlet) BC. The global matrix of
> > the system would be like this
> >
> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >  [ k_{1,1}  k_{1,2}  k_{1,3} ]     [ u_{1} ]     [ f_{1} ]
> >  [ k_{2,1}  k_{2,2}  k_{2,3} ]  ·  [ u_{2} ]  =  [ f_{2} ]
> >  [ k_{3,1}  k_{3,2}  k_{3,3} ]     [ u_{3} ]     [ f_{3} ]
> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >
> > The above mentioned procedure does this [Ashgar05]:
> >       (i) Insert 1 at the diagonal location and zero at all
> >       off-diagonal locations in the row corresponding to the
> >       specified degree of freedom.
> >
> >       (ii) Insert the known nodal value to the corresponding
> >       location in the right-hand side.
> >
> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >  [ k_{1,1}  0  k_{1,3} ]     [ u_{1} ]     [ f_{1} ]
> >  [    0     1     0    ]  ·  [ u_{2} ]  =  [  Δ{u} ]
> >  [ k_{3,1}  0  k_{3,3} ]     [ u_{3} ]     [ f_{3} ]
> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >
> > I read that libMesh solves equations with a penalty method [CMISS,
> > hooshi]. Does it also apply the method described above?
> >
> > That’s it. Thanks!
> >
> >
> >
> > [Logan05] Daryl L. Logan, A first course in the finite element method,
> > (2012), Cengage Learning, Stanford, CT, U.S.A.
> >
> > [Ashgar05] M. Ashgar Bhatti, Fundamental finite element analysis and
> > applications: with mathematica and matlab computations (2005), John
> > Wiley \& Sons.
> >
> > [CMISS]
> > <https://www.cmiss.org/openCMISS/wiki/LibmeshBoundaryConditions>
> >
> > [hooshi] <https://hooshi.gitlab.io/FILES/math521_libmesh.pdf>
>

Re: [Libmesh-users] Are there QBC, non-homogeneous BC, essential BC by modifying equations?

[edgar <edg...@cr...>]

Nevermind. I found this [1]:

     - Cons of this approach :
       - Works for an interpolary finite element basis but not in 
general.
       - May be inefficient to change individual entries once the global 
matrix is assembled.
     - Need to enforce boundary conditions for a generic finite element 
basis at the element stiffness matrix level.

[1] 
https://users.oden.utexas.edu/~roystgnr/libmeshpdfs/roystgnr/sandia_libmesh.pdf

On 2021-04-24 05:14, edgar wrote:
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>                       ARE THERE QBC, NON-HOMOGENEOUS
>                 BC, ESSENTIAL BC BY MODIFYING EQUATIONS?
>            ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> 
> 
> Hello busy developers and scientists! I’ll try to make it short.
> 
> [Logan12] calls them /nonhomogeneous boundary conditions/ (BC),
> [Ashgar05] refers to them as /essential boundary conditions by 
> modifying
> equations/ and I am sure that some people call them qualifying boundary
> conditions (who?).
> 
> The procedure consists, for example, from a 1D system like this (2
> elements, 3 nodes), where nodes 1 (n1) and 3 (n3) have an imposed value
> of f and node 2 (n2) has essential (Dirichlet) BC. The global matrix of
> the system would be like this
> 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>  [ k_{1,1}  k_{1,2}  k_{1,3} ]     [ u_{1} ]     [ f_{1} ]
>  [ k_{2,1}  k_{2,2}  k_{2,3} ]  ·  [ u_{2} ]  =  [ f_{2} ]
>  [ k_{3,1}  k_{3,2}  k_{3,3} ]     [ u_{3} ]     [ f_{3} ]
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> 
> The above mentioned procedure does this [Ashgar05]:
>       (i) Insert 1 at the diagonal location and zero at all
>       off-diagonal locations in the row corresponding to the
>       specified degree of freedom.
> 
>       (ii) Insert the known nodal value to the corresponding
>       location in the right-hand side.
> 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>  [ k_{1,1}  0  k_{1,3} ]     [ u_{1} ]     [ f_{1} ]
>  [    0     1     0    ]  ·  [ u_{2} ]  =  [  Δ{u} ]
>  [ k_{3,1}  0  k_{3,3} ]     [ u_{3} ]     [ f_{3} ]
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> 
> I read that libMesh solves equations with a penalty method [CMISS,
> hooshi]. Does it also apply the method described above?
> 
> That’s it. Thanks!
> 
> 
> 
> [Logan05] Daryl L. Logan, A first course in the finite element method,
> (2012), Cengage Learning, Stanford, CT, U.S.A.
> 
> [Ashgar05] M. Ashgar Bhatti, Fundamental finite element analysis and
> applications: with mathematica and matlab computations (2005), John
> Wiley \& Sons.
> 
> [CMISS] 
> <https://www.cmiss.org/openCMISS/wiki/LibmeshBoundaryConditions>
> 
> [hooshi] <https://hooshi.gitlab.io/FILES/math521_libmesh.pdf>

Re: [Libmesh-users] _ss_id_to_name works for Gmsh

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

On Wed, Apr 28, 2021 at 5:45 PM edgar <edg...@cr...> wrote:

> Dear all,
>
> I know that some times, the documentation is hard to maintain, and you
> may already know what I will tell you now. I just wanted to let you know
> that `_ss_id_to_name' (from `BoundaryInfo') works on a mesh that I
> created with physical groups in Gmsh. This code
>
> ┌────
> │ for (std::string &gtpt_boundary_name :
> │      gtpt_boundary_names) {
> │     std::cout << "Boundary name: " << gtpt_boundary_name
> │               << "  id: "
> │               << my_mesh_boundaries.get_id_by_name (
> │                    gtpt_boundary_name)
> │               << std::endl;
> │ }
> └────
>
> produces
>
> ┌────
> │ Boundary name: left  id: 4
> │ Boundary name: back  id: 3
> │ Boundary name: bottom  id: 2
> │ Boundary name: top  id: 5
> └────
>
> Needless to say that `gtpt_boundary_names' holds a series of strings
> with boundary names and `my_mesh_boundaries' is a
> `libMesh::BoundaryInfo' object. The documentation states:
>
>        Currently this is only implemented for ExodusII
>
> Just trying to help. Please, don't get mad at me.
>

Thanks for your report, I updated the docs in libmesh fe33016c4.

-- 
John

Re: [Libmesh-users] GetPot interface with UTF-8?

[edgar <edg...@cr...>]

Thanks, John.

On 2021-04-30 17:53, John Peterson wrote:
> Yeah, I think you've pretty well shown that GetPot only supports ASCII
> files.

I just wanted to make sure that I wasn't missing something. I was not 
nit-picking.

> I actually don't know how hard it would be to generalize it to use
> wchar or something, but the next problem would be that libmesh itself 
> uses
> only std::strings everywhere, so updating GetPot would likely only be 
> the
> tip of the iceberg of changes that would be required to fully support 
> UTF-8.

I think that these kind of things are cumbersome enough to avoid them.

I know that I send a ton of e-mails every week. Thank you for your 
patience. I promise that there will come a moment when my questions are 
more relevant. I am just getting used to libMesh.

Re: [Libmesh-users] GetPot interface with UTF-8?

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

On Thu, Apr 29, 2021 at 4:50 PM edgar <edg...@cr...> wrote:

> Dear list,
>
> I noticed that if I have a GetPot file such as:
>
> ┌────
> │ [./ó]
> │     val = 1
> │ [../]
> └────
>
> , that my program would crash. As soon as I change `ó' by `o', it works
> fine. This makes me think that the crash arises because of this line in
> getpot.h
>
> ┌────
> │ str += getpot_cast_int<char>(tmp);
> └────
>
> which is #define'd in getpot.h
>
> ┌────
> | #define getpot_cast_int libMesh::cast_int
> └────
>
> and goes back to libmesh_common.h
>
> ┌────
> │ template <typename Tnew, typename Told>
> │ inline Tnew cast_int (Told oldvar)
> │ {
> │   libmesh_assert_equal_to
> │     (oldvar, static_cast<Told>(static_cast<Tnew>(oldvar)));
> │
> │   return(static_cast<Tnew>(oldvar));
> │ }
> └────
>
> It seems that only int-equivalent (i.e. 8-bit) characters are allowed in
> the GetPot file, is that correct? Is there support for UTF-x? (x: a
> number base, e.g. 8, 16, etc.)
>

Yeah, I think you've pretty well shown that GetPot only supports ASCII
files. I actually don't know how hard it would be to generalize it to use
wchar or something, but the next problem would be that libmesh itself uses
only std::strings everywhere, so updating GetPot would likely only be the
tip of the iceberg of changes that would be required to fully support UTF-8.

-- 
John

[Libmesh-users] GetPot interface with UTF-8?

[edgar <edg...@cr...>]

Dear list,

I noticed that if I have a GetPot file such as:

┌────
│ [./ó]
│     val = 1
│ [../]
└────

, that my program would crash. As soon as I change `ó' by `o', it works 
fine. This makes me think that the crash arises because of this line in 
getpot.h

┌────
│ str += getpot_cast_int<char>(tmp);
└────

which is #define'd in getpot.h

┌────
| #define getpot_cast_int libMesh::cast_int
└────

and goes back to libmesh_common.h

┌────
│ template <typename Tnew, typename Told>
│ inline Tnew cast_int (Told oldvar)
│ {
│   libmesh_assert_equal_to
│     (oldvar, static_cast<Told>(static_cast<Tnew>(oldvar)));
│
│   return(static_cast<Tnew>(oldvar));
│ }
└────

It seems that only int-equivalent (i.e. 8-bit) characters are allowed in 
the GetPot file, is that correct? Is there support for UTF-x? (x: a 
number base, e.g. 8, 16, etc.)

[Libmesh-users] _ss_id_to_name works for Gmsh

[edgar <edg...@cr...>]

Dear all,

I know that some times, the documentation is hard to maintain, and you 
may already know what I will tell you now. I just wanted to let you know 
that `_ss_id_to_name' (from `BoundaryInfo') works on a mesh that I 
created with physical groups in Gmsh. This code

┌────
│ for (std::string &gtpt_boundary_name :
│      gtpt_boundary_names) {
│     std::cout << "Boundary name: " << gtpt_boundary_name
│               << "  id: "
│               << my_mesh_boundaries.get_id_by_name (
│                    gtpt_boundary_name)
│               << std::endl;
│ }
└────

produces

┌────
│ Boundary name: left  id: 4
│ Boundary name: back  id: 3
│ Boundary name: bottom  id: 2
│ Boundary name: top  id: 5
└────

Needless to say that `gtpt_boundary_names' holds a series of strings 
with boundary names and `my_mesh_boundaries' is a 
`libMesh::BoundaryInfo' object. The documentation states:

       Currently this is only implemented for ExodusII

Just trying to help. Please, don't get mad at me.

[Libmesh-users] Are there QBC, non-homogeneous BC, essential BC by modifying equations?

[edgar <edg...@cr...>]

            ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                       ARE THERE QBC, NON-HOMOGENEOUS
                 BC, ESSENTIAL BC BY MODIFYING EQUATIONS?
            ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


Hello busy developers and scientists! I’ll try to make it short.

[Logan12] calls them /nonhomogeneous boundary conditions/ (BC),
[Ashgar05] refers to them as /essential boundary conditions by modifying
equations/ and I am sure that some people call them qualifying boundary
conditions (who?).

The procedure consists, for example, from a 1D system like this (2
elements, 3 nodes), where nodes 1 (n1) and 3 (n3) have an imposed value
of f and node 2 (n2) has essential (Dirichlet) BC. The global matrix of
the system would be like this

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  [ k_{1,1}  k_{1,2}  k_{1,3} ]     [ u_{1} ]     [ f_{1} ]
  [ k_{2,1}  k_{2,2}  k_{2,3} ]  ·  [ u_{2} ]  =  [ f_{2} ]
  [ k_{3,1}  k_{3,2}  k_{3,3} ]     [ u_{3} ]     [ f_{3} ]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The above mentioned procedure does this [Ashgar05]:
       (i) Insert 1 at the diagonal location and zero at all
       off-diagonal locations in the row corresponding to the
       specified degree of freedom.

       (ii) Insert the known nodal value to the corresponding
       location in the right-hand side.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  [ k_{1,1}  0  k_{1,3} ]     [ u_{1} ]     [ f_{1} ]
  [    0     1     0    ]  ·  [ u_{2} ]  =  [  Δ{u} ]
  [ k_{3,1}  0  k_{3,3} ]     [ u_{3} ]     [ f_{3} ]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

I read that libMesh solves equations with a penalty method [CMISS,
hooshi]. Does it also apply the method described above?

That’s it. Thanks!



[Logan05] Daryl L. Logan, A first course in the finite element method,
(2012), Cengage Learning, Stanford, CT, U.S.A.

[Ashgar05] M. Ashgar Bhatti, Fundamental finite element analysis and
applications: with mathematica and matlab computations (2005), John
Wiley \& Sons.

[CMISS] <https://www.cmiss.org/openCMISS/wiki/LibmeshBoundaryConditions>

[hooshi] <https://hooshi.gitlab.io/FILES/math521_libmesh.pdf>

Re: [Libmesh-users] Rotation of coordinates in Tet face

[Renato P. <re...@gm...>]

Sure!

That is exactly what I needed.
Thank you very much.

Renato

Em qui, 22 de abr de 2021 15:27, John Peterson <jwp...@gm...>
escreveu:

>
>
> On Thu, Apr 22, 2021 at 1:11 PM Renato Poli <re...@gm...> wrote:
>
>> Thanks John,
>>
>> What would be the straightforward way to append normals and tangents in a
>> single tensor?
>> The idea is to define them as a base so I can operate and iterate.
>>
>
> It just depends on what data structure you want to use for the tensor. For
> example, you could use the libmesh RealTensorValue class which has a
> constructor taking 3 Points as rows:
>
> auto T = RealTensorValue(n, t1, t2).transpose();
>
> (This may or may not compile, hopefully you get the idea.)
>
> --
> John
>

Re: [Libmesh-users] Rotation of coordinates in Tet face

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

On Thu, Apr 22, 2021 at 1:11 PM Renato Poli <re...@gm...> wrote:

> Thanks John,
>
> What would be the straightforward way to append normals and tangents in a
> single tensor?
> The idea is to define them as a base so I can operate and iterate.
>

It just depends on what data structure you want to use for the tensor. For
example, you could use the libmesh RealTensorValue class which has a
constructor taking 3 Points as rows:

auto T = RealTensorValue(n, t1, t2).transpose();

(This may or may not compile, hopefully you get the idea.)

-- 
John

Re: [Libmesh-users] Rotation of coordinates in Tet face

[Renato P. <re...@gm...>]

Thanks John,

What would be the straightforward way to append normals and tangents in a
single tensor?
The idea is to define them as a base so I can operate and iterate.

rgds,
Renato

On Thu, Apr 22, 2021 at 10:21 AM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Apr 21, 2021 at 10:39 AM Renato Poli <re...@gm...> wrote:
>
>> Hello,
>>
>> I am willing to make a coordinate rotation on a Tet face to calculate
>> normal and tangent displacements between discontinuous elements.
>>
>> As I understand, I need a transformation matrix gathering normal and
>> tangents to define a local coordinate system:
>> T_ij = [ nx_i ns_i nt_i ]
>>
>> I can see all the calculations are there, but I am not sure what is the
>> most elegant/usual way to get such matrix in libmesh.
>>
>> Any suggestion? Any documentation pointer would be helpful!
>>
>
> See FEAbstract::get_normals() and get_tangents() in
> include/fe/fe_abstract.h. These call the corresponding functions on FEMap.
> Similarly to the other "get_" interfaces on FE, the values are computed at
> quadrature points, so you would need to reinit a "side" FE after
> pre-requesting these values, similarly to what is done in
> systems_of_equations_ex4, for example.
>
> --
> John
>

Re: [Libmesh-users] Rotation of coordinates in Tet face

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

On Wed, Apr 21, 2021 at 10:39 AM Renato Poli <re...@gm...> wrote:

> Hello,
>
> I am willing to make a coordinate rotation on a Tet face to calculate
> normal and tangent displacements between discontinuous elements.
>
> As I understand, I need a transformation matrix gathering normal and
> tangents to define a local coordinate system:
> T_ij = [ nx_i ns_i nt_i ]
>
> I can see all the calculations are there, but I am not sure what is the
> most elegant/usual way to get such matrix in libmesh.
>
> Any suggestion? Any documentation pointer would be helpful!
>

See FEAbstract::get_normals() and get_tangents() in
include/fe/fe_abstract.h. These call the corresponding functions on FEMap.
Similarly to the other "get_" interfaces on FE, the values are computed at
quadrature points, so you would need to reinit a "side" FE after
pre-requesting these values, similarly to what is done in
systems_of_equations_ex4, for example.

-- 
John

[Libmesh-users] Rotation of coordinates in Tet face

[Renato P. <re...@gm...>]

Hello,

I am willing to make a coordinate rotation on a Tet face to calculate
normal and tangent displacements between discontinuous elements.

As I understand, I need a transformation matrix gathering normal and
tangents to define a local coordinate system:
T_ij = [ nx_i ns_i nt_i ]

I can see all the calculations are there, but I am not sure what is the
most elegant/usual way to get such matrix in libmesh.

Any suggestion? Any documentation pointer would be helpful!

Thanks upfront,
Renato

Re: [Libmesh-users] (no subject)

[Jahrul A. <al...@mu...>]

Hi, John
I have the following error if I compile libmesh using openmpi. I am
reposting it because this time it is different from what I posted earlier
(sorry, it did not go to libmesh-users). I have the same petsc as mentioned
in the previous post.

../configure --prefix=/opt/libmesh/1.7.0 --with-cxx=mpicxx --enable-parmesh
--disable-tecio --disable-fparser --with-mpi=/usr/lib64/openmpi/bin/
gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2)



CXXLD    fparser_parse-opt
/usr/bin/ld: warning: libmpi.so.40, needed by
/autofs/awcm/shared/awcm++/libs/libmesh/build-mpi/contrib/timpi/src/.libs/libtimpi_opt.so,
may conflict with libmpi.so.12
/usr/bin/ld: warning: libmpi.so.40, needed by
/autofs/awcm/shared/awcm++/libs/libmesh/build-mpi/contrib/timpi/src/.libs/libtimpi_opt.so,
may conflict with libmpi.so.12
/usr/bin/ld: ./.libs/libmesh_opt.so: undefined reference to
`TIMPI::Communicator::Communicator(int const&)'
/usr/bin/ld: ./.libs/libmesh_opt.so: undefined reference to
`TIMPI::Request::Request(int const&)'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:13545: fparser_parse-opt] Error 1
make[1]: Leaving directory
'/autofs/awcm/shared/awcm++/libs/libmesh/build-mpi'
make: *** [Makefile:32158: all-recursive] Error 1

=====================================
Jahrul Alam, PhD
Associate Professor, Dept of Mathematics and Statistics
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3054, Tel: 709-864 8071
=====================================


On Mon, Apr 5, 2021 at 1:36 PM Jahrul Alam <al...@mu...> wrote:

>
> Hi John
> Compiling with intel 2020, I get the posted error (regardless of 1.6.0,
> 1.6.1, 1.7.0_pre). With intel 2020, I was able to compile libMesh-1.7.0_pre
> without PETSc, where I have PETSc 3.14.1.
>
> On a different workstation, I have Fedora 31,  gcc 9.3.1 and PETSC 3.9.x.
> Here, I have a different error regarding TIMPI (I have posted earlier, see
> below).
>
> I did a "git clone petsc" to get fresh petsc on my fedora box, and
> /configure --with-cc=gcc --with-cxx=g++ --with-fc=gfortran --download-mpich
> --download-fblaslapack.
>
> I now configure libmes (note the choice of mpicxx download with petsc)
> build]$ ../configure --prefix=/opt/libmesh/1.7.0
> --with-cxx=/autofs/awcm/shared/awcm++/libs/petsc/arch-linux-c-debug/bin/mpicxx
>
> Can you check if the auto pointer in parallel_algebra needs to be improved
> to make it compiler friendly. This line 218 gave me some hard time, but it
> is fixed in my case.
>
> Previous error with TIMPI:
>
> In file included from ../src/base/dof_map_constraints.C:39:
>
> ./include/libmesh/parallel_algebra.h: In constructor ‘TIMPI::StandardType<libMesh::Point>::StandardType(const
> libMesh::Point*)’:
>
> ./include/libmesh/parallel_algebra.h:218:34: error: cannot convert ‘TIMPI::StandardType<double>’
> to ‘MPI_Datatype’ {aka ‘ompi_datatype_t*’} in initialization
>
>   218 |     MPI_Datatype tmptype, type = T_type;
>
>
>
> =====================================
> Jahrul Alam, PhD
> Associate Professor, Dept of Mathematics and Statistics
> Memorial University, St John's, NL, Canada
> http://www.math.mun.ca/~alamj/
> eMail: al...@mu...
> Office: HH-3054, Tel: 709-864 8071
> =====================================
>
>
> On Mon, Apr 5, 2021 at 11:22 AM John Peterson <jwp...@gm...>
> wrote:
>
>> Hi,
>>
>> There was a somewhat recent discussion about this issue on #2565 and
>> #2827,
>> but as far as I know, it was never satisfactorily resolved at that time,
>> otherwise the update would presumably have made it into 1.6.1.
>>
>> Jahrul, just to confirm, are you saying that libmesh master works for you
>> with Intel 18 (or newer) compilers? Also, if I understand correctly, you
>> had to update PETSc as well? Can you let us know what version of PETSc you
>> used?
>>
>> --
>> John
>>
>>
>> On Sun, Apr 4, 2021 at 11:54 AM Jahrul Alam <al...@mu...> wrote:
>>
>> > I have a similar error with 1.6.1.tar.gz. Using git, I get 1.7.0_pre,
>> and
>> > following is the error. Now, I have done a fresh installation of latest
>> > PETSc, configured libmesh using
>> > --with-cxx=/path/to/petsc/arch-linux-c-debug/bin/mpicxx, everything
>> else is
>> > as before, libmesh compiled smoothly with no error.
>> >
>> >
>> >  CXX      src/base/libmesh_opt_la-dirichlet_boundary.lo
>> > In file included from ./include/libmesh/fe_base.h(26),
>> >                  from ./include/libmesh/fem_context.h(27),
>> >                  from ./include/libmesh/fem_function_base.h(26),
>> >                  from ./include/libmesh/composite_fem_function.h(23),
>> >                  from ../src/base/dirichlet_boundary.C(25):
>> > ./include/libmesh/fe_abstract.h(491): error: more than one operator "+"
>> > matches these operands:
>> >             built-in operator "arithmetic + arithmetic"
>> >             function "operator+(const PetscInt={int} &, const
>> PetscComplex
>> > &)"
>> >             operand types are: const libMesh::OrderWrapper + const
>> unsigned
>> > int
>> >     Order get_order()  const { return static_cast<Order>(fe_type.order +
>> > _p_level); }
>> >                                                                        ^
>> >
>> > make[1]: *** [Makefile:25279:
>> > src/base/libmesh_opt_la-dirichlet_boundary.lo] Error 1
>> >
>> >
>> >
>> >
>> > =====================================
>> > Jahrul Alam, PhD
>> > Memorial University, St John's, NL, Canada
>> > http://www.math.mun.ca/~alamj/
>> > eMail: al...@mu...
>> > Office: HH-3054, Tel: 709-864 8071
>> > =====================================
>> >
>> >
>> > On Sun, Apr 4, 2021 at 12:15 PM Charles Puelz <cha...@gm...>
>> > wrote:
>> >
>> > > I am having an issue building 1.6.1 on TACC with the intel compilers
>> > > (18.0.2)
>> > >
>> > > I am getting this error:
>> > >
>> > > ./include/libmesh/fe_abstract.h(443): error: more than one operator
>> "+"
>> > > matches these operands:
>> > >             built-in operator "arithmetic + arithmetic"
>> > >             function "operator+(const PetscInt={int} &, const
>> > PetscComplex
>> > > &)"
>> > >             operand types are: const libMesh::OrderWrapper + const
>> > unsigned
>> > > int
>> > >     Order get_order()  const { return
>> static_cast<Order>(fe_type.order +
>> > > _p_level); }
>> > >
>> > > I've attached my configure log file.  Any thoughts?
>> > >
>> > > Thanks!
>> > >
>> > > -- Charles
>> >
>> >
>>
>> _______________________________________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>

Re: [Libmesh-users] (no subject)

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

Hi,

There was a somewhat recent discussion about this issue on #2565 and #2827,
but as far as I know, it was never satisfactorily resolved at that time,
otherwise the update would presumably have made it into 1.6.1.

Jahrul, just to confirm, are you saying that libmesh master works for you
with Intel 18 (or newer) compilers? Also, if I understand correctly, you
had to update PETSc as well? Can you let us know what version of PETSc you
used?

--
John


On Sun, Apr 4, 2021 at 11:54 AM Jahrul Alam <al...@mu...> wrote:

> I have a similar error with 1.6.1.tar.gz. Using git, I get 1.7.0_pre, and
> following is the error. Now, I have done a fresh installation of latest
> PETSc, configured libmesh using
> --with-cxx=/path/to/petsc/arch-linux-c-debug/bin/mpicxx, everything else is
> as before, libmesh compiled smoothly with no error.
>
>
>  CXX      src/base/libmesh_opt_la-dirichlet_boundary.lo
> In file included from ./include/libmesh/fe_base.h(26),
>                  from ./include/libmesh/fem_context.h(27),
>                  from ./include/libmesh/fem_function_base.h(26),
>                  from ./include/libmesh/composite_fem_function.h(23),
>                  from ../src/base/dirichlet_boundary.C(25):
> ./include/libmesh/fe_abstract.h(491): error: more than one operator "+"
> matches these operands:
>             built-in operator "arithmetic + arithmetic"
>             function "operator+(const PetscInt={int} &, const PetscComplex
> &)"
>             operand types are: const libMesh::OrderWrapper + const unsigned
> int
>     Order get_order()  const { return static_cast<Order>(fe_type.order +
> _p_level); }
>                                                                        ^
>
> make[1]: *** [Makefile:25279:
> src/base/libmesh_opt_la-dirichlet_boundary.lo] Error 1
>
>
>
>
> =====================================
> Jahrul Alam, PhD
> Memorial University, St John's, NL, Canada
> http://www.math.mun.ca/~alamj/
> eMail: al...@mu...
> Office: HH-3054, Tel: 709-864 8071
> =====================================
>
>
> On Sun, Apr 4, 2021 at 12:15 PM Charles Puelz <cha...@gm...>
> wrote:
>
> > I am having an issue building 1.6.1 on TACC with the intel compilers
> > (18.0.2)
> >
> > I am getting this error:
> >
> > ./include/libmesh/fe_abstract.h(443): error: more than one operator "+"
> > matches these operands:
> >             built-in operator "arithmetic + arithmetic"
> >             function "operator+(const PetscInt={int} &, const
> PetscComplex
> > &)"
> >             operand types are: const libMesh::OrderWrapper + const
> unsigned
> > int
> >     Order get_order()  const { return static_cast<Order>(fe_type.order +
> > _p_level); }
> >
> > I've attached my configure log file.  Any thoughts?
> >
> > Thanks!
> >
> > -- Charles
>
>

Re: [Libmesh-users] (no subject)

[Jahrul A. <al...@mu...>]

I have a similar error with 1.6.1.tar.gz. Using git, I get 1.7.0_pre, and
following is the error. Now, I have done a fresh installation of latest
PETSc, configured libmesh using
--with-cxx=/path/to/petsc/arch-linux-c-debug/bin/mpicxx, everything else is
as before, libmesh compiled smoothly with no error.


 CXX      src/base/libmesh_opt_la-dirichlet_boundary.lo
In file included from ./include/libmesh/fe_base.h(26),
                 from ./include/libmesh/fem_context.h(27),
                 from ./include/libmesh/fem_function_base.h(26),
                 from ./include/libmesh/composite_fem_function.h(23),
                 from ../src/base/dirichlet_boundary.C(25):
./include/libmesh/fe_abstract.h(491): error: more than one operator "+"
matches these operands:
            built-in operator "arithmetic + arithmetic"
            function "operator+(const PetscInt={int} &, const PetscComplex
&)"
            operand types are: const libMesh::OrderWrapper + const unsigned
int
    Order get_order()  const { return static_cast<Order>(fe_type.order +
_p_level); }
                                                                       ^

make[1]: *** [Makefile:25279:
src/base/libmesh_opt_la-dirichlet_boundary.lo] Error 1




=====================================
Jahrul Alam, PhD
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3054, Tel: 709-864 8071
=====================================


On Sun, Apr 4, 2021 at 12:15 PM Charles Puelz <cha...@gm...>
wrote:

> I am having an issue building 1.6.1 on TACC with the intel compilers
> (18.0.2)
>
> I am getting this error:
>
> ./include/libmesh/fe_abstract.h(443): error: more than one operator "+"
> matches these operands:
>             built-in operator "arithmetic + arithmetic"
>             function "operator+(const PetscInt={int} &, const PetscComplex
> &)"
>             operand types are: const libMesh::OrderWrapper + const unsigned
> int
>     Order get_order()  const { return static_cast<Order>(fe_type.order +
> _p_level); }
>
> I've attached my configure log file.  Any thoughts?
>
> Thanks!
>
> -- Charles
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

[Libmesh-users] (no subject)

[Charles P. <cha...@gm...>]

I am having an issue building 1.6.1 on TACC with the intel compilers
(18.0.2)

I am getting this error:

./include/libmesh/fe_abstract.h(443): error: more than one operator "+"
matches these operands:
            built-in operator "arithmetic + arithmetic"
            function "operator+(const PetscInt={int} &, const PetscComplex
&)"
            operand types are: const libMesh::OrderWrapper + const unsigned
int
    Order get_order()  const { return static_cast<Order>(fe_type.order +
_p_level); }

I've attached my configure log file.  Any thoughts?

Thanks!

-- Charles

Re: [Libmesh-users] Suggestion: turn some macros into functions

[edgar <edg...@cr...>]

On 2021-03-31 13:32, John Peterson wrote:
> Hi Edgar,
> 
> Yes, clearly something like this will work:
> 
>   libmesh_example_requires_fun(bool (0),
>>                                 "TESTME",
>>                                 __FILE__,
>>                                 __LINE__);
> 
> 
> but you then force the user to manually pass __FILE__ and __LINE__ to 
> every
> invocation of the "libmesh_error_msg_fun" function. To me this makes it 
> not
> very desirable/useful.
> 
> There is also the issue of not being able to "stream" messages into a
> function the same way that is possible with macros, for example we 
> often
> write code like:
> 
> libmesh_error_msg("Invalid shape function index i = " << i);
> 
> which is very convenient. If I understand correctly, your original 
> issue
> with the macros was that you could not properly "namespace" them, e.g.
> libMesh::libmesh_error_msg() does not work, but I think this is a
> relatively minor price to pay for the other conveniences that using a 
> macro
> provides.
> 
> --
> John

Thank you for your answer. Yes, indeed. My initial situation was that I 
thought of the convenience of having a =namespace=, but as I mentioned 
(and I know the previous e-mail was long), there are some times when one 
needs an actual function. Fortunately, libMesh is a kitchen and anyone 
can prepare their own recipe :) . Thanks.

Re: [Libmesh-users] Suggestion: turn some macros into functions

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

Hi Edgar,

Yes, clearly something like this will work:

  libmesh_example_requires_fun(bool (0),
>                                 "TESTME",
>                                 __FILE__,
>                                 __LINE__);


but you then force the user to manually pass __FILE__ and __LINE__ to every
invocation of the "libmesh_error_msg_fun" function. To me this makes it not
very desirable/useful.

There is also the issue of not being able to "stream" messages into a
function the same way that is possible with macros, for example we often
write code like:

libmesh_error_msg("Invalid shape function index i = " << i);

which is very convenient. If I understand correctly, your original issue
with the macros was that you could not properly "namespace" them, e.g.
libMesh::libmesh_error_msg() does not work, but I think this is a
relatively minor price to pay for the other conveniences that using a macro
provides.

--
John

Re: [Libmesh-users] Suggestion: turn some macros into functions

[edgar <edg...@cr...>]

On 2021-03-31 02:01, edgar wrote:

> 
> Dear John,
> 
> --- 8< ---
> │ #endif /* LIBMESH_MACRO_HANDLER_H */
> └────
> Listing 2: header file (libmesh_macro_handle.h). Note that
> `libmesh_example_requires_fun' could have also been `int', but I
> modified it to show a stack trace too.
> 
> --- 8< ---
> │ }
> └────
> Listing 3: source file (libmesh_macro_handle.cpp)

Apologies, I just noticed that I left the code of 
=libmesh_example_requires_fun= in the header file 
=libmesh_macro_handle.h= (should only have the declaration). Obviously, 
the definition needs to be in =libmesh_macro_handle.cpp=. (It used to be 
a template. As such, it could have been in the header file. A template 
seemed like too much).

Re: [Libmesh-users] Suggestion: turn some macros into functions

[edgar <edg...@cr...>]

On 2021-03-22 19:26, edgar wrote: > On 2021-03-22 18:26, John Peterson
wrote: >> The main reason that libmesh_error_msg() and friends are
macros is that >> they use the __FILE__ and __LINE__ preprocessor
defines to help direct the >> user to the exact place in the code where
the error was triggered. I’m not >> sure if it is possible to do this
same trick with inline functions, IIRC it >> will always report the line
where the inline function is defined in the >> source rather than the
line where it is called.  > > Thank you very much, John

Dear John,

I checked the C++ documentation. It seems that both `__FILE__' and
`__LINE__' should show up anywhere. They are also usable by functions as
well.

I was not planning to give more attention to this subject, but it came
back to bite me when I tried to use the macro in a `void' function .
So, this works: it reports the line number of the calling file, and
allows the functionality that `libmesh_example_requires' and
`libmesh_error_msg' provide in functions which may not be of `int' type.

Again, if it convenient to have this in libMesh, I can modify
`libmesh_common.h' in my local copy of the repo and push it onto
<https://www.notabug.org/broncodev/libmesh> or send it to you as a diff
file (the mailing list would not take attachments).

┌────
│ #include "../include/libmesh_macro_handler.h"
│ #include "libmesh/libmesh.h"
│ #include "libmesh/mesh.h"
│ #include <iostream>
│
│ using namespace libMesh;
│
│ int main (int argc, char * argv[]) {
│   libMesh::LibMeshInit
│     init (argc, argv);
│
│   libmesh_example_requires_fun(bool (0),
│                                "TESTME",
│                                __FILE__,
│                                __LINE__);
│   // This works too (comment previous function to test)
│   libmesh_error_msg_fun("FOUL");
│
│   printf("Not to be shown");
│
│   return 0;
│ }
└────
Listing 1: Main function

┌────
│ #ifndef LIBMESH_MACRO_HANDLER_H
│ #define LIBMESH_MACRO_HANDLER_H
│
│ #include <iostream>
│ #include "libmesh/libmesh.h"
│ #include "libmesh/libmesh_common.h"
│
│ /**
│  * @brief      Turns =libmesh_error_msg= into a function
│  *
│  * @details    =libmesh_error_msg= is a macro. To use
│  *             it inside a function, the function needs
│  *             to be of =int= type. This function just
│  *             captures the result of the macro,
│  *
│  * @param      msg: (std::string) message to show
│  *
│  * @return     int
│  */
│ int
│ libmesh_error_msg_fun(const std::string msg);
│
│ /**
│  * @brief      Function which is equivalent to 
libmesh_example_requires
│  *
│  * @details    This function allows to have the same functionality as 
libmesh_example_requires, but does not have a return value. Since it is 
not a macro, it can be called from within functions which are not of int 
type
│  *
│  * @param      condition: (const bool. Ex: bool(0)) condition which 
needs to occur to trigger the exception handling
│  *             msg: (const char *. Ex: "--enable-lib") The 
functionality which the example requires
│  *             file: (const char *. Ex: __FILE__) Name of calling file
│  *             line: (const int. Ex: __LINE__) Line from where the 
exception happened in file
│  *
│  * @return     void
│  */
│ void
│ libmesh_example_requires_fun (const bool condition,
│                               const char *msg,
│                               const char *file,
│                               const int line) {
│
│     // // This would not work, because of the =void= type:
│     // libmesh_example_requires (condition, option);
│
│     if (!condition) {
│         do {
│
│             libMesh::out
│               << "Configuring libMesh with " << msg
│               << " is required to run this example."
│               << std::endl;
│             std::stringstream msg_stream;
│             msg_stream << msg;
│             libMesh::MacroFunctions::report_error (
│               file, line, LIBMESH_DATE, LIBMESH_TIME);
│             LIBMESH_THROW (
│               libMesh::LogicError (msg_stream.str ()));
│         } while (0);
│   }
│ }
│
│ #endif /* LIBMESH_MACRO_HANDLER_H */
└────
Listing 2: header file (libmesh_macro_handle.h). Note that
`libmesh_example_requires_fun' could have also been `int', but I
modified it to show a stack trace too.

┌────
│ #include <stdio.h>
│ #include <iostream>
│ #include "libmesh/libmesh.h"
│ #include "libmesh/libmesh_common.h"
│ #include "../include/libmesh_macro_handler.h"
│
│ int
│ libmesh_error_msg_fun(const std::string msg) {
│   libmesh_error_msg(msg);
│
│   return 0;
│ }
└────
Listing 3: source file (libmesh_macro_handle.cpp)

Re: [Libmesh-users] Setting output directories in libmesh

[edgar <edg...@cr...>]

>> Since your attachment did not come through, I'm not sure where you'd 
>> like
>> to add this line. My suggestion would be to pull the branch from the
>> original PR, make your proposed change, and then either push that to 
>> your
>> own libmesh fork so that we can try it out, or paste the diff (output 
>> of
>> git diff or git log -p for the commit) so that someone can recreate 
>> it.

..aaaaand here is a diff (attached).

Re: [Libmesh-users] Setting output directories in libmesh

[edgar <edg...@cr...>]

On 2021-03-23 16:07, John Peterson wrote:
> Hi Edgar,
> 
> Sorry for the lack of reply. I did get your patch, but did not have a
> chance to try it out yet. Should this be applied on top of the changes 
> in
> the related PR (https://github.com/libMesh/libmesh/pull/2602)? On 
> libmesh
> master? Also, you mentioned:
> 
>> "and needs further fixing"
> 
> Any hints as to what else might need to be changed?

Hi John. Further apologies for missing the discussion 
(https://github.com/libMesh/libmesh/pull/2388). I thought that it was 
abandoned. What I can report about 
https://github.com/libMesh/libmesh/pull/2602 is this:

With the b91a8d3c5 commit of libMesh, I removed the line where my patch 
is applied, then ran =autoconf=, and omitted the =sed= line which 
changes =configure=. The summary is that it still uses =contrib/netcdf= 
for me (https://bitbin.it/pVrS2245/). I do have =--enable-netcdf= 
--with-netcdf=/usr/include --with-netcdf-lib=/usr/lib= as configuration 
flags.

I _am_ able to compile with my local netcdf if
1. I apply the patch
2. Run =autoconf=
3. Run the =sed= line on =configure=

After I read 
https://github.com/libMesh/libmesh/wiki/Updating-configure-tests%2C-Makefiles%2C-etc 
and it seems that libMesh's building stack creates a new an error with 
TIMPI

configure: error: libmesh/contrib/timpi/configure failed for 
contrib/timpi
==> ERROR: A failure occurred in build().
     Aborting...

In any case, you can see the final =configure= and my =netcdf.m4= here: 
https://notabug.org/broncodev/libMesh.git (my internet connection could 
be better an it is uploading as I click Send)

Re: [Libmesh-users] Suggestion: turn some macros into functions

[edgar <edg...@cr...>]

On 2021-03-22 18:26, John Peterson wrote:
> The main reason that libmesh_error_msg() and friends are macros is that
> they use the __FILE__ and __LINE__ preprocessor defines to help direct 
> the
> user to the exact place in the code where the error was triggered. I'm 
> not
> sure if it is possible to do this same trick with inline functions, 
> IIRC it
> will always report the line where the inline function is defined in the
> source rather than the line where it is called.

Thank you very much, John.