Re: [deal.II] Re: Subdivided cylinder and boundary ids

[Alex Cumberworth]

Hi Bruno,

Sure, I can try making a PR this week.

Best,
Alex

On Sunday, June 27, 2021 at 9:36:50 p.m. UTC+2 blais...@gmail.com wrote:

> I most likely copied this mistake from the regular Cylinder and did not 
> think of it when I coded the subdivided cylinder.
> Alex, if you feel comfortable, you could go ahead and make a PR following 
> Wolfgang's suggestion. Otherwise, I'll gladly look into it this week :)
> Best
> BRuno
>
>
> On Friday, June 25, 2021 at 11:52:51 p.m. UTC-4 Wolfgang Bangerth wrote:
>
>> On 6/25/21 12:37 PM, Marc Fehling wrote:
>> > # Instead of an absolute threshold, you can introduce a relative one, 
>> for 
>> > example, `epsilon * cell->diameter()` or something similar.
>>
>> FWIW, in most places, this is what we do.
>> 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/d0c5b90e-5f8e-4ed7-b492-5365f5ae4329n%40googlegroups.com.

[deal.II] Subdivided cylinder and boundary ids

[Alex Cumberworth]

I have been trying to construct a system that is small (a total length of 
1e-5 m) with the subdivided cylinder grid generator. However, I have been 
having trouble with the boundary indicators. I wanted to set my own 
boundaries, and because there is no colorize option (it defaults to setting 
the left end face of the cylinder to 1, and the right end to 2), I tried to 
first set all boundary ids to 0. However, this leads to the following 
exception:

terminate called after throwing an instance of 
'dealii::TriaAccessorExceptions::ExcNoPeriodicNeighbor'
  what():  

An error occurred in line <2597> of file 
 
in function
dealii::TriaIterator > 
dealii::CellAccessor::neighbor_or_periodic_neighbor(unsigned 
int) const [with int dim = 3; int spacedim = 3]
The violated condition was: 
false
Additional information: 
(none)

Since in my test system, I was setting the boundary ids to be the same as 
the default, I tried to rely on this instead. However, I was having strange 
behaviour where it seemed that the entire system was having the boundary 
conditions applied to it. I scrolled through grid_generator.cc and found 
that subdivided_cylinder has a hardcoded epsilon of 1e-5 for determining 
whether a face is at the boundary. Of course, with a system of my size, all 
faces will end up being considered to be at the boundary.

Because it not only sets the boundary ids, but the manifold ids, it seems I 
will have to modify the subdivided_cylinder to make the epsilon value much 
smaller or somehow relative to the system size, which is simple enough.

It would probably also be good to have the colorize option. However, I am 
not sure what to make of the exception when I try to set all the boundary 
ids to 0.

Best,
Alex

-- 
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/3428a9ad-a1d4-4106-86e0-73f806fe2e46n%40googlegroups.com.

[deal.II] Integrating with curved manifolds

[Alex Cumberworth]

I am working with a mesh generated from subdivided_cylinder, and am 
wondering whether the area and volume should be assumed to match that of a 
true cylinder, or if it only converges to that when many refinements are 
made. I would like to calculate the total energy of the system by 
integrating over the whole volume, as well as calculate shear forces by 
integrating over faces on the surface.

I am trying to compare the results of the FEM code to that of 
Euler-Bernoulli beam theory, similarly to how was done in this question. 
 
Basically, I use Dirichlet conditions and hold one end in place, while the 
other end is displaced by small amount in the positive y direction. In this 
case, I use a radius of 1, a total length of 20, and a displacement of 0.1. 
When I ran this calculation with a regular flat manifold (i.e., a standard 
rectangular cuboid beam), I found that I only needed to refine along the 
beam axis (x) in order to converge to the analytical results from beam 
theory. However, here I am finding that no matter how much I refine along 
the beam axis, the result does not converge, and in fact barely changes at 
all. When I refine in all directions, then the energy and shear force 
increase, although they then overshoot the analytical result.

[image: cylinder_shear-force_refined.png]

To be clear, for calculating the beam theory result, I used the same 
expression as for the rectangular cuboid beam, but with a different second 
moment of area, and this was in agreements with the FEM calculations with 
the rectangular cuboid beam. I am using quadratic elements.

Any thoughts would be greatly appreciated,

Alex

-- 
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/8053cd87-91a2-4c36-8bc9-c9cc6a905dfan%40googlegroups.com.

[deal.II] Re: Deal.II site appears to be down

[Alex Cumberworth]

I am also unable to access the website, although it is specifically the 
documentation pages that are down.

Best,
Alex

On Monday, June 14, 2021 at 2:16:08 a.m. UTC+2 corbin@gmail.com wrote:

> Hello everyone,
>
> It seems dealii.org is experiencing some problems or is down (I'm on the 
> east coast of the US)--checking on 
> https://downforeveryoneorjustme.com/dealii.org, it seems the server is 
> not responding and the issue isn't local to me.
>
> I'm posting this for the site admins just in case I'm the first to notice.
>
> Best,
> Corbin 
>

-- 
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/0ca30dd9-eab3-4c5a-b00f-27efe8e9bf21n%40googlegroups.com.

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

[Alex Cumberworth]

Hi Wolfgang,

I tried a quadratic element, and was able to reduce the number of degrees 
of freedom for the same level of convergence by another order of magnitude. 
Thanks!

Best,
Alex

On Friday, June 11, 2021 at 3:34:08 p.m. UTC+2 Wolfgang Bangerth wrote:

> On 6/11/21 4:04 AM, Alex Cumberworth wrote:
> > 
> > To answer the question I posed, I did some more tests and found that 
> refining 
> > in the width and height of the beam has no effect on the convergence of 
> the 
> > shear force. I went down to just a single division in z and 2 in y (in 
> other 
> > words there are just two faces when looking down the end of the beam), 
> and 
> > could get the same level of agreement with beam theory with one order of 
> > magnitude fewer degrees of freedom. I guess I am still mildly surprised 
> how 
> > refined I had to made the x direction, but perhaps if I also used 
> adaptive 
> > refinement things would further improve.
>
> You might also want to try quadratic or cubic elements. For smooth 
> solutions, 
> that often does wonders!
>
> 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/26a2014b-3001-4765-8794-babd2b0a6ce1n%40googlegroups.com.

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

[Alex Cumberworth]

Hi Michael,

I think that is the first point in my code that something from the 
automatic differentiation module is referred to, which is a part of 
trilinos. Was your version of deal.ii compiled with trilinos, and if so, 
was your version of trilinos compiled with sacado?

To answer the question I posed, I did some more tests and found that 
refining in the width and height of the beam has no effect on the 
convergence of the shear force. I went down to just a single division in z 
and 2 in y (in other words there are just two faces when looking down the 
end of the beam), and could get the same level of agreement with beam 
theory with one order of magnitude fewer degrees of freedom. I guess I am 
still mildly surprised how refined I had to made the x direction, but 
perhaps if I also used adaptive refinement things would further improve.

Best,
Alex

On Thursday, June 10, 2021 at 6:20:58 p.m. UTC+2 lian...@gmail.com wrote:

> Alex, 
>
>  
>
> Thank you for sharing your codes. I have some compiling errors relating to 
> “EnergyFunctional’: 
>
> solve_ring_nonlinear.cpp:520:43: error: ‘*EnergyFunctional’* in namespace 
> ‘dealii::Differentiation::AD’ *does not name a template type*
>
>   520 | using ADHelper = Differentiation::AD::EnergyFunctional<
>
>   |   ^~~~
>
> Can you help me with that?
>
>  
>
> For the large error, I noticed you’re using linear element. I encountered 
> the same large error when comparing it with Abaqus with FE_Q(1). But the 
> error came down with less grids when I used higher finite element 
> FE_Q(2). I remember the deflection of beam is a cubic function of 
> coordinate. You may try that see if it improves.
>
>  
>
> Best,
>
> Michael
>
>  
>
> *From: *Alex Cumberworth
> *Sent: *Wednesday, June 9, 2021 9:54 AM
> *To: *deal.II User Group
> *Subject: *[deal.II] Re: Integrated material and spatial traction forces 
> on boundary not equal
>
>  
>
> Hello,
>
>  
>
> I have attached the most recent version of my code here. I have tried to 
> make setting boundary conditions in the parameter file more convenient for 
> myself; you can set boundary domains, boundary conditions that use these 
> domains, and stages if the displacement is large. However, there are not 
> many comments, so you may want to just remove this part for your own 
> purposes.
>
>  
>
> However, I have been a bit surprised in my comparisons at how fine a mesh 
> is required to achieve convergence with the beam theory result. I am now 
> using a beam that is 1 x 2 x 20, and using the subdivided rectangle helper 
> function, I set the number of subdivisions to be 5 and 10 for the width and 
> height, respectively. I then varied the number of subdivision in the length 
> between 10 and 1000. The beam theory result is that the shear force has a 
> magnitude of 0.001 for a displacement on the right side of 0.1. Even at 
> 1000 subdivisions, the FEM result is 0.00113 (from 0.00129 at 500). The 
> system has 200 000 degrees of freedom, and the result is still off by 13%. 
> Is it expected that even to calculate a shear force in this simple problem 
> that such a large number of degrees of freedom are required?
>
>  
>
>  
>
> Best,
>
> Alex
>
>  
>
> On Monday, June 7, 2021 at 3:39:44 p.m. UTC+2 lian...@gmail.com wrote:
>
>
> 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, bea

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

[Alex Cumberworth]

Hello,

I finally managed to get everything compiled and running. To solve the last 
issue, I started completely fresh with trilinos, and it no longer tried to 
find the static version of sacado. I think there must have been something 
leftover in the cmake files in the installation of trilinos from a previous 
build without the build shared libraries option in trilinos configuration.

To summarize the more generalizable issues from this:

- If there are issues when including trilinos in the build, consider 
compiling trilinos with MPI to ensure it will have the same MPI version as 
deal.ii
- If there are weird MPI issues with not finding header files, make sure 
that MPI was set on the first call of cmake (as I think one thing that 
happened here was I changed it later and the compiler did not get updated 
to the proper mpi wrapper, or at least I noticed this when compiling 
trilinos)
- If you are running on a cluster system with loadable modules, make sure 
things are properly loaded (and or unloaded) before running cmake. This 
could be especially relevant when there are multiple MPI implementations 
present
- Check whether the cmake variables are what you think they are (e.g., 
check uppercase vs lower case)

I never did get deal.ii to compile when including tpetra, but since I 
didn't need it I didn't attempt again with the other issues solved, so I 
can't say too much more about that.

One thing that is still unclear to me: is it possible to compile trilinos 
and deal.ii without MPI? It seemed here that there are wrapper classes that 
trilinos will only compile if MPI is enabled? If this is true, perhaps that 
should be included on this this page 
<https://www.dealii.org/9.1.1/external-libs/trilinos.html>?

Thanks to everyone that helped!

Best,
Alex

On Tuesday, June 8, 2021 at 6:37:09 a.m. UTC+2 vachanpo...@gmail.com wrote:

> 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: 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+un...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/59c24d

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] 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] 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 
>> <https://www.dealii.org/current/doxygen/deal.II/classLinearAlgebra_1_1VectorSpaceVector.html>
>>  
>> 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,
>>  
>>
>>  
>>   

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 
>> wi

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

[Alex Cumberworth]

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 Epetra_config.h - we'll query it to determine MPI and 64bit
> # indices support:
> #
> DEAL_II_FIND_FILE(EPETRA_CONFIG_H Epetra_config.h
>   HINTS ${Trilinos_INCLUDE_DIRS}
>
>   NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH
>   NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH
>   )
>
> Notice the hint: it is Trilinos_INCLUDE_DIRS and 
> not TRILINOS_INCLUDE_DIRS. If your dealii version also has Trilinos in 
> smallcase, then maybe making this change will do the job. You may even try 
> manually adding the full path in the cmake module file as a hint.
>
> Hope this helps
> Vachan
>
> On Thu, 3 Jun 2021 at 15:07, Alex Cumberworth  
> wrote:
>
>> Hello,
>>
>> The file does exist and is readable. If I set a manual include flag it is 
>> able to find it:
>>
>> CMAKE_CXX_FLAGS_DEBUGRELEASE  
>> -I/opt/ohpc/pub/libs/gnu9/openmpi4/trilinos/13.0.0/include
>>
>> then it is able to get past this point. From the output in my previous 
>> message, it seems that cmake is not looking in the right place for these 
>> header files, and I have no idea how to set this properly:
>>
>> --   TRILINOS_INCLUDE_DIRS: 
>> /include;/opt/ohpc/pub/libs/gnu9/openmpi4/hdf5/1.10.6/include;/usr/include;/opt/ohpc/pub/libs/gnu9/openmpi4/boost/1.73.0/include
>> --   TRILINOS_USER_INCLUDE_DIRS: 
>> /include;/opt/ohpc/pub/libs/gnu9/openmpi4/hdf5/1.10.6/include;/usr/include;/opt/ohpc/pub/libs/gnu9/openmpi4/boost/1.73.0/include
>>
>> There are further issues past this point, but perhaps if I understand the 
>> problem here that will help with the later issues.
>>
>> Best,
>> Alex
>>
>> On Tuesday, June 1, 2021 at 9:02:12 p.m. UTC+2 Wolfgang Bangerth wrote:
>>
>>>
>>> Alex, 
>>>
>>> > I have also tried 
>>> > 
>>> > cmake -DTRILINOS_DIR=/opt/ohpc/pub/libs/gnu9/openmpi4/trilinos/13.0.0  
>>> .. 
>>> > 
>>> > It is also unable to find the epetra header file. 
>>>
>>> I can not tell why that would be so (but you should be able to find out 
>>> by 
>>> searching for the place in CMakeFiles/CMakeErrors.log where it shows you 
>>> the 
>>> command that was executed to find that file). It may be that the file 
>>> just 
>>> doesn't exist. It may be that it's not readable. It may be that the 
>>> compiler 
>>> finds an error in it. 
>>>
>>> If you can't figure out how to use that installation, why not install 
>>> Trilinos 
>>> yourself in your home directory and take it from there? 
>>>
>>> Best 
>>> W. 
>>>
>>>
>>> -- 
>>>  
>>> Wolfgang Bangerth email: bang...@colostate.edu 
>>> ww

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

[Alex Cumberworth]

Hello,

The file does exist and is readable. If I set a manual include flag it is 
able to find it:

CMAKE_CXX_FLAGS_DEBUGRELEASE  
-I/opt/ohpc/pub/libs/gnu9/openmpi4/trilinos/13.0.0/include

then it is able to get past this point. From the output in my previous 
message, it seems that cmake is not looking in the right place for these 
header files, and I have no idea how to set this properly:

--   TRILINOS_INCLUDE_DIRS: 
/include;/opt/ohpc/pub/libs/gnu9/openmpi4/hdf5/1.10.6/include;/usr/include;/opt/ohpc/pub/libs/gnu9/openmpi4/boost/1.73.0/include
--   TRILINOS_USER_INCLUDE_DIRS: 
/include;/opt/ohpc/pub/libs/gnu9/openmpi4/hdf5/1.10.6/include;/usr/include;/opt/ohpc/pub/libs/gnu9/openmpi4/boost/1.73.0/include

There are further issues past this point, but perhaps if I understand the 
problem here that will help with the later issues.

Best,
Alex

On Tuesday, June 1, 2021 at 9:02:12 p.m. UTC+2 Wolfgang Bangerth wrote:

>
> Alex,
>
> > I have also tried
> > 
> > cmake -DTRILINOS_DIR=/opt/ohpc/pub/libs/gnu9/openmpi4/trilinos/13.0.0  ..
> > 
> > It is also unable to find the epetra header file.
>
> I can not tell why that would be so (but you should be able to find out by 
> searching for the place in CMakeFiles/CMakeErrors.log where it shows you 
> the 
> command that was executed to find that file). It may be that the file just 
> doesn't exist. It may be that it's not readable. It may be that the 
> compiler 
> finds an error in it.
>
> If you can't figure out how to use that installation, why not install 
> Trilinos 
> yourself in your home directory and take it from there?
>
> 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/1f525829-638b-42f4-badd-01d70d5de9efn%40googlegroups.com.

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

[Alex Cumberworth]

 TRILINOS_TPETRA_IS_FUNCTIONAL
-- Performing Test TRILINOS_TPETRA_IS_FUNCTIONAL - Failed
-- Tpetra was found but is not usable! Disabling Tpetra support.
-- Performing Test TRILINOS_MUELU_IS_FUNCTIONAL
-- Performing Test TRILINOS_MUELU_IS_FUNCTIONAL - Failed
-- MueLu was found but is not usable through Epetra! Disabling MueLu 
support.
-- SACADO_CONFIG_H not found! Call:
-- FIND_FILE(SACADO_CONFIG_H Sacado_config.h HINTS /include 
NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH 
NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH)
-- SACADO_TRAD_HPP not found! Call:
-- FIND_FILE(SACADO_TRAD_HPP Sacado_trad.hpp HINTS /include 
NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH 
NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH)
-- DEAL_II_WITH_TRILINOS successfully set up with external dependencies.

Best,
Alex

On Thursday, May 27, 2021 at 3:21:19 p.m. UTC+2 Wolfgang Bangerth wrote:

> On 5/27/21 4:25 AM, Alex Cumberworth wrote:
> > 
> > However, trilinos is loaded as a module, and even with the fresh 
> configuration 
> > it is unable to find the header. Even with
> > 
> > //Path to a file.
> > 
> SACADO_CONFIG_H:FILEPATH=/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include/Sacado.hpp
> > 
> > //Path to a file.
> > 
> SACADO_TRAD_HPP:FILEPATH=/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include/Sacado_trad.hpp
> > 
> > in the CMakeCache.txt, and rerunning cmake, it is still unable to 
> actually 
> > Sacado.hpp while compiling. I am also trying to contact the cluster 
> > administrators to double check they have installed trilinos correctly, 
> but I 
> > still find it odd that even specifying the exact location of the headers 
> in 
> > the cmake configuration still does not results in a successful 
> compilation.
>
> Are any of the other Trilinos header files found? Is the file readable?
>
> cmake does not communicate the location of individual header files to the 
> compiler, just include paths. So if the compiler can find one Trilinos 
> header 
> file, it should find them all.
>
> 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/8481572f-143a-4a7a-98c7-61aa6f9acbdbn%40googlegroups.com.

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

[Alex Cumberworth]

I am working on the cluster that is available at my research institute, so 
I don't actually have root access. It is CentOS 8.3.2011 with openHPC. With 
the weird stl header file issues, it seemed that the compiler module had 
not been properly loaded, and then when I did properly load it, I didn't 
start a fresh configuration, and so the problems persisted. Now that I have 
done that the issues with math.h are solved.

However, trilinos is loaded as a module, and even with the fresh 
configuration it is unable to find the header. Even with

//Path to a file.
SACADO_CONFIG_H:FILEPATH=/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include/Sacado.hpp

//Path to a file.
SACADO_TRAD_HPP:FILEPATH=/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include/Sacado_trad.hpp

in the CMakeCache.txt, and rerunning cmake, it is still unable to actually 
Sacado.hpp while compiling. I am also trying to contact the cluster 
administrators to double check they have installed trilinos correctly, but 
I still find it odd that even specifying the exact location of the headers 
in the cmake configuration still does not results in a successful 
compilation.
On Thursday, May 27, 2021 at 5:53:48 a.m. UTC+2 Wolfgang Bangerth wrote:

> On 5/26/21 11:17 AM, Alex Cumberworth wrote:
> > It seems that the issues stem from not setting the include directories 
> > properly. Even with CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH set as 
> I 
> > mentioned in my previous response, I am running into errors. The 
> compilation 
> > proceeds for a while, but then at some point when cmath is included, it 
> fails 
> > to find math.h,
> > 
> > [ 42%] Building CXX object 
> > source/sundials/CMakeFiles/obj_sundials_release.dir/arkode.cc.o
> > 
> > In file included from 
> > 
> /home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/base/numbers.h:28,
> >  from 
> > 
> /home/ipausers/cumberworth/src/dealii-9.2.0/build/include/deal.II/base/config.h:449,
> >  from 
> > /home/ipausers/cumberworth/src/dealii-9.2.0/source/sundials/arkode.cc:17:
> > /opt/ohpc/pub/compiler/gcc/9.3.0/include/c++/9.3.0/cmath:45:15: fatal 
> error: 
> > math.h: No such file or directory
> >45 | #include_next 
> >   |   ^~~~
> > compilation terminated.
> > 
> > If I use make VERBOSE=1, I can manually modify the command to include
> > 
> > -isystem /opt/ohpc/pub/compiler/gcc/9.3.0/include/c++/9.3.0
> > 
> > which solves that issue, but I don't know how to add this during 
> > configuration.
>
> I suspect that you will get an endless sequence of problems beyond just 
> this 
> one if you go down the road of trying to address this with compiler flags. 
> I 
> suspect that what is happening is that you compiled and installed GCC 9.3 
> yourself, and then moved everything from the directory you installed it in 
> to 
> /opt/ohpc/pub/compiler/gcc/9.3.0? You will have to install GCC in a way so 
> that it knows where not only its header files are, but also the libraries, 
> the 
> linker, etc.
>
> What happens if you use that compiler (without passing extra flags) to 
> compile 
> a trivial .cc file that only #includes ?
>
> 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/3fb19862-5d00-4ad2-9bc7-eb065bcc19b8n%40googlegroups.com.

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

[Alex Cumberworth]

It seems that the issues stem from not setting the include directories 
properly. Even with CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH set as I 
mentioned in my previous response, I am running into errors. The 
compilation proceeds for a while, but then at some point when cmath is 
included, it fails to find math.h,

[ 42%] Building CXX object 
source/sundials/CMakeFiles/obj_sundials_release.dir/arkode.cc.o

In file included from 
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/base/numbers.h:28,
 from 
/home/ipausers/cumberworth/src/dealii-9.2.0/build/include/deal.II/base/config.h:449,
 from 
/home/ipausers/cumberworth/src/dealii-9.2.0/source/sundials/arkode.cc:17:
/opt/ohpc/pub/compiler/gcc/9.3.0/include/c++/9.3.0/cmath:45:15: fatal 
error: math.h: No such file or directory
   45 | #include_next 
  |   ^~~~
compilation terminated.

If I use make VERBOSE=1, I can manually modify the command to include

-isystem /opt/ohpc/pub/compiler/gcc/9.3.0/include/c++/9.3.0

which solves that issue, but I don't know how to add this during 
configuration. I tried setting

CMAKE_CXX_FLAGS_DEBUGRELEASE -isystem 
/opt/ohpc/pub/compiler/gcc/9.3.0/include/c++/9.3.0

But it seems to put the flag in the wrong order, as it still is unable to 
find math.h.

In compiling a later file, it is unable to find the sacado header file, 
although it exists on the system and cmake seemed to indicate it had found 
the headers. I have set

SACADO_CONFIG_H  
/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include
SACADO_TRAD_HPP  
/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include

but this doesn't work.

In file included from 
/home/ipausers/cumberworth/src/dealii-9.2.0/build/include/deal.II/base/config.h:449,
 from 
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/base/exceptions.h:19,
 from 
/home/ipausers/cumberworth/src/dealii-9.2.0/source/dofs/dof_objects.cc:16:
/home/ipausers/cumberworth/src/dealii-9.2.0/include/deal.II/base/numbers.h:151:12:
 
fatal error: Sacado.hpp: No such file or directory
  151 | #  include 
  |^~~~
compilation terminated.

Again, I can set

-I/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include

to compile, but then there are still further issues with other headers not 
being found.

Best,

Alex
On Monday, May 24, 2021 at 5:22:57 p.m. UTC+2 Wolfgang Bangerth wrote:

> On 5/21/21 11:03 AM, Alex Cumberworth wrote:
> > 
> > I don't really see how this can be, as this version of the compiler 
> fully 
> > supports C++11. I also tried setting the flag DEAL_II_CXX_VERSION_FLAG, 
> but 
> > using valid standard specifiers just results in errors like "The 
> supplied flag 
> > "c++11" was not recognized by the compiler." To be clear, I ran
> > 
> > cmake .. -DDEAL_II_CXX_VERSION_FLAG=c++11
>
> Try
> cmake .. -DDEAL_II_CXX_VERSION_FLAG="-std=c++11"
> or
> cmake .. -DDEAL_II_CXX_VERSION_FLAG=-std=c++11
> and see whether that works.
>
> GCC 9.2 is new enough so that it should work. There is probably something 
> else 
> that doesn't work, and you can find out what that is by looking at
> CMakeFiles/CMakeOutput.log
> CMakeFiles/CMakeError.log
>
> These files are lengthy, so it may take a bit of searching for the place 
> where 
> the C++11 flags are set.
>
> 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/afdb75a3-90dc-49a7-b0b2-6217a40d77dcn%40googlegroups.com.

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

[Alex Cumberworth]

Hi Bruno,

It turns out that it was unable to find the header files, as once I set 
CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH, it was able to pass the 
tests.

Thanks for your help,
Alex
On Friday, May 21, 2021 at 7:54:47 p.m. UTC+2 bruno.t...@gmail.com wrote:

> Alex,
>
> I think that deal.II picks the compiler correctly but it looks like
> the stl library is too old. What version of libstdc++ is installed on
> the system?
>
> Best,
>
> Bruno
>
> Le ven. 21 mai 2021 à 13:41, Alex Cumberworth
>  a écrit :
> >
> > Hi Bruno,
> >
> > From the output when I run a fresh configuration:
> >
> > -- The CXX compiler identification is GNU 9.3.0
> > -- The C compiler identification is GNU 9.3.0
> > -- Check for working CXX compiler: 
> /opt/ohpc/pub/compiler/gcc/9.3.0/bin/c++
> > -- Check for working CXX compiler: 
> /opt/ohpc/pub/compiler/gcc/9.3.0/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> >
> > and then bit further down
> >
> > -- Include 
> /home/ipausers/cumberworth/src/dealii-9.2.0/cmake/checks/check_01_cxx_features.cmake
> > -- Performing Test DEAL_II_HAVE_FLAG_stdcxx17
> > -- Performing Test DEAL_II_HAVE_FLAG_stdcxx17 - Success
> > -- Using C++ version flag "-std=c++17"
> > -- Performing Test DEAL_II_HAVE_CXX17_ATTRIBUTES
> > -- Performing Test DEAL_II_HAVE_CXX17_ATTRIBUTES - Failed
> > -- Performing Test DEAL_II_HAVE_CXX17_IF_CONSTEXPR
> > -- Performing Test DEAL_II_HAVE_CXX17_IF_CONSTEXPR - Success
> > -- Performing Test DEAL_II_NON_CONSTEXPR_LAMBDA
> > -- Performing Test DEAL_II_NON_CONSTEXPR_LAMBDA - Failed
> > -- Performing Test DEAL_II_HAVE_FLAG_stdcxx14
> > -- Performing Test DEAL_II_HAVE_FLAG_stdcxx14 - Success
> > -- Performing Test DEAL_II_HAVE_CXX14_MAKE_UNIQUE
> > -- Performing Test DEAL_II_HAVE_CXX14_MAKE_UNIQUE - Failed
> > -- Performing Test DEAL_II_HAVE_CXX14_CONSTEXPR_STDMAXMIN
> > -- Performing Test DEAL_II_HAVE_CXX14_CONSTEXPR_STDMAXMIN - Failed
> > -- Performing Test DEAL_II_HAVE_CXX14_CLANGAUTODEBUG_BUG_OK
> > -- Performing Test DEAL_II_HAVE_CXX14_CLANGAUTODEBUG_BUG_OK - Success
> > -- Performing Test DEAL_II_HAVE_FLAG_stdcxx11
> > -- Performing Test DEAL_II_HAVE_FLAG_stdcxx11 - Success
> > -- Performing Test DEAL_II_HAVE_CXX11_FEATURES
> > -- Performing Test DEAL_II_HAVE_CXX11_FEATURES - Failed
> > -- Performing Test DEAL_II_HAVE_CXX11_FUNCTIONAL_LLVMBUG20084_OK
> > -- Performing Test DEAL_II_HAVE_CXX11_FUNCTIONAL_LLVMBUG20084_OK - Failed
> > -- Performing Test DEAL_II_HAVE_CXX11_MACOSXC99BUG_OK
> > -- Performing Test DEAL_II_HAVE_CXX11_MACOSXC99BUG_OK - Success
> > -- Performing Test DEAL_II_HAVE_CXX11_ICCNUMERICLIMITSBUG_OK
> > -- Performing Test DEAL_II_HAVE_CXX11_ICCNUMERICLIMITSBUG_OK - Success
> > -- Performing Test DEAL_II_HAVE_CXX11_ICCLIBSTDCPP47CXX11BUG_OK
> > -- Performing Test DEAL_II_HAVE_CXX11_ICCLIBSTDCPP47CXX11BUG_OK - Success
> > CMake Error at cmake/checks/check_01_cxx_features.cmake:472 (MESSAGE):
> >
> > Alex
> >
> > On Friday, May 21, 2021 at 7:35:16 p.m. UTC+2 bruno.t...@gmail.com 
> wrote:
> >>
> >> Alex,
> >>
> >> Can you check that deal.II pick up the right compiler? It should be 
> printed on your screen. You don't need to specify DEAL_II_CXX_VERSION_FLAG 
> when using gcc.
> >>
> >> Best,
> >>
> >> Bruno
> >>
> >> On Friday, May 21, 2021 at 1:03:13 PM UTC-4 alexanderc...@gmail.com 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am trying to compile deal.II, version 9.2, on CentOS 8.3.2011 (the 
> last version). I have gcc 9.3.0, which is relatively recent. However, when 
> I run cmake, I end up with the following message:
> >>>
> >>> The current combination of compiler and C++ version flag is missing 
> some
> >>> features of the C++11 version of the language necessary for compiling
> >>> deal.II. Please ensure that the CMake variable 
> DEAL_II_CXX_VERSION_FLAG is
> >>> set to the correct flag to enable C++11 support; if it is already set 
> and
> >>> you still see this message then you will need to upgrade your compiler.
> >>>
> >>> I don't really see how this can be, as this version of the compiler 
> fully supports C++11. I also tried setting the flag 
> DEAL_II_CXX_VERSION_FLAG, but using valid standard specifiers just results 
> in errors like "The supplied flag "c++11" was not

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

[Alex Cumberworth]

Hi Bruno,

>From the output when I run a fresh configuration:

-- The CXX compiler identification is GNU 9.3.0
-- The C compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /opt/ohpc/pub/compiler/gcc/9.3.0/bin/c++
-- Check for working CXX compiler: /opt/ohpc/pub/compiler/gcc/9.3.0/bin/c++ 
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done

and then bit further down

-- Include 
/home/ipausers/cumberworth/src/dealii-9.2.0/cmake/checks/check_01_cxx_features.cmake
-- Performing Test DEAL_II_HAVE_FLAG_stdcxx17
-- Performing Test DEAL_II_HAVE_FLAG_stdcxx17 - Success
-- Using C++ version flag "-std=c++17"
-- Performing Test DEAL_II_HAVE_CXX17_ATTRIBUTES
-- Performing Test DEAL_II_HAVE_CXX17_ATTRIBUTES - Failed
-- Performing Test DEAL_II_HAVE_CXX17_IF_CONSTEXPR
-- Performing Test DEAL_II_HAVE_CXX17_IF_CONSTEXPR - Success
-- Performing Test DEAL_II_NON_CONSTEXPR_LAMBDA
-- Performing Test DEAL_II_NON_CONSTEXPR_LAMBDA - Failed
-- Performing Test DEAL_II_HAVE_FLAG_stdcxx14
-- Performing Test DEAL_II_HAVE_FLAG_stdcxx14 - Success
-- Performing Test DEAL_II_HAVE_CXX14_MAKE_UNIQUE
-- Performing Test DEAL_II_HAVE_CXX14_MAKE_UNIQUE - Failed
-- Performing Test DEAL_II_HAVE_CXX14_CONSTEXPR_STDMAXMIN
-- Performing Test DEAL_II_HAVE_CXX14_CONSTEXPR_STDMAXMIN - Failed
-- Performing Test DEAL_II_HAVE_CXX14_CLANGAUTODEBUG_BUG_OK
-- Performing Test DEAL_II_HAVE_CXX14_CLANGAUTODEBUG_BUG_OK - Success
-- Performing Test DEAL_II_HAVE_FLAG_stdcxx11
-- Performing Test DEAL_II_HAVE_FLAG_stdcxx11 - Success
-- Performing Test DEAL_II_HAVE_CXX11_FEATURES
-- Performing Test DEAL_II_HAVE_CXX11_FEATURES - Failed
-- Performing Test DEAL_II_HAVE_CXX11_FUNCTIONAL_LLVMBUG20084_OK
-- Performing Test DEAL_II_HAVE_CXX11_FUNCTIONAL_LLVMBUG20084_OK - Failed
-- Performing Test DEAL_II_HAVE_CXX11_MACOSXC99BUG_OK
-- Performing Test DEAL_II_HAVE_CXX11_MACOSXC99BUG_OK - Success
-- Performing Test DEAL_II_HAVE_CXX11_ICCNUMERICLIMITSBUG_OK
-- Performing Test DEAL_II_HAVE_CXX11_ICCNUMERICLIMITSBUG_OK - Success
-- Performing Test DEAL_II_HAVE_CXX11_ICCLIBSTDCPP47CXX11BUG_OK
-- Performing Test DEAL_II_HAVE_CXX11_ICCLIBSTDCPP47CXX11BUG_OK - Success
CMake Error at cmake/checks/check_01_cxx_features.cmake:472 (MESSAGE):

Alex

On Friday, May 21, 2021 at 7:35:16 p.m. UTC+2 bruno.t...@gmail.com wrote:

> Alex,
>
> Can you check that deal.II pick up the right compiler? It should be 
> printed on your screen. You don't need to specify DEAL_II_CXX_VERSION_FLAG 
> when using gcc. 
>
> Best,
>
> Bruno
>
> On Friday, May 21, 2021 at 1:03:13 PM UTC-4 alexanderc...@gmail.com wrote:
>
>> Hello,
>>
>> I am trying to compile deal.II, version 9.2, on CentOS 8.3.2011 (the last 
>> version). I have gcc 9.3.0, which is relatively recent. However, when I run 
>> cmake, I end up with the following message:
>>
>>   The current combination of compiler and C++ version flag is missing some
>>   features of the C++11 version of the language necessary for compiling
>>   deal.II.  Please ensure that the CMake variable 
>> DEAL_II_CXX_VERSION_FLAG is
>>   set to the correct flag to enable C++11 support; if it is already set 
>> and
>>   you still see this message then you will need to upgrade your compiler.
>>
>> I don't really see how this can be, as this version of the compiler fully 
>> supports C++11. I also tried setting the flag DEAL_II_CXX_VERSION_FLAG, but 
>> using valid standard specifiers just results in errors like "The supplied 
>> flag "c++11" was not recognized by the compiler." To be clear, I ran
>>
>> cmake .. -DDEAL_II_CXX_VERSION_FLAG=c++11
>>
>> The version of cmake is 3.11.4.
>>
>> Any thoughts would be greatly appreciated.
>>
>> Alex
>>
>

-- 
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/8e4425ff-c296-4753-8f4d-f37668306373n%40googlegroups.com.

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

[Alex Cumberworth]

Hello,

I am trying to compile deal.II, version 9.2, on CentOS 8.3.2011 (the last 
version). I have gcc 9.3.0, which is relatively recent. However, when I run 
cmake, I end up with the following message:

  The current combination of compiler and C++ version flag is missing some
  features of the C++11 version of the language necessary for compiling
  deal.II.  Please ensure that the CMake variable DEAL_II_CXX_VERSION_FLAG 
is
  set to the correct flag to enable C++11 support; if it is already set and
  you still see this message then you will need to upgrade your compiler.

I don't really see how this can be, as this version of the compiler fully 
supports C++11. I also tried setting the flag DEAL_II_CXX_VERSION_FLAG, but 
using valid standard specifiers just results in errors like "The supplied 
flag "c++11" was not recognized by the compiler." To be clear, I ran

cmake .. -DDEAL_II_CXX_VERSION_FLAG=c++11

The version of cmake is 3.11.4.

Any thoughts would be greatly appreciated.

Alex

-- 
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/2a7c0fe9-cc26-4f2c-8e9f-278f4d0eb6d3n%40googlegroups.com.

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

[Alex Cumberworth]

ng for the 
> "material force". Is ” piola_kirchhoff" really the symmetric, fully 
> referential Piola-Kirchhoff stress? If so, then no you cannot expect these 
> two quantities to match. F_{0} = \int_{dB_{0}} S . N dA is not the same 
> force as  F_{t}, but is rather a “pseudo-force” that describes some 
> reference traction per unit reference area. You need to push forward its 
> first index (i.e. compute P = F.S) and then you can get to computing F_{t} 
> as stated above.
>
> I hope that helps clear things up a bit.
>
> Best,
> Jean-Paul
>
>
> On 11. May 2021, at 12:46, Alex Cumberworth  
> 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.
>
> 
> 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_

Re: [deal.II] Calculating normal vectors to deformed surface with pushforward operation

[Alex Cumberworth]

Hi Jean-Paul,

Thanks for your response. The spatial normal vectors are now correct. It 
seems my lack of grounding in differential geometry was the culprit here.

However, the integrated forces are still not as I expect, but I think this 
is a separate issue, so I will create a new thread.

Best,
Alex
On Tuesday, May 4, 2021 at 6:58:33 p.m. UTC+2 Jean-Paul Pelteret wrote:

> Hi Alex,
>
> Well, the one thing that I can clearly identify as being problematic is 
> that the normal vector does not transform with the deformation gradient 
> (directly), but rather with its cofactor. This is what Nanson’s formula for 
> the transformation of surface areas tell us. We actually have a function 
> that does this transformation, namely 
> Physics::Transformations::nansons_formula() 
> <https://dealii.org/current/doxygen/deal.II/namespacePhysics_1_1Transformations.html#aa82925b742c3708f625a48a7abc440bc>
>  . 
> Maybe you could try to use that and see if you get the result that you’re 
> looking for.
>
> Best,
> Jean-Paul
>
> On 4. May 2021, at 12:36, Alex Cumberworth  
> wrote:
>
> Hello,
>
> I would like to calculate traction/stress vectors for the deformed 
> configuration. I have solved for a non-linear elasticity problem and am 
> dealing with the Green-Lagrange strain tensor and the second Piola-Kirchoff 
> stress tensor. I thought the simplest way to get the traction vectors would 
> be to first calculate them in the material reference frame (by calculating 
> the stress tensor and applying it to normal vectors in the material 
> reference), and then using a pushforward operation (by applying the 
> deformation gradient) to produce the stress vectors in the spatial 
> reference frame (and also dividing by the determinant of the deformation 
> vector to take care of the change in area).
>
> However, the results do not appear as expected. To understand what was 
> going on, I first decided to apply the pushforward operation to the normal 
> vectors. I used the following code to carry this out.
>
> template 
> class SpatialNormalVectorPostprocess: public DataPostprocessorVector {
>   public:
> SpatialNormalVectorPostprocess();
> virtual void evaluate_vector_field(
> const DataPostprocessorInputs::Vector& input_data,
> std::vector>& computed_quantities) const;
> };
>
> template 
> SpatialNormalVectorPostprocess::SpatialNormalVectorPostprocess():
> DataPostprocessorVector(
> "spatial_normal",
> update_gradients | update_normal_vectors) {}
>
> template 
> void SpatialNormalVectorPostprocess::evaluate_vector_field(
> const DataPostprocessorInputs::Vector& input_data,
> std::vector>& computed_quantities) const {
>
> for (unsigned int i {0}; i != input_data.normals.size(); i++) {
> Tensor<2, dim, double> grad_u {};
> Tensor<2, dim, double> identity_tensor {};
> for (unsigned int d {0}; d != dim; d++) {
> grad_u[d] = input_data.solution_gradients[i][d];
> identity_tensor[d][d] = 1;
> }
> const Tensor<2, dim, double> deformation_grad {
> grad_u + identity_tensor};
> const Tensor<1, dim, double> material_normal_vector {
> input_data.normals[i]};
> const Tensor<1, dim, double> spatial_normal_vector_t {
> deformation_grad * material_normal_vector};
> Vector spatial_normal_vector(dim);
> for (unsigned int d {0}; d != dim; d++) {
> spatial_normal_vector[d] = spatial_normal_vector_t[d];
> }
> computed_quantities[i] = spatial_normal_vector;
> }
> }
>
> However, as seen below, the resulting vectors are not normal to the 
> surfaces:
>
> 
>
> Contrast this with if I instead update the mesh and directly output the 
> normal vectors:
>
> 
>
> Any input would be greatly appreciated.
>
> Best wishes,
> Alex
>
> -- 
> 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+un...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/2e3fcd85-f799-419b-b66b-097513328f46n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/dealii/2e3fcd85-f799-419b-b66b-097513328f46n%40googlegroups.com?utm_medium=email_source=footer>
> .
> 
&g

Re: [deal.II] Inhomogeneous periodic boundary constraints

[Alex Cumberworth]

I ended up getting it working, so in case anyone else is interested in 
doing something similar, I have attached updated versions of the previous 
scripts. I further modified set_periodicity_constraints so that it can take 
a function to set the inhomogeneity based on the values of the two support 
points associated with the two degrees of freedom that are being tied 
together, although it would need to be modified for more general use (the 
functions works on the difference of the two points, and further it uses 
only the absolute value of the difference in the x-component). I have also 
not made changes to allow for adaptive mesh refinement. I think this is a 
pretty ugly solution to the general problem of inhomogeneous periodic 
boundary constraints, but I couldn't see how to do it without modifying 
these functions without largely replicating them.

The issues mentioned in the previous post regarding 
distribute_local_to_global() and AffineConstraints::distribute() stemmed 
from a misunderstanding of exactly what these functions were doing, and 
have been fixed. It does seem that with these constraints, SolverCG does 
not work as a solver (I suppose the matrix is not symmetric anymore?), but 
either SolverGMRES or the direct solver SparseDirectUMFPACK work.

The script has also been improved based on other tutorials, and now 
includes parsing for a parameter file. I tried to include an example 
parameter file but I guess the mailing list has a restriction on allowable 
file types.

Best,
Alex

-- 
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/0c692129-a363-4d67-98a7-8c7e04ba3892n%40googlegroups.com.
#ifndef modded_periodic_functions_h
#define modded_periodic_functions_h

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

using namespace dealii;

template 
void set_periodicity_constraints(
const FaceIterator& face_1,
const typename identity::type& face_2,
const FullMatrix& transformation,
AffineConstraints& affine_constraints,
const std::vector> dofs_to_supports,
Function& boundary_function,
const ComponentMask& component_mask,
const bool face_orientation,
const bool face_flip,
const bool face_rotation,
const number periodicity_factor) {
static const int spacedim = FaceIterator::AccessorType::space_dimension;

// we should be in the case where face_1 is active, i.e. has no children:
Assert(!face_1->has_children(), ExcInternalError());

Assert(face_1->n_active_fe_indices() == 1, ExcInternalError());

// TODO: the implementation makes the assumption that all faces have the
// same number of dofs
//AssertDimension(
//face_1->get_fe(face_1->nth_active_fe_index(0)).n_unique_faces(),
//1);
//AssertDimension(
//face_2->get_fe(face_2->nth_active_fe_index(0)).n_unique_faces(),
//1);
//const unsigned int face_no = 0;

// If face_2 does have children, then we need to iterate over these
// children and set periodic constraints in the inverse direction:
if (face_2->has_children()) {
Assert(face_2->n_children() == GeometryInfo::max_children_per_face,
   ExcNotImplemented());

const unsigned int dofs_per_face =
face_1->get_fe(face_1->nth_active_fe_index(0))
.n_dofs_per_face();
FullMatrix child_transformation(dofs_per_face, dofs_per_face);
FullMatrix subface_interpolation(dofs_per_face, dofs_per_face);

for (unsigned int c = 0; c < face_2->n_children(); ++c) {
// get the interpolation matrix recursively from the one that
// interpolated from face_1 to face_2 by multiplying from the left
// with the one that interpolates from face_2 to its child
const auto& fe = face_1->get_fe(face_1->nth_active_fe_index(0));
fe.get_subface_interpolation_matrix(fe, c, subface_interpolation);
subface_interpolation.mmult(child_transformation, transformation);

set_periodicity_constraints(
face_1,
face_2->child(c),
child_transformation,
affine_constraints,
dofs_to_supports,
boundary_function,
component_mask,
face_orientation,
face_flip,
face_rotation,
periodicity_factor);
 

Re: [deal.II] Inhomogeneous periodic boundary constraints

[Alex Cumberworth]

Hi Jean-Paul,

Thanks for the response. I realize I should have specified that the values 
of the inhomogeneities that I would like to use are the differences in the 
two points that are being glued together. This means that when I set the 
inhomogeneity for a degree of freedom, I actually need access to all the 
degrees of freedom with non-zero weights in the line of the constraint 
involved. In the end, it seemed that the set_periodicity_constraints and 
make_periodicity_constraints functions are mostly about going through and 
figuring out which DOFs are being linked, so it seemed easier to modify 
those functions than to add the inhomogeneities after calling them.

I implemented the modifications for when the faces are at the same level of 
refinement, but am now having trouble with the solver not converging. My 
problem of bending a bar around to glue the faces together to form a ring 
does not satisfy the assumption of infinitesimal strain, so I have included 
the nonlinear strain term to use the Saint Venant–Kirchhoff model of 
elasticity, and am using Newton's method to solve the problem. I was able 
to solve the same problem by setting the boundary conditions directly, 
although I had to solve the problem in stages in which I updated the 
boundary to move along a spiral path to achieve convergence. With the 
inhomogeneous periodic constraints, I also try solving the problem in 
stages in which I slowly move from a homogeneous problem (the solution of 
which is no deformation) to the final inhomogeneous problem, although with 
a more direct path. However, with even the smallest inhomogeneity, after a 
few Newton iterations, the residual from the CG solver suddenly becomes nan.

I am wondering whether I have setup the constraints properly, particularly 
whether I have called the functions to condense and distribute the problem 
correctly. In the "Constraints on degrees of freedom" module, step 1 of the 
second approach under "Treatment of inhomogeneous constraints" involves 
calling distribute_local_to_global() during assembly. In my case, because I 
will calculate the right hand side again with the updated solution to 
calculate the residual, I have to call this on two occaions. However, in 
calculating the residual, I only need to assemble the right hand side, so I 
first tried using the second variant of distribute_local_to_global(), which 
takes only the local matrix (in addition of course to the local and global 
RHS vector) as an argument. In the description of the function, it says it 
is used for situations involving inhomogeneous constraints where the global 
matrix does not need to be assembled again, which seems to apply here. 
However, the assembly in the next Newton iteration, which uses the same 
solution vector (with the step size alpha=1), produces a different result 
(where it calls variant 9 of the function). Have I misunderstood the 
difference between these two functions?

In step two of the second approach under "Constraints on degrees of freedom", 
it states "Set the concerning components of the solution to the 
inhomogeneous constrained values (for example using 
AffineConstraints::distribute())". However, in the step-22 example cited 
for use of inhomogeneous constraints, the distribute method on the 
constraints object is only called after running the linear solver (which I 
understand needs to be done as well), not before. In my own tests, it 
seemed to make no difference whether I called before solving or not. Are 
the solution components being set in some other function then?

I also wonder if I am using the wrong solver, preconditioner, and/or 
sparsity pattern for my problem. However before I can address that it seems 
I need to check I have set the constraints up properly. I have for now 
stuck with the choices made in the early tutorial steps of SolverCG, 
PreconditionSSOR, and copying from a DynamicSparsityPattern object to 
SparsityPattern.

I have attached an example program for solving my problem, as well as the 
file with the modifications to the periodic boundary conditions functions. 
The main modifications to the periodic boundary conditions functions are on 
lines 310-314, where I calculate the difference between the position of the 
support points the DOFs are associated with and set the inhomogeneity for 
the current DOF. I did print out the values of the component being used, 
and this part at least appears to be correct.

Any further thoughts would be much appreciated.

Best,
Alex

-- 
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 

[deal.II] Inhomogeneous periodic boundary constraints

[Alex Cumberworth]

I need to implement periodic boundary constraints with inhomogeneities. 
>From reading through the documentation and source code of the library, it 
seems that to do this I will need to modify the set_periodicity_constraints 
function in the dof_tools_constraints.cc file to also add an inhomogeneity. 
Is there a simpler way to do this that I missed that allows me to use the 
make_periodicity_constraints() function and then add the inhomogeneity 
after calling it?

To give some context, I am solving an elasticity problem that involves 
taking a beam, deforming it, and "glueing" together some of the faces (e.g. 
to form a ring -- I included an image of this in a previous post 
).

Any thoughts would be greatly appreciated.

Best,
Alex

-- 
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/777d38f4-bc4d-459d-aef6-63c35143997dn%40googlegroups.com.

Re: [deal.II] Tie constraints in deall.II?

[Alex Cumberworth]

Thanks for the information. Unfortunately I am more interested in the 
second case, so I will look around for examples of the mortar 
element/master slave approach.

Alex

On Thursday, December 17, 2020 at 2:11:14 a.m. UTC+1 Wolfgang Bangerth 
wrote:

>
> > I am considering switching to deal.II for carrying out my elasticity 
> > calculations, but I am not sure from the documentation, tutorials, and 
> this 
> > user group if it is not too difficult to create a constraint between two 
> > surfaces such that they are bonded, or forced to be continuous. In 
> ABAQUS this 
> > is called a tie constraint 
>
> If you can make the mesh at the ends of your object match (e.g., if you 
> want 
> to bend your object into a ring), then the construction of these 
> constraints 
> is essentially identical to how one imposes periodic constraints -- 
> namely, 
> that each degree of freedom one end has to be some kind of linear function 
> of 
> the corresponding degree of freedom on the other end. deal.II has 
> functions 
> for this kind of thing that you could base an implementation for your 
> cases on.
>
> If the meshes don't match, e.g., if you want to glue one end piece to the 
> side 
> of your tube, then the situation becomes more complicated and the usual 
> approach to this is to use "mortar elements" or (what we used to call) a 
> master-slave approach where in essence the displacement on one side is 
> "projected" onto the displacements of the other side. That, too, can be 
> done 
> in deal.II (and has been done), but it is substantially more complicated 
> because you have to solve a geometry problem where you ask which point on 
> one 
> surface a node on the other surface corresponds to.
>
> 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/58c49192-5bef-4611-bd95-b27945f16e42n%40googlegroups.com.