Re: [deal.II] interpolate_boundary_values does not work

[Zhuoran Wang]

Thanks for the clarification, Dr. Bangerth.
I think I will use the zero boundary condition to test whether finite
element spaces are appropriate.

Best,
Zhuoran

On Tue, Jun 8, 2021 at 12:19 AM Wolfgang Bangerth 
wrote:

> On 6/6/21 10:35 PM, Zhuoran Wang wrote:
> > I'm now trying to use WG(P1,P1) to solve Darcy. For WG(P0,P0), I used
> FE_DGQ
> > and FE_FaceQ which are the same as FE_DGP and FE_FaceP. But for higher
> > elements, I need to use FE_FaceP.
> > If the face dof is correctly figured out, I suppose I can assign the
> D.B.C to
> > constraints by myself. Is that correct?
>
> The issue is that FE_DGP is not interpolatory (i.e., the basis functions
> do
> not have the phi_i(x_j)=delta_ij property), and consequently the
> VectorTools::interpolate_boundary_values function does not work.
>
> But you can do the equivalent work yourself:
>for (cell=...)
>  for (face=...)
>if (face->at_boundary())
>  {
> get the DoF indices for that face, which in your case will only
>   correspond to the FE_FaceP component
> determine which values these DoFs need to have
> add the corresponding constraints to the AffineConstraints
> object
>  }
>
> The second step in the inner loop might be the difficult one if you have
> nontrivial boundary values since then you probably want to compute the
> projection of these boundary values onto the finite element space on that
> face. But if you have zero boundary values, for example, then you'd just
> set
> all DoFs to zero in that loop.
>
> Best
>   W.
>
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/TX_xy-KFDMQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/1ef2ff40-d865-dba5-847f-d5ad859ab04a%40colostate.edu
> .
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAO_HR-j7Bhq6vYoW-%3DNwr6bcUTn160NN2D6N6yvbYXF%2B8pyu9A%40mail.gmail.com.

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[vachan potluri]

Alex,

I think this is a problem related to the cluster's OS. On Cray XC50, I had
to explicitly set the link type to dynamic before installation, because by
default Cray does a static link. I had to set

export XTPE_LINK_TYPE=dynamic
export CRAYPE_LINK_TYPE=dynamic

before the installation. You can try and see if anything similar is
happening.

Regards,
Vachan

On Mon, 7 Jun 2021 at 22:34, Wolfgang Bangerth 
wrote:

> On 6/7/21 10:35 AM, Alex Cumberworth wrote:
> >
> > make[2]: *** No rule to make target
> > '/home/ipausers/cumberworth/lib/libsacado.a', needed by
> > 'lib/libdeal_II.g.so.9.3.0'.  Stop.
> > make[1]: *** [CMakeFiles/Makefile2:3238:
> source/CMakeFiles/deal_II.g.dir/all]
> > Error 2
> > make: *** [Makefile:149: all] Error 2
> >
> > There is libsacado.so in the directory I specified for trilinos
> libraries. I
> > configured both trilinos and deal.ii to build shared libraries. I also
> have set
> >
> > DEAL_II_PREFER_STATIC_LIBS   OFF
> >
> > I'm not really sure why it seems to only look for the static version of
> the
> > library.
>
> I don't think that the deal.II configuration specifies this. Check the
> files
> under lib/cmake in your Trilinos installation. For example, I find there
> the
> following information that deal.II simply imports:
>
> trilinos-12.8.1-mpi/lib> grep -r libsacado *
> cmake/Sacado/SacadoTargets-release.cmake:  IMPORTED_LOCATION_RELEASE
> "${_IMPORT_PREFIX}/lib/libsacado.so.12.8.1"
> cmake/Sacado/SacadoTargets-release.cmake:  IMPORTED_SONAME_RELEASE
> "libsacado.so.12"
> cmake/Sacado/SacadoTargets-release.cmake:list(APPEND
> _IMPORT_CHECK_FILES_FOR_sacado "${_IMPORT_PREFIX}/lib/libsacado.so.12.8.1"
> )
> Binary file libsacado.so matches
> Binary file libsacado.so.12 matches
> Binary file libsacado.so.12.8.1 matches
>
> Best
>   W.
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/59c24df0-17d6-5c39-4ef9-9ba5fb722ca8%40colostate.edu
> .
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CALAVa_yf8y1_7Q9i5K2uZv-%2BO6%3DLwFa9tVwxg88C8f%2BPM8HEkw%40mail.gmail.com.

Re: [deal.II] Re:

[Wolfgang Bangerth]

And the nonlinear equations of elasticity are actually elliptic equations?


Yes. If the stress-strain relationship is monotonic, i.e., if the stress 
increases with increasing strain. (So no bizarre materials with negative 
compressibility, for example.)



-Is the *expected rate* the rate which the laplace equation (assuming that 
this holds for elasticity as just discussed) yields for the gradients of the 
solution, i.e. ||grad (u-u_h)||_L2 <= ...h^p ?


Yes. You'd expect h^p for the gradients, and the ZZ approach can yield 
something like h^{p+1} at least in certain points. That is, you'd get 
something like

  || r - nabla u || + O(h^{p+1})
where r is the reconstructed gradient. (Assuming your coefficient is 1. 
Otherwise you'd have something like

  || r - kappa nabla u || + O(h^{p+1})
where r is the reconstructed stress and kappa is the stress strain tensor.


For me it's not yet fully clear how convergence rate of a projection method 
(L2, SPR) is linked to ||grad (u-u_h)||_L2 <= ...h^p .
Basically the input for the projection methods are the gradients (stresses) at 
the qps. Of course these values will be changed by the method( apply 
projection -> get_function_values), but is this "change" totally independent 
of the rate p from ||grad (u-u_h)||_L2 <= ...h^p ?


When you say "these values will be changed", can you explain what you refer 
to? What is "before" and what is "after" this change?


Best
 W.

--

Wolfgang Bangerth  email: bange...@colostate.edu
   www: http://www.math.colostate.edu/~bangerth/

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/6d3d426b-24df-54f4-9d23-128a93cf759b%40colostate.edu.

Re: [deal.II] Re:

[Simon Wiesheier]

" I'm sure someone has proved this, but my intuition is that for every
elliptic
equation without an advection term, you will get the same convergence rate
as
for the Laplace equation as long as the coefficient in the elliptic
operator
is nice enoug."

I'll will search in the literature to get deeper information, so thanks for
the hint!
And the nonlinear equations of elasticity are actually elliptic equations?

One last question regarding the convergence rate:
As I previously said in this chat, I am projecting the dim*dim coefficients
of the stress tensor, which are only availabe at the qps, to the nodes
using a global L2-projection and for comparison a superconvergent approach
(superconvergent patch recovery introduced by Zienkiewicz and Zhu).
I will then also determine the convergence rate of the two approaches. As
the name suggests, the superconvergent approach should give me a higher
convergence rate
*as expected. *
-Is the *expected rate* the rate which the laplace equation (assuming that
this holds for elasticity as just discussed) yields for the gradients of
the solution, i.e. ||grad (u-u_h)||_L2 <= ...h^p ?

For me it's not yet fully clear how convergence rate of a projection method
(L2, SPR) is linked to ||grad (u-u_h)||_L2 <= ...h^p .
Basically the input for the projection methods are the gradients (stresses)
at the qps. Of course these values will be changed by the method( apply
projection -> get_function_values), but is this "change" totally
independent of the rate p from ||grad (u-u_h)||_L2 <= ...h^p ?
For me this seems to be the case since in the literature people compare the
rate of  a L2-projection with the rate of a SPR-projection (or other
methods).

Thanks again for helping me!

Best
Simon

Am Mo., 7. Juni 2021 um 17:47 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 6/7/21 8:12 AM, Simon wrote:
> > Yes, actually both schemes converge to the same solution.
> > Maybe I should do some postprocessing with a visualiuation in order to
> figure
> > out what the lumped integration does with the values at the qps.
>
> Then the difference you observe is simply numerical error.
>
>
> > I want to determine the convergence rate for the elasticity equations
> with the
> > PDE: div(stress-tensor) = 0.
> > -Since I determine the convergence rate, the before mentioned *constant*
> in
> > the inequality cancels out, i.e. I should get the same convergence rate
> as for
> > the laplace equation. Is that right?
>
> Correct. The *rate* is independent of the factor.
>
>
> > -I actually solve the nonlinear elasticity equations (hyperelasticity);
> The
> > finite element spaces, test functions,... are the same as for linear
> > elasticity, but the stresses depend now nonlinear on the gradient of the
> > displacements. My question is if the nonlinearity changes the error
> estimates?
> > Let´s assume I determine the convergence rate in the L2-norm for linear
> > elasticity, which is in the best case 2 for for p=1. Should I also get 2
> for
> > the nonlinear elasticity equations?
>
> I'm sure someone has proved this, but my intuition is that for every
> elliptic
> equation without an advection term, you will get the same convergence rate
> as
> for the Laplace equation as long as the coefficient in the elliptic
> operator
> is nice enough. Nice enough here will mean that your stress-strain
> relationship does not degenerate, i.e.,
>||sigma|| / ||eps||
> does not go to zero or infinity, and is a smooth function of some sort.
>
> Best
>   W.
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/e751f64b-5cc3-d823-0855-5e51d6dd4d46%40colostate.edu
> .
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAM50jEuZUUR0U65WcYWXYynGkt8GfnBDOvHEZh96jNR8FXPTNg%40mail.gmail.com.

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Wolfgang Bangerth]

On 6/7/21 10:35 AM, Alex Cumberworth wrote:


make[2]: *** No rule to make target 
'/home/ipausers/cumberworth/lib/libsacado.a', needed by 
'lib/libdeal_II.g.so.9.3.0'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:3238: source/CMakeFiles/deal_II.g.dir/all] 
Error 2

make: *** [Makefile:149: all] Error 2

There is libsacado.so in the directory I specified for trilinos libraries. I 
configured both trilinos and deal.ii to build shared libraries. I also have set


DEAL_II_PREFER_STATIC_LIBS   OFF

I'm not really sure why it seems to only look for the static version of the 
library.


I don't think that the deal.II configuration specifies this. Check the files 
under lib/cmake in your Trilinos installation. For example, I find there the 
following information that deal.II simply imports:


trilinos-12.8.1-mpi/lib> grep -r libsacado *
cmake/Sacado/SacadoTargets-release.cmake:  IMPORTED_LOCATION_RELEASE 
"${_IMPORT_PREFIX}/lib/libsacado.so.12.8.1"
cmake/Sacado/SacadoTargets-release.cmake:  IMPORTED_SONAME_RELEASE 
"libsacado.so.12"
cmake/Sacado/SacadoTargets-release.cmake:list(APPEND 
_IMPORT_CHECK_FILES_FOR_sacado "${_IMPORT_PREFIX}/lib/libsacado.so.12.8.1" )

Binary file libsacado.so matches
Binary file libsacado.so.12 matches
Binary file libsacado.so.12.8.1 matches

Best
 W.

--

Wolfgang Bangerth  email: bange...@colostate.edu
   www: http://www.math.colostate.edu/~bangerth/

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/59c24df0-17d6-5c39-4ef9-9ba5fb722ca8%40colostate.edu.

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Alex Cumberworth]

I have now run into another error, although I suspect it should be more 
straightforward to solve:

make[2]: *** No rule to make target 
'/home/ipausers/cumberworth/lib/libsacado.a', needed by 
'lib/libdeal_II.g.so.9.3.0'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:3238: 
source/CMakeFiles/deal_II.g.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

There is libsacado.so in the directory I specified for trilinos libraries. 
I configured both trilinos and deal.ii to build shared libraries. I also 
have set

DEAL_II_PREFER_STATIC_LIBS   OFF

I'm not really sure why it seems to only look for the static version of the 
library.

Best,
Alex

On Monday, June 7, 2021 at 6:11:52 p.m. UTC+2 Wolfgang Bangerth wrote:

> On 6/7/21 10:02 AM, Alex Cumberworth wrote:
> > The cause of this particular issue actually appears to be some symlinks 
> to the 
> > mpi include directory in my home directory. I am surprised that this was 
> the 
> > cause of the errors as they still point to the same mpi directory that 
> cmake 
> > finds. Once I removed them the errors disappeared. While I am still 
> compiling, 
> > I have passed all previous points where I had errors.
> > 
>
> Good to know -- it had to be something particular about your installation 
> given that people compile with Trilinos all the time without seeing these 
> errors :-)
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/111bd344-8a39-4f09-a7cf-624963c8855dn%40googlegroups.com.

Re: [deal.II] interpolate_boundary_values does not work

[Wolfgang Bangerth]

On 6/6/21 10:35 PM, Zhuoran Wang wrote:
I'm now trying to use WG(P1,P1) to solve Darcy. For WG(P0,P0), I used FE_DGQ 
and FE_FaceQ which are the same as FE_DGP and FE_FaceP. But for higher 
elements, I need to use FE_FaceP.
If the face dof is correctly figured out, I suppose I can assign the D.B.C to 
constraints by myself. Is that correct?


The issue is that FE_DGP is not interpolatory (i.e., the basis functions do 
not have the phi_i(x_j)=delta_ij property), and consequently the 
VectorTools::interpolate_boundary_values function does not work.


But you can do the equivalent work yourself:
  for (cell=...)
for (face=...)
  if (face->at_boundary())
{
   get the DoF indices for that face, which in your case will only
 correspond to the FE_FaceP component
   determine which values these DoFs need to have
   add the corresponding constraints to the AffineConstraints object
}

The second step in the inner loop might be the difficult one if you have 
nontrivial boundary values since then you probably want to compute the 
projection of these boundary values onto the finite element space on that 
face. But if you have zero boundary values, for example, then you'd just set 
all DoFs to zero in that loop.


Best
 W.


--

Wolfgang Bangerth  email: bange...@colostate.edu
   www: http://www.math.colostate.edu/~bangerth/

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/1ef2ff40-d865-dba5-847f-d5ad859ab04a%40colostate.edu.

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Wolfgang Bangerth]

On 6/7/21 10:02 AM, Alex Cumberworth wrote:
The cause of this particular issue actually appears to be some symlinks to the 
mpi include directory in my home directory. I am surprised that this was the 
cause of the errors as they still point to the same mpi directory that cmake 
finds. Once I removed them the errors disappeared. While I am still compiling, 
I have passed all previous points where I had errors.




Good to know -- it had to be something particular about your installation 
given that people compile with Trilinos all the time without seeing these 
errors :-)


Best
 W.

--

Wolfgang Bangerth  email: bange...@colostate.edu
   www: http://www.math.colostate.edu/~bangerth/

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/916290e4-e28e-c7f6-e72a-1b294c00f545%40colostate.edu.

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Alex Cumberworth]

The cause of this particular issue actually appears to be some symlinks to 
the mpi include directory in my home directory. I am surprised that this 
was the cause of the errors as they still point to the same mpi directory 
that cmake finds. Once I removed them the errors disappeared. While I am 
still compiling, I have passed all previous points where I had errors.

Best,
Alex

On Monday, June 7, 2021 at 5:41:24 p.m. UTC+2 Wolfgang Bangerth wrote:

> On 6/7/21 8:41 AM, Alex Cumberworth wrote:
> > I noticed that I attached the error file for 9.2, and that the source of 
> the 
> > error in 9.3 is different. In 9.2, something goes wrong when one of the 
> > bundled sundials files is compiled, while 9.3, it is when one of the 
> bundled 
> > arborx files is compiled. Both involve the same MPI errors. Both are 
> supposed 
> > to be turned off (output from cmake):
>
> These sorts of things happen because cmake caches stuff from one 
> invocation to 
> another and doesn't notice that you pass flags on the command line that 
> would 
> alter what has been cached before.
>
> Just rm -r the entire build directory before you call cmake and see 
> whether 
> that helps.
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/f6cc88c4-7a2b-4a84-8978-573fd5aa7b7bn%40googlegroups.com.

Re: [deal.II] Re:

[Wolfgang Bangerth]

On 6/7/21 8:12 AM, Simon wrote:

Yes, actually both schemes converge to the same solution.
Maybe I should do some postprocessing with a visualiuation in order to figure 
out what the lumped integration does with the values at the qps.


Then the difference you observe is simply numerical error.


I want to determine the convergence rate for the elasticity equations with the 
PDE: div(stress-tensor) = 0.
-Since I determine the convergence rate, the before mentioned *constant* in 
the inequality cancels out, i.e. I should get the same convergence rate as for 
the laplace equation. Is that right?


Correct. The *rate* is independent of the factor.


-I actually solve the nonlinear elasticity equations (hyperelasticity); The 
finite element spaces, test functions,... are the same as for linear 
elasticity, but the stresses depend now nonlinear on the gradient of the 
displacements. My question is if the nonlinearity changes the error estimates?
Let´s assume I determine the convergence rate in the L2-norm for linear 
elasticity, which is in the best case 2 for for p=1. Should I also get 2 for 
the nonlinear elasticity equations?


I'm sure someone has proved this, but my intuition is that for every elliptic 
equation without an advection term, you will get the same convergence rate as 
for the Laplace equation as long as the coefficient in the elliptic operator 
is nice enough. Nice enough here will mean that your stress-strain 
relationship does not degenerate, i.e.,

  ||sigma|| / ||eps||
does not go to zero or infinity, and is a smooth function of some sort.

Best
 W.

--

Wolfgang Bangerth  email: bange...@colostate.edu
   www: http://www.math.colostate.edu/~bangerth/

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/e751f64b-5cc3-d823-0855-5e51d6dd4d46%40colostate.edu.

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Wolfgang Bangerth]

On 6/7/21 8:41 AM, Alex Cumberworth wrote:
I noticed that I attached the error file for 9.2, and that the source of the 
error in 9.3 is different. In 9.2, something goes wrong when one of the 
bundled sundials files is compiled, while 9.3, it is when one of the bundled 
arborx files is compiled. Both involve the same MPI errors. Both are supposed 
to be turned off (output from cmake):


These sorts of things happen because cmake caches stuff from one invocation to 
another and doesn't notice that you pass flags on the command line that would 
alter what has been cached before.


Just rm -r the entire build directory before you call cmake and see whether 
that helps.


Best
  W.

--

Wolfgang Bangerth  email: bange...@colostate.edu
   www: http://www.math.colostate.edu/~bangerth/

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/8eee0b16-3d88-c9ea-586b-06de8fe88518%40colostate.edu.

Re: [deal.II] Re:

[Simon]

Yes, actually both schemes converge to the same solution. 
Maybe I should do some postprocessing with a visualiuation in order to 
figure out what the lumped integration does with the values at the qps.

I´ve got one more basic question ragarding the determination of the 
convergence rate as it is done in many tutorials (step 7, step 51,...). For 
that purpose I watched your new videos (3.9, 3.91, 3.93, 3.95) where you 
derived the error estimation for the laplace equation in certain norms. You 
mentioned in there that for many PDEs one comes up with the same results, 
i.e. that the finite element error is at least as good as the interpolation 
error *times some equation-dependent constant*. 
I want to determine the convergence rate for the elasticity equations with 
the PDE: div(stress-tensor) = 0. 
-Since I determine the convergence rate, the before mentioned *constant* in 
the inequality cancels out, i.e. I should get the same convergence rate as 
for the laplace equation. Is that right?

-I actually solve the nonlinear elasticity equations (hyperelasticity); The 
finite element spaces, test functions,... are the same as for linear 
elasticity, but the stresses depend now nonlinear on the gradient of the 
displacements. My question is if the nonlinearity changes the error 
estimates?
Let´s assume I determine the convergence rate in the L2-norm for linear 
elasticity, which is in the best case 2 for for p=1. Should I also get 2 
for the nonlinear elasticity equations?

I know that these questions are not directly related to dealii, but I guess 
you have a deep knowledge in that area. I would appreciate if you helped my 
answering that.

Best
Simon

Wolfgang Bangerth schrieb am Sonntag, 6. Juni 2021 um 01:58:39 UTC+2:

> On 6/4/21 9:14 AM, Simon Wiesheier wrote:
> > 
> > So intuitively speaking, what is the effect of the lumped integration? 
> From a 
> > mathematical viewpoint there are no more couplings between the DoFs. But 
> does 
> > this lead to lower nodal values, higher nodal values or is this context 
> dependent?
>
> I have to admit that I have no intuition.
>
> Do both schemes converge? To the same solution?
>
> Best
> W.
>
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/30a00e59-625d-403e-812f-cc051802deeen%40googlegroups.com.

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Alex Cumberworth]

Hi Daniel,

I have actually set

DEAL_II_WITH_SUNDIALS:BOOL=OFF

so I don't really understand why it is trying to compile with sundials. 
Sundials is actually not installed on my system, so deal.ii must be using 
the bundled version. I will try to compile sundials and see if that helps.

Best,
Alex
On Monday, June 7, 2021 at 3:37:11 p.m. UTC+2 d.arnd...@gmail.com wrote:

> Alex,
>
> it looks like Trilinos and SUNDIALS are using different MPI 
> implementations that are incompatible. There is not much we can do about 
> this within deal.II.
> Can you try to reinstall SUNDIALS or Trilinos using the same MPI 
> implementation as the other one?
>
> Best,
> Daniel
>
> Am Mo., 7. Juni 2021 um 09:26 Uhr schrieb Alex Cumberworth <
> alexanderc...@gmail.com>:
>
>> Hi Bruno,
>>
>> I repeated the compilation with deal.ii 9.3 and had the same error. I 
>> looked at the documentation in deal.ii for the class EpetraWrappers, and 
>> apparently it requires MPI:
>>
>> *This class implements a wrapper to the Trilinos distributed vector class 
>> Epetra_FEVector. This class is derived from the 
>> LinearAlgebra::VectorSpaceVector 
>> 
>>  
>> class. Note however that Epetra only works with Number = double. This class 
>> requires Trilinos to be compiled with MPI support.*
>> Since epetra is a required trilinos module, does this mean that if 
>> trilinos is included, it must be compiled with MPI (and then therefore also 
>> deal.ii, as cmake does not allow non-matching MPI configurations between 
>> them)?
>>
>> I recompiled trilinos with mpi on (openmpi 4.0.5), but when attempting to 
>> recompile deal.ii with MPI on, I ended up with new errors. There are too 
>> many errors to paste here, but it begins with
>>
>> In file included from 
>> /home/ipausers/cumberworth/include/Teuchos_Time.hpp:56,  
>>  
>>  
>>
>>  from 
>> /home/ipausers/cumberworth/include/Teuchos_TimeMonitor.hpp:70,   
>>  
>> 
>>  
>>  from 
>> /home/ipausers/cumberworth/include/Teuchos_CommUtilities.hpp:45, 
>>  
>> 
>>  
>>  from 
>> /home/ipausers/cumberworth/include/Teuchos_CommHelpers.hpp:46,   
>>  
>> 
>>  
>>  from 
>> /home/ipausers/cumberworth/include/Kokkos_TeuchosCommAdapters.hpp:47,
>>  
>> 
>>  
>>  from 
>> /home/ipausers/cumberworth/include/Sacado_Fad_ScalarTraitsImp.hpp:627,   
>>  
>> 
>>  
>>  from 
>> /home/ipausers/cumberworth/include/Sacado_Fad_DFadTraits.hpp:144,
>>  
>> 
>>  
>>  from 
>> /home/ipausers/cumberworth/include/Sacado.hpp:51,
>>  
>> 
>>  
>>  from 
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/base/numbers.h:151,
>>  
>>   
>>  
>>  from 
>> /home/ipausers/cumberworth/src/dealii-9.2.0/build13/include/deal.II/base/config.h:449,
>>  
>>
>>  
>>  from 
>> /home/ipausers/cumberworth/src/dealii-9.2.0/source/sundials/arkode.cc:17:
>>  
>> 
>>  
>> /home/ipausers/cumberworth/include/mpi.h:30:13: error: conflicting 
>> declaration ‘typedef int 
>> MPI_Datatype’
>>
>>  
>>30 | typedef int 
>> MPI_Datatype;
>>  
>>   
>>  
>>   | 
>> ^~~~ 
>> 
>>
>>
>> 

Re: [deal.II] step 21 runs error

[Daniel Arndt]

Nick,

Just pass "MappingQGeneric

(1)" as first argument, see
https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#ac6b404bf03cb2a742b290421cc2789fe
.

Best,
Daniel

Am Mo., 7. Juni 2021 um 05:37 Uhr schrieb Nick Wang :

> When using the function "project", we found the mapping is necessary(in
> vector_tools_project.templates.h),but in step21(line 1155) don't have
> mapping. So when we run this exe, it has error and we can't get results.
> Therefore, we want know how to change this problem.
> [image: 1.png][image: 2.png]
> Thanks,
> Nick
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/c72ebdc7-d674-44e0-991d-794622168fd3n%40googlegroups.com
> 
> .
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAOYDWbJ4SdSE1PDFyyJXo_GunS6dF1YJ5Saudmqu_QhBAc0kqQ%40mail.gmail.com.

[deal.II] Re: Integrated material and spatial traction forces on boundary not equal

[Michael Lee]

Hi Alex,
I'm learning deal.ii and trying do the similar verification. If it is 
possible for you to share the code with me?

Thank you!
Michael
On Tuesday, May 11, 2021 at 4:46:55 AM UTC-6 alexanderc...@gmail.com wrote:

> Hello,
>
> As a test to validate my code, I am solving the equations for 
> geometrically nonlinear elasticity (the Saint Venant-Kirchhoff model) for a 
> beam with a small displacement boundary condition on the right end such 
> that I can compare with Euler-Bernoulli beam theory. I can compare both the 
> displacement and the shear force between the FEM solution and the beam 
> theory solution. In my FEM integration, I output the normal and shear 
> forces for both sides of the beam in both the material and spatial 
> reference. The left and right sides are balanced, as expected, but the 
> spatial and material forces are not quite equal.
>
> Shouldn't it be the case that spatial and material force is the same? Here 
> are the outputted forces for the right side
>
> Right boundary material normal force: 0.0694169
> Right boundary spatial normal force: 0.0724468
>
> Right boundary material shear force: 0.152057
> Right boundary spatial shear force: 0.152864
>
> Further, beam theory gives a shear force with a magnitude of exactly 0.2. 
> If I make the displacement smaller the FEM and beam theory shear forces do 
> not converge. Is it expected for them to converge?
>
> Below is the deformed system with the stress vectors on the faces 
> included. The black grid is the deformed FEM solution, while the solid red 
> is the beam theory solution.
> [image: beam.png]
> If there is an issue, I would guess it would be in the integration. In 
> converting the material normal vector to the spatial reference, I first 
> only applied the inverse transpose of the deformation gradient, and did not 
> multiply by the determinant until calculating the force vector. I did this 
> so that I can get the unit normal spatial vectors to add up and later 
> average so that I have an average normal vector for the whole boundary face 
> to calculate the normal and shear force vectors. I have pasted the function 
> in below:
>
> template 
> void SolveRing::integrate_over_boundaries() {
> QGauss quadrature_formula(fe.degree + 1);
> FEFaceValues fe_face_values(
> fe,
> quadrature_formula,
> update_values | update_gradients | update_quadrature_points |
> update_JxW_values | update_normal_vectors);
>
> std::vector> material_force(2);
> std::vector> spatial_force(2);
> std::vector> ave_material_normal(2);
> std::vector> ave_spatial_normal(2);
> const FEValuesExtractors::Vector displacements(0);
> for (const auto& cell: dof_handler.active_cell_iterators()) {
> for (const auto face_i: GeometryInfo::face_indices()) {
> const unsigned int boundary_id 
> {cell->face(face_i)->boundary_id()};
> if (not(boundary_id == 1 or boundary_id == 2)) {
> continue;
> }
> fe_face_values.reinit(cell, face_i);
> std::vector> normal_vectors {
> fe_face_values.get_normal_vectors()};
> std::vector> solution_gradients(
> fe_face_values.n_quadrature_points);
> fe_face_values[displacements].get_function_gradients(
> present_solution, solution_gradients);
> for (const auto q_i: 
> fe_face_values.quadrature_point_indices()) {
> const Tensor<2, dim, double> grad_u 
> {solution_gradients[q_i]};
> const Tensor<1, dim, double> material_normal {
> normal_vectors[q_i]};
>
> const Tensor<2, dim, double> grad_u_T {transpose(grad_u)};
> const Tensor<2, dim, double> green_lagrange_strain {
> 0.5 * (grad_u + grad_u_T + grad_u_T * grad_u)};
> const Tensor<2, dim, double> piola_kirchhoff {
> lambda * trace(green_lagrange_strain) *
> unit_symmetric_tensor() +
> 2 * mu * green_lagrange_strain};
>
> ave_material_normal[boundary_id - 1] += material_normal;
> material_force[boundary_id - 1] += piola_kirchhoff *
>material_normal *
>fe_face_values.JxW(q_i);
>
> const Tensor<2, dim, double> deformation_grad {
> grad_u + unit_symmetric_tensor()};
> const double deformation_grad_det {
> determinant(deformation_grad)};
> const Tensor<2, dim, double> cauchy {
> deformation_grad * piola_kirchhoff *
> transpose(deformation_grad) / 
> deformation_grad_det};
>
> Tensor<1, dim, double> spatial_normal {
>   

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Daniel Arndt]

Alex,

it looks like Trilinos and SUNDIALS are using different MPI implementations
that are incompatible. There is not much we can do about this within
deal.II.
Can you try to reinstall SUNDIALS or Trilinos using the same MPI
implementation as the other one?

Best,
Daniel

Am Mo., 7. Juni 2021 um 09:26 Uhr schrieb Alex Cumberworth <
alexandercumberwo...@gmail.com>:

> Hi Bruno,
>
> I repeated the compilation with deal.ii 9.3 and had the same error. I
> looked at the documentation in deal.ii for the class EpetraWrappers, and
> apparently it requires MPI:
>
> *This class implements a wrapper to the Trilinos distributed vector class
> Epetra_FEVector. This class is derived from the
> LinearAlgebra::VectorSpaceVector
> 
> class. Note however that Epetra only works with Number = double. This class
> requires Trilinos to be compiled with MPI support.*
> Since epetra is a required trilinos module, does this mean that if
> trilinos is included, it must be compiled with MPI (and then therefore also
> deal.ii, as cmake does not allow non-matching MPI configurations between
> them)?
>
> I recompiled trilinos with mpi on (openmpi 4.0.5), but when attempting to
> recompile deal.ii with MPI on, I ended up with new errors. There are too
> many errors to paste here, but it begins with
>
> In file included from
> /home/ipausers/cumberworth/include/Teuchos_Time.hpp:56,
>
>  from
> /home/ipausers/cumberworth/include/Teuchos_TimeMonitor.hpp:70,
>
>  from
> /home/ipausers/cumberworth/include/Teuchos_CommUtilities.hpp:45,
>
>  from
> /home/ipausers/cumberworth/include/Teuchos_CommHelpers.hpp:46,
>
>  from
> /home/ipausers/cumberworth/include/Kokkos_TeuchosCommAdapters.hpp:47,
>
>  from
> /home/ipausers/cumberworth/include/Sacado_Fad_ScalarTraitsImp.hpp:627,
>
>  from
> /home/ipausers/cumberworth/include/Sacado_Fad_DFadTraits.hpp:144,
>
>  from
> /home/ipausers/cumberworth/include/Sacado.hpp:51,
>
>  from
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/base/numbers.h:151,
>
>  from
> /home/ipausers/cumberworth/src/dealii-9.2.0/build13/include/deal.II/base/config.h:449,
>
>  from
> /home/ipausers/cumberworth/src/dealii-9.2.0/source/sundials/arkode.cc:17:
>
> /home/ipausers/cumberworth/include/mpi.h:30:13: error: conflicting
> declaration ‘typedef int
> MPI_Datatype’
>
>30 | typedef int
> MPI_Datatype;
>
>   |
> ^~~~
>
>
> I have included the rest as an attachment.
>
> Best,
> Alex
> On Monday, June 7, 2021 at 2:03:34 p.m. UTC+2 bruno.t...@gmail.com wrote:
>
>> Alex,
>>
>> This is really strange. I've never seen that error before. Can you try
>> to install deal.II 9.3
>> https://github.com/dealii/dealii/releases/tag/v9.3.0 and see if you
>> get the same error?
>>
>> Best,
>>
>> Bruno
>>
>> Le lun. 7 juin 2021 à 05:54, Alex Cumberworth
>>  a écrit :
>> >
>> > Hello,
>> >
>> > I recompiled trilinos without tpetra to sidestep this error, but ended
>> up with another error involving epetra, and apparently epetra is minimal
>> module required for trilinos with deal.ii, so I cannot do the same
>> thing.The error:
>> >
>> > [ 31%] Building CXX object
>> source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out_dof_data.cc.o
>> > In file included from
>> /home/ipausers/cumberworth/src/dealii-9.2.0/source/numerics/data_out_dof_data.cc:28:
>>
>> >
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:33:
>> error: ‘EpetraWrappers’ is not a member of ‘dealii::LinearAlgebra’
>> > 429 | VectorHelper::extract(
>> > | ^~
>> >
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:55:
>> error: template argument 1 is invalid
>> > 429 | VectorHelper::extract(
>> > | ^
>> >
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:28:
>> error: ‘EpetraWrappers’ in namespace ‘dealii::LinearAlgebra’ does not name
>> a type
>> > 430 | const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
>> > | ^~
>> >
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:51:
>> error: expected unqualified-id before ‘&’ token
>> > 430 | const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
>> > | ^
>> >
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:50:
>> error: expected ‘)’ before ‘&’ token
>> > 430 | const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
>> > | ^~
>> > | )
>> >
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:65:
>> note: to match this ‘(’
>> > 429 | VectorHelper::extract(
>> > | ^
>> >
>> 

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Bruno Turcksin]

Alex,

This is really strange. I've never seen that error before. Can you try
to install deal.II 9.3
https://github.com/dealii/dealii/releases/tag/v9.3.0 and see if you
get the same error?

Best,

Bruno

Le lun. 7 juin 2021 à 05:54, Alex Cumberworth
 a écrit :
>
> Hello,
>
> I recompiled trilinos without tpetra to sidestep this error, but ended up 
> with another error involving epetra, and apparently epetra is minimal module 
> required for trilinos with deal.ii, so I cannot do the same thing.The error:
>
> [ 31%] Building CXX object 
> source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out_dof_data.cc.o
> In file included from 
> /home/ipausers/cumberworth/src/dealii-9.2.0/source/numerics/data_out_dof_data.cc:28:
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:33:
>  error: ‘EpetraWrappers’ is not a member of ‘dealii::LinearAlgebra’
>   429 | VectorHelper::extract(
>   | ^~
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:55:
>  error: template argument 1 is invalid
>   429 | VectorHelper::extract(
>   |   ^
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:28:
>  error: ‘EpetraWrappers’ in namespace ‘dealii::LinearAlgebra’ does not name a 
> type
>   430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
>   |^~
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:51:
>  error: expected unqualified-id before ‘&’ token
>   430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
>   |   ^
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:50:
>  error: expected ‘)’ before ‘&’ token
>   430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
>   |  ^~
>   |  )
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:65:
>  note: to match this ‘(’
>   429 | VectorHelper::extract(
>   | ^
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:51:
>  error: non-member function ‘void 
> dealii::internal::DataOutImplementation::extract(...)’ cannot have 
> ref-qualifier
>   430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
>   |   ^
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:51:
>  error: ‘extract’ is not a template function
> make[2]: *** 
> [source/numerics/CMakeFiles/obj_numerics_debug.dir/build.make:303: 
> source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out_dof_data.cc.o] 
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:3317: 
> source/numerics/CMakeFiles/obj_numerics_debug.dir/all] Error 2
> make: *** [Makefile:149: all] Error 2
>
> Best,
> Alex
> On Friday, June 4, 2021 at 5:24:03 p.m. UTC+2 Alex Cumberworth wrote:
>>
>> Hi Vachan,
>>
>> Thanks for your response. This actually works. However, I still end up with 
>> an incompatibility of the MPI configuration between the Trilinos library and 
>> deal.ii. I ended up compiling Trilinos from source (12-4-1), but during 
>> compilation of deal.ii, I have a new error:
>>
>> In file included from 
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/dofs/dof_accessor.templates.h:35,
>>  from 
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/dofs/dof_accessor.h:2069,
>>  from 
>> /home/ipausers/cumberworth/src/dealii-9.2.0/source/numerics/data_out.cc:18:
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/lac/read_write_vector.h:624:21:
>>  error: ‘Vector’ in namespace ‘Tpetra’ does not name a template type
>>   624 |   const Tpetra::Vector 
>> _vector,
>>   | ^~
>> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/lac/read_write_vector.h:624:27:
>>  error: expected ‘,’ or ‘...’ before ‘<’ token
>>   624 |   const Tpetra::Vector 
>> _vector,
>>   |   ^
>> make[2]: *** 
>> [source/numerics/CMakeFiles/obj_numerics_debug.dir/build.make:82: 
>> source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out.cc.o] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:3317: 
>> source/numerics/CMakeFiles/obj_numerics_debug.dir/all] Error 2
>> make: *** [Makefile:149: all] Error 2
>>
>> The same error occurs when I use version 13 of Trilinos.
>>
>> Best,
>> Alex
>>
>> On Thursday, June 3, 2021 at 1:30:49 p.m. UTC+2 

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

[Alex Cumberworth]

Hello,

I recompiled trilinos without tpetra to sidestep this error, but ended up 
with another error involving epetra, and apparently epetra is minimal 
module required for trilinos with deal.ii, so I cannot do the same 
thing.The error:

[ 31%] Building CXX object 
source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out_dof_data.cc.o
In file included from 
/home/ipausers/cumberworth/src/dealii-9.2.0/source/numerics/data_out_dof_data.cc:28:
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:33:
 
error: ‘EpetraWrappers’ is not a member of ‘dealii::LinearAlgebra’
  429 | VectorHelper::extract(
  | ^~
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:55:
 
error: template argument 1 is invalid
  429 | VectorHelper::extract(
  |   ^
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:28:
 
error: ‘EpetraWrappers’ in namespace ‘dealii::LinearAlgebra’ does not name 
a type
  430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
  |^~
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:51:
 
error: expected unqualified-id before ‘&’ token
  430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
  |   ^
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:50:
 
error: expected ‘)’ before ‘&’ token
  430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
  |  ^~
  |  )
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:429:65:
 
note: to match this ‘(’
  429 | VectorHelper::extract(
  | ^
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:51:
 
error: non-member function ‘void 
dealii::internal::DataOutImplementation::extract(...)’ cannot have 
ref-qualifier
  430 |   const LinearAlgebra::EpetraWrappers::Vector & /*vector*/,
  |   ^
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/numerics/data_out_dof_data.templates.h:430:51:
 
error: ‘extract’ is not a template function
make[2]: *** 
[source/numerics/CMakeFiles/obj_numerics_debug.dir/build.make:303: 
source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out_dof_data.cc.o] 
Error 1
make[1]: *** [CMakeFiles/Makefile2:3317: 
source/numerics/CMakeFiles/obj_numerics_debug.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

Best,
Alex
On Friday, June 4, 2021 at 5:24:03 p.m. UTC+2 Alex Cumberworth wrote:

> Hi Vachan,
>
> Thanks for your response. This actually works. However, I still end up 
> with an incompatibility of the MPI configuration between the Trilinos 
> library and deal.ii. I ended up compiling Trilinos from source (12-4-1), 
> but during compilation of deal.ii, I have a new error:
>
> In file included from 
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/dofs/dof_accessor.templates.h:35,
>  from 
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/dofs/dof_accessor.h:2069,
>  from 
> /home/ipausers/cumberworth/src/dealii-9.2.0/source/numerics/data_out.cc:18:
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/lac/read_write_vector.h:624:21:
>  
> error: ‘Vector’ in namespace ‘Tpetra’ does not name a template type
>   624 |   const Tpetra::Vector 
> _vector,
>   | ^~
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/lac/read_write_vector.h:624:27:
>  
> error: expected ‘,’ or ‘...’ before ‘<’ token
>   624 |   const Tpetra::Vector 
> _vector,
>   |   ^
> make[2]: *** 
> [source/numerics/CMakeFiles/obj_numerics_debug.dir/build.make:82: 
> source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out.cc.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:3317: 
> source/numerics/CMakeFiles/obj_numerics_debug.dir/all] Error 2
> make: *** [Makefile:149: all] Error 2
>
> The same error occurs when I use version 13 of Trilinos.
>
> Best,
> Alex
>
> On Thursday, June 3, 2021 at 1:30:49 p.m. UTC+2 vachanpo...@gmail.com 
> wrote:
>
>> Hi Alex,
>>
>> I previously ran into a lot of issues when I tried to install dealii on 
>> our institute's cluster. The OS was different though and I had problems 
>> with PETSc.
>>
>> I don't know if this helps but this is the relevant section in 
>> dealii-9.2.0/cmake/modules/FindTRILINOS.cmake file which searches for 
>> epetra.
>>
>> # Look for 

[deal.II] step 21 runs error

[Nick Wang]

When using the function "project", we found the mapping is necessary(in 
vector_tools_project.templates.h),but in step21(line 1155) don't have 
mapping. So when we run this exe, it has error and we can't get results. 
Therefore, we want know how to change this problem.
[image: 1.png][image: 2.png]
Thanks,
Nick

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/c72ebdc7-d674-44e0-991d-794622168fd3n%40googlegroups.com.