Re: [deal.II] Re: Some changes in arpack.h (Functionality to compute only eigenvalues)

[Animesh Rastogi IIT Gandhinagar]

Hi Bruno,


It's not in deal.II. Anasazi is part of Trilinos. If you are using 

> Trilinos vector, it's pretty straightforward. You just copy the code 
> from 
> https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/anasazi.templates.hpp
>  
> The solver is used here: 
>
> https://github.com/ORNL-CEES/mfmg/blob/4026049f0d5e3904562e394954f76cd86aac2ef3/include/mfmg/dealii/amge_host.templates.hpp#L209-L275


Response - I am not using Trilinos vectors. I am using normal BlockVectors 
and BlockSparseMatrix from dealii Linear Algebra class. Is it possible for 
me to convert my BlockVectors and BlockSparseMatrix to the one from 
Trilinos::BlockSparseMatrix and  Trilinos::BlockVectors? 

>
> If you want to use a different kind of vectors, drop these files in 
> your code 
> https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/multivector.hpp,
>  
>
>
> https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/anasazi_traits.hpp,
>  
>
> and 
> https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/belos_traits.hpp.
>  
>
>

Response - I could not understand when you suggest to drop these files in 
my code. Do I need to download these files in my project folder and then 
include these files as header files?  

You will need to remove the ASSERT, if you don't want to pull more 
> files.

 
Response - Could you please let me know which "ASSERT" do you suggest to 
remove? Also, what exactly is meant by "don't want to pull more". I did not 
understand this part as well. Apologies for too many questions!

Thanks a lot!

Animesh

-- 
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/09c8195c-0abb-46ee-bd5d-b69e2eef64dfn%40googlegroups.com.

[deal.II] Unable to run 'make test'

[Romin Chittettu]

Hi all,
I am new to deal.ii and have tried my best to get a solution to this error. 
Couldnt find any. Hope someone could help me out. The installation was done 
following the steps mentioned on the website. on an Ubuntu environment 
the previous steps of installation work perfectly fine. I get an error in 
'make test' which is as follows:



[100%] Running quicktests...
Test project /home/romin/dealii-9.2.0/build/tests/quick_tests
Start 6: gmsh.debug
Start 1: step.debug
Start 2: step.release
Start 3: affinity.debug
1/6 Test #3: affinity.debug ...   Passed1.06 sec
Start 4: tbb.debug
2/6 Test #2: step.release .   Passed1.21 sec
Start 5: boost_zlib.debug
3/6 Test #6: gmsh.debug ...***Failed1.34 sec
make[7]: *** 
[tests/quick_tests/CMakeFiles/gmsh.debug.run.dir/build.make:76: 
tests/quick_tests/CMakeFiles/gmsh.debug.run] Error 1
make[6]: *** [CMakeFiles/Makefile2:5883: 
tests/quick_tests/CMakeFiles/gmsh.debug.run.dir/all] Error 2
make[5]: *** [CMakeFiles/Makefile2:5890: 
tests/quick_tests/CMakeFiles/gmsh.debug.run.dir/rule] Error 2
make[4]: *** [Makefile:2393: gmsh.debug.run] Error 2
Test gmsh.debug: RUN
===   OUTPUT BEGIN  
===
[  0%] Built target kill-gmsh.debug-OK
[  0%] Built target obj_sundials_inst
[  0%] Built target obj_sundials_debug
[  5%] Built target obj_tbb_debug
[  7%] Built target obj_muparser_debug
[ 13%] Built target expand_instantiations_exe
[ 21%] Built target obj_numerics_inst
[ 28%] Built target obj_numerics_debug
[ 36%] Built target obj_fe_inst
[ 55%] Built target obj_fe_debug
[ 57%] Built target obj_dofs_inst
[ 69%] Built target obj_dofs_debug
[ 71%] Built target obj_lac_inst
[ 78%] Built target obj_lac_debug
[ 82%] Built target obj_base_inst
[103%] Built target obj_base_debug
[103%] Built target obj_gmsh_inst
[103%] Built target obj_gmsh_debug
[107%] Built target obj_grid_inst
[123%] Built target obj_grid_debug
[125%] Built target obj_hp_inst
[125%] Built target obj_hp_debug
[125%] Built target obj_multigrid_inst
[130%] Built target obj_multigrid_debug
[132%] Built target obj_distributed_inst
[136%] Built target obj_distributed_debug
[136%] Built target obj_algorithms_inst
[138%] Built target obj_algorithms_debug
[138%] Built target obj_matrix_free_inst
[140%] Built target obj_matrix_free_debug
[142%] Built target obj_meshworker_inst
[142%] Built target obj_meshworker_debug
[142%] Built target obj_opencascade_inst
[142%] Built target obj_opencascade_debug
[144%] Built target obj_particle_inst
[146%] Built target obj_particle_debug
[148%] Built target obj_differentiation_ad_inst
[150%] Built target obj_differentiation_ad_debug
[153%] Built target obj_differentiation_sd_inst
[153%] Built target obj_differentiation_sd_debug
[153%] Built target obj_physics_inst
[155%] Built target obj_physics_debug
[155%] Built target obj_physics_elasticity_inst
[157%] Built target obj_physics_elasticity_debug
[157%] Built target obj_non_matching_inst
[157%] Built target obj_non_matching_debug
[159%] Built target deal_II.g
[161%] Built target gmsh.debug
gmsh.debug: RUN failed. Output:


An error occurred in line <54> of file 
 in function
int main()
The violated condition was: 
ierr == 0
Additional information: 
This exception -- which is used in many places in the library -- 
usually indicates that some condition which the author of the code thought 
must be satisfied at a certain point in an algorithm, is not fulfilled. An 
example would be that the first part of an algorithm sorts elements of an 
array in ascending order, and a second part of the algorithm later 
encounters an element that is not larger than the previous one.

There is usually not very much you can do if you encounter such an 
exception since it indicates an error in deal.II, not in your own program. 
Try to come up with the smallest possible program that still demonstrates 
the error and contact the deal.II mailing lists with it to obtain help.

Stacktrace:
---
#0  /home/romin/dealii-9.2.0/build/tests/quick_tests/gmsh.debug: main


Aborted (core dumped)


gmsh.debug: **RUN failed***

===OUTPUT END   
===
Expected stage PASSED - aborting
CMake Error at /home/romin/dealii-9.2.0/cmake/scripts/run_test.cmake:140 
(MESSAGE):
  *** abort



4/6 Test #4: tbb.debug    Passed1.01 sec
5/6 Test #5: boost_zlib.debug .   Passed0.89 sec
6/6 Test #1: step.debug ...   Passed3.98 sec

83% tests passed, 1 tests failed out of 6

Total Test time (real) =   3.98 sec

The following tests FAILED:
  6 - gmsh.debug (Failed)
Errors while running CTest

***
**

[deal.II] Modifying shape function data in MatrixFree

['David' via deal.II User Group]

Hi all,

I'm currently trying to implement a vectorized variant of the residual 
assembly as it is done in step-44/one of the corresponding code-gallery 
examples using FEEvaluation objects in combination with matrix-free. 

I was not able to find an appropriate solution for the given code line 
and
 
the subsequent application for the assembly process: the major problem is 
that the shape function gradients are defined with regard to the current 
configuration, whereas my matrix-free object holds a mapping, which refers 
to the initial configuration. The reference configuration mapping  of my 
matrix-free object is desired as the final integration is actually 
performed in the reference frame.
A valid option is probably (I have not tried it) to use a matrix-free 
object with a different mapping (MappingQEulerian) which directly evaluates 
the shape gradients in the deformed configuration and use another 
referential matrix-free object for the integration part. 
The main reason to avoid this approach is that it would require a 
reinitialization of the 'deformed' matrix-free object in each nonlinear 
step and the mapping needs to be recomputed in each reinizialization. On 
the other hand, the expensive reinitialization is not really required as 
the mapping between the referential and the current configuration is known 
due to the (inverse) deformation gradient. 
Therefore, I'm looking for an opportunity to access the shape gradients and 
perform a push forward similarly to the approach in step-44 in order to 
evaluate the desired quantities. 

Until now I was not able to find an obvious solution for this computations 
using the FEEvaluation class. Maybe anyone else has a better idea for the 
described problem.

Thanks in advance,
David

-- 
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/34669b15-4c36-410c-9665-071b7bbe2c44n%40googlegroups.com.

[deal.II] Re: Modifying shape function data in MatrixFree

['David' via deal.II User Group]

Maybe as an edit: what I currently do looks the following way:

```
// Get gradient in reference frame
const Tensor<2, dim, VectorizedArrayType> grad_u = phi.get_gradient(q_point
); 
// Compute deformation gradient
const Tensor<2, dim, VectorizedArrayType> F = Physics::Elasticity::
Kinematics::F(grad_u); 
const SymmetricTensor<2, dim, VectorizedArrayType> b = Physics::Elasticity::
Kinematics::b(F); 

const VectorizedArrayType det_F = determinant(F); 
// Invert F
const Tensor<2, dim, VectorizedArrayType> F_inv = invert(F); 
const SymmetricTensor<2, dim, VectorizedArrayType> b_bar = Physics::
Elasticity::Kinematics::b( Physics::Elasticity::Kinematics::F_iso(F)); 
// Get tau from material description 
SymmetricTensor<2, dim, VectorizedArrayType> tau; material->get_tau(tau, 
det_F, b_bar, b);

// Gradient itslef is included in the integrate call, apply push forward 
with F^{-1}
const Tensor<2, dim, VectorizedArrayType> symm_grad_Nx = symmetrize(F_inv);
// Compute the result
const Tensor<2, dim, VectorizedArrayType> result = symm_grad_Nx * Tensor<2, 
dim, VectorizedArrayType>(tau);
// Apply an additional push forward with F^{-T}
phi.submit_gradient(-result * transpose(F_inv), q_point);  // end loop over 
quadrature points 

// For each element
phi.integrate(false, true); 
```

It works, but I don't get the quadratic convergence order of the Newton 
scheme anymore. Hence, I assume this is not sufficient.
David schrieb am Dienstag, 29. Dezember 2020 um 12:41:35 UTC+1:

>
> Hi all,
>
> I'm currently trying to implement a vectorized variant of the residual 
> assembly as it is done in step-44/one of the corresponding code-gallery 
> examples using FEEvaluation objects in combination with matrix-free. 
>
> I was not able to find an appropriate solution for the given code line 
> and
>  
> the subsequent application for the assembly process: the major problem is 
> that the shape function gradients are defined with regard to the current 
> configuration, whereas my matrix-free object holds a mapping, which refers 
> to the initial configuration. The reference configuration mapping  of my 
> matrix-free object is desired as the final integration is actually 
> performed in the reference frame.
> A valid option is probably (I have not tried it) to use a matrix-free 
> object with a different mapping (MappingQEulerian) which directly evaluates 
> the shape gradients in the deformed configuration and use another 
> referential matrix-free object for the integration part. 
> The main reason to avoid this approach is that it would require a 
> reinitialization of the 'deformed' matrix-free object in each nonlinear 
> step and the mapping needs to be recomputed in each reinizialization. On 
> the other hand, the expensive reinitialization is not really required as 
> the mapping between the referential and the current configuration is known 
> due to the (inverse) deformation gradient. 
> Therefore, I'm looking for an opportunity to access the shape gradients 
> and perform a push forward similarly to the approach in step-44 in order to 
> evaluate the desired quantities. 
>
> Until now I was not able to find an obvious solution for this computations 
> using the FEEvaluation class. Maybe anyone else has a better idea for the 
> described problem.
>
> Thanks in advance,
> David
>

-- 
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/7b3c1488-cf75-4526-8442-d1045dc73398n%40googlegroups.com.

Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing

[Wolfgang Bangerth]

On 12/28/20 5:11 PM, Marc Fehling wrote:


In case a FE_Nothing has been configured to dominate, the solution should be 
continuous on the interface if I understood correctly, i.e., zero on the face. 
I will write a few tests to see if this is actually automatically the case in 
user applications. If so, this check for domination will help other users to 
avoid this pitfall :)




More tests = more better :-)
Cheers
 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/0398a440-3ee2-9642-9c27-c519eb2f12e5%40colostate.edu.

Re: [deal.II] Re: Problem about modifying CMakeList.txt to add library

[Wolfgang Bangerth]

My question is, I want to use the eigenvalue problem solving capability of 
armadillo in my code. However, my matrix type is of BlockSparseMatrix in 
dealii. How do I go about using my BlockSparseMatrix with the available 
armadillo functions that use sp_mat type matrices 
? 
One idea that I thought was to print my block_sparse_matrix using the function 
block_write() 
 
that prints the dealii Sparse_matrix in a binary format. However, I am not 
able to read that file using armadillo's functionality to load binary files 
.


Just write a function that copies the data from one object to another. You can 
iterate over deal.II matrix entries, and then you just need to figure out how 
Armadillo wants its matrices filled.


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/3b64f36b-70fc-762d-e9c2-e5e3c6f28208%40colostate.edu.

Re: [deal.II] Tips and tricks for functional tests on chaotic systems

[blais...@gmail.com]

There is a Facebook deal.II account? Now I know what to follow :)!
Cheers!
Bruno


On Tuesday, December 29, 2020 at 12:20:15 p.m. UTC-5 Wolfgang Bangerth 
wrote:

> On 12/28/20 10:54 PM, blais...@gmail.com wrote:
> > 
> > If you want to see an animation of DEM done using the deal.II particle 
> > library, you can find one on the following youtube link:
> > https://www.youtube.com/watch?v=jPrxQ3KqNcI=youtu.be
>
> Nice -- that just made it to the deal.II Facebook account :-)
>
> Cheers
> 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/7607b1b3-a8f1-48d6-a329-ffb93765f0b7n%40googlegroups.com.

Re: [deal.II] Re: Modifying shape function data in MatrixFree

[Jean-Paul Pelteret]

Hi David,

So as I'm sure that you know, if you want to assemble the linear system 
for quasi-static non-linear (hyper)elasticity with a referential 
DoFHandler (using no Eulerian mapping to transform the shape functions 
to the spatial setting) AND without doing a similar transformation by 
hand (as step-44 does) then you are pretty much limited to using one of 
two parameterisations. Either you have to choose the (two-point) 
Kirchoff stress (P) and deformation gradient (F) as the work conjugate 
pairs, or the (fully-referential) Piola-Kirchhoff stress (S) and the 
Green-Lagrange strain tensor (E = 0.5(C-I) with C being the right 
Cauchy-Green tensor).


Thinking about just the residual term: to the best of my knowledge (and 
from what I recall from the work that we did here 
), the 
variation dC = symm(F^{T}.dF) = symm(F^{T} d(Grad(u))) -- with u 
representing the displacement -- cannot be framed a way that the 
matrix-free framework supports: the test function cannot be 
pre-multiplied by a field variable. One would have to somehow rephrase 
the whole problem such that you end up with just the test function 
d(Grad(u)) as a pre-multiplication to your stress variable, and in the 
end you come up with the exactly the other parameterisation because P = 
F.S and dF = d(I + Grad(u)) == d(Grad(u)). So you may as well start off 
by parameterising the problem in terms of F and P, and naturally you 
have to adjust the linearisation as well. The linearisation of the 
two-point tensor P contains both the material and geometric tangent (you 
can identify each by linearising the decomposition P = F.S to get these 
two quantities). I get the sense from what I seein the code that you've 
shared you're trying to accomplish exactly this (although I'm not sure 
its quite right, since tau = P.F^{T} --> P = tau.F^{-T}, and you seem to 
have some extra manipulation involving what you call symm_grad_Nx -- 
this looks a bit suspect to me).


I have some code to share that will do the transformation from the 
stress and tangent quantities already used in step-44 to those that you 
need for this F-P parameterisation. You can put these in the 
PointHistory class


template
classPointHistory
{ ...
// Fully referential configuration
SymmetricTensor<2, dim>
get_S() const
{
returnPhysics::Transformations::Contravariant::pull_back(get_tau(), F);
}
SymmetricTensor<4, dim>
get_H() const
{
returnPhysics::Transformations::Contravariant::pull_back(get_Jc(), F);
}
// Mixed / two-point configuration
Tensor<2, dim>
get_P() const
{
returnget_F() *Tensor<2, dim>(get_S());
}
Tensor<4, dim>
get_HH() const
{
// Reference: Simo1984a eq 4.4 // Simo, J. C. and Marsden, J. // On the 
rotated stress tensor and the material version of the {Doyle-Ericksen} 
formula // DOI: 10.1007/BF00281556

constSymmetricTensor<2, dim>S =get_S();
constSymmetricTensor<4, dim>H =get_H();
// Push forward index 2 of material stress contribution
// This index operation relies on the symmetry of the
// last two indices, so therefore (in case it makes a
// difference) we transform it first.
Tensor<4, dim>tmp1;
for(unsignedintI =0; I HH_mixed;
constTensor<2, dim>I_ns =Physics::Elasticity::StandardTensors::I;
for(unsignedinti =0; i Naturally, the above could be simplified a bit for this fixed 
parameterisation.


With this, the (matrix-based) assembly would looks something like this 
for the RHS

// Excuse the messiness -- coding in an email client is not a good idea!
for(unsignedintq_point =0; q_point n_q_points; ++q_point) { const 
Tensor<2,dim> P = lqph[q_point]->get_P();

for(unsignedinti =0; i dofs_per_cell; ++i) {
constunsignedinti_group =this->fe.system_to_base_index(i).first.first; 
const Tensor<2,dim> dF_I = fe_values_ref[this->u_fe].gradient(i, q_point);

if(i_group ==this->u_dof)
data.cell_rhs(i) -=double_contract(dF_I, P) *JxW;
... // See the rest of step-44

and the salient part of the tangent matrix assembly would be something like
for(unsignedintq_point =0; q_point n_q_points; ++q_point) {// 
Linearisation of P with respect to F; // contains both material and 
geometric tangent contributions  const Tensor<4,dim> HH = 
lqph[q_point]->get_HH();

for(unsignedinti =0; i dofs_per_cell; ++i) {
constunsignedinti_group = 
this->fe.system_to_base_index(i).first.first;const Tensor<2,dim> dF_I = 
fe_values_ref[this->u_fe].gradient(i, q_point);

for(unsignedintj =0; j <=i; ++j)
{
constunsignedintj_group = this->fe.system_to_base_index(j).first.first;
const Tensor<2,dim> dF_J = fe_values_ref[this->u_fe].gradient(j, q_point);

if((i_group ==j_group) &&(i_group ==this->u_dof))
{
cell_matrix(i, j) +=scalar_product(dF_I, HH,dF_J)*JxW; } ... // See the 
rest of step-44


So IIRC the call to phi.submit_gradient() that is bound to the 
undeformed/non-mapped DoFHandler is effectively the same as testing 
against what I've called dF_I in the above code. I think that the 
transformations from tau->P and Jc->HH should make it 

Re: [deal.II] Tips and tricks for functional tests on chaotic systems

[Wolfgang Bangerth]

On 12/28/20 10:54 PM, blais...@gmail.com wrote:


If you want to see an animation of DEM done using the deal.II particle 
library, you can find one on the following youtube link:

https://www.youtube.com/watch?v=jPrxQ3KqNcI=youtu.be


Nice -- that just made it to the deal.II Facebook account :-)

Cheers
 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/b6e4a73a-9af9-6ea4-ca9d-471d559fd86b%40colostate.edu.

Re: [deal.II] Quasi Static Compressible Finit Strain for Heterogenous Hyperelastic material

[Jean-Paul Pelteret]

HI Animesh,

You forgot to show the most critical part of the error report in your 
post: The actual source line that's causing the problem! Thankfully it 
was included in the error log that you uploaded.


In file included from 
/home/animesh/Documents/dealii/dealii-9.2.0/examples/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:73:0:
/usr/local/include/deal.II/physics/elasticity/kinematics.h: In 
instantiation of ‘dealii::Tensor<2, dim, Number> 
dealii::Physics::Elasticity::Kinematics::F_iso(const dealii::Tensor<2, 
dim, Number>&) [with int dim = 2; Number = 
Sacado::Fad::Exp::GeneralFaddouble> >]’:
/home/animesh/Documents/dealii/dealii-9.2.0/examples/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:1861:90: 
required from ‘void Cook_Membrane::AssemblerSacado::Fad::Exp::GeneralFaddouble> > >::assemble_system_tangent_residual_one_cell(const typename 
dealii::DoFHandler::active_cell_iterator&, typename 
Cook_Membrane::Assembler_BaseSacado::Fad::Exp::GeneralFaddouble> > >::ScratchData_ASM&, typename 
Cook_Membrane::Assembler_BaseSacado::Fad::Exp::GeneralFaddouble> > >::PerTaskData_ASM&) [with int dim = 2; typename 
dealii::DoFHandler::active_cell_iterator = 
dealii::TriaActiveIterator2>, false> >; typename Cook_Membrane::Assembler_BaseSacado::Fad::Exp::GeneralFaddouble> > >::ScratchData_ASM = Cook_Membrane::Assembler_Base<2, 
Sacado::Fad::Exp::GeneralFaddouble> > >::ScratchData_ASM; typename 
Cook_Membrane::Assembler_BaseSacado::Fad::Exp::GeneralFaddouble> > >::PerTaskData_ASM = Cook_Membrane::Assembler_Base<2, 
Sacado::Fad::Exp::GeneralFaddouble> > >::PerTaskData_ASM]’
/home/animesh/Documents/dealii/dealii-9.2.0/examples/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:2325:1: 
required from here
/usr/local/include/deal.II/physics/elasticity/kinematics.h:294:47: 
error: no match for ‘operator*’ (operand types are 
‘Sacado::Fad::Exp::PowerOpdouble> >, double, false, true, Sacado::Fad::Exp::ExprSpecDefault, 
Sacado::Fad::Exp::PowerImpl::Scalar>’ and ‘const dealii::Tensor<2, 2, 
Sacado::Fad::Exp::GeneralFaddouble> > >’)

   return std::pow(determinant(F), -1.0 / dim) * F;
  ~^~~

What's going on here is that Sacado's implementation of the pow() 
function returns a specialised number type that deal.II doesn't 
recognise (this Sacado number type uses expression templates, which 
means that every operation returns a specialised type, and not the 
original AD number type). I guess that we could try to detect this and 
implement support in the operator* for Tensors and SymmetricTensors (and 
probably in other places in the library), but this would only be 
possible if Sacado has some type traits to help us filter out which of 
these special numbers are indeed Sacado types. I'm pretty sure that they 
do have such traits, but its been some time since we implemented this so 
I cannot remember for certain.


For now,the simple solution would be to cast the LHS value to a Sacado 
type. like this:


return SacadoNumberType(std::pow(determinant(F), -1.0 / dim)) * F;

where SacadoNumberType is some type definition for the Sacado type that 
you're using. We certainly have support for premultiplication of a 
Tensor by another SacadoNumberType.


I hope that this fixes the issue for you.

Best,
Jean-Paul

On 29.12.20 12:55, Animesh Rastogi IIT Gandhinagar wrote:

Hi Jean-Paul,

I have reconfigured and reinstalled dealii with Trilinos so that I can 
use the eigenvalue functionality from Trilinos.


When I am running the Quasi_Static_compressibility (cook_membrane) 
code from the code gallery, I am getting the following error. I did 
not face this issue when my dealii was not compiled with Trilinos.


/home/animesh/Documents/dealii/dealii-9.2.0/examples/Quasi_static_Finite_strain_Compressible_Elasticity/cook_membrane.cc:2325:1: 
required from here
/home/animesh/share/trilinos/include/Sacado_Fad_Exp_Ops.hpp:775:1: 
*error*: no type named ‘type’ in ‘struct 
Sacado::mpl::enable_if_cSacado::Fad::Exp::MultiplicationOpdouble> >, double, false, true, Sacado::Fad::Exp::ExprSpecDefault, 
Sacado::Fad::Exp::PowerImpl::Scalar>, dealii::Tensor<2, 2, 
Sacado::Fad::Exp::GeneralFaddouble> > >, false, false, Sacado::Fad::Exp::ExprSpecDefault> >’
CMakeFiles/cook_membrane.dir/build.make:62: recipe for target 
'CMakeFiles/cook_membrane.dir/cook_membrane.cc.o' failed

make[3]: *** [CMakeFiles/cook_membrane.dir/cook_membrane.cc.o] Error 1
CMakeFiles/Makefile2:195: recipe for target 
'CMakeFiles/cook_membrane.dir/all' failed

make[2]: *** [CMakeFiles/cook_membrane.dir/all] Error 2
CMakeFiles/Makefile2:138: recipe for target 'CMakeFiles/run.dir/rule' 
failed

make[1]: *** [CMakeFiles/run.dir/rule] Error 2
Makefile:144: recipe for target 'run' failed
make: *** [run] Error 2


Could you please let me know how to get rid of this issue?

I am attaching the full command line output when I ran the 
cook_membrane's program and cmake command used to build 

Re: [deal.II] Using Dealii to developing aa finite element software on Windows

[Wolfgang Bangerth]

On 12/29/20 2:54 PM, amir kiani wrote:
We tried updating our compilers. But a lot of errors were reported during the 
compilation of our software.


That is maybe not a useful answer for you, but at some point you will have to 
update your OS and compilers -- Microsoft will simply not support your current 
versions any more after some point. In other words, sticking with the versions 
you currently have is not avoiding work for you, but just postponing it. If 
you get error with your software and newer compilers, it may be useful to just 
spend the day or two and address them by making your code base compatible with 
newer compilers -- it's going to make your code base more portable to other 
compilers as well.


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/4b2424f1-ba8e-ff75-c425-0394b1af9103%40colostate.edu.

Re: [deal.II] Div-conforming elements in 3D

[Konrad Simon]

Dear Jean-Paul,

Many thanks for your reply.

On Tuesday, December 29, 2020 at 9:31:49 PM UTC+1 Jean-Paul Pelteret wrote:

> Hi Konrad,
>
> I'm sorry for taking some time to reply. To be honest, the inner working 
> of the FE classes is not something that I've ever had the time or 
> opportunity to dig into, so I'm really not well positioned to answer many 
> of your questions. I'm glad that you've submitted a PR for the work that 
> you've done thus far, and I hope that you can be guided by someone who has 
> more familiarity with this part of the library.
>
 
It will be my pleasure if other people will be able to benefit from 
implementations that I had to add and to contribute it as well as I 
benefited from other peoples‘ work. Let‘s hope that the stuff I asked to 
add makes sense. 
 

>
> What I can say, though, is that the various FE classes have been 
> implemented by numerous people over time, and the logic that dictates the 
> way that the DoFs are assigned varies between each FE. We have always 
> considered this to be perfectly fine -- this is, to the average person, an 
> implementational detail, and the interface that we have to interrogate DoFs 
> (e.g. which vector component they're associated with, whether or not they 
> have support points, etc...) seems to be sufficiently rich to most users. 
> So, as the end user, you shouldn't be writing code that would care that the 
> FE_Q element orders DoFs like this: [N_{0,x} N_{0,y} N_{0,z} N_{1,x} ...] ; 
> while IIRC the FE_DGQ element orders DoFs like this: [N_{0,x} N_{1,x} 
> N_{2,x} ... N_{0,y} N_{1,y} ...] .
>
> So, returning to your original set of questions: In general, I don't 
> believe that it can be assumed that all cell vertex DoFs are enumerated 
> before line/edges DoFs, before face DoFs, before cell interior DoFs. 
> Through the FiniteElementData class, the FiniteElement base class seems to 
> have a set of n_dofs_per_[vertex,line,face,cell]_dofs() 
> 
>  
> and get_first_[line/quad/hex]_index() 
> 
>  
> functions, which does suggest that I'm wrong about this, so I'd be happy to 
> be corrected on this point.  (Question: What does a vertex/edge/face DoF 
> even mean for a DG element?) Maybe these are the exact functions that you 
> were looking for (and maybe with this , if the [vertex,edge,face,cell] 
> groupings do apply, you can map from the cell DoF->associated geometric 
> entity using these functions). But I don't that they would help 
> understanding the ordering (e.g. lexiographic or something else; element 
> base index fast or spacedim fast, etc.) within each grouping -- again, 
> that's probably a decision that was left to the designer of each FE class, 
> and I don't think that there's been a need for any consistency between the 
> classes. But again, I'm just putting my thoughts out there and anticipate 
> being corrected on these points.
>

In my humble opinion the FE should only be implemented in terms of a 
reference element. This is, as far as I can tell, the case for all elements 
in Deal.II. The mapping though is problematic on complicated domains and I 
saw that one needs to renumber or switch signs for some shape functions if 
one wants to satisfy continuity conditions for the respective spaces. This 
is partly taken care of by the DoFHandler (see renumbering of FE_Q on 
faces) class which confused me, while other parts like the sign change is 
not. I guess I got the idea. Also, the concept of (generalized) support 
points is nice but sometimes it is not really clear to me if this is 
helpful in the context of element pairings (for example in the language of 
finite element exterior calculus where this concept does not really make 
sense globally). I may be wrong and miss a point here  and would love to 
get a lesson.
 

>
> I get the feeling that there is no overlap in assignment of DoFs between 
> geometric entities. Consider each of these entities not to have closure: so 
> you're actually referring to DoFs associated with the cell interior (excl. 
> faces, edges and vertices), face interior (excl edges and vertices) and 
> edge interiors (excl. vertices). To me, that the only sensible 
> interpretation of this. 
>
 
This is partly what is not fully clear to me. Vertex/edge/face/volume dofs 
(again FEEC) depends on the functionals that define them and less on 
location (a Raviart-Thomas or Nedelec shape function is not regular enough 
for point evaluations, although viewing them as a polynomial suggests so). 


> Thanks for giving this so much thought, and for the interesting questions. 
> I've certainly got a lot to learn from the responses that may come from the 
> other developers.
>
 
As I said, I hope other people can benefit from that but I am not super 
familiar with this part of the 

Re: [deal.II] Using Dealii to developing aa finite element software on Windows

[amir kiani]

Thanks dear Wolfgang
The features of Deall.ii is very good.
I will try to use these wonderfull features.
You and your colleagues did a great job. I wish best for you.

On Mon, Dec 28, 2020, 22:38 Wolfgang Bangerth 
wrote:

> On 12/26/20 10:08 PM, amir kiani wrote:
> > By reading tutorials on the website of Deal.ii, I realized that using
> > Deal.ii directly on windows is experimentally supported.
>
> That may no longer be an accurate description. deal.II 9.2 is used in a
> number
> of industrial applications that run on Windows. It definitely works on
> Windows.
>
> 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/75e252ef-0e7e-c5dc-6703-57cc514ee84c%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/CALNzT0d%2BU8DgVEaWWrN4cXAhV-Viua2VWfeZZUmapAetZ-FqWg%40mail.gmail.com.

Re: [deal.II] Using Dealii to developing aa finite element software on Windows

[amir kiani]

Dear Timo
I appreciate your answer.
We tried updating our compilers. But a lot of errors were reported during
the compilation of our software.


On Mon, Dec 28, 2020, 20:05 Timo Heister  wrote:

> Hi Amir,
>
> deal.II 9.1 requires c++11
> deal.II 9.2 requires c++11
> deal.II 9.3 will require c++14
>
> Your only choice would be to use an older version of deal.II but I
> would strongly suggest updating your compilers instead.
>
> On Sun, Dec 27, 2020 at 12:09 AM amir kiani 
> wrote:
> >
> > Hello.
> > Recently I started to learn finite element programming.
> > By surfing the net, I came to C++ and Deal.ii.
> > One of my concerns in using Deal.ii and C++ is about any possible future
> limitations.
> > By reading tutorials on the website of Deal.ii, I realized that using
> Deal.ii directly on windows is experimentally supported.
> > Now my main question:
> > As presented on the Deal.ii Website, If I build Deal.ii via each
> approach (and in any operating system like Linux), Can I use classes and
> libraries of Deal.ii in other C++ programs? Consider I want to use Deal.ii
> features in C++03 with Visual Studio 2008 on Windows 7.
> > Because I am working on developing an existing software, I am restricted
> to use this standard of C++ and this version of Visual Studio.
> > I appreciate all answers in advance
> >
> > --
> > 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/a4df4788-b1c4-44e6-97c1-b06b6912554dn%40googlegroups.com
> .
>
>
>
> --
> Timo Heister
> http://www.math.clemson.edu/~heister/
>
> --
> 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/CAMRj59H%2B8vXqn0WJb4aAQ_MyfWkfAz7CogB9kp55pycfe6vfgg%40mail.gmail.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/CALNzT0coBMX0fHN36YmFGQeG%2B5HnOX3rYPXkxwW89BN3gOkcpg%40mail.gmail.com.

Re: [deal.II] Div-conforming elements in 3D

[Jean-Paul Pelteret]

Hi Konrad,

I'm sorry for taking some time to reply. To be honest, the inner working 
of the FE classes is not something that I've ever had the time or 
opportunity to dig into, so I'm really not well positioned to answer 
many of your questions. I'm glad that you've submitted a PR for the work 
that you've done thus far, and I hope that you can be guided by someone 
who has more familiarity with this part of the library.


What I can say, though, is that the various FE classes have been 
implemented by numerous people over time, and the logic that dictates 
the way that the DoFs are assigned varies between each FE. We have 
always considered this to be perfectly fine -- this is, to the average 
person, an implementational detail, and the interface that we have to 
interrogate DoFs (e.g. which vector component they're associated with, 
whether or not they have support points, etc...) seems to be 
sufficiently rich to most users. So, as the end user, you shouldn't be 
writing code that would care that the FE_Q element orders DoFs like 
this: [N_{0,x} N_{0,y} N_{0,z} N_{1,x} ...] ; while IIRC the FE_DGQ 
element orders DoFs like this: [N_{0,x} N_{1,x} N_{2,x} ... N_{0,y} 
N_{1,y} ...] .


So, returning to your original set of questions: In general, I don't 
believe that it can be assumed that all cell vertex DoFs are enumerated 
before line/edges DoFs, before face DoFs, before cell interior DoFs. 
Through the FiniteElementData class, the FiniteElement base class seems 
to have a set of n_dofs_per_[vertex,line,face,cell]_dofs() 
 
and get_first_[line/quad/hex]_index() 
 
functions, which does suggest that I'm wrong about this, so I'd be happy 
to be corrected on this point.  (Question: What does a vertex/edge/face 
DoF even mean for a DG element?) Maybe these are the exact functions 
that you were looking for (and maybe with this , if the 
[vertex,edge,face,cell] groupings do apply, you can map from the cell 
DoF->associated geometric entity using these functions). But I don't 
that they would help understanding the ordering (e.g. lexiographic or 
something else; element base index fast or spacedim fast, etc.) within 
each grouping -- again, that's probably a decision that was left to the 
designer of each FE class, and I don't think that there's been a need 
for any consistency between the classes. But again, I'm just putting my 
thoughts out there and anticipate being corrected on these points.


I get the feeling that there is no overlap in assignment of DoFs between 
geometric entities. Consider each of these entities not to have closure: 
so you're actually referring to DoFs associated with the cell interior 
(excl. faces, edges and vertices), face interior (excl edges and 
vertices) and edge interiors (excl. vertices). To me, that the only 
sensible interpretation of this.


Thanks for giving this so much thought, and for the interesting 
questions. I've certainly got a lot to learn from the responses that may 
come from the other developers.


Best,
Jean-Paul


On 18.12.20 20:50, Konrad Simon wrote:

Dear Deal.II community,

Suppose I chose FE_Nedelec<3> of some order as finite element.

1. Is there a way to query for a given cell_dof_index 
whether it is a face_dof and to get the face_index?


2. If this dof is a line_dof is it by definition also a 
face_dof? I need to exclude line_dofs and treat them 
separately.


3. Is there a convention that (if I am not using FESystem) in the set 
of all cell_dofs all line_dofs come before 
all face_dofs and only then the volume_dofs?


I am asking since I am trying to come up with a patch for 
RaviartThomas and a pattern to implement it in the current structures 
without interfering with them (too much).


Best,
Konrad
On Wednesday, December 16, 2020 at 9:33:57 PM UTC+1 Konrad Simon wrote:

Dear Jean-Paul, dear Deal.II community,

I partially solved the problem of sign flipping and permuting the
degrees of freedom and would like to come up with a merge-request
at least for the RaviartThomas elements. I have some questions
before I can go on and guidance would be appreciated.

I decided to go a similar way that is taken for FE_Q elements.
There one has only a permutation of dofs on non-standard or
flipped or rotated faces since a sign change in the orientation
does not matter. A vector of size n_faces_per_cell of which each
contains a table mapping each face_dof and each of the 8
combinations of the flags (non-standard | flipped | rotated) to an
offset of that face_dof. The system behind that relies on the
lexicographic ordering of dofs if I understand correctly. My
questions:

1. Is there a similar numbering scheme for dofs on faces for RT
elements. There one has face moments as dofs